Title: An Open Question (or How I Learned To Stop Worrying And Love Public Wi-Fi)

Author: Martin Moene

Date: 10 March 2016 14:39:26 +00:00 or Thu, 10 March 2016 14:39:26 +00:00

Summary: Vertices examines some of the dangers of using other people’s networks.

Body: 

A paranoid is someone who knows a little of what’s going on.
~ William S. Burroughs

Just because you’re paranoid doesn’t mean they aren’t after you.
~ origin unknown

The term ‘computer virus’ was coined over 30 years ago [1] to describe self-replicating computer programs, and since then, we’ve become very well acquainted with the threats posed by computer malware of many different kinds. It’s a brave personal computer owner who has no anti-virus protection, and more general anti-malware programs are becoming popular too. Many people, however, believe that this protection is both necessary and sufficient.

It’s becoming increasingly apparent that Identity Theft is a burgeoning problem (see [2] for some data from early 2015), and in an age when wireless Internet connectivity is considered essential, as is being able to have it whilst out-and-about, it is here that we are the most vulnerable.

These vulnerabilities present challenges to the developers of mobile applications and connected devices, too, since they have a responsibility to protect their customers’ information. In this article I want to consider some of the risks with this continuous connectivity, on the basis that fore-warned is fore-armed. To finish off, I’ll suggest some simple things you can do to mitigate or eliminate those risks.

Threat landscape

The Age of Mobile Communications is in full swing, no doubt about it. Mobile phones have been with us for a good while, but much more recently, those phones have become ‘smart’, which essentially means ‘connected to the Internet’. Although the take-up of technology such as 4G has been good (by the look of it), the coverage in the UK is still very patchy, and so many people take advantage of cafés, hotels, coffee shops and pubs providing customer Wi-Fi – often for free. Naturally enough, this has led to an increase in the use of these establishments as temporary offices, establishing a kind of barter trade of connectivity for beer/coffee/snacks which seems to be largely tolerated on both sides.

Many of us routinely allow our telephones, tablets, laptops, etc., to just connect to any wireless signal going, and use that channel to catch up on email, social media of various types, The News, whatever. With all of this wireless communications traffic saturating (in some cases, literally) the air-waves, it’s no wonder, then, that folk with less than entirely honourable intentions have taken advantage.

Public Wi-Fi is only one part of the problem. The Internet of Things is a much less visible network of connected devices, and demonstrably vulnerable to attack (for some fun examples, see [3], and [4]). At least part of the reason that so many security flaws are found in such devices is that they are designed to be small, and have low power requirements, which translates to having insufficient processing power and/or resources to spare for things like encryption.

The home front

You might think that being able to crack your home router would be the crown jewels for most miscreants (and you shouldn’t underestimate how bad that would be), but it’s sufficiently difficult, if the security is good enough, that if an attacker can’t get in with ‘password’, they’ll probably give up. The norm these days is for home routers to use WPA2 with a pre-shared key – which is good enough as long as the password is sufficiently strong. (WEP security for routers is known to be deeply flawed. [5])

The primary goal of an attacker is usually financial: if they cannot gain direct access to your bank account (and they almost certainly cannot do that), then the aim is to obtain enough information about you to be able to impersonate you well enough to transfer your money by convincing your bank that it is you authorising it, or spend your money by clocking up online transactions using your credit card or other means.

Of course, there are the obvious bits of information that are of direct interest – credit card numbers and security codes, your father’s middle name, and so on – but any information is valuable, and can be obtained in a variety of ways. Your online presence in social networking, online petitions, mailing lists, just about anything, could provide someone with at least part of the means to pretend to be you, but hijacking your home router probably isn’t the most effective way to obtain it. If I were an attacker, I wouldn’t bother with targeting a single individual unless I knew it was going to be worth it. I’d much rather cast a wide net, and see what I could find.

By which I mean sitting in a public place when it’s busy, and letting all that traffic come to me.

Hackers’ delight

My mate Norm is a reasonably tech-savvy fellow. He lives in a fashionable part of town near to his work where he does ‘something in IT’, which is mostly keeping a small company email and web server in good order, and making sure the backups get run. It’s not unusual on a Friday early evening to see him join some friends in one of the many bars that litter the route between the office and home, and tonight is the turn of a pub called The Queen’s Head. He orders his round of drinks at the bar, and while he’s waiting, he takes out his phone and checks to see if there’s a wireless network in range so he can try and round up a few more people to make a night of it.

