VPN Flaw Shows Users' IP Addresses 124
AHuxley writes "A VPN flaw announced at the Telecomix Cyphernetics Assembly in Sweden allows individual users to be identified. 'The flaw is caused by a combination of IPv6, which is a new Internet protocol due to replace the current IPv4, and PPTP (point-to-point tunneling protocol)-based VPN services, which are the most widely used. ... The flaw means that the IP address of a user hiding behind a VPN can still be found, thanks to the connection broadcasting information that can be used to identify it. It's also relatively easy to find a MAC address (which identifies a particular device) and a computer's name on the network that it's on.' The Swedish anti-piracy bureau could already be gathering data using the exploit."
garbage in, garbage out... (Score:2, Informative)
Any Network Admin worth his weight... (Score:3, Informative)
Wait, IPv6+PPTP+IPSEC only? (Score:5, Informative)
You don't need PPTP if you're using IPSEC and IPv6. Even Microsoft clients don't need it any more.
Re:garbage in, garbage out... (Score:3, Informative)
Re:Any Network Admin worth his weight... (Score:5, Informative)
Any Network Admin worth his weight has not been using pptp for vpn for quite some time. IPSEC (AES) anyone? Just sayin.
IPSEC doesn't have to use AES, it supports other ciphers. Further, PPTP does not specify encryption, but Windows clients use MPPE, which is RSA RC4.
Re:Tor (Score:3, Informative)
Cipher Conference Video (Score:4, Informative)
Re:garbage in, garbage out... (Score:5, Informative)
assigning a second IP address, that you also control, to an interface is not 'spoofing' in any sense of the word. If you assign an IP address that I control, then you're spoofing, at which point you have the same problem in IP6 that you have in IP4.
Re:garbage in, garbage out... (Score:3, Informative)
Kind of two separate arguments.
Lets look at the original posters claim
MAC address sure, since your device's MAC address isn't used after your packets reach the ISP's border. However, I invite you to try to establish a full duplex connection using a spoofed IP.
Now his point is that your MAC is irrelevant beyond your layer 2 link. OK, correct on ipv4.
However, what if you use ipv6 and RFC 2462 "Stateless Address Autoconfiguration" which basically picks your ipv6 address based on your MAC address. Wedging a 48 bit mac address into, say, a /28 of ipv4 space isn't going to work too well, but wedging a 48 bit mac address into a /64 LAN of ipv6 works pretty well.
http://www.ietf.org/rfc/rfc2462.txt [ietf.org]
Now the argument is that no matter which ISP you connect to, or which starbucks you connect to, etc, you can always correlate that large collection of 128 bit ipv6 addresses in a log by trashing the upper 64 bits and figuring out which 48 bit mac addresses map into the /64 ipv6 addresses.
Even worse, the top 24 bits of the mac define the device manufacturer, so no matter where you go in the world, people know you've got an apple, or whatever.
So, "your device's MAC address isn't used after your packets reach the ISP's border" isn't really true if your layer 3 address depends directly on your layer 2 address.
On the other hand, if instead of using your autoconfigured address, you fake or "spoof" some other random /64 on the LAN, then you can't be tracked. Now if you do this at work, your local net nanny is going to get all teed off that some "unknown" mac address is online, because look at that ipv6 address that doesnt match any known inventoried hardware MAC address.
You can insist that using a "fake" MAC is not spoofing, or whatever, but then you're getting into pointless naming games.
Re:Tor (Score:3, Informative)
Somebody who listens to your tor traffic at your end has absolutely no way of telling who you are communicating with. so who you are talking to is just as hidden as what you say. All packets in the tor network are encrypted in such a way that the contents are only ever known by the exit node. There is little point in using SSL if sending a file to wikieaks via tor, since only wikileaks and the exit node would see the plaintext even over plain old http, and neither would be able to determine who or where the sender was. If wikileaks is going to publish what you sent anyway, so the exit node could see it upon publication, there is little reason to hide anything, unless there is identifying information in your submission that wikileaks has agreed not to republish. In that case using SSL over tor to talk to wikileaks makes good sense.
You would use SSL over Tor only if there was some reason why the it would be undesirable for the exit node to hear what you are saying, and you also want to hide your identity or perhaps only your location from the server you are talking to.
Re:Tor (Score:3, Informative)
The exit node might know that there's an SSL connection going through his computer that terminates at wikileaks. If everything is configured properly he should be unable to determine where that SSL connection originated.
Re:Cipher Conference Video (Score:1, Informative)
Unfortunately the talk is structured very poorly. The talk is about several deanonymization techniques: Flash, which allegedly does not respect proxy settings (I think it's an option), can be used to establish connections outside of the VPN if you can make the victim open a web page. Alternatives are image URLs with FTP or other protocols for which no proxy on the VPN is configured, etc. The IPv6 problem is of the same nature: If you link to an image with an IPv6 address in the URL, the request will not go through the VPN but through the normal IPv4 interface where the OS uses an IPv6 translation scheme which uses the real IPv4 and MAC addresses as part of the IPv6 address.
The common idea between all these attacks is that not all connections are forced through the VPN (or dropped) and the applications can still see the local network environment and leak this information. This is a problem shared by all VPN technologies. If you want to avoid this, make a VPN router connect to the VPN and expose only the VPN to the local network. The only packets which are ever allowed on the real external IPv4 interface should be the encapsulated tunnel packets and packets necessary for setting up the tunnel. You can still leak information by (stupidly) making services available which leak local information (like network shares, browser services with identifying names, etc.).