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.'"
Straight from the horse mouth (Score:5, Informative)
o..k (Score:5, Informative)
Yes, if you control the server end of a VPN connection you can tell the other end what to route you.. assuming the client has been configured that way. Why are VPN connections configured that way? Because the admin is considered the trusted party. The user (typically an employee) trusts the admin to be more secure than he is.
If the server was setup to route whatever the client said to route, that would be bad, but it's mostly not the case.
Re:Only an issue if you use IP based URLs (Score:5, Informative)
It's right there in the first demonstrated attack.. if you control the server end of the VPN you can control where DNS traffic goes and so redirect any url to any IP.
Re:Say What??? (Score:4, Informative)
Yes.. the writer of the article doesn't know squat about IP and/or is pushing an agenda (like suggesting ipv6 as an alternative).
As another poster mentioned, the number of things that have to happen for this to be a practical exploit makes it laughable. If your VPN is compromised to that extent a few cookies is the *last* of your problems.
btw. there are non-routable IP addresses.. the whole 127/8 block, broadcast addresses, etc. but the original article just got it completely wrong.
Re:IPv6? (Score:3, Informative)
172.16.0.0/12
Re:Author of article is a fucking cunt (Score:2, Informative)
It's a switcheroo (Score:1, Informative)
The attack scenario involves two separate networks with RFC1918 addresses. The victim is on one network, the attacker is (to some extent) in control of the other network. The victim connects to the other network with a VPN client and requests pages from a webserver on that network.
The VPN connection is the key here, because it allows the attacker to create routes for servers which are normally on the victim's network. If the addresses used were public addresses, the client could be configured to reject overriding routes, but since collisions of RFC1918 addresses are to be expected, it accepts the routes.
The attacker can use these routes to poison the victim's browser cache: The browser can't tell the difference between the attacker's server and the server which the victim normally connects to, because they're named the same and have the same IP address. Only the routing has changed.
When the victim disconnects the VPN, the attacker's files remain in the browser cache and when the victim connects to the local server, they're used instead of the correct files.
The attacker could steal cookies directly, without poisoning the cache, but capturing a live login (or other locked-down resources) requires control over the login page while the victim logs in to the local server, i.e. when the victim is not connected to the rogue network via VPN. That's where the cache poisoning comes in.
Re:Author of article is a fucking cunt (Score:3, Informative)