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)
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:
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:
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.
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.
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.
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
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.
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.
Joined: 06 Jun 2006 Posts: 101 Location: Germany, Bensheim
Posted: Fri Jul 24, 2009 22:47 Post subject:
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
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!
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
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.
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 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>
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.)
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
oh well :P