Sure enough, he finds a nice strong signal from an access point (AP) broadcasting its name as ‘QueensHead Customer Wifi’. It’s an open network, so he doesn’t have to go to the bother of asking for the Wi-Fi password, or seeing if it’s written up anywhere, so he connects and is away on the Internet.

Is Norm taking unnecessary risks by doing this?

This being an open network, the traffic is unencrypted, and could – in theory – be ‘sniffed’ by anyone. This only matters, of course, for sensitive information being transmitted or received, e.g. login credentials, passwords, the stuff that Norm knows he wants to keep private. In practice, most or all of this traffic will be encrypted before it reaches the network, most commonly with a HTTPS connection from a browser or mobile-app versions of his social networking sites.

So, while an eavesdropper on the network can inspect the traffic, it’ll still be encrypted. The security isn’t perfect (there really is no such thing), but it’s sufficiently difficult to crack the channel encryption that it will defeat anyone but the most determined and skilled attacker, who probably doesn’t care about Norm’s friends’ updates on social networks, to be honest. (And if you think you are the target of such people, you already know how to protect yourself better than I do.)

Is it enough for Norm to depend on that level of security? What are the risks?

No, I’m Brian

Anyone can set up a wireless base station as an access point. Most modern mobile phones have the ability to do it, and even to ‘tether’ that AP to the mobile data connection out to the Internet. To continue the prior example, what do you think would be the effect of me doing that on my own phone in the same pub, and renaming my portable Wi-Fi hotspot to be the same as the open network – ‘QueensHead Customer Wifi’?

Well, to be honest, in practice, not much effect at all. Firstly, most mobile phone hotspot facilities are deliberately WPA2 protected, so impersonating an open network wouldn’t have much point, since anyone connecting would have to provide a password. Secondly, when devices such as your phone look for a network to connect to, they will inspect certain metrics about any in range. The most obvious of those metrics will be signal strength, and the pub’s router providing ‘real’ Wi-Fi will be much stronger than my phone.

Still, it’s a possibility, and in theory at least, if someone managed to connect to my wireless hotspot, I could intercept and inspect their traffic. And there is certainly no difficulty in having two devices broadcasting the same network SSID – there are perfectly reasonable reasons to do that. However, anyone who did connect would be using my bandwidth, and a mobile phone is not a great platform for packet sniffing.

A laptop of reasonable spec, however, is a different matter. It’s fairly straightforward in Windows or Linux to advertise yourself as an access point with SSID, if your wireless hardware supports it. Inexpensive wireless cards and USB dongles are available which support the ‘Master’ mode required to do it, in any case, and having one of these also gets around the problem that you can’t operate a wireless network device in Master mode and as a client to the Internet at the same time. Having two wireless interfaces means you can use one as an access point and the other to connect to the Internet. That’s important, because not many people who connect to your access point will stay connected long if they can’t themselves connect to the Internet!

What I’ve just described is what’s known as a Rogue AP, and is a classic Man-in-the-Middle (MitM) attack using wireless networking. If you have connected your device to my AP, there are a few things I can now do to try and collect more interesting data than the possibly encrypted packets you’re sending and receiving.

Before we go on, I must make clear at this point that doing any of these things is illegal in most countries. Specifically, intercepting somebody else’s network connection without their permission, for any purpose, can land you in real trouble with the authorities. I describe them here for educational purposes. In short, don’t do any of these things. YHBW.

Thought police

I can set up my own DNS server, and respond to any DNS requests by you with an address of my choosing – and therefore, with content of my choosing. That content could even be a look-alike page for the request you’ve made, requesting that you log in. I’m sure I don’t need to spell out the consequences of that.

This attack is called a DNS Hijack, and it’s made possible with a small handful of open-source tools and some networking know-how. [6] There’s a good chance you’ve seen one in action, if you’ve ever used a public (open or not) Wi-Fi and been redirected to a ‘Captive Portal’ that requires a login, payment, or just acceptance of T&Cs. It’s usually done the same way, by intercepting DNS requests and forwarding to the IP address of the portal. You might think this usage is benign, but of course it can itself be spoofed, and used to phish for credit card details, or other information.

Bait and switch

I have already mentioned that HTTPS is secure enough to deflect most attackers, but with a bit of ingenuity it’s possible to subvert it under some circumstances. First, I can intercept your request for a secure (HTTPS) connection, and act as a proxy to your requested site, providing you with a regular HTTP connection, and maintaining the HTTPS connection myself, forwarding all requests and responses appropriately. As far as the remote site is concerned, you are connected securely, but you might notice that your own connection was HTTP only – if you happened to look, for example, at the browser address bar. This method might be used to obtain your credentials over an insecure line (between you and my router).

