Re: [Omaha.pm] [olug] Yesterday's dd-wrt release fixes vulnerability

[Rob Townley <rob.townley@gmail.com>]

On Wed, Jul 22, 2009 at 8:10 PM, Chad Homan<choman@gmail.com> wrote:
> I've dug into this a little but. The bug exist in the v24 sp1 firmware.
> I personally have been running the June 19 pre-sp2 release which also has
> the bug.
>
> If your running anything prior to v24 sp1, you can run the test rob privided
>
> and verify that the bug effects you
>
> There are two fixes posted currently, both available on the dd-wrt home
> page.
> Note that the suggested firmware fix is temporary until the router DB is
> updated.
> well according to the website
>
> Chad, CISSP
>
>
>
> On Wed, Jul 22, 2009 at 6:54 PM, Cheyenne Deal <deal.cheyenne@gmail.com>wrote:
>
>> When did the problem start, I have a 04/07 release 07 as in 2007
>>
>> -----Original Message-----
>> From: Rob Townley <rob.townley@gmail.com>
>> Sent: Wednesday, July 22, 2009 6:31 PM
>> To: Omaha Linux User Group <olug@olug.org>
>> Subject: [olug] Yesterday's dd-wrt release fixes vulnerability
>>
>> If you have dd-wrt firmware, you will want to update.  There is a
>> vulnerability in it that malicious website code could get root just by
>> visiting that malicious website from behind your dd-wrt firewall, CSRF
>> style.
>>
>> Test:    http://192.168.1.1/cgi-bin/;reboot
>> _______________________________________________
>> OLUG mailing list
>> OLUG@olug.org
>> https://lists.olug.org/mailman/listinfo/olug
>>
>> _______________________________________________
>> OLUG mailing list
>> OLUG@olug.org
>> https://lists.olug.org/mailman/listinfo/olug
>>
> _______________________________________________
> OLUG mailing list
> OLUG@olug.org
> https://lists.olug.org/mailman/listinfo/olug
>

Cross Site Request Forgery highlights a much broader security problem
for just about anything that has a web based interface - printers,
cameras, firewalls, switches, webmin, nagios, CUPS, web based address
books, web based email and .  i am going to pick on webmin to remind
professionals that this type of attack applies to you even if you do
not use dd-wrt.   CSRF / XSRF allows malicious code on an internet
website to call code on a private only webmin interface.  Since google
and HoneyNET project research suggest there could be millions of
websites hacked, we really can't trust any website.  What frustrates
me is having webmin type browser sessions only accessible via https
can actually make the problem worse.

For the web developers out there such as the developers of the IE6
only Cisco SRW2048 and a local Omahan that commented that he will
never develop web apps for Safari again because there is no need, test
your code in multiple browsers because users need to easily be able to
use one brand of browser for web based administration and another
brand for browsing the web and yet another brand for web based email,
calendering, and contacts.   Yes, the alternative is to have multiple
user profiles for the same browser, but that does not always work for
me.

If you use dd-wrt, check back often to see if there are updates.
After using soho firewalls for more than a decade, dd-wrt is still
safer than most any other i have used.  The open-wrt ssh base was not
at fault here, it was the more closed web based interface.


Below is gat3way's dd-wrt  forum posting used for reference:
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=55173
	
Posted: Fri Jul 24, 2009 7:48 am
The patch makes that exploit impossible to succeed even though it does
not thoroughly mitigate the CSRF attack vectors. That because now:

1) you have to be already authorized (before the fix it was possible
to execute commands via /cgi-bin without authorization)
2) the CSRF attack has to come from a https site, otherwise a referer
header is sent, it's checked against the httpd server hostname and
since it won't match, the request will be rejected.

OTOH, older POST-based CSRF could work if the attack comes from a
https site AND if you have already authorized at the web ui.

In other words, preventing CSRF attacks now will be easy if users just
follow a simple rule: when you login at the web management ui, do your
job, DO NOT browse other sites in other tabs (actually, closing all
tabs except the dd-wrt one is best), then log-out from the dd-wrt web
ui and continue browsing other sites. This way, you can be almost sure
no CSRF attack will be possible.