Become a fan of Slashdot on Facebook


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:2, Interesting)

    by Vuojo ( 1547799 ) on Thursday June 11, 2009 @07:01PM (#28301979)
    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.
  • 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?

  • 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 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

  • 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 jrumney ( 197329 ) on Thursday June 11, 2009 @08:33PM (#28302809)

    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.

  • by Anonymous Coward on Thursday June 11, 2009 @10:44PM (#28303695)

    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 NoScript since the recent negative news about it. I won't use Firefox, either. Opera offers a much wider and simpler blocking ability of content across the board. It's proprietary, but so is the flash plugin which most of you swallow while using Firefox. So are the graphics drivers in a lot of your *nix setups.

  • Not identical (Score:3, Interesting)

    by TheLink ( 130905 ) on Friday June 12, 2009 @05:52AM (#28305657) Journal
    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 SIGKILLed, the O/S will automatically free up the "lock", which is harder to do reliably and safely if I use filebased locking. Yes it's a waste of addresses and ports, but there are about 16 million loopback addresses I figure the server can spare a few of them.

    Anyway there are plenty of uncommon 10.x.x.x addresses. When I had to select 10.x.x.x address ranges for work-related purposes, I just picked ones that I thought that would be relatively unused and then googled for them to confirm they were relatively unused. I found it quite easy to guess which ones would be rare for some reason.

    I won't say which ones I picked of course ;).

    [1] If a hacker or a fault removes the firewall rules or the firewall stops working, hopefully the servers become inaccessible to the outside world.

Kill Ugly Processor Architectures - Karl Lehenbauer