WPA2 with pre-shared key has long been a bad idea for Enterprise networks. You only need to look at the name “WPA2 Personal” to realise it is not designed to be used in the workplace. That being said, companies still choose to use it. If you’re one of those, there is yet another reason not to, as another new attack has been found against it.
Security researcher Jens Steube (also the creator of the “Hashcat” tool) stumbled across the new attack vector whilst trying to poke holes in the new WPA3 standard.
WPA2 attacks are nothing new – they’ve been seen before, however previously they’ve often relied on capturing and attacking a successful four-way handshake performed by a genuine wireless client. Granted, that is necessarily not all that difficult to do – people log into WiFi networks frequently. The newly discovered attack however, does not require this handshake data. In fact, it doesn’t even require clients to be on the wireless network at all. The attacker can launch the attack directly against the access point itself.
It all has to do with a value in one of the optional headers header known as the Pairwise Master Key ID (PMKID) which can be used to speed up certain wireless roaming scenarios. If you want to get a bit more into the nuts and bolts, then this article gives a brief write up on the attack tool and this article gives some good information on the different roaming options supported by a Cisco Unified Wireless solution (plus a good overview in general).
What does the attack do?
In a nutshell, the attack allows an attacker to derive enough information (without active wireless clients) to be able to launch an offline brute force attack against a hash of the pre-shared key. It does not make cracking the key any easier, however it does make collecting the info to launch an offline attack easier.
How long the key actually takes to crack will depend on its complexity and length.
What devices does this affect?
There is no definitive list yet. It was believed that this would likely affect any WPA or WPA2 based wireless networks that utilise roaming. It does not affect WPA2 Enterprise.
Cisco have published this article in response to the new attack vector. It states that they are not aware of any of their products being affected by it. They say they do not support PMKID roaming with WPA2 pre-shared key, so you should be good.
Your home devices and/or corporate devices from other vendors may well be affected though. Probably worth checking.
Woohoo! I’m not affected
Easy there tiger. Did you miss the bit where I said pre-shared key is a bad idea in the enterprise environment?! Yep, you may not be affected by this attack. But you really shouldn’t be using pre-shared keys to secure your wireless. Why?
- It is a password. If there is one thing we’ve all learnt about humans and passwords it is that we tend to be quite rubbish at them! Have you actually used a long, RANDOM string for the key? Or have you used something like “MyR3allyS3cr3tW1F1K3y” so that you can remember it when adding new devices…
- Even if you have used a really good pre-shared key, you still have a single password for all the devices that connect to the network. If just one of your end devices is compromised or lost, you’re going to have to change that key across ALL endpoint devices and wireless access points/controllers. I don’t know about you, but I can think of better ways to spend my days!
- What if you wanted to revoke a single device’s access to the wireless network? How are you going to achieve that with a pre-shared key? Not necessarily straight forward.
- Session encryption keys are derived from the pre-shared key. What this means in practice is that someone who has the pre-shared key can not only join the wireless network, but they can also sniff other users’ traffic after capturing some handshake data from them. Not a difficult task.
What is the solution?
Switch to WPA2 Enterprise (the clue is in the name)! WPA2 Enterprise uses EAP and 802.1x to authenticate users and/or devices to a backend RADIUS server. This has a number of benefits:
- It is a lot more secure. No poorly created pre-shared keys to secure the network communications, instead the EAP protocols will generate strong, genuinely random keys for use with encryption.
- Access to single devices/users can easily be revoked by disabling accounts. Similarly, a single lost device does not require changes across all other devices.
- Session encryption keys are dynamically generated on a per-session basis. It will not be possible to just sniff another users traffic because you’re on the same wireless network.
- More features – when using WPA2 Enterprise with a backend server you can start tying in with more advanced Network Access Control features such as authentication chaining and posturing.
- Improved audit trail – with a pre-shared key there is nothing tying a session to a user/device except maybe a MAC address (which can be easily spoofed). WPA2 Enterprise ties a session to a specific authentication such as a user or machine domain account.
Disclaimer – I’m a big fan of Cisco’s ISE solution! I think it is a great product. I’m not going to hide that. I’d strongly recommend anyone considering this kind of authentication to review it and understand its other capabilities across both wired, wireless and VPN networks. That being said, just because you aren’t using a fancy NAC solution doesn’t mean you have to be complacent and stick with WPA2 pre-shared key.
Running a Windows Server environment? Then stick the Network Policy Server (NPS) role on one of your servers and you’ve got yourself a simple RADIUS server for handling authentication!
More of a Linux house? Then go and check out Freeradius.
Securing your wireless network with strong authentication mechanisms does not have to be difficult. It really isn’t. Did I mention please don’t use pre-shared keys?!
What about exceptions?
“I’ve got an old barcode scanner that can only do pre-shared key…”
Ahh legacy devices – there is no getting away from them! An unfortunate reality in many networks. Yep, certain old devices will only support WPA2 pre-shared key. Maybe they won’t even support that if you’re really unlucky. When this is the case I guess you have two main options:
- Upgrade to newer devices that support more secure wireless authentication methods,
- Isolate the WPA2 Personal wireless network from the rest of your network as much as possible. Ensure it provides the minimum required access to fulfil the function of the attached devices. That way, if/when someone compromises your key they will have minimal access.
Option one clearly makes the most sense from a security perspective, but that doesn’t necessarily always align to business requirements and constraints.
What’s the take away from this? Move away from WPA2 PSK (did I say that already?)
If people would find it useful I’d be happy to look at writing up a simple “how-to” guide on setting this up on Windows NPS as a basic solution. Get in touch if you think this would be of use. I won’t go publishing your name or company or anything like that don’t worry – it is just so I get an idea of whether to spend the time doing it or not.
As always, questions or comments then get in touch. And go and follow me on Twitter @mike_sec_eng
2018-08-09 01:00 +0100