Posted: Thu Jul 23, 2009 15:33 Post subject: Use a non-standard IP range
One idea that would mitigate automated CSRF attacks like this is for everyone to use a unique IP address range - there is the whole of 10.x.x.x to use, and 172.16.something, and of course 192.168.N.x where N => 2.
You can also set the router to be a non-standard IP within the range - anything from 2 to 254 would help.
This is not the first automated router attack and won't be the last - changing your IP range is a bit of a hassle but you only have to do it once.
It's not a perfect protection of course, as someone could do attacks that try all these ranges and IP addresses, but that's a lot harder than a crafted forum image that attacks the default router address.
Of course, you should also use a non-standard DNS or hostname (if you use a /etc/hosts file) for the router - get creative, call it something without router or firewall in the name. _________________ DD-WRT v23 SP1 / WRT54G 2.2 / 12 dBi omni - great for houses with thick stone walls
If your router reboots, then your router should get the firewall rules / or updated.
>router_ip = wan_ip?
No, internal router ip, if your router is NOT on 192.168.1.1
well... either LAN or WAN; having admin GUI open to the WAN makes the issue worse, but either the WAN or the LAN IP will allow to trigger the vuln; it's a pity that the DEVs didn't clearly explain this
Posted: Thu Jul 23, 2009 15:45 Post subject: Re: Use a non-standard IP range
Cato2 wrote:
One idea that would mitigate automated CSRF attacks like this is for everyone to use a unique IP address range - there is the whole of 10.x.x.x to use, and 172.16.something, and of course 192.168.N.x where N => 2.
You can also set the router to be a non-standard IP within the range - anything from 2 to 254 would help.
This is not the first automated router attack and won't be the last - changing your IP range is a bit of a hassle but you only have to do it once.
It's not a perfect protection of course, as someone could do attacks that try all these ranges and IP addresses, but that's a lot harder than a crafted forum image that attacks the default router address.
Of course, you should also use a non-standard DNS or hostname (if you use a /etc/hosts file) for the router - get creative, call it something without router or firewall in the name.
Well... as already stated (see other posts in this thread) it shouldn't be so difficult to guess/retrieve the LAN subnet and the GW IP and in any case changing the subnet is just a band-aid; by the way another way of fixing the issue (assuming you DON'T have the admin GUI enabled on WAN) would be changing the web admin port (aka httpd port) from the standard 80 to something else, that way a trick like the
IMG SRC="http://192.168.1.1/cgi-bin...
won't work since it would hit port 80 on the router box and, after changing the httpd port there won't be anything listening or answering there but, again that would just be another band-aid, although easier to implement in case you have several clients sitting behind the DD-WRT router and you can't or don't want to change the subnet
Last edited by OB1 on Thu Jul 23, 2009 15:50; edited 1 time in total
Posted: Thu Jul 23, 2009 15:57 Post subject: Re: Use a non-standard IP range
OB1 wrote:
Cato2 wrote:
One idea that would mitigate automated CSRF attacks like this is for everyone to use a unique IP address range - there is the whole of 10.x.x.x to use, and 172.16.something, and of course 192.168.N.x where N => 2.
You can also set the router to be a non-standard IP within the range - anything from 2 to 254 would help.
This is not the first automated router attack and won't be the last - changing your IP range is a bit of a hassle but you only have to do it once.
It's not a perfect protection of course, as someone could do attacks that try all these ranges and IP addresses, but that's a lot harder than a crafted forum image that attacks the default router address.
Of course, you should also use a non-standard DNS or hostname (if you use a /etc/hosts file) for the router - get creative, call it something without router or firewall in the name.
Well... as already stated (see other posts in this thread) it shouldn't be so difficult to guess/retrieve the LAN subnet and the GW IP and in any case changing the subnet is just a band-aid; by the way another way of fixing the issue (assuming you DON'T have the admin GUI enabled on WAN) would be changing the web admin port (aka httpd port) from the standard 80 to something else, that way a trick like the
IMG SRC="http://192.168.1.1/cgi-bin...
won't work since it would hit port 80 on the router box and, after changing the httpd port there won't be anything listening or answering there but, again that would just be another band-aid, although easier to implement in case you have several clients sitting behind the DD-WRT router and you can't or don't want to change the subnet
Yeah this was already discussed way back in the thread by myself and others. Band-aid fix is right. Not a good feeling knowing your ddwrt devices are a URL away from crash/hack no matter where you hide the address & port.
I completely disabled the httpd until I updated to the fixed build.
Posted: Thu Jul 23, 2009 16:12 Post subject: Re: Use a non-standard IP range
jrock wrote:
Yeah this was already discussed way back in the thread by myself and others. Band-aid fix is right. Not a good feeling knowing your ddwrt devices are a URL away from crash/hack no matter where you hide the address & port.
I completely disabled the httpd until I updated to the fixed build.
Heh.. agreed, and as I see it, I think that while the DEVs did a good job in quickly fixing it, they also did a bad job in NOT clearly alerting the users
anyways, since the patch is now available, let's explore the issue a lil bit more
Imagine registering a host name on a public domain, say "foo.bar.com" and setting up the DNS so that it will resolve to 192.168.1.1 at that point it would be quite easy to post around links to foo.bar.com and "own" a bunch of routers
See, milw0rm example used a passive (listening) netcat command, now imagine using an ACTIVE one carrying on a reverse telnet connection toward port 80 of an external host
as soon as a user sitting behind a vulnerable DD-WRT will visit a page with an "exploit URL" (say an IMG SRC or even a stylesheet or whatever) the vuln will be triggered
at that point the URL will fire the reverse-telnet netcat on the router, the command will connect to the external host on which a script, listening on port 80 (in this example) will receive the shell prompt, at that point the script will automatically upload to the router (say using wget or whatever) an IRC bot and have the router join an hidden channel and wait for commands
voilà; in a few hours the attacker would have a bunch of WRT boxes ready at his command... now, do you think this DOES NOT need some kind of ALERT ?
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Thu Jul 23, 2009 16:56 Post subject:
No. Because the same thing happens to many people's computers in a day. Eventually, they figure out they have a virus and the get someone to fix the problem. Those who actually *keep* up with their router's firmware, will upgrade and be safe. Enough said.
If you think there should be a *major* announcement, then donate to the cause. Give money to DD-WRT, and put out the word that everyone needs to update. That is all you can really do. _________________ E3000 22200M KongVPN K26
WRT600n v1.1 refirb mega 18767 BS K24 NEWD2 [not used]
WRT54G v2 16214 BS K24 [access point]
Try Dropbox for syncing files - get 2.5gb online for free by signing up.
Read! Peacock thread
*PLEASE* upgrade PAST v24SP1 or no support.
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Thu Jul 23, 2009 17:09 Post subject:
By the way, has anyone checked the main page to DD-WRT? There is an announcement for incoming people as "plain as day" about the recent exploit. Is that announcement good enough for everyone? _________________ E3000 22200M KongVPN K26
WRT600n v1.1 refirb mega 18767 BS K24 NEWD2 [not used]
WRT54G v2 16214 BS K24 [access point]
Try Dropbox for syncing files - get 2.5gb online for free by signing up.
Read! Peacock thread
*PLEASE* upgrade PAST v24SP1 or no support.
Joined: 06 Jun 2006 Posts: 101 Location: Germany, Bensheim
Posted: Thu Jul 23, 2009 18:35 Post subject:
hi
i had a discussion on pm with the user before, the wds problem is not related to the "iptables rules". _________________ NewMedia-NET GmbH
Christian Scheele (CEO)
http://www.dd-wrt.com
Well I am the culprit to blame for that mess. I didn't expect my disclosure would cause that little havoc indeed.
I've been following your discussion since yesterday, I did not want to intervene, however due to a number of wrong assumptions I saw there, I think I have to clarify on a number of things.
First off - about the CSRF which in fact is one of the 2 issues here. I am sorry to tell you but IMO both the active developers of DD-WRT do not have a good understanding on the problem, especially Eko (nothing personal, that's my observation - the statement he made after releasing his fix is kinda irresponsible). DD-WRT v24sp1 and all prior versions do not have CSRF protection at all to start with. The anti-CSRF fix realised in the httpd.c as in the SVN repository which made it into sp2 is weak. And you may deduce why by just reading about CSRF attacks on Wikipedia. It's all about getting the value of the Referer: header and strcmp() it against the hostname in case it is not NULL of course. Well, I had some little discussion with a user called brainslayer (coincidence?) on youtube. I wrote there and I will write here as well - if the CSRF attack comes from a https site then NO REFERERS ARE BEING SENT AT ALL. At least not with most browsers (Firefox/IE/Safari/Opera). That is because sending them is considered an information leak (remember, the HTTP traffic is SSL-encrypted, this applies for the HTTP requests as well of course). So even with v24sp2, CSRF attacks are still possible from a https site.
However the cgi-bin vulnerability is fixed.
Now about the cgi-bin vulnerability. Some people say it is not possible as a result of a CSRF attack because the backslash (in my example) becomes url-encoded. Well in a way they are right, the backslash gets urlencoded. OTOH (sorry for being rude) - guys you need to read some "bash for dummies" book and if you already have, then you have no imagination at all. What about spawning a shell at port tcp/11111 by using [removed:phuzi0n] for example? Yeah, no backslash there and it works.
As for the ways to fix the problem - if I were a dd-wrt user, I would either update or kill the httpd service. The netfilter-based solution is not bad, however it opens a possibility for a nice DoS attack in case a XSS flaw is found somewhere in the web UI. What I mean is that if someone finds a XSS flaw then he may create a rogue site with a hidden iframe that loads your web UI with a nice XSS js code that sets a cookie containing "cgi-bin" which expires after years. Bingo - you will never ever be able to access your web UI again unless you clear your cookies. But that's just theoretical. I never tested the web admin interface for xss flaws - probably there are no xss flaws at all, probably there are, dunno.
One more thing worth mentioning is that an attacker that already got root would probably be able to silently backdoor the router persistently (I mean across reboots). That's because the LD_LIBRARY_PATH (and /etc/ld.so.conf) contains /jffs/lib and if the *hacker* enables jffs and uploads a library containing backdoor code there, it will be preloaded during the initscripts' execution. Yet that's something I have not tested yet - so I am not 100% sure about it.
I would also point out that I am kinda negative about the way the vulnerability was presented by the DD-WRT developers on the site. However it's just my viewpoint.
And here is something you may consider funny. I never ever owned a wireless router. I finally decided to buy one and flash it with either dd-wrt or openwrt or tomato. That's why I downloaded them and emulated them with qemu to see what they can do. I wanted to customize the web UI a bit, write some script that does statistics on the number of conntrack entries over time, etc. Well, the security problem in DD-WRT was quick to detect.
Anyway...if you need to ask me something about that, shoot it.
but, again that would just be another band-aid, although easier to implement in case you have several clients sitting behind the DD-WRT router and you can't or don't want to change the subnet