In a more sophisticated variant of this attack, my proxy could provide you with an SSL certificate, which would most likely cause a warning on your device that the connection might not be secure, but if you ignored that warning, you’d think you had a secure connection.

This attack is called SSL-stripping, and is described in detail on the website run by the man who developed it [7].

The coders’ challenge

If you are writing code for mobile applications or IoT devices that process user information in any way, then you have a responsibility, and probably a legal requirement, to protect that information. As a developer, you need to be aware of actual and potential threats to make your product(s) secure. There is more to this than hardening code against buffer over-runs and SQL injection, although those things are still important.

Identifying those vulnerabilities, and crafting a viable attack to exploit them, actually requires a significant amount of effort, and won’t even be considered if you’re sending your admin password – or worse, your customer’s password – in plaintext back to ‘Mother’.

One of the simplest ways to be less insecure is to gather less data: if you don’t need it, don’t ask for it. However, I am aware that useful tools often require a revenue stream. The increasing appetite of marketing departments for our most personal data is unnerving at best (to me, anyway), but if you must have it, at least use it and transmit it securely. If your app talks over the Internet, make it always use HTTPS or other secure channel, and warn the user very loudly if an encrypted connection is unavailable.

Fortifying applications and devices with certificate authenticated security is not a trivial exercise, certainly it’s harder than statically identifying buffer over-runs, but there it is. Fruit that hangs low on one side of the fence isn’t necessarily easy to reach from the other.

Whoever you want me to be

You might at this point still regard these attacks as pretty unlikely. After all, they depend on you connecting to the Internet through an open access point that happens to be under my control, and conducting your business over that connection. I still have a couple of tricks in my bag of goodies to share. First, let’s have a quick tour of how most devices associate with Wi-Fi routers.

Beacon and probe

When you turn on Wi-Fi on your phone (for example), you will often see a list of available wireless network names (SSIDs). This list is obtained by listening for Beacon Frames, which are part of the IEEE 802.11 management protocol. The beacon is sent by a wireless access point, and includes its name, MAC address and what (if any) security protocols it supports, amongst other things.

Conversely, your phone will send probe frames to listening APs. Broadcast probes are just a request for the list of networks in range, a direct counterpart of the beacon frame above. However, many devices remember the networks to which they have previously connected in a preferred network list. The device will probe directly for those networks (usually only when there is no active wireless connection). If the phone receives a response to such a probe, it will probably attempt to automatically connect (this is the default behaviour for most wireless device drivers).

If the phone is connected to a wireless network, and that connection is dropped, the preferred network list will be probed again. The response to a probe contains information about signal strength and data rates, and most devices will use this data to choose the ‘best’ connection.

I am Spartacus

I’ve already mentioned about wireless equipment and monitor mode, which allows me to listen to all and any wireless traffic including the management frames such as beacons and probes. If I receive a probe for a network called ‘Spartacus’, I can arrange to respond with the equivalent of ‘I am Spartacus’, and if I am broadcasting a strong signal, there is every chance the probing device will try to connect to my rogue access point.

One last thing to note: most devices will stop probing for new networks once they have associated and connected with an access point. However, with the right equipment – it’s that inexpensive wireless hardware again – I can even arrange to impersonate the network to which you’re currently connected, force you to drop that connection (this is called a de-auth, AKA ‘get off my LAN’), at the same time as listening for the resulting probes and impersonating those networks too.

Moreover, my access point can impersonate dozens of networks simultaneously, capturing the traffic from anyone who allows their device to connect.

Are you paranoid yet?

Back to my question about Norm. Now do you think he was being reckless to depend just on HTTPS encryption over an open network? There are other attacks made possible (or easier) with the rogue access point, including session side-jacking, cross-site scripting and cross-site request forgery. If you think this is cause for concern, so you should – it definitely is! See [8], [9], [10], [11] and [12].

The real question now is this: is there anything you can do about it, to either detect the attacks, or render them useless to an attacker?

The answer to that is simple: yes there is. First, use a modern browser that implements HSTS [13]. This will defeat SSL stripping and protocol hijacking, and was in fact developed as a direct response to the original SSLStrip demo by Moxie Marlinspike (see [7]). Second, use a browser plugin such as HTTPSEverywhere [14] or one of its variants. This tool attempts to enforce a secure connection if one is available, and tries to make sure that your whole experience is as secure as it can be.

