free wi fi hotspots and vpn

securityguy

"Securityguy, there are huge risks taken when using open non-secure public WiFi hotspots & I would like to hazard a guess that a large number of those attending that conference would have been savvy-enough to be using VPN to connect to the www."

Outline them. We've now got two hard men telling us how much they know. Describe the attack. Describe an example of someone actually being a victim of such an attack.

The usual proposals involve using the access point to either intercept Google (for people who connect to banks by searching for the bank rather than using a bookmark) or to similarly run a DNS resolver which hands back incorrect IP numbers for some or all target websites. In fact, you can just assume the attacker can arbitrarily modify, observe, delete and inject traffic (a "Dolev Yao" attacker), so even if you have the correct address for the service you're accessing, the attacker can do what they want with your traffic and terminate it on a machine under their control.

However, in order to make this work, you need a certificate signed by a CA that the victim's browser will accept (especially now almost all browsers are using https to access Google, which pretty much kills the first attack).

There have, indeed, been attacks on CAs that have yielded a small handful of certificates, but there isn't the slightest evidence that such certificates are in anything approximating wide, or even narrow, circulation. If on the other hand they are (ie, if people are able to obtain certificates signed by widely-accepted root certificates which have banks or other valuable targets as the certificates) then they are hardly going to mess about doing one-at-a-time physical attacks on wireless APs, they're going to use much more scalable attacks to use those fake certificates much more widely.

Alternatively, they need to have access to the private keys associated with legitimate certificates and again, if the attacker has the private key for https://www.somebank.co.uk, how does messing around wireless access points materially improve their attack?

