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.'"
IPv6? (Score:4, Interesting)
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?
-Taylor
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.
Re: (Score:2)
I like protocols with encryption. IPv6 supports no encryption at all on the IP layer.
Are you a troll, or are you really unaware of the fact that IPSec is an optional part of IPv4 and a required part of IPv6?
Re: (Score:2)
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.
Possible? Yes. Realistic? No. (Score:1)
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
Re: (Score:2)
Re: (Score:2)
the chances of you guessing its IP address are vanishingly small.
Indeed. Vanishingly small is an understatement [krytosvirus.com]
Re: (Score:2, Interesting)
Re: (Score:2)
I would think so. It seems like everyone is using either 192.168.0.0/24 or 192.168.1.0/24 subnets and once in a while somebody has set up 10.0.0.0/24 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.
-Taylor
Re: (Score:3, Informative)
172.16.0.0/12
Re: (Score:1)
Re: (Score:2)
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.
Definition of vulnerability or weakness? (Score:4, Insightful)
Re: (Score:2)
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".
-Taylor
Phew! (Score:5, Funny)
Re: (Score:2)
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: (Score:2)
If bad guys control the server end of the VPN the entire network is likely compromised and needs to be shut down for de-lousing. DNS injection attacks (hell, why bother, ARP spoof) are just the icing on the cake.
And of course the server end of a VPN can redirect any URL to any IP. It's called a proxy. Lots of companies use them.
Re: (Score:2)
Ya.. I don't really get why this attack would be of much concern to anyone, but that's not a requirement for security research these days :)
Straight from the horse mouth (Score:5, Informative)
You need your eyes examined (Score:1)
Re:You need your eyes examined (Score:4, Funny)
That's not what the ladies say... ;)
Network 10 has more than 1280 addresses. (Score:2)
Use it, and use random IP numbers
Re: (Score:2)
Re:Network 10 has more than 1280 addresses. (Score:5, Interesting)
While we're clearing up misconceptions, the 127.x.x.x network is an entire class A loopback.
That means 127.44.55.66 is identical to 127.0.0.1
Not identical (Score:3, Interesting)
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
Another possible mitigation (Score:2)
It might be interesting to have the VPN software tell client programs (browsers) to flush cache whenever the former makes or breaks connection.
Re: (Score:2)
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 172.16.0.0/12.
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: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:1)
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
Re: (Score:2)
The moral of the story (Score:2)
Address space limitation? (Score:3, Interesting)
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 http://10.0.0.1/intranet [10.0.0.1] - then if he connects to other network (that I control) via VPN I can forge http://10.0.0.1/intranet [10.0.0.1] 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?
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...
Re: (Score:2)
I think it's the other way around. First, you get malicious javascript loaded on http://10.0.0.1/myscript.js [10.0.0.1] when you visit the exploit site.
Then when you connect to http://10.0.0.1/myscript.js [10.0.0.1] on a different non-routable subnet you end up running the malicious script instead of the local version, which could include doing fun stuff against the HTTP server you are connecting to.
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: (Score:2)
Yes, but if you control the starbucks network, there's much easier ways to own people that don't rely on their internal network details.
Re: (Score:2)
You wouldn't be 'owning' the laptop users, you'd be gaining access to their private networks. If you logged enough info from the starbucks network, you could probably discover lots of internal sites that people had bookmarked and forgot which network they were on when clicking it.
The root of the problem seems to be caching scripts from sites the browser can't positively identify. Why didn't anyone think of this when XSS vulnerabilities first hit the front pages? You just shouldn't cache dynamic content f
Re: (Score:3, Interesting)
I doesn't have to be an intranet addresses either. Consider that the DNS at Starbucks could have been compromised to redirect slashdot.org 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.
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: (Score:1)
what I don't understand. I thought browsers would cache via server names and URI, not on base of the resolved IP address. So as long as your intranet is on intranet.example.com and not on 192.168.1.3 I can't see a problem.
Don't assume... (Score:3, Interesting)
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.
Maybe I'm missing something... (Score:3, Interesting)
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.
Re: (Score:1)
Re: (Score:2)
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
Say What??? (Score:1)
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)
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: (Score:2, Informative)
Re: (Score:3, 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 over
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
upnp, arp, javascript, iframes, pork me more! (Score:1, Interesting)
Let's not forget upnp, which a ton of fools leave enabled:
http://www.gnucitizen.org/blog/flash-upnp-attack-faq [gnucitizen.org]
http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play [gnucitizen.org]
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
Use 10.$((RANDOM%256)).$((RANDOM%256)).0/24 (Score:2)
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
or
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.