saw it, but it's totally WRONG, tried it by myself, with WAN httpd disabled and it WORKS, I suspect Eko didn't fully understand the issue; also, it would be a good idea posting an alert on the site front page urging the users to update to the latest firmware before someone will start using DD-WRT boxes as bots
[edit]
If you want to try it by yourself do the following
setup a web page somewhere on the internet; on the
page add an IMG tag like the following one (add angular brackets as needed)
IMG SRC="http://192.168.1.1/cgi-bin/;init$IFS6"
or something like that; then using a vulnerable version of DD-WRT, and a machine sitting behind the DD-WRT router, open that page
the browser will see the IMG reference and attempt to fetch it, but the URL points to the LAN IP of the router, so the result will be triggering the exploit and executing the command; in the above case you'll be sending an "init 6" but you may use whatever other command you want, including "nc" or whatever else
Alot of confusion here about this bug.
As stated there have been posts from the developer's themselves as recent as today stating that this bug only effects the httpd when remote/wan admin is enabled.
The original post in this thread clearly sums it up that that is not the case & we have multiple people confirming that this bug does exist and that it can be triggered via CSRF drive-by.
I'm grateful for dd-wrt and all development, but with the time, effort, and attention put into it how could they overlook this huge security hole, and now almost ignore it.
saw it, but it's totally WRONG, tried it by myself, with WAN httpd disabled and it WORKS, I suspect Eko didn't fully understand the issue; also, it would be a good idea posting an alert on the site front page urging the users to update to the latest firmware before someone will start using DD-WRT boxes as bots
[edit]
If you want to try it by yourself do the following
setup a web page somewhere on the internet; on the
page add an IMG tag like the following one (add angular brackets as needed)
IMG SRC="http://192.168.1.1/cgi-bin/;init$IFS6"
or something like that; then using a vulnerable version of DD-WRT, and a machine sitting behind the DD-WRT router, open that page
the browser will see the IMG reference and attempt to fetch it, but the URL points to the LAN IP of the router, so the result will be triggering the exploit and executing the command; in the above case you'll be sending an "init 6" but you may use whatever other command you want, including "nc" or whatever else
Alot of confusion here about this bug.
As stated there have been posts from the developer's themselves as recent as today stating that this bug only effects the httpd when remote/wan admin is enabled.
The original post in this thread clearly sums it up that that is not the case & we have multiple people confirming that this bug does exist and that it can be triggered via CSRF drive-by.
I'm grateful for dd-wrt and all development, but with the time, effort, and attention put into it how could they overlook this huge security hole, and now almost ignore it.
?
Heh... something I'm wondering about as well :(
And btw there's another issue too, as m1lw0rm stated, the code parsing cgi-bin requests isn't properly sanitizing the input and this may (didn't verify it) lead to some other nasty bug
SIGH
hope the developers will understand that this isn't a "minor issue" and will fix it and PROPERLY alert the users; at the moment, the alert on the site front page is wrong and may give users a wrong sense of security the exploit works even if the WEB GUI isn't enabled on WAN so the only real way to fix it is to upgrade to the fixed firmware (hope it was really fixed) and/or change the WEB (httpd) admin port to something different
Yes, m1lw0rm used the classic "kiddie protection" to avoid some lame folk using the exploit w/o understanding it, but aside from that, the exploit works, and it works without any need to have the web admin GUI opened on the WAN interface
I don't believe this is true but I may be mistaken. The report clearly lists 1) No metacharacters handling which indicates to me that the backslash is key to this particular example link. If you remove the backslash then netcat fails to run although other commands work fine without backslashes. _________________ 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)
I just noticed the alert on the home page. Thats a good start to getting the word out on this.
Thank you pete & admins.
OB1 wrote:
the alert on the site front page is wrong and may give users a wrong sense of security
Even though they don't go into detail about the worst of the problem, at least they are acknowledging it and directing people to a fixed build.
I don't think we'll see a 'code-red' unless we see some actual reports of folks being hacked.
I'm not suggesting to cry "the sky is falling", but telling the users that the vuln exists only if the WEB GUI is enabled on WAN is wrong and may lead to a false sense of security... someone may decide that he'll just need to disable WAN admin and feel secure while ... he isn't
Yes, m1lw0rm used the classic "kiddie protection" to avoid some lame folk using the exploit w/o understanding it, but aside from that, the exploit works, and it works without any need to have the web admin GUI opened on the WAN interface
I don't believe this is true but I may be mistaken. The report clearly lists 1) No metacharacters handling which indicates to me that the backslash is key to this particular example link. If you remove the backslash then netcat fails to run although other commands work fine without backslashes.
Hmmm.... maybe you're right, will have to play with that some more
the above will run nc in reverse telnet mode, connect to the host at IP 1.2.3.4, port 80 and start a shell; the backslash is needed to avoid the misinterpretation of the port # but it may be avoided by using a different syntax
Last edited by OB1 on Wed Jul 22, 2009 17:08; edited 1 time in total
I'm not suggesting to cry "the sky is falling", but telling the users that the vuln exists only if the WEB GUI is enabled on WAN is wrong and may lead to a false sense of security... someone may decide that he'll just need to disable WAN admin and feel secure while ... he isn't
I'm not disagreeing with you.
It seems that either developers are mis-informed or in denial perhaps along with us.
I think there should be full disclosure of what the problem is from the developers so people are informed. We have people verifying this bug independently, and others saying that it won't work via drive-by because of ONE character mismatch.. Then we have the developers that are denying the bug exists all together when remote-management is disabled.
The fix in build 12548 seems to work correctly. _________________ 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)
I'm not suggesting to cry "the sky is falling", but telling the users that the vuln exists only if the WEB GUI is enabled on WAN is wrong and may lead to a false sense of security... someone may decide that he'll just need to disable WAN admin and feel secure while ... he isn't
This actually might be a reference to a previous exploit, a couple of months ago. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Last edited by Murrkf on Wed Jul 22, 2009 17:25; edited 1 time in total
I think there should be full disclosure of what the problem is from the developers so people are informed. We have people verifying this bug independently, and others saying that it won't work via drive-by because of ONE character mismatch.. Then we have the developers that are denying the bug exists all together when remote-management is disabled.
To be precise, only the example link doesn't work in a SIMPLE drive by. Commands without backslashes work easily in img sources and commands that needs the backslash could probably be ran through javascript or flash. _________________ 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)
To be precise, only the example link doesn't work in a SIMPLE drive by. Commands without backslashes work easily in img sources and commands that needs the backslash could probably be ran through javascript or flash.
Thank you for clarifying that I should have read closer to the posts.