New Exploit Uses JavaScript To Compromise Intranets, VPNs 87
redsoxh8r writes "Security researcher Robert Hansen, known as Rsnake, has developed a new class of attack that abuses a weakness in many corporate intranets and most browsers to compromise remote machines with persistent JavaScript backdoors. Threatpost reports: 'The attacks rely on the long-term caching policies of some browsers and take advantage of the collisions that can occur when two different networks use the same non-routable IP address space, which happens fairly often because the amount of address space is quite small. The bottom line is that even a moderately skilled attacker has the ability to compromise remote machines without the use of any vulnerability or weakness in the client software.'"
Definition of vulnerability or weakness? (Score:4, Insightful)
Re:IPv6? (Score:5, Insightful)
Yes, IPv6 would help here, and in a lot of other instances. With IPv6, unless you're already communicating with a host, or it has a public identity because it's a server, the chances of you guessing its IP address are vanishingly small. So this attack wouldn't work, and also the typical attack that internet worms do where they just randomly try ports on various IP addresses en masse also wouldn't work, because the statistics are no longer in their favor.
I don't see any actual erxploit here (Score:5, Insightful)
All it is is a pretty wild theory that an exploit could occur... and there are a vast number of increasingly unlikely events that have to transpire for it to happen.
a) Your browser has to have unpatched remote script injection exploits.
b) You have to be using VPN to connect to *an untrusted network*. This is the opposite of what you normally use VPN for
c) Once connected to this insecure network via VPN, you have to for some reason visit a page on it that shares the IP address as another web server in your network. As well, the person who is hosting the exploit script on this page (that they are trying to cache) has to also know the name of the exact same script file *on your network*, so that the cache will pick it up the next time you connect to your own resources.
To me, all seems very unlikely. Sure, you could do this in a lab environment, but in the real world, if a would-be-intruder already knew that much about your network, and you are for some reason VPN'ing into a network that they control, then you likely have bigger issues with physical security and meat-space trust relationships in our business, and are already screwed over.
Re:Address space limitation? (Score:5, Insightful)
Nope, you won't. It was stated in his article [sectheory.com] that HTTPS is immune.
You could also dump all cached content when the browser closes. (That's what I do)
The only thing that can get me is cookies!... but they're so useful and tasty...
Er...that is not a new exploit, and makes no sense (Score:4, Insightful)
Because if the attacker could do that at Starbucks, he would not need to cache-poison my browser to get my login cookies to slashdot... they would already be sent with every request.
This is why DNSSEC is important to get rolled out. And also why you should not use public WiFi to do anything online that you worry about someone compromising.
Re:It's a switcheroo (Score:4, Insightful)
As others have pointed out above: why the heck would anyone VPN to an untrusted network? The only way that would be remotely feasible is with some kind of DNS exploit.
Then that's assuming that you've got your 'trap' network setup to accept connections from whatever VPN software the target is using?!?!? (Cisco client? Juniper??!?! SSL web based? Nortel? what version??!?!?! What if split tunnelling is disabled??!!) And you know what credentials the end user is using so the connection is 'accepted'.
And you know what internal servers the end user is going to target.
If you know that much about your target's intranet then whats the point of doing this, you're already in anyway via other easier more deadly means. brunes69 (86786) sums it up nicely
And oh its obviously complete BS that there's only 1280 'non routable' private addresses, yes they're routable, yes there's more but the point is most people use 10.0.0.x/24, 10.1.1.x/24, 192.168.1.x/24 and the like. So effectively you only have to cover a dozen or so of the common /24s. But my above point still stands
Re:IPv6? (Score:4, Insightful)
64 bits, actually.
The address is usually made up of the prefix and the interface identifier, so technically the addresses aren't random - the interface identifier is derived from the MAC address of the interface, typically. But you'd have to know the ethernet address of the device you're trying to reach, *and* its prefix, at the same time, in order to be able to attack it. Since this particular attack is valuable precisely because you don't need to know those things, IPv6 would in fact render it useless.
Having said that, I think CGA (cryptographically generated addresses) are going to get popular, and if that's so, then even knowing the MAC address won't be able to help you.