DD-WRT Root exploit posted today

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3 ... 11, 12, 13, 14, 15  Next
Author Message
phuzi0n
DD-WRT Guru


Joined: 10 Oct 2006
Posts: 10143

PostPosted: Fri Jul 24, 2009 4:09    Post subject: Reply with quote
VValdo wrote:
Posting "clear examples" of exploits allows for a public discussion where the eyeballs of knowledgeable experts here on this forum can discuss whether or not the patch is sufficient to fix the problem. In this case, Gat3way is suggesting it doesn't completely do so.


A clear example was already included in the initial disclosure. The new one was just a link that will work via CSRF without a blackslash, something that has never been denied as a possibility of the vulnerability. Exposing it here just allows for anyone to throw it in an img tag with no knowledge of shell scripting and get a shell as root.

Nobody is trying to cover up the existence of this vulnerability or sweep it under the rug, NewMedia-NET GmbH has handled it fairly well IMO. I personally think sidewaysstarion deserves more credit for bringing it to everyone's attention while gat3way posted it to a 0day exploit site. Note that there's a drastic difference between posting a vulnerability versus posting an exploit.

_________________
Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Sponsor
VValdo
DD-WRT Novice


Joined: 13 Apr 2009
Posts: 24

PostPosted: Fri Jul 24, 2009 5:47    Post subject: Reply with quote
Here's my suggestion for clarification on the front page. I would of course add tons of links to the new firmware, wikipedia article to CSRF, wiki page for this vulnerability, the forum, this thread, etc.

This is for discussion purposes. I invite comment/corrections.

W

--------------------------

23-07-09

Updated Vulnerability Report

What is the vulnerability?

On 20-7-09, user “gat3way” at milw0rm.com reported a serious vulnerability whereby a remote user could gain full (root) access to the router via DD-WRT's web administration interface, also called the “Control Panel”.

DD-WRT's default behavior is to limit web interface access to the Local Area Network (LAN). However, using an attack called a Cross-Site Request Forgery (CSRF), a specially-crafted Web page located on the Wide Area Network (WAN) could also trigger the exploit when accessed from a browser inside the LAN.

Who does this affect?

This problem affects ALL versions of DD-WRT prior to build 12533, which was released on the 21st of July, 2009. Due to the severity of this exploit, all users of DD-WRT are encouraged to immediately update to build 12533 or later.

How do I know if I'm vulnerable?

You can verify that you are vulnerable by loading the following test URL from your browser:

http://YOUR_ROUTER_IP/cgi-bin/;reboot

Replace “YOUR_ROUTER_IP” above with the IP address for the router. By default, DD-WRT uses a LAN-side IP address of 192.168.1.1

If your browser subsequently reboots, you are vulnerable.

If you have enabled https web access in addition to (or rather than) the default httpd, you can try:

https://YOUR_ROUTER_IP/cgi-bin/;reboot

If you have enabled Remote Access (ie, WAN/Internet access) to the Web administration interface, you can try using your router's IP address on the WAN side. The WAN IP address is available via the Status->WAN menu in your administration Web Interface. (You may also learn this information by visiting whatismyip.com)

What if I can't update my firmware right now?

If you are unable to update your DD-WRT firmware, a temporary workaround is available using a firewall rule.

NOTE: To use this workaround, you must first disable HTTPS requests if it is enabled. To disable HTTPS requests, use DD-WRT's Web Interface. Under Administration > Management > Remote Access, make sure that HTTPS is unchecked. Then select “Apply Settings” at the bottom.

To enable the firewall rule from the web interface, go to Administration > Commands and enter the following:

Code:
insmod ipt_webstr
ln -s /dev/null /tmp/exec.tmp
iptables -D INPUT -p tcp -m tcp -m webstr --url cgi-bin -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -m tcp -m webstr --url cgi-bin -j REJECT --reject-with tcp-reset

Then choose Save Firewall and reboot your router. This rule blocks any attempt to access the Control Panel that has "cgi-bin" in the URL.

This workaround is intended to be temporary. As soon as you are able to do an upgrade to the latest DD-WRT firmware, you should do so.

Where can I get more information about this?

More information about this vulnerability are at the DD-WRT wiki. Additionally, the DD-WRT forum is available to help answer questions.
Bib
DD-WRT Guru


Joined: 07 Jul 2008
Posts: 622
Location: France

PostPosted: Fri Jul 24, 2009 7:05    Post subject: Reply with quote
BrainSlayer wrote:
regarding CSRF. dd-wrt has CSRF prevention code inside since some months. this is something which should be noted


