Forgot your password?
typodupeerror
Security Programming IT Technology

New Exploit Uses JavaScript To Compromise Intranets, VPNs 87

Posted by timothy
from the criminal-enterprises-deal-in-cache dept.
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.'"
This discussion has been archived. No new comments can be posted.

New Exploit Uses JavaScript To Compromise Intranets, VPNs

Comments Filter:
  • by Saija (1114681) on Thursday June 11, 2009 @06:46PM (#28301787) Journal
    here [sectheory.com]
  • o..k (Score:5, Informative)

    by QuantumG (50515) * <qg@biodome.org> on Thursday June 11, 2009 @06:52PM (#28301863) Homepage Journal

    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.

  • by QuantumG (50515) * <qg@biodome.org> on Thursday June 11, 2009 @06:54PM (#28301893) Homepage Journal

    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)

    by Tony Hoyle (11698) <tmh@nodomain.org> on Thursday June 11, 2009 @08:05PM (#28302555) Homepage

    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)

    by TCM (130219) on Thursday June 11, 2009 @08:07PM (#28302567)

    172.16.0.0/12

  • by Philip_the_physicist (1536015) on Thursday June 11, 2009 @08:27PM (#28302775)
    RTFA. He is saying that only about 1280 non-routable addresses are normally used, not that only 1280 exist. It is the small number which are normally used which makes guessing addresses viable.
  • It's a switcheroo (Score:1, Informative)

    by Anonymous Coward on Thursday June 11, 2009 @09:48PM (#28303339)

    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.

  • by iggymanz (596061) on Friday June 12, 2009 @01:23AM (#28304579)
    in the real world, where NAT boxes spit out dhcp on a default subnet with a default gateway address, what the author presents is indeed the case. but you may insert your head back into your rectum if you think the air smells better in there.

We want to create puppets that pull their own strings. - Ann Marion

Working...