If you are using a VPN, it's not at all clear how it protects you in this scenario without a lot of extra care. Firstly, you're trusting the VPN provider, who can carry out precisely the same attacks as a putative Wireless AP attacker, but on a much larger scale. Second, even if you do trust the VPN provider (say, they're your employer), an attacker able to forge certificates and re-route IP traffic can carry out the strong attacks on many SSL VPNs, depending on the precise structure of the certificate chain that is being used. Yes, there are VPNs which are robust in the face of a Dolev-Yao attacker but they're not easy to configure correctly and not easy to use with full protection.

If you are likely to accept forged certificates, avoiding free WiFi won't make you any safer.

If you are able to generate forged certificates or have access to private key material, you don't need to mess about with Free WIFi.

You'd get a good paper for a good conference if you could find evidence that such attacks had happened. Such papers are in remarkably short supply, because the bad guys don't find it rewarding.

You can read in detail advice from the last Black Hat conference on how to set these APs up:

https://www.sensepost.com/blog/9460.html

You'll notice that useful attacks require users who are willing to click through bogus certificates, or the ability to forge real certificates.

"I ussed to work in QC for a major multi-national & my line manager used to work from home during the evenings using a works laptop. This used a VPN to connect at all times, as this was the company policy."

As indeed does everyone working from home. The reason why VPNs are company policy are not to do with concerns about the intervening network; the real benefit is that it allows you to punch a single hole in your firewall (for the VPN) and protect it with two factor authentication, and then have people outside the boundary accessing assets insider the firewall on IP numbers that aren't even routed over the Internet. The crypto on the link is a handy bonus, but the perimeter security it enables is far more important.

patman99

Let me explain it better.

A non-encrypted public WiFi hotspot (one without a password) sees the data flying around unencrypted so that anyone with packet sniffing software installed can 'grab' this data and view it.

It is the data equivalent of passing a hand-written note around a classroom. Everyone can have a read of it before it reaches the recipient.

Anyway, a good number of the low-lifes who were using laptops with data sniffing software on to steal people's bank and card details now use hacked phones and tablets with NFC built in, as it is much easier.

JJ_Egan

Yep NFC and wireless bank/ credit cards really surprised me when i carried out a simple test .See Eddie Lee Defcon 20 .

[Deleted User]

If you have home broadband with a fixed IP address, use a cheap Linux/Unix box with an SSH server running on it. Then on the client run Putty and connect to the box at home. More here:
http://alvinalexander.com/unix/edu/putty-ssh-tunnel-firefox-socks-proxy/

securityguy

patman99 wrote: »

Let me explain it better.

A non-encrypted public WiFi hotspot (one without a password) sees the data flying around unencrypted so that anyone with packet sniffing software installed can 'grab' this data and view it.

So what? You're using end to end encryption with https, yes? For everything that matters, yes? So either the encryption works, in which case it doesn't matter that you're using an insecure access point, or the encryption doesn't work, in which case it doesn't matter what access point you're using, you're still screwed.

And the WiFi encryption only encrypts the air-side of the traffic anyway, so an attacker who has control of the access point (which is the whole point of the claims made about the "insecurity" of free WiFi) by definition has control of the encryption used airside.

Again: lots of "oh, I know super elite stuff, bow down to me" FUD, but no-one is spelling out actual attacks that actually yield worthwhile returns, but which do not involve either obtaining forged SSL certificates or convincing users to accept bogus certificates. And if you can do those things, why do you care about airside encryption?

For the typical user, the main vectors of insecurity are clicking on links in phishing email and accepting bogus forged certificates. Neither of those threats depends on the attacker controlling the access point.

Fightsback

securityguy wrote: »

So what? You're using end to end encryption with https, yes?.

http://www.techrepublic.com/blog/it-security/convenience-or-security-you-cant-have-both-when-it-comes-to-wi-fi/

I'll go with Jacob Williams.

securityguy

Fightsback wrote: »

http://www.techrepublic.com/blog/it-security/convenience-or-security-you-cant-have-both-when-it-comes-to-wi-fi/

I'll go with Jacob Williams.

Who is talking about a different problem to the OP.

This discussion didn't start out about unencrypted WiFi, but about free WiFi. If the attacker controls the access point, it doesn't matter what encryption is in use airside, as the attacker has access to the plaintext.

Let's spell this out.

Unencrypted Wifi: everyone in the area can sniff traffic, the protection is a VPN or https.

Encrypted Wifi: anyone who controls the access point can sniff traffic, the protection is a VPN or https.

Using a VPN: the owner of the VPN server can sniff traffic, the protection is https.

There is nothing magical about a VPN: it's just a way of wrapping all your traffic in (approximately) the same protection https has and (approximately) it is subject to the same attacks.

RobTang

securityguy wrote: »

Again: lots of "oh, I know super elite stuff, bow down to me" FUD, but no-one is spelling out actual attacks that actually yield worthwhile returns, but which do not involve either obtaining forged SSL certificates or convincing users to accept bogus certificates. And if you can do those things, why do you care about airside encryption?

I would actually expect a good portion of users to accept invalid SSL certs, Its a viable attack vector and much more useful when they are directly connected to you as you can redirect anything rather then hoping they hit a random fake site

Right an attack, not really my area of expertise but I can theorise...
Lets say for the sake of argument your device is connected to my "bad" hotspot.

Account escalation (where you share the same password with multiple sites) and access to your email (can potentially use forgot your password to access sites)

Many people use sites which have accounts but are not SSL secured (eg forums) so I can intercept your password and hopefully re-use it on a more important site.

Email I reckon there's an additional vector, people who run their own domain names probably don't have SSL connections to their email server (like Hillary Clinton's server for the first 3 months), additionally both TalkTalk and EE don't seem to use SSL either for their email authentication, so again in both cases you can intercept the password.
Ok the potential targets is a lot smaller but it has the advantage of not requiring user interaction as clients will poll their email servers regularly and due to things like auto connect with name spoofing you could probably grab a fair few logins by just having people walk past your hotspot with their smartphone.

Now ill admit the strike rate will be extremely low and from that the amount of junk will be pretty high as well so probably not worthwhile but I reckon you'll turn a few interesting accounts and maybe some info for social engineering.

At worst I'll have some more passwords to add to dictionary attacks and to cross reference against stolen hashmap databases.

securityguy

Bloody hell, those mail services are shockers, aren't they? The SMTP only offers LOGIN and PLAIN and the EE one doesn't even offer STARTTLS, the TalkTalk (Opal, really) does offer STARTTLS but the configuration details turn it off. Similarly for POP, and the IMAP service doesn't seem to offer STARTTLS at all.

http://ee.co.uk/help/mobile-and-home-connections/broadband-gallery-mobile-broadband/fibre-broadband/home-broadband-email/broadband-email-settings

http://help2.talktalk.co.uk/email-settings-imap-pop3

I assume that these are legacy services with a small number of customers on them, which they haven't bothered to bring up to modern standards. Users of those services are at huge risk: wireless makes it worse, but they're at risk in any environment. A VPN in that situation would help, but it would be interesting to see EE/TT's justification for running services are completely insecure as that. I confess, I didn't realise that in 2015 any reputable provider would be exposing their customers to that much risk.

Trying 193.252.22.134...
Connected to smtp.orangehome.co.uk.
Escape character is '^]'.
220 mwinf5d43 ME ESMTP server ready
ehlo xxxx
250-mwinf5d43 hello [xxxx], pleased to meet you
250-HELP
250-AUTH LOGIN PLAIN
250-SIZE 44000000
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 OK

Fightsback

securityguy wrote: »

Bloody hell, those mail services are shockers, aren't they? The SMTP only offers LOGIN and PLAIN and the EE one doesn't even offer STARTTLS, the TalkTalk (Opal, really) does offer STARTTLS but the configuration details turn it off. Similarly for POP, and the IMAP service doesn't seem to offer STARTTLS at all.

Thank you for proving Jacob Williams's point

You can read his credentials here:

https://www.linkedin.com/pub/jacob-williams/16/38a/779