[olug] Yesterday's dd-wrt release fixes vulnerability

[Rob Townley]

On Fri, Jul 24, 2009 at 4:37 PM, Rob Townley<rob.townley at gmail.com> wrote:
> On Wed, Jul 22, 2009 at 8:10 PM, Chad Homan<choman at 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 at 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 at gmail.com>
>>> Sent: Wednesday, July 22, 2009 6:31 PM
>>> To: Omaha Linux User Group <olug at 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 at olug.org
>>> https://lists.olug.org/mailman/listinfo/olug
>>>
>>> _______________________________________________
>>> OLUG mailing list
>>> OLUG at olug.org
>>> https://lists.olug.org/mailman/listinfo/olug
>>>
>> _______________________________________________
>> OLUG mailing list
>> OLUG at 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.
>

*FireGPG and many other extensions are convenient, but would not be
surprised if some are an extremely bad idea - not up on them at the
moment.  Other extensions provide some protection from Cross Site
Scripting (XSS) - NoScript and  CSRF Protector and are required.

*web2.0collage.com could probably find your internal websites.