We all know it… we all talk about… we all say how ‘bad’ it is. Yes, we know WEP SUCKS – so why are you still using it?
Yes- I’m talking to YOU!
Day after day, we walk into customer sites- almost all of which are under some (or several) compliance mandates- and day after day, I still see WEP being used in production networks. So, why are they still using WEP? Usually just because they haven’t changed. It worked, it was comfortable and it was ‘okay’ when they implemented it.
But, things have changed. Today any 15 year-old with a free utility and a configured wireless card can crack your WEP… in a few minutes. It’s time to update! In case you’ve been hesitant, let’s go over a few reasons why WEP is so bad.
I’ve included (for your reading enjoyment) a short technical review of why WEP sucks, as well as a non-technical summary for you, or for someone you’re explaining it to.
Note: I should qualify- this is WEP in wireless implementations. WEP has been and is still successfully used in other wired and remote-access applications.
What’s Wrong with WEP
-
Use of a streaming algorithm
WEP uses RC4, a stream cipher, in synchronous mode for encryption. This requires the key generators on each end to be kept synchronized by some external means; otherwise all remaining data is lost after the first bit of lost data that caused the de-synchronization. Data loss is expected over wireless medium, making a stream cipher a bad choice. This is one of the primary issues of WEP in wireless.
Non-tech summary: The algorithm WEP uses requires complete synchronization, but data loss is expected in wireless, making it difficult to keep both ends in sync.
-
Per-packet master key re-use
To solve the synchronization issue, WEP was tweaked to change synchronization from per-session to per-packet. This means 802.11 is exchanging keys every packet, instead of every session. However, WEP tends to expose the master key with each use- the per-packet key is a simple concatenation of the IV and the Master Key and is re-transmitted with every packet, greatly increasing the exposure of the key. As we all know, more exposures = more vulnerable key. In addition, the 802.11 standard didn’t include instructions on IV rotation, making key reuse very likely.
Non-tech summary: WEP took a semi-random value and added it onto the master key to get per-packet keys. Because the master key was not well hidden or masked, it could be easily ‘found’, and because it was used in every single packet, it gave eavesdroppers more opportunity to listen and figure out what it was.
-
Group use of same PSK & Sharing of keys across APs
Other issues with WEP are related to authentication and integrity. With WEP, administrators are limited to just a few pre-shared keys per AP/SSID, which means the same pre-shared keys are used by multiple endpoints, increasing vulnerability and decreasing the ability to identify individual authenticated stations. Just as WEP forced multiple endpoints to use the same key or keys for a particular AP, it also leads to the sharing of keys across multiple access points configured for the same SSID service.
Non-tech summary: With WEP, we can usually only specify 1-4 secret ‘keys’ on an access point, so all laptops, whether there are 10 or 100, must use one of those keys, so keys are not unique to the user. It would be like using the same physical key to access a building- you would have no way to know who, or which key exactly, was used after the door was opened.
-
Lack of authentication of network to client
The client authenticates with a PSK, but is susceptible to man in the middle attacks from rogue devices and eavesdroppers. The client uses the pre-configured, pre-shared key to tell the AP it’s authorized to connect. However, with WEP, the AP is not using certificates or any means to identify itself to the clients.
Non-tech summary: If the access point doesn’t authenticate itself to the laptop- the laptop can’t know if it’s your ‘real’ access point, or if it’s some hackers that happens to be in range. This is a big problem with enterprise networks, where there may be multiple access points and maybe even multiple wireless networks available.
-
Confidentiality vulnerabilities with header
The ICV (integrity check) in WEP does not protect the header, leaving it vulnerable to redirection attacks. Only the payload, or message, is included in the ICV, so the header can be modified without affecting the integrity check. Integrity fail.
Non-tech summary: The header is not protected- it’s neither encrypted or checked as part of the ‘message integrity check’, which verifies that the message hasn’t been tampered with. If the header isn’t tamper-proof, then there’s nothing to keep the bad guys from redirecting traffic to or from your access point or laptops.
-
Integrity vulnerability & replay attacks
WEP is also very susceptible to replay attacks since the ICV (integrity check) is not linked to timestamps or session sequence numbers. It’s possible to capture packets and replay later. The receiving device would have no way to validate the integrity of the packet.
Non-tech summary: WEP is also vulnerable to replay attacks. Doesn’t sound that bad, right? Well, imagine you logged in and paid a bill for $1,000. What if a bad guy could ‘replay’ that series of messages and re-send themselves another $1,000?
And, there you have it. Hopefully I’ve simplified without over-simplifying. I’m sure some of my fellow wireless packet h3ads will chastise me for portions, but I can live with that.
If you like this article, please use the new ‘Share This’ feature below!
# # #
