I was invited to deliver a presentation at last week’s CyberUK In Practice event on the work that Common Technology Services (CTS) is doing to enable Wi-Fi roaming between government buildings.
Here is a summary of what I discussed at the event: common Wi-Fi security issues and the security approaches that CTS is taking.
Wi-Fi is not always safe
Although it might sound obvious to some people, Wi-Fi is not always safe. The big difference between wireless and wired networks is that with wireless networks you can't rely on your physical building security to keep attackers away from the cables that expose your data and users.
Your security is totally reliant on encryption, as all data transmitted can be collected by an attacker some distance away.
Man in the middle attacks: rogue hotspot
The easiest way for an attacker to become the man in the middle is to set up a rogue hotspot (Evil Twin). This is easily achieved with a laptop and an open source toolkit.
You're expecting free Wi-Fi, and the name of the network matches your hotel or coffee shop So it's ok? Well maybe not...
How can we tell if it's the official Wi-Fi or an attacker?
Open network: an attacker can simply set up an access point with the same name.
Pre shared key: if an attacker knows the key, they can set up an access point indistinguishable from the real network using that key, this is potentially worse as encryption makes it seem trustworthy.
Enterprise Wi-Fi: if the presented certificate isn't checked automatically by the device or manually by the user then there is no protection against rogue hotspots.
Man in the middle attacks: ARP spoofing
A man in the middle attack is possible if an attacker can connect to a network and contact the other clients. This is regardless of the encryption type or login method, and is also possible on wired networks.
They can spoof the gateway IP address to divert all traffic via their device and then use the same techniques as before.
Dodgy root certificates
Another form of attack is to present the user with a properly encrypted session by first persuading them to install a root certificate. This can then be used to sign the connection to the attacker and make it very difficult for the user to notice unless they check the certificate carefully.
This may sound difficult, but it's exactly how corporate proxy works to filter secure web sites.
But how does an attacker get the user to install a dodgy root certificate? Vendors have mistakenly installed a trusted root certificate on their standard build, including the private key, on multiple occasions.
Find out more information on this from vendors such as Dell and Lenovo.
This allows an attacker to extract the key and present certificates that would be trusted by affected devices.
Another way is to trick the user to install it via a convincing web page.
Captive portals (are evil)
You might have the best corporate web filtering solution on the market but they can't protect users from captive portals.
So you have to make one of two choices:
Fail Closed: always-on VPN. This can't contact the gateway so my users can't work in hotels and coffee shops.
Fail Open: I rely on my last line of defence, endpoint hardening and antivirus to protect me.
Once a portal is presented to the user, it is more likely to be trusted than a standard pop up encountered during web browsing especially if it has the branding of the location.
An attacker can entice the user to install malware by posing as an innocent mundane update. As they are intercepting the internet traffic, it is trivial to present a popup to the user with a real vendor web address.
My favourite example is one vendor who has a feature where you can't get on the network before installing some software to check if antivirus is installed. Although this app is signed, it trains the user that installing software to get on the network is OK.
Security decisions: moral hazard
In public Wi-Fi deployments, security decisions are made by the organisation providing the service. However the risk is passed completely to the user, and potentially, if they lose money, to their bank. This creates a moral hazard.
The main requirement for a public Wi-Fi operator is to get you to agree to terms and conditions that reduce their liability for what you do on the internet such as copyright infringement. I'm sure they will also make it clear that they are not responsible for security problems.
Some banks are spotting this by putting in their online banking terms and conditions that you must only connect to hotspots you trust, however without encryption trust this isn't possible.
Betrayed by your devices: probes and privacy
Your phone helpfully broadcasts the names of your saved Wi-Fi networks so that if any of them are in range it can connect quickly.
This is great for connectivity, but not so good for privacy. With the help of an online database we can map those network names onto physical locations.
If an attacker knows the network name used by an organisation, they can potentially discover staff’s home addresses. They just need to follow the trail of breadcrumbs:
- Attacker knows organisation network name
- Attacker listens for devices wanting to connect to that network
- Attacker listens for network probes from the same device as they broadcast to connect
- If one of those networks sounds like a personal one (i.e. have a domestic supplier in the name) they can cross-reference them on databases and find out where someone lives
Wi-Fi Pineapple/Karma attack
There is a twist on standard rogue access points. Now an attacker can just answer yes to these probe requests and any devices nearby will automatically connect if there is no encryption. So if you leave open Wi-Fi networks saved on your device you are susceptible to this attack.
WPA2-Personal problems
Pre shared keys are fine for home use if only you know the password, however the security of the network depends on the privacy of that password so should be considered unencrypted if it is widely known.
The hash of the key can be recovered from every authentication to the network, and taken away for offline attack. This can be achieved using brute force with a password list. Your average gaming PC can try over 100 thousand combinations per second.
Rainbow tables are large lists of hashes which can be generated and used by an attacker to make password cracking faster. But the hashes are salted, which is the process of adding extra information to the password so that once cracked that hash isn't known on all systems.
In this case the extra information is the Service Set Identifier (SSID) so you'll need one table for each network name. There are sets which are freely downloadable for the most popular ones, so leaving your Wi-Fi name as the manufacturer's name probably isn't the best idea.
But then if you make your network name unique then an attacker can find out the location if it's in a database. So something rare but not unique might be best.
WPA2-Enterprise problems
As well as the 'man in the middle' attacks there's an attack that is specific to enterprise Wi-Fi. The attacker can pretend to be the legitimate access point and authentication server. If the user or device doesn't check the certificate properly then the user's credentials can be stolen.
When an organisation is implementing a WPA2-Enterprise Wi-Fi network it can be tempting to use their existing credential store such as active directory. This can be a real problem as an attacker could use those stolen credentials to get into any services that use that same credential store. External services such as webmail and VPN are especially vulnerable or those credentials could be used as part of a more sophisticated attack.
Although it is only the hash that is stolen there are cloud services that will break any hash in less than 24 hours for a small fee.
Privileged network access using credentials should be avoided where possible as if they get stolen the attacker has an easy way to connect to the inside network.
How can we protect ourselves?
Don't leave open networks saved on your device
Open networks are easily faked, and if you've saved them on your device then an attacker can personalise their attack to your specific networks. So if you need to use a public network, delete it when you are done.
Always check the certificate of networks
Every time a network presents a certificate you need to check it, if it's not a managed device and done for you you'll need to do it manually be obtaining it via different means.
Check the certificate of sites
When you're about to enter any personal information or login details into a browser, check for green in the address bar, and that the information in the certificate sounds plausible.
If you're putting in Wi-Fi...
Use encryption
Think very carefully about the risks to your users before deploying open networks.
Limit pre shared key networks to small user groups
Pre shared key is called WPA2-Personal because when the key is only known to one person then it's secure, so should be avoided for large user groups or public use.
Deploy profiles to managed devices to automatically check certificates
Make sure your users are able to check the certificate by providing it to them before they connect, and preferably deploy a profile to do it automatically.
Isolate your users
When you configure your network, don't allow your clients to talk to each other and enable whatever spoofing protections that your hardware supports. This prevents an attacker from exploiting another device directly, or using ARP spoofing to intercept legitimate users' traffic.
HTTP Strict Transport Security
The website tells the browser that it should only connect if it is encrypted.
This record is then remembered by the browser for a period of time. The only problem with this is that it can be sent unencrypted, this allows the attacker to remove it before sending it on to the client. So to avoid that problem browsers have a hard coded list of sites which can't be circumvented. Surprisingly none of the banks I tested were on the list.
If you are implementing a secure website then implementing HTTP Strict Transport Security (HSTS) and getting it hard coded into the browsers should be fairly high on your agenda.
HSTS also protects against the more advanced 'man in the middle' attacks by defining which certificate authorities can sign the certificate for that site. This means that dodgy root certificates that an attacker has managed to get onto the device doesn't get them anywhere.
To get around this the attacker would have to rewrite the address of the secure site to something else which isn't on the list. This is a bit more likely to get noticed by the user, for example www.gov.uk is protected by HSTS but wwww.gov.uk isn't.
Finally...
In the second part of my presentation I’ll discuss the solutions Common Technology Service has used to address these security concerns, and what we’re doing about government-wide roaming.
1 comment
Comment by Rob Knight posted on
Thanks for the informative blog.
Inexpensive devices have been available some time on which captive portals are remediated for some time to permit the use of secured laptops, tablets etc. where the VPN fails closed and/or endpoint firewall policies drop anything not destined for the VPN gateway and once established, the corpotato network.
This protects corporate assets and data.