Yeah I thought of that too, but not everybody uses .1 .
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 really. If they are on the target machine or have control of it, yes. But otherwise, howso? Explain.
My original post about being less vulnerable while not using the default address had to do with being less vulnerable to drive-by type of csrf attacks which i believe will be the majority of exploits with this bug. (pre-crafted links with the 192.168.1.1 address)
If we are talking about web browswer vulnerabilities ct.. I don't know of any that will send network configuration to the host. As a matter of fact even the machine's private ip would not be visable to the host. Only the public address would be shown.
I'm not saying the address could not be guessed, it just wouldnt be deducted the way you describe.
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.
Like it has been said, the remote server shouldn't be able to get your NAT addresses, but don't forget scripts made in JavaScript run locally (in your machine) and not on the server side.
That is, although the remote server doesn't know your computer NAT'ed IP address, a script is well capable of reveling it, automatically craft and query a "command" url.
Still, I am not so sure how to retrieve the proper gateway information with JavaScript, mostly because I have never had to do that in the past...
Like it has been said, the remote server shouldn't be able to get your NAT addresses, but don't forget scripts made in JavaScript run locally (in your machine) and not on the server side.
That is, although the remote server doesn't know your computer NAT'ed IP address, a script is well capable of reveling it, automatically craft and query a "command" url.
Still, I am not so sure how to retrieve the proper gateway information with JavaScript, mostly because I have never had to do that in the past...
Yes I was going to bold 'web browser alone' in my post. I understand with javascript it could be a different story, or any plug-in for that matter.
I was more worried about an easily distributable embedded csrf than sophisticated malicious java apps. But you are correct.
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Wed Jul 22, 2009 2:14 Post subject:
If you run firefox with the plugin "NoScript", then 'cross-site' exploits will not be possible. Therefore it is reasonable to assume that even if I did not have the latest version, I would be relatively safe from having someone hack my router. _________________ 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.
Posted: Wed Jul 22, 2009 2:54 Post subject: Re: same
Howdy...
Long time DD-WRT forums reader, first time poster.
uid0 wrote:
I also was able to replicate this on DD-WRT v24-sp1 (07/27/08) std... obviously upgrading tonight.
Anyone know if the VINT builds are affected by this?
I'm running a very old (but hither-to very reliable) WRT54GS v. 1.0, 1.1, or 2.0. (It is so old it does not have a version number on the bottom label near the S/N and MAC address bar codes; I am thinking it's v1.1.)
I tried running v24-sp1, but kept experiencing various weirdnesses, so I replaced it with the v24-std VINTage build:
-- From DD-WRT "Info" front page:
-- Firmware: DD-WRT v24 (05/20/08) std
I've also tried poking at the router using the YT vid as a guide, but to this point I haven't been able to root it. However, this is probably more due to me fat-fingering something and less due to its robustness; I would presume that the VINT builds have the same (or a very, very similar) version of the httpd daemon installed...
Anyone try this exploit on a VINT-installed router to see what happens?
Great work, guys!
I've simply disabled telnet & ssh when not in use, and disabled http(s) access to the device on non-LAN interfaces.
I hope that covers my bases
- J
No, this is *NOT* enough. You must disable HTTP(S) *completely*, or upgrade the firmware.