 ztmikeMark for moderationPremium
join:2001-08-02
Michigan City, IN
2 edits | reply to fAcEtIOUs
Re: Open-source firmware flaw exposes wireless routers - DD-WRT Thanks.
But that's Beta software..do they not have a fix that's not labled as "beta" ?
Has anyone done this over Linux? Their how-to has a .exe file that is a Windows file.
(I can't seem to find their how-to link)
Edit: Found it
»www.wrtrouters.com/guides/upgradetolinux/ |
|
 jdongEat A Beaver, Save A Tree.Premium
join:2002-07-09
Rochester, MI
kudos:1 | said by ztmike:Thanks. But that's Beta software..do they not have a fix that's not labled as "beta" ? Nope. dd-wrt in fact posts a sticky in their forum encouraging everyone to use nightly builds.
--
Ubuntu MOTU Developer and Forums Council |
|
pandoraPremium
join:2001-06-01
Outland
kudos:1 Reviews:
 ·ooma
·Google Voice
·Future Nine Corp..
 ·Comcast
| reply to Karride
said by Karride: Tomato also does not have built in openvpn support, which I use for my job. It does. See - »www.mediafire.com/?sharekey=19f5···12ee1386
--
"People demand freedom of speech as a compensation for the freedom of thought which they seldom use." |
|
 EGeezerSummertimePremium
join:2002-08-04
Midwest
kudos:7
·Callcentric
| reply to SirMeowmix_III
Re: Firmware flaws and securing routers. said by SirMeowmix_III :
I'm sorry but this information is incorrect. The root issue is poor security and programming practices in httpd.c, earlier in the thread I had posted some examples of how easily the CSRF can be executed. The list can be expanded and as jdong had indicated threading makes exhaustive/common RFC1918 lists pretty easy. The RFC1918 address space is quite limited and unless you're talking about security through obscurity by using RFC3330 address ranges instead of those provided by RFC1918 you can still be vulnerable.
Looking at the code, the complete lack of sanity checks, and this vulnerability itself I would promote killing the httpd process and only starting it via SSH when necessary.
The ISC steps you posted are accurate but changing the IP to another RFC1918 IPv4 space doesn't accomplish as much as you may believe.
Thank you.
I agree that the root cause isn't defaults, but changing defaults does mitigate inasmuch as historically, malware writers have gone after the low hanging fruit first - those with default logins and settings. In that respect, changing defaults has value. by thwarting the simpler automated attacks such as the one being circulated.
There was ample opportunity to write threaded exploits in an earlier similar exploit, but it didn't happen. That doesn't mean it wouldn't happen in the future, though. It will be interesting to see if such an exploit shows up.
I have no expectations that changing defaults is a substitute for remedying root vulnerabilities or as a substitute for conventional security measures - only that it can provide additional hurdles that require more work and time to overcome.
I definitely agree your suggestion to disable httpd is a reasonable and effective measure on case someone does actually start writing more sophisticated attack code.
--
The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis |
|
|
|
| reply to Stem Bolt
Re: Open-source firmware flaw exposes wireless routers - DD-WRT out of curiousity I work at an ISP and had to kill three devices on the network tonite because they were killing the wireless network by hammering out a large volume of packets, they are however NATted. I just shut them down, I didnt have time to investigate further and it was late. The MACs of the devices just all came back to Cisco/Linksys
Could this be related (waiting for three calls in the morning) |
|
thrymr
join:2009-07-23
West Orange, NJ | reply to Ravenheart
said by Ravenheart:I thought a quick fix might be to make a top-level firewall rule on that machine to block outgoing port 80* to the router IP. Do you (or anybody) think that would cover it? I have an nice, stable build of DD-WRT and don't want to rush into another one that might introduce other problems. There is a firewall rule to fix the vulnerability, posted to the DD-WRT home page:
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
Also, just to be clear, the vulnerability exists if you have httpd enabled at all, even if WAN access to HTTP management is disabled. Browser limitations on cross-site scripting offer some protection, as I understand it. A DD-WRT forum thread exists on the topic. |
|
| reply to Stem Bolt
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
What about URI encoding? For example, 'cgi-bin' becomes '%63%67%69%2d%62%69%6e', does ipt_webstr correctly handle escaping? Hes anyone tested this mitigation methods with escaping? |
|
| reply to Stem Bolt
Looking at »svn.dd-wrt.com:8000/dd-wrt/brows···rev=6216 I do not see URI escaping handling... |
|
 sivranBack to Opera againPremium
join:2003-09-15
Arlington, TX
kudos:1
·RoadRunner Cable
1 edit | reply to thrymr
Eh, simply disabling the access does work. For example disable http access and enable https, an http link won't work but an https one will.
Disabling both (nvram set http_enable 0; nvram set httpsd_enable 0; nvram commit (if you want it to survive a reboot)) results in the router shutting down the httpd process altogether (sensibly enough), eliminating any chance of exploitation.
Er, I looked again, and it didn't shutdown the httpd. Don't mind me, I'm blind. It was right there on the ps listing after all. Still, it's not listening or responding to anything.
Switching to https-only though causes the browser to pop a certificate dialog, which is fair enough mitigation as long as you remember never to accept it permanently. 
Anyway, I'd rather look into Tomato. DD-WRT's usage meter tends to die and stop recording at seemingly random intervals. This vuln is just one more (better) reason to do so.
--
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon profitable cause... |
|
sivranBack to Opera againPremium
join:2003-09-15
Arlington, TX
kudos:1 Reviews:
·RoadRunner Cable
| reply to Millenniumle
said by Millenniumle:It isn't clear to me how to use the ssh interface. I've seen instruction to use the router's administration > diagnostics window to disable the web gui, but since the diagnostics window is part of the web gui, how do I get the web gui back once it is disabled? Must've missed this post.
Use an ssh client (like Putty or XShell) and point it at your router's IP, port 22. Note that the username will be root, not the username you set up in the web ui.
I've posted the commands to use in previous posts.
--
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon profitable cause... |
|
jdongEat A Beaver, Save A Tree.Premium
join:2002-07-09
Rochester, MI
kudos:1 | reply to SirMeowmix_III
said by SirMeowmix_III :
[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
[/code]
What about URI encoding? For example, 'cgi-bin' becomes '%63%67%69%2d%62%69%6e', does ipt_webstr correctly handle escaping? Hes anyone tested this mitigation methods with escaping?
Not even to mention this effectively disables all admin-type functionality on the router even for authenticated users; might as well just drop everything to incoming port 80.
--
Ubuntu MOTU Developer and Forums Council |
|
| reply to sivran
Thank you, sivran  . |
|
