Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Exploit Uses JavaScript To Compromise Intranets, VPNs

timothy posted more than 5 years ago | from the criminal-enterprises-deal-in-cache dept.

Security 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.'"

cancel ×

87 comments

Sorry! There are no comments related to the filter you selected.

IPv6? (3, Interesting)

Facegarden (967477) | more than 5 years ago | (#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?
-Taylor

Re:IPv6? (4, Insightful)

mellon (7048) | more than 5 years ago | (#28301831)

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:IPv6? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28303347)

IPv6I don't like hackers to be able to nmap my whole subnet from remote to find some unpatched box. IPv6 doesn't support firewalls or NATs so its trivial to scan an address space, even one as big as IPv6.

I like protocols with encryption. IPv6 supports no encryption at all on the IP layer.

I like network stacks that have been through the bugs like land, smurf, ping of death, and other exploits that IPv4 has dealt with. IPv6 has yet to be tested against dedicated black hats.

Existing issues in IPv4 are a handful already. Why add another protocol to the mix that may make things worse?

Re:IPv6? (1)

TheRaven64 (641858) | more than 5 years ago | (#28306801)

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:IPv6? (1)

TheRaven64 (641858) | more than 5 years ago | (#28306791)

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. (1)

Mathinker (909784) | more than 5 years ago | (#28312805)

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.

Re:Possible? Yes. Realistic? No. (1)

TheRaven64 (641858) | more than 5 years ago | (#28314905)

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.

Re:IPv6? (0)

Anonymous Coward | more than 5 years ago | (#28323419)

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.

I respectfully disagree.

A person implementing this attack will not be guessing the network address. They will probe for or have that information before-hand. As the FTA mentions, this attack is most likely to be used between companies with some sort of relationship. Such scenario would make guessing the victim's network address unnecessary

Re:IPv6? (2, Interesting)

Vuojo (1547799) | more than 5 years ago | (#28301979)

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.

Re:IPv6? (1)

Facegarden (967477) | more than 5 years ago | (#28302065)

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:IPv6? (0)

Anonymous Coward | more than 5 years ago | (#28302153)

don't forget 172.16.0.0/20, the other private address space

Re:IPv6? (2, Informative)

TCM (130219) | more than 5 years ago | (#28302567)

172.16.0.0/12

Re:IPv6? (0)

Anonymous Coward | more than 5 years ago | (#28305099)

Actually not. The world has decided they still want NAT with IPv6.

Slashdot loses again because they are losers who live in their basements and never have touched a boob and are wrong about every single technology.

Re:IPv6? (1)

lavacano201014 (999580) | more than 5 years ago | (#28310459)

But if we were right, we wouldn't be Slashdot.

Re:IPv6? (1)

Shadow-isoHunt (1014539) | more than 5 years ago | (#28302381)

Actually, not really. Exploits could go after the default addresses interfaces take.

Re:IPv6? (0)

Anonymous Coward | more than 5 years ago | (#28302601)

We are talking about IPv6 [wikipedia.org] the protocol that does things like choose 40 bits of an address randomly and include the MAC address in the IP by default, right?

Re:IPv6? (3, Insightful)

mellon (7048) | more than 5 years ago | (#28305047)

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? (4, Insightful)

280Z28 (896335) | more than 5 years ago | (#28301755)

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.

Re:Definition of vulnerability or weakness? (1)

Facegarden (967477) | more than 5 years ago | (#28301777)

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

oh no (0)

Anonymous Coward | more than 5 years ago | (#28301769)

they are taking over our intranets

Phew! (5, Funny)

unifyingtheory (1357069) | more than 5 years ago | (#28301775)

Good thing I don't use the Internet.

Re:Phew! (0)

Anonymous Coward | more than 5 years ago | (#28304881)

Good thing I don't use the Internets.

There, I fixed that for ya.

Re:Phew! (1)

dominious (1077089) | more than 5 years ago | (#28305595)

Has anyone else read the title as "New Exploit Uses JavaScript To Compromise the Internets" ?

Only an issue if you use IP based URLs (0)

Anonymous Coward | more than 5 years ago | (#28301783)

It's only an issue if you use the IP address in your URL. If you don't, you're pretty much OK (unless the attackers can hijack DNS, in which case you've got other problems anyway).

Re:Only an issue if you use IP based URLs (4, Informative)

QuantumG (50515) | more than 5 years ago | (#28301893)

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:Only an issue if you use IP based URLs (1)

Tony Hoyle (11698) | more than 5 years ago | (#28302583)

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:Only an issue if you use IP based URLs (1)

QuantumG (50515) | more than 5 years ago | (#28302667)

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 :)

Re:Only an issue if you use IP based URLs (0)

Anonymous Coward | more than 5 years ago | (#28303603)

The attack is a combination of two components: Spoofing and persistence. The VPN puts the rogue admin in the position to spoof web server responses for servers on the rogue network (naturally) and on the victim's network. This enables him to poison the victim's browser cache, which creates a backdoor to the victim's network after the VPN is disconnected. This is possible because the VPN client must accept routes to RFC1918 addresses: Collisions are very likely and without these routes the VPN would not work. The same attack works with public addresses, but then the client could reasonably reject routes to addresses which are not on the network that he wants to connect to. If the victim physically connects to a rogue network, private of public doesn't matter.

A key point of the attack is that the end of the VPN connection is not the end of the rogue admin's influence over your computer. Flush your caches.

Re:Only an issue if you use IP based URLs (0)

Anonymous Coward | more than 5 years ago | (#28304273)

If you read the article it is talking specifically about a situation where you are connecting to an untrusted VPN (such as in the case of connecting to a partner or a vendor), and this untrusted VPN then goes about having the browser cache results for pages that would exist on the internal trusted VPN. Via Javascript and some other magic this then results in an exploit.

Straight from the horse mouth (5, Informative)

Saija (1114681) | more than 5 years ago | (#28301787)

here [sectheory.com]

You need your eyes examined (1)

rattaroaz (1491445) | more than 5 years ago | (#28302415)

Robert Hansen is a MAN, not a horse. Get your facts straight!

Re:You need your eyes examined (4, Funny)

Anonymous Coward | more than 5 years ago | (#28302907)

That's not what the ladies say... ;)

Network 10 has more than 1280 addresses. (1)

John Hasler (414242) | more than 5 years ago | (#28301809)

Use it, and use random IP numbers

Re:Network 10 has more than 1280 addresses. (1)

skelly33 (891182) | more than 5 years ago | (#28302141)

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*

Re:Network 10 has more than 1280 addresses. (0)

Anonymous Coward | more than 5 years ago | (#28303773)

Generally, yes. I happened to buy a "Zoom" and its default is 10.x.x.x. Zoom seem like very smart people.

Re:Network 10 has more than 1280 addresses. (4, Interesting)

prockcore (543967) | more than 5 years ago | (#28302237)

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

TheLink (130905) | more than 5 years ago | (#28305657)

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.

Another possible mitigation (1)

Burz (138833) | more than 5 years ago | (#28302607)

It might be interesting to have the VPN software tell client programs (browsers) to flush cache whenever the former makes or breaks connection.

Re:Network 10 has more than 1280 addresses. (1)

SCHecklerX (229973) | more than 5 years ago | (#28311047)

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 (5, Informative)

QuantumG (50515) | more than 5 years ago | (#28301863)

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:o..k (1)

DarkOx (621550) | more than 5 years ago | (#28302529)

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 guard against these types of attacks.

Re:o..k (1)

Tony Hoyle (11698) | more than 5 years ago | (#28302631)

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:o..k (1)

Sprinkels (41102) | more than 5 years ago | (#28305859)

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 your laptop at home and at work. (Or visit the unsafe websites with your work computer.

Re:o..k (1)

IceCreamGuy (904648) | more than 5 years ago | (#28306789)

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%.

Re:o..k (0)

Anonymous Coward | more than 5 years ago | (#28303365)

I think you might be confused as to why you'd do that. It doesn't make the client any more secure. It prevents the client from creating a proxy in from the outside.

Some default "share my internet connection" configurations would automatically create that proxy.

Of course it does nothing to prevent someone from opening a proxy to get outside once they are in. So it only protects you from accidental proxies. People who actually want to circumvent your security can still do it.

Re:o..k (0)

Anonymous Coward | more than 5 years ago | (#28303495)

That is precisely how this attack works. By making the client route everything, including the RFC1918 addresses, to your network, you reroute traffic which is destined for a server on the client's network to your network, where you can respond to this traffic with your own server. The reason why your users can't use their network printers is that their computers are now trying to talk to IP addresses on your network. You could see what they try to print: simply configure a printer to respond to these requests. You could embed iframes in your local web pages which cache subverted scripts to replace the scripts that your user's router uses. When your user logs out of the VPN and logs in to his router, your script will be used because it's still cached.

It should be noted that this attack does not strictly rely on RFC1918 addresses. The attacker could just as well cache data for servers on routeable addresses, as long as he can spoof that server's response and embed the references in inconspicuous web pages. A person typically in a position to perform this kind of attack is the network administrator on any network which the victim uses, not just a VPN. Obvious candidates would be public WLANs, internet cafes, customer networks and vendor networks (public or private IP address space doesn't matter in that case). The only reason why RFC1918 addresses complicate this issue is that VPN clients are typically configured to accept routes from the VPN server for the whole RFC1918 address space, because collisions are frequent and the client would be unable to reach the servers on the remote network if these routes were rejected. If VPNs were only used to authenticate and encrypt traffic on existing routes, then the network admin on the remote network would not be in a position to spoof responses from servers which are not under his control anyway.

The bit to take home from reading that paper is that connecting to a VPN is like physically moving the computer to another network, unless you reject all additional routing information (which you can't do if RFC1918 addresses are involved).

Rsnake? (0)

Anonymous Coward | more than 5 years ago | (#28301877)

Does he hack with Zero Cool and Acid Burn against The Plague?

HACK THE PLANET!

The moral of the story (1)

rednip (186217) | more than 5 years ago | (#28301985)

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.

Re:The moral of the story (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28302279)

If your partner is kathleen fent, don't trust her. bitch has anal warts.

FailZors? (-1)

Anonymous Coward | more than 5 years ago | (#28302063)

Address space limitation? (2, Interesting)

kosmosik (654958) | more than 5 years ago | (#28302127)

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? (4, Insightful)

BikeHelmet (1437881) | more than 5 years ago | (#28303071)

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:Address space limitation? (0)

Anonymous Coward | more than 5 years ago | (#28305465)

Nope, you won't. It was stated in his article [sectheory.com] that HTTPS is immune.

Well, unless you bring sslstrip [thoughtcrime.org] into the equation. Robert Hansen states that all the parts are here, it's just a matter of assembling them and making them work together. Can't agree more.

Re:Address space limitation? (1)

bwcbwc (601780) | more than 5 years ago | (#28311037)

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 (5, Insightful)

brunes69 (86786) | more than 5 years ago | (#28302135)

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:I don't see any actual erxploit here (0)

Anonymous Coward | more than 5 years ago | (#28302273)

Actually you don't need the VPN, consider something like this.

I visit the starbucks across from my office and use their wireless. Through evil intent some HTML is modified to pull down and cache some URLs that collide with the URLs in my internal network. I go back across the street, plug in and unknowingly use the cached URLs which have javascript fragments that leak information out to the attacker.

Betcha can find lots of cases where laptops of a known company congregate and use an insecure wireless and then with knowledge of that companies internal servers you could craft the collisions.

SSL is an effective mitigation, you would now also need to get a forged certificate to poison the cache.

Re:I don't see any actual erxploit here (1)

IntlHarvester (11985) | more than 5 years ago | (#28305119)

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:I don't see any actual erxploit here (1)

ToasterMonkey (467067) | more than 5 years ago | (#28311315)

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 from sites without trusted certificates, period :\

Re:I don't see any actual erxploit here (2, Interesting)

jrumney (197329) | more than 5 years ago | (#28302809)

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 (3, Insightful)

brunes69 (86786) | more than 5 years ago | (#28303351)

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:Er...that is not a new exploit, and makes no se (0)

Anonymous Coward | more than 5 years ago | (#28304529)

DNSSEC wouldn't prevent this exploit, since an untrustworthy network can let you think you're talking to whatever IP you want, including the ones DNSSEC says are trusted.

Re:Er...that is not a new exploit, and makes no se (1)

Gunstick (312804) | more than 5 years ago | (#28305369)

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.

Re:I don't see any actual erxploit here (0)

Anonymous Coward | more than 5 years ago | (#28305685)

a) No, the browser can not do anything against this attack. As far as the browser is concerned, it is talking to the victim's own server, so everything it sees can and will be cached. The user will not visit his own server's web page when on an untrusted network, but the admin of an untrusted network can (trivially) inject iframes into other HTTP-delivered pages and make the victim's browser load URLs from the address of the victim's own server.

b) The point of the paper is that people too easily trust other networks and think that using non-routable addresses somehow protects their own network. A VPN is just one way to connect the victim's computer to an untrusted network (vendor, client, internet cafe, open WLAN, ...) The paper lists some common scenarios where the sole purpose of the VPN is to protect the network that the client connects to. The victim does not necessarily trust the VPN network. Like you, the victim thinks: "My system is patched, my browser is not vulnerable, I'm safe."

c) You have to visit just one arbitrary non-SSL page. That's it. The attacker injects iframes into it, the iframes load URLs which collide with your local servers. Guessing names of servers and script file URLs is not that hard because many networks use the same names/IPs and appliances. The attacker can just sweep the most common ones and have a hit.

In response to other responses:

This is not about cookie-stealing. The victim is security-conscious and uses neither cookies nor credentials while on an untrusted network. This attack still owns the victim, because the cache persists until the victim is back on his trusted network where he enters credentials and accesses confidential information.

DNSSEC does not protect against this attack, because it is a routing-level attack. No DNS manipulation is necessary.

The problems are
1) trust of non-routable addresses as being safe from external interference and
2) the false belief that the risk of accepting information through untrusted networks only persists as long as the untrusted network is connected.

Don't assume... (2, Interesting)

FranTaylor (164577) | more than 5 years ago | (#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.

Re:Don't assume... (0)

Anonymous Coward | more than 5 years ago | (#28306837)

Firewalls don't prevent this attack. Security on all machines can be impeccable and the attack is still possible. The intranet does not need an Internet connection for this attack to be able to cause harm. The browser cache does all the walking. If one machine from the intranet also connects to a rogue network at times (internet cafe, open WLAN, etc.), then the attack can happen. Proper SSL (i.e. with unique certificates) prevents the attack.

Maybe I'm missing something... (2, Interesting)

azrider (918631) | more than 5 years ago | (#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.

Re:Maybe I'm missing something... (1)

Anonymous Coward | more than 5 years ago | (#28302725)

Exploit: user connects to free WiFi which uses 10. or 192.168. addresses. That WiFi connection inserts iframes into google.com with whatever they want to cache. User views google.com, 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.

Re:Maybe I'm missing something... (0)

Anonymous Coward | more than 5 years ago | (#28304101)

The article specifically mentions VPN's (Virtual Private Networks). By definition, these are encrypted.

Nope. IPsec allows for a VPN using authentication only, without encryption. But you would have to be pretty weird to do that.

/pedantic

Re:Maybe I'm missing something... (0)

Anonymous Coward | more than 5 years ago | (#28304279)

So VPN's are a poor example. What about motel networks?

Of course, there are so many other attacks available on untrusted networks. They can create their own DNS zones and realistic websites so I am tricked into entering my password there. The can redirect my http traffic through a squid server and collect my cookies. And since they control the DNS, they can use that SSL root signing hack that was on /. a while back. So they can spoof SSL sites too.

Just like in the real world, you can never be perfectly secure.

Re:Maybe I'm missing something... (1)

IceCreamGuy (904648) | more than 5 years ago | (#28306887)

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 corporate Intranet foils this attack.

javascript backdoor? (0)

Anonymous Coward | more than 5 years ago | (#28302319)

could someone explain how that part works? why isn't javascript sandboxed properly?

Say What??? (1)

al0ha (1262684) | more than 5 years ago | (#28302409)

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

Re:Say What??? (0)

Anonymous Coward | more than 5 years ago | (#28302489)

> Or am I missing something here?

Reading comprehension.

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

It's true. Most of the time, you see 192.168.0.x - 192.168.4.x

Re:Say What??? (3, Informative)

Tony Hoyle (11698) | more than 5 years ago | (#28302555)

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.

Author of article is a fucking cunt (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28302511)

"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."

Wait, wat?

RFC1918 has only 1280 addresses?

I stopped reading at this point. If authors cannot get _BASIC_ facts right, how the fuck can I believe _ANYTHING_ else this cunt says?

In short, this whole thing is a load of shit. Sure, its not difficult to do if you have full control of a network. But whats hard when you have full control?

tl;dr author is a fucking clueless poseur.

Re:Author of article is a fucking cunt (2, Informative)

Philip_the_physicist (1536015) | more than 5 years ago | (#28302775)

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.

Re:Author of article is a fucking cunt (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28302951)

You sir are wrong. Define "normally used". The author seems to be a noob who thinks rfc1918 is 10/8 and 192.168/16, and that people only use a few subnets out of this space. WRONG.

And he then says the available pool is 1280 addresses. It is not 1280 addresses, rather a figure in the millions.

Can you spell ignorant? What about short sighted? What about naive? All 3 of those words come to mind when reading this imbeciles attempt at this supposed exploit.

Re:Author of article is a fucking cunt (0)

Anonymous Coward | more than 5 years ago | (#28303885)

Actually, he specifically says what RFC1918 is, so no ignorance there. I believe what he means is that most default home networks and corporate networks are only using a few subnets. I guess if you aren't a normal business or home network, this wouldn't apply, but I would hardly say he's ignorant.

Re:Author of article is a fucking cunt (2, Informative)

iggymanz (596061) | more than 5 years ago | (#28304579)

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.

Re:Author of article is a fucking cunt (0)

Anonymous Coward | more than 5 years ago | (#28304007)

teach me to be as cool as you, faggot

It's a switcheroo (1, Informative)

Anonymous Coward | more than 5 years ago | (#28303339)

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.

Re:It's a switcheroo (3, Insightful)

wintermute000 (928348) | more than 5 years ago | (#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

upnp, arp, javascript, iframes, pork me more! (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28303695)

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

Use 10.$((RANDOM%256)).$((RANDOM%256)).0/24 (1)

rdebath (884132) | more than 5 years ago | (#28304541)

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.

nothing new (1)

x4r (1573235) | more than 5 years ago | (#28306207)

95%(!!!!)of internet exploits - uses Java Script to inject/execute maliciouse content. last ten years. and btw, NOT EVER ONE antivirus - has monitor and clarify JS activity on owner PC's, browsers. p.s. weak corporation - tend to use JS, against SQL logic(UDF code in SQL servers), which is BAD in both terms security, performance, cost. and both infect pages with 3rd-party content(well know that almost ALL internet adverisement network(such as banner networks), have malicious content or at least - used by govt inteligency agencies), or [censored]Adobe Flash, which is "insecure by design" and used for intel, long ears ago, too.

Re:nothing new (0)

Anonymous Coward | more than 5 years ago | (#28321959)

I couldn't understand a single thought of yours.

Learn some fucking English.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?