Lastly, invest in a Virtual Private Network, and use it anytime you’re using a connection you cannot guarantee is safe. Doing all your Internet activity over the VPN (in addition to using HTTPS and everything else) renders most of the attacks I’ve described here toothless. DNS hijacking is easily defeated by knowing the IP address of your VPN server and not connecting by name, but a fake captive portal might be harder to bypass.

Using a VPN that you trust means that it doesn’t matter if you’re unwittingly connecting to the Internet via a rogue access point. The VPN server itself will usually provide its own end-points for DNS and gateways to the Internet, and most VPN software also encrypts the data transmitted and received, affording you an extra level of security.

Detecting the presence of a Rogue AP isn’t necessarily easy, and in a corporate environment warrants expensive internal routing equipment and an army of vigilant network supervisors. However, on a personal level, if you notice that your phone is connected to a network with the same name as your home Wi-Fi, and you’re in a cafe miles from your house, then unless your home Wi-Fi is named something common, it’s probably a fake network. Similarly, if you find yourself connected to an open network that you were expecting to be protected, there’s a good chance it’s a rogue. Be wary of captive portals, and always be vigilant about personal information you provide to anyone.

Socially speaking

If I can get enough information on you, such as, say, your date of birth, post code and mother’s maiden name, along with details of your bank account, I might be able to persuade your bankers to transfer money into an account I control. In fairness to most banks these days, they’re more aware of the need for better security over the phone, and so this may not be enough – but if I am an attacker and can get even some of this data on you, it’s a start.

If I can’t use that information directly to get your money, I may be able to sell it on to someone else who can. Identity fraud is big business, attracting serious money, and correspondingly scary people. If I can (theoretically) do all this, then someone else with a real intent to rob you can actually do it.

If you ever use a Wi-Fi connection in a coffee shop, pub, hotel, airport, someone else’s house, and especially if you ever use public open Wi-Fi, you need to be aware of the risks, and know how to protect yourself. Absolute security is a myth, of course, but you can do some things for little or no cost to make life much more difficult for any attacker. Not doing the simple things described here just make life unnecessarily easy for people who want to scam you or steal your identity.

If you are a company making mobile apps, or devices that use the Internet, whether it’s a router, smart TV, home-automation IoT widget, or a toy, or you’re a programmer writing the code for such things, if you make use of customer details then this stuff matters. If I am your customer, then it’s not your data. It’s my data. And it’s just possible that in the future, I won’t just have to take your word that you’re secure, I’ll be able to look for myself. [15]

References

[1] Fred Cohen, Wikipedia, https://en.wikipedia.org/wiki/Fred_Cohen

[2] Cifas, ‘Identity Fraud up by 27%...’, https://www.cifas.org.uk/id_fraud_first_quarter

[3] Nick Feamster, ‘Who will secure the Internet of Things?’, Jan 2016, https://freedom-to-tinker.com/blog/feamster/who-will-secure-the-internet-of-things/

[4] John Leyden, The Register, ‘Hopelessly insecure Motorola CCTV...’, Feb 2016, http://www.theregister.co.uk/2016/02/03/motorola_cctv_iot_insecure/

[5] Lee Barken, ‘WEP Vulnerabilities’, Dec 2003,http://www.informit.com/articles/article.aspx?p=102230&seqNum=12

[6] Chris Sanders, Windows Security, ‘Understanding Man in the Middle Attacks’, Apr 2010, http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html

[7] Moxie Marlinspike, SSLStrip, http://www.thoughtcrime.org/software/sslstrip/

[8] Shaun Nichols, The Register, ‘How to hijack MILLIONS of Samsung Mobes...’, Jun 2015, http://www.theregister.co.uk/2015/06/17/samsung_flaw_keyboard/

[9] Chris Sanders, Windows Security, ‘Understanding Man in the Middle Attacks’, May 2010, http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part3.html

[10] Scott Helme, ‘Advanced Session Hijacking’, Aug 2013, https://scotthelme.co.uk/advanced-session-hijacking/

[11] Wikipedia, https://en.wikipedia.org/wiki/Cross-site_scripting

[12] OWASP, Oct 2015, https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

[13] Wikipedia, HTTP Strict Transport Security, https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[14] HTTPSEverywhere, Electronic Frontier Foundation, https://www.eff.org/https-everywhere

[15] Kieren McCarthy, The Register, ‘Show us the code...’, Jan 2016, http://www.theregister.co.uk/2016/01/25/source_code_ftc_commissioner/

Notes: 

More fields may be available via dynamicdata ..