Slashdot Mirror
New Exploit Uses JavaScript To Compromise Intranets, VPNs
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.'"
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
Worldwide Military budgets: $2100 billion. Worldwide Space Exploration budgets: $38 billion. Really, world? Really?
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.
Turning coffee into code.
Good thing I don't use the Internet.
here
Slashdot ya no es que lo era!
Use it, and use random IP numbers
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
How we know is more important than what we know.
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.
How we know is more important than what we know.
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.
The force that blew the Big Bang continues to accelerate.
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 - then if he connects to other network (that I control) via VPN I can forge http://10.0.0.1/intranet 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?
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.
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.
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.
And ye shall know the truth, and the truth shall make you free.
John 8:32(King James Version)
>> 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 something here?
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
Robert Hansen is a MAN, not a horse. Get your facts straight!
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.
It might be interesting to have the VPN software tell client programs (browsers) to flush cache whenever the former makes or breaks connection.
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 :)
How we know is more important than what we know.
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.
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.
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.
Let's not forget upnp, which a ton of fools leave enabled:
http://www.gnucitizen.org/blog/flash-upnp-attack-faq
http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play
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.
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.
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.
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.
Atari rules... ermm... ruled.
127.x.x.x addresses are supposed to go to the loopback device. But that does not mean they are identical.
:). 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.
;).
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
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.
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 is vanishingly small.
Or am I missing something? I'm far from being an expert on networking.