As I type there are probably hundreds of people downloading v24sp1 having no idea of this vulnerability.
It's NOT the only bug they'll find...... _________________ 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.."
I think t his vulnerability may be misunderstand by a lot of people.
We need to find out if dd-wrt is fine if http isn't open to the internet. Does anyone know?
Read the thread..
I believe original post states that it is not directly exploitable via WAN port but it IS with a CSRF spoof. Meaning somebody could embed a bad link on any webpage you view and it will be sent to the router. Even worse is there is no authentication needed as previous CSRF exploits.
Please read the first post again.
I just realized you may have meant something else... srry if you did..
From what I've gathered the only way right now to squash this is to stop the httpd service on the router all together (no web config). Or install the very latest beta build referenced in this thread.
Last edited by jrock on Tue Jul 21, 2009 21:44; edited 2 times in total
We need to find out if dd-wrt is fine if http isn't open to the internet. Does anyone know?
If you run httpd at all, you're vulnerable. The particular 'netcat to get a shell' crafted example link doesn't appear to work when used in a browser (ie. a forum img src) because the backslash gets convert to its URL encoded form, but the command is still ran and other commands can be ran just by posting a crafted link on a web page. _________________ 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)
Joined: 22 Jun 2008 Posts: 2440 Location: Am now Dark_Shadow
Posted: Tue Jul 21, 2009 21:43 Post subject:
jrock wrote:
DHC_DarkShadow wrote:
I think t his vulnerability may be misunderstand by a lot of people.
We need to find out if dd-wrt is fine if http isn't open to the internet. Does anyone know?
Read the thread..
I believe original post states that it is not directly exploitable via WAN port but it IS with a CSRF spoof. Meaning somebody could embed a bad link on any webpage you view and it will be sent to the router. Even worse is there is no authentication needed as previous CSRF exploits.
Please read the first post again.
I just realized you may have meant something else... srry if you did..
From what I've gathered the only way right now to squash this is to stop the httpd service on the router all together (no web config).
As I type there are probably hundreds of people downloading v24sp1 having no idea of this vulnerability.
It's NOT the only bug they'll find......
This is worse than bricking routers imo. We may start seeing router based botnets because of this. I have no idea what criteria BS uses in deciding to release new official builds but I sure hope this pushes him to finally release a SP2 final. _________________ 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)
We need to find out if dd-wrt is fine if http isn't open to the internet. Does anyone know?
The thing is, any site can have content hosted under another ip or a script that internally loads an url, in this case something to retrieve from an url along the lines of http://192.168.1.1/cgi-bin/;some_command .
Do note that while your browser fetches the non-existent content at that url, it will be unknowingly parsing a command to your router at that ip. (example: if an image tag contains http://192.168.1.1/cgi-bin/;some_command, the browser will attempt to retrieve an image from that location, but will actually be giving a command to your router)
As long as you have the webif available you are exploitable, regardless of how you set the remote access -- it will be your local computer parsing the exploited url, not a remote one.
Still, blacklisting your router ip in your browser may be an effective temporary fix. (just remember to "un-blacklist" it to access the webif)
Edit: I see I took too much time writing this and there are already some replies..
I'm thinking people who choose to NOT use the standard address of 192.168.1.1 will be less effected by most exploits also.
Am I correct in assuming this?
It's not too hard to get the computer's IP and replace the last number with 1, but yes, it might help.
Yeah I thought of that too, but not everybody uses .1 . And with the nature of this problem I imagine 99.99% of exploits will be drive-by website hits with pre-crafted URLs.
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Tue Jul 21, 2009 22:27 Post subject:
ct wrote:
Come to think of it, if you can get to the computer's IP, you can probably also get to the default gateway's.
Not necessarily. *If* you are using the *standard* setup, then a "drive-by" hit and run would be easy. However, if you change your subnet mask (which possibly means a change in default gateway), or if you have a "non-standard" private IP address range, or even changing the gateway to the high end of the range, you would be fairly safe. _________________ 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.
i vote for more secure default settings (some of this are already set by default as preferred, but not all):
1. wan access to router off by default
2. wireless access to router off by default
3. https only access to router by default
4. must to set an personal password on first use
5. captcha like test on every login to break malware/attacks automation
6. having proper protection for this one would also be nice http://www.securityfocus.com/bid/32703/info
PS can someone test if the use of https only blocks this attack?
Last edited by saso on Wed Jul 22, 2009 7:35; edited 1 time in total