So, does the use of these CSRF prevention code enabled firmwares (please, from which release exactly BrainSlayer?) in addition with disabled "Allow any remote IP" and HTTPS only (LAN and WAN) would somewhat mitigate the issue and permit to postpone the upgrade?

I ask this also because the CSRF prevention feature stated in the quote have been told to be not so good.
gat3way
DD-WRT Novice


Joined: 23 Jul 2009
Posts: 4

PostPosted: Fri Jul 24, 2009 7:48    Post subject: Reply with quote
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.
VValdo
DD-WRT Novice


Joined: 13 Apr 2009
Posts: 24

PostPosted: Fri Jul 24, 2009 8:03    Post subject: Reply with quote
gat3way wrote:
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.


If I remember right, last years' exploit was something like this... if you'd previously authorized to the control panel with the browser and then visited an evil site without first logging out, your browser could end up unintentionally running some stuff on DD-WRT....

This isn't ideal. You'd think a cookie-based session ID or something would get passed in the URL with every request to the router. Still, if this is where we are now, it's a hell of a lot better than three days ago.

W
OB1
DD-WRT Novice


Joined: 22 Jul 2009
Posts: 25

PostPosted: Fri Jul 24, 2009 9:08    Post subject: Reply with quote
VValdo wrote:

If I remember right, last years' exploit was something like this... if you'd previously authorized to the control panel with the browser and then visited an evil site without first logging out, your browser could end up unintentionally running some stuff on DD-WRT....

This isn't ideal. You'd think a cookie-based session ID or something would get passed in the URL with every request to the router. Still, if this is where we are now, it's a hell of a lot better than three days ago.


As I already wrote, a quick workaround for this remaining issue would be changing the httpd (admin gui) port(s) from 80/443 to something else, this way even if one forgets to close the admin GUI before surfing, the exploit will fail since the attacker should then guess the correct port for the CSRF URL

Sure, it's just a band-aid, and, to some extent, a form of S.T.O. but since it's easy to implement and since it offers some degree of additional protection, I think it may be worth doing it
VValdo
DD-WRT Novice


Joined: 13 Apr 2009
Posts: 24

PostPosted: Fri Jul 24, 2009 17:01    Post subject: Reply with quote
OB1 wrote:

As I already wrote, a quick workaround for this remaining issue would be changing the httpd (admin gui) port(s) from 80/443 to something else, this way even if one forgets to close the admin GUI before surfing, the exploit will fail since the attacker should then guess the correct port for the CSRF URL

Sure, it's just a band-aid, and, to some extent, a form of S.T.O. but since it's easy to implement and since it offers some degree of additional protection, I think it may be worth doing it


As far as i can find, there is no direct way in the Web UI to redefine the http port. Maybe I've just missed it, but the boxes I see are just "http" and "https". Looks like if you want to redirect ports, you've got to do it as described here, namely:

Code:
killall httpd
cd /www
httpd -p 81 -h /www
cd /jffs
httpd -h /jffs


Will that work across boots? Maybe it can also be done via port forwarding or something but I haven't fooled with that. Hmm. Now that I think about it, I don't know if that would work.

Anyway- changing your port and IP are probably okay workarounds, but they are *very* temporary.

W
Menkatek
DD-WRT Novice


Joined: 11 Nov 2008
Posts: 44

PostPosted: Fri Jul 24, 2009 22:42    Post subject: Reply with quote
Did anyone have problems with remote access after implementing the temporary fix?

I logged in via remote desktop to a WAN PC and with a browser session to the router, added those four lines. But I was immediately disconnected and now can't get back in.
chris
Site Admin


Joined: 06 Jun 2006
Posts: 101
Location: Germany, Bensheim

PostPosted: Fri Jul 24, 2009 22:47    Post subject: Reply with quote
Hi,

i tested that with remote access, and after applying it, i was still on the router

_________________
NewMedia-NET GmbH
Christian Scheele (CEO)
http://www.dd-wrt.com
Menkatek
DD-WRT Novice


Joined: 11 Nov 2008
Posts: 44

PostPosted: Fri Jul 24, 2009 22:53    Post subject: Reply with quote
Thanks for the quick reply, chris.

I'm using beta firmware on a WHR-G300N. From my notes, it is 'DD-WRT v24-sp2 (02/17/09) std - build 11625'.

I'll have my parents power cycle the router when they awaken. I really hope it's nothing serious, as they know nothing about computers and I'm currently in the US!
OB1
DD-WRT Novice


Joined: 22 Jul 2009
Posts: 25

PostPosted: Mon Jul 27, 2009 7:11    Post subject: Reply with quote
VValdo wrote:


ports, you've got to do it as described here, namely:

Code:
killall httpd
cd /www
httpd -p 81 -h /www
cd /jffs
httpd -h /jffs


Will that work across boots?


you won't need the second part (that is the "jffs" one) but just the killall and the "www" one;

just to be clear you will only need

Code:

killall httpd
cd /www
httpd -p 81 -h /www


about working across boots, according to the document you linked it seems it will survive boots; again, it isn't a real solution, but at least will make things worst for an attacker since, assuming you didn't open the web GUI to the WAN (which imHo is totally creazy, if you need remote admin, use SSH) the attacker will then have to guess the port on which your httpd is running; as a note, it may be useful having an option in the web gui to change the admin port so that it will be easy, even for "non skilled" users to tweak that setting
VValdo
DD-WRT Novice


Joined: 13 Apr 2009
Posts: 24

PostPosted: Mon Jul 27, 2009 7:52    Post subject: Reply with quote
OB1 wrote:


about working across boots, according to the document you linked it seems it will survive boots; again, it isn't a real solution, but at least will make things worst for an attacker since, assuming you didn't open the web GUI to the WAN (which imHo is totally creazy, if you need remote admin, use SSH) the attacker will then have to guess the port on which your httpd is running; as a note, it may be useful having an option in the web gui to change the admin port so that it will be easy, even for "non skilled" users to tweak that setting


Yeah I think such a GUI option would be good. I can't see how quitting and restarting the httpd daemon could be permanent on reboot.

Right now a more realistic option is probably just to change your LAN-side IP and hope it isn't easily detectable.

W
OB1
DD-WRT Novice


Joined: 22 Jul 2009
Posts: 25

PostPosted: Mon Jul 27, 2009 8:22    Post subject: Reply with quote
VValdo wrote:

Yeah I think such a GUI option would be good. I can't see how quitting and restarting the httpd daemon could be permanent on reboot.

Right now a more realistic option is probably just to change your LAN-side IP and hope it isn't easily detectable.


Uhm... sounds like you may be right, rereading that document, at a point it says that the box will reboot but... the doc is wrong, as soon as the box reboots the port changes will get lost Sad oh well :P

As for changing the IP; yes, that may help too, but in some cases it may not be a viable option; imagine having a bunch of systems sitting behind a DD-WRT box, and some of them (e.g. printers, servers...) using stating network settings; changing the subnet would be a PITA while changing the port won't "break" things :)

Also, and since we're at it; referring to the remaining CSRF issue, an idea to help preventing it (aside from changing the admin port) would be modifying the web gui to require another authentication for "write" operation; I mean something like this:

you log on the gui; from that moment on you can browse the settings and so on

if you change one or more settings, as soon as you hit the "write" button, the GUI will popup an auth request and you'll have to reenter the credentials

this way, even if someone tries to play CSRF on an open admin page, the request will be blocked by the auth request; sure, such an approach may be annoying, but at least it may be a butt-saver <g>
tenho
DD-WRT Novice


Joined: 16 Mar 2009
Posts: 16

PostPosted: Mon Jul 27, 2009 13:54    Post subject: Firmware: DD-WRT v24 RC-7 (03/26/08) vpn Reply with quote
Sorry guys, no time right now to comb through all the 12 pages of this discussion (maybe somebody already has reported about this).

I just read about this issue and wanted to inform, that the bug is ALSO PRESENT in the DD-WRT v24 RC-7 (03/26/08 ) vpn build, so not only v24 SP1 seems to be affected.
(I use the RC-7 build because of the SDmod and JFFS support.)

Cheers
Stefan
OB1
DD-WRT Novice


Joined: 22 Jul 2009
Posts: 25

PostPosted: Mon Jul 27, 2009 14:21    Post subject: Re: Firmware: DD-WRT v24 RC-7 (03/26/08) vpn Reply with quote
tenho wrote:
Sorry guys, no time right now to comb through all the 12 pages of this discussion (maybe somebody already has reported about this).

I just read about this issue and wanted to inform, that the bug is ALSO PRESENT in the DD-WRT v24 RC-7 (03/26/08 ) vpn build, so not only v24 SP1 seems to be affected.
(I use the RC-7 build because of the SDmod and JFFS support.)

Cheers
Stefan


Thanks for the report; judging from the vuln, and as already discussed, the issue may as well affect all previous versions ... I suspect the "httpd" code didn't change so much Smile
Goto page Previous  1, 2, 3 ... 11, 12, 13, 14, 15  Next Display posts from previous:    Page 12 of 15
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum