Follow Slashdot stories on Twitter


Forgot your password?
Security Programming IT Technology

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.'"
This discussion has been archived. No new comments can be posted.

New Exploit Uses JavaScript To Compromise Intranets, VPNs

Comments Filter:
  • IPv6? (Score:4, Interesting)

    by Facegarden ( 967477 ) on Thursday June 11, 2009 @06:43PM (#28301745)

    Knowing basically nothing about anything involved, i see address space limitations are a partial issue here - does that mean some use of IPv6 would help somewhere somehow?

    • Re:IPv6? (Score:5, Insightful)

      by mellon ( 7048 ) on Thursday June 11, 2009 @06:50PM (#28301831) Homepage

      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.

      • Unless, of course, your IPv6 network is set up by one of the persistent idiots that post here saying that they are going to use the IPv6 private range and NAT their networks for 'security' rather than giving them publicly-routable addresses and configuring their firewall sensibly. In this case, the same exploit is possible as long as you can find a valid IP address in the private v6 range.

        Another win for the NAT-is-security crowd.

        • From Wikipedia about IPv6 private addresses: "The addresses include a 40-bit pseudorandom number that minimizes the risk of address collisions if sites merge or packets are misrouted."

          So you are technically correct that the exploit is still possible --- but it isn't practical unless the attacker knows most of the bits of that 40-bit salt. And even then, since subnets are 64-bits wide in IPv6, it looks to me like the probability of the attacker guessing the IP address of some resource in the private network

          • You're not missing anything other than the fact that two exploits can be used in conjunction. There is a vulnerability in most browsers currently, for example, which lets some JS find whether a link has ever been visited by interrogating the stylesheet. Similar vulnerabilities can be used to get the address of the VPN server. Once you've done that, you can use this vulnerability to compromise the intranet. The second exploit is much harder if it's a publicly-routable (but firewalled) address.
      • the chances of you guessing its IP address are vanishingly small.

        Indeed. Vanishingly small is an understatement []

    • Re: (Score:2, Interesting)

      by Vuojo ( 1547799 )
      I would think so. It seems like everyone is using either or subnets and once in a while somebody has set up subnet so your internal addresses wouldn't be that hard to guess. With IPv6 we could forget all this NAT crap and use "real" IP addresses.
      • I would think so. It seems like everyone is using either or subnets and once in a while somebody has set up subnet so your internal addresses wouldn't be that hard to guess. With IPv6 we could forget all this NAT crap and use "real" IP addresses.

        Hmm, that is pretty cool actually, I never realized that we could just forgo NAT completely, but it makes sense! Man, that would be nice.

    • Actually, not really. Exploits could go after the default addresses interfaces take.
  • by 280Z28 ( 896335 ) on Thursday June 11, 2009 @06:44PM (#28301755) Homepage
    Isn't this the definition of a vulnerability or weakness in the client software? Just because you don't see xxxx as a threat in advance doesn't mean someone won't eventually use it as one.
    • Isn't this the definition of a vulnerability or weakness in the client software? Just because you don't see xxxx as a threat in advance doesn't mean someone won't eventually use it as one.

      Agreed. Clearly if it is susceptible to attacks, that is a "weakness".

  • Phew! (Score:5, Funny)

    by unifyingtheory ( 1357069 ) on Thursday June 11, 2009 @06:46PM (#28301775) Homepage
    Good thing I don't use the Internet.
  • by Saija ( 1114681 ) on Thursday June 11, 2009 @06:46PM (#28301787) Journal
    here []
  • Use it, and use random IP numbers

    • 10 net has 16,777,216 addresses to be precise : it's a full class A network. I had the same thought. It's only "quite" small because people use the default settings that ship with their routers which are generally 192.168*
    • by prockcore ( 543967 ) on Thursday June 11, 2009 @07:30PM (#28302237)

      While we're clearing up misconceptions, the 127.x.x.x network is an entire class A loopback.

      That means is identical to

      • Not identical (Score:3, Interesting)

        by TheLink ( 130905 )
        127.x.x.x addresses are supposed to go to the loopback device. But that does not mean they are identical.

        You could have different services/servers listening on different loopback IPs (though same ports). Then have your firewall rules redirect[1] different connections to the different servers.

        For some of the programs I write, to help prevent multiple instances from running I have the program bind exclusively to a "loopback address:port". It's ugly, but pretty effective :). If my program ever crashes or gets
    • It might be interesting to have the VPN software tell client programs (browsers) to flush cache whenever the former makes or breaks connection.

    • I just got done re-numbering my home LAN for similar reasons. I want to make sure that wherever I am, I can likely use my VPN without collision. I re-did everything for a random spot within

  • o..k (Score:5, Informative)

    by QuantumG ( 50515 ) * <> 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 DarkOx ( 621550 )

      Which is exactly why despite the bitching of my users, the VPN at our company routes everything to the gateway at my end of the VPN tunnels except of course VPN traffic itself which is obviously routed to the users normal gateway. Everything is axed via the firewall policy in the client.

      People don't like it because it means they can't use their network printers they have at home and their downloads to outside sites break whenever they connect or disconnect from the VPN. This is the only way though to gua

      • You're guarding against nothing.. just pushing extra traffic through the VPN and slowing down their internet connection.

        I bet 90% of them have just changed the default route back anyway.

        • I bet 90% of them have just changed the default route back anyway.

          The Grandparent does not talk about changing the default route, but about forcing all trafic, including local traffic which does not use the default route, through the VPN. The VPN client forces this at lower level than IP.

          Yes I, this is evil. A better solution is to use Remote Desktop Service through SSL or similar. This way the local webbrowser at home never connect to the business netwerk. However the exploit is stil posible if you use you

        • First of all, any good VPN client allows the admin to prevent that (i.e., I don't consider the built in Windows PPTP client to be an example of a "good client"). However, that being said, for almost any circumstance I'm pretty confident the number of users who would know to do that would be 1%.
  • VPN connections need special routing. If you don't trust your VPN partner totally, you should be sure that only the traffic you want goes over the connection.
  • by kosmosik ( 654958 ) <kos&kosmosik,net> on Thursday June 11, 2009 @07:17PM (#28302127) Homepage

    I think address space limitation is not an issue here. If I correctly understand this vulnerability means that for example some user has cached session cookies for intranet site like [] - then if he connects to other network (that I control) via VPN I can forge [] site in my network trick the browser by injecting JavaScript code and read this users session cookies? Do I understand this correctly?

    Well if I do then SSL/TLS certificates and cryptography in general are the means to authenticate someones (or some servers) indentity.

    So my question is: if sites in my intranet use proper PKI and SSL/TLS mechanisms am I still voulnerable to this flaw?

  • by brunes69 ( 86786 ) <slashdot.keirstead@org> on Thursday June 11, 2009 @07:18PM (#28302135) Homepage

    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: (Score:3, Interesting)

      by jrumney ( 197329 )

      I doesn't have to be an intranet addresses either. Consider that the DNS at Starbucks could have been compromised to redirect to the attacker's servers, thus gaining your login cookies for slashdot. And they could update your cached copy of slashdot's javascript while they're at it. What this boils down to is that connecting over http on an insecure network is a security risk, and not just for the period that you are connected.

  • Don't assume... (Score:3, Interesting)

    by FranTaylor ( 164577 ) on Thursday June 11, 2009 @07:19PM (#28302147)

    That your internal network is "safe"

    Keep up those firewalls and security on all machines on a network with Internet access.

    Belt-and-suspenders security is the only way if your resources are finite.

  • by azrider ( 918631 ) on Thursday June 11, 2009 @07:38PM (#28302309)
    The article specifically mentions VPN's (Virtual Private Networks). By definition, these are encrypted. Unless the attack happens prior to the VPN connection, how does the attacker inject anything into an encrypted datastream? If it is done prior to the connection, what is new about the attack vector
    Once the VPN is connected, for all intents and purposes the equipment on both ends of the line are on the same LAN (different segment maybe, but not necessarily). This is much smoke and no flame.
    • by Anonymous Coward
      Exploit: user connects to free WiFi which uses 10. or 192.168. addresses. That WiFi connection inserts iframes into with whatever they want to cache. User views, doesn't notice the iframes. User later connects to their VPN and brings up one of their intranet pages that got cache-poisoned via an IP URL. Attacker's cached Javascript now runs with the user's rights to that intranet page.
    • Once the VPN is connected, for all intents and purposes the equipment on both ends of the line are on the same LAN

      You're missing the point, which is that whether or not you're connected to the VPN, chances are good that your browser stores some credential information. If you're on a LAN that's the same subnet as your VPN endpoint, then once you disconnect, a malicious local user would be able to coax your browser to give up cookies about the VPN-accessed pages. Your browser uses IP addresses to associate a cookie with a host, which is what makes this possible, and explains why the certificate model of HTTPS on the corp

  • >> But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses, Hansen estimates--collisions between networks often occur.

    First of all there is no such thing as non-routable IP addresses. While private IP space may not be routed on the Internet, it is all routable on the private network.

    Secondly, 10. private IP space is a Class A assignment which translates to 16,777,216 IP addresses. Where did they get 1280?

    Or am I missing some
    • Re:Say What??? (Score:4, Informative)

      by Tony Hoyle ( 11698 ) <> 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.

  • It's a switcheroo (Score:1, Informative)

    by Anonymous Coward

    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 over

    • by wintermute000 ( 928348 ) <`ua.moc.sserpxetenalp' `ta' `redneb'> on Thursday June 11, 2009 @11:11PM (#28303945)

      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

  • by Anonymous Coward

    Let's not forget upnp, which a ton of fools leave enabled: [] []

    Ask 20 random people outside of a computing environment how they disable javascript in their browser and gauge their responses, now ask about Iframes. A growing number of javascript attacts are targeting arp in interesting ways, upnp or no. If you're not in a static arp environment, do the research *now*.

    I simply won't use NoScr

  • This all relies on being able to arrange a collision of RFC1597 addresses if you use

    echo 10.$((RANDOM%256)).$((RANDOM%256)).0/24


    echo 172.$((RANDOM%16+16)).$((RANDOM%256)).0/24


    echo 192.168.$((RANDOM%250+4)).0/24

    to choose your trusted network it becomes a lot harder. The 172 range seems especially overlooked.

    A targeted attack, where the attacker isn't guessing addresses, is still possible of course.

    BTW: This has always been suggested because of the possibility of later merges of multiple private networks.

Matter cannot be created or destroyed, nor can it be returned without a receipt.