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!
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.
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.
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
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)
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.
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.
That's not what the ladies say... ;)
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.
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
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.
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.