cracking wep encryption

30.12.2005 (updated 02.01.2006)

chrome * liquidinfo.net
(http://www.liquidinfo.net/disclaimer)

Abstract
In my earlier wireless paper(http://www.liquidinfo.net/wireless.pdf) I discussed about ways
to secure a wireless access point and how to circumvent the protective measures
available, like MAC filtering. I however did not cover how to crack the encryption. In this
short paper I will go through briefly the advances in cracking WEP encryption and on how I
cracked my own 128-bit WEP-encryption with a hands-on approach.

Additional disclaimer: I am not an expert in this area, and this is really nothing new and
innovative, just my own thoughts about the issue. If you decide to start playing around with
cracking wireless networks, that is your own responsibility. Only test this on your own
access point, if you feel like testing this in practice. It is illegal to break into someone elses
network without permission!

WEP attacks briefly

WEP means Wired Equivalent Privacy and attempts to provide a minimal level of security
for a wireless LAN, resembling the same security and privacy offered on a wired LAN. A
passphrase or certain lenght HEX-string is shared between the access point and the
wireless clients and it is used to encrypt data for the whole session a client has with the
wireless network. To read more about how it works, follow link: http://wireless-lan.wireless-
computer-networking.com/wep.htm.

As the WEP encryption key is the same as long as it is administratively changed, this
opens it up for a dictionary/brute-force attack, where the key is attempted to be discovered
by guess-work. This can be considered as an ineffective attack, unless the used
passphrase is a really silly dictionary- word. It takes usually a long time to perform as any
other similar attack, and if a full-lenght HEX-key is used, it is not feasible to try this route.

The encryption algorithm contains a weakness where it generates weak IVs (initialization
vectors) that reveal information about the WEP key that can be used to crack the WEP
key. This is what the FMS Attack
(http://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/stubbl.pdf, Fluhrer-
Mantin-Shamir) attempts to exploit, but it requires to capture a lot of packets
(4,000,000-6,000,000) for the statistical attack to be effective. Also improved firmware from
vendors that decrease the weak IVs and new features where the WEP key is swapped
between certain intervals decrease the chances of getting enough encrypted data for a
successful attack.
There has however been improvements in the statistical attacks, H1kari being the one that
included the second SNAP header byte analysis in the attack
(http://www.dachb0den.com/projects/bsd-airtools/wepexp.txt) that lessened the required
amount of packets to 500,000-2,000,000. KoreK took the statistical analysis further and
discovered 16 other statistical weaknesses in WEP encryption algorithm, reducing the
amount of packets needed for cracking the encryption to about 300,000 packets, but it can
be done with even less if one is lucky. Unfortunately I haven't been able to find much
(http://netstumbler.org/showthread.php?p=93943#post93943) about the attacks, but those
are based on the H1karis attack.

Even with the great improvements in statistical attacks, it can take a long time to gather
enough packets to crack the key. It depends on how saturated the target network is. A big
file download by a client may decrease the time to 15-30 minutes, but could take hours or
even days if there isn't much activity on-going. It is possible to generate packets to speed
up the encrypted packet gathering stage.

It is possible to cause an access point to de-authenticate (deauth) clients from the wireless
network, and clients are forced to authenticate themselves again. During the
authentication, about 100-200 encrypted packets are generated per client. Unless there
isn't many clients in the wireless network, this doesn't generate much traffic and is more
easily detected as clients start to wonder why they drop off the network. If you need to get
the SSID of the access point, this attack causes the client to send a probe request which
contains the SSID. (During writing the first wireless paper I wasn't aware of this method,
thus it was not included. This also works for WPA)

This is not a very speedy way of generating traffic, but it works. Another method is to
replay encrypted packets back into the wireless network. This works, because WEP
doesn't have measures against replay attacks. Any encrypted packet can be replayed, but
most beneficial are packets that generate a response and that means more encrypted
packets collected. A safe shot is to identify an encrypted ARP-packet based on it's size
and replay it into the network. Replaying ARP-packets also has the benefit of small size,
meaning that sending packets is quicker.

Attacking the network

The tools I chose for breaking into my own wireless home network is not really relevant. It
is sufficient that I can capture data and inject packets into the network. I also have a
prism54-based FullMAC card that is capable to capture and inject packets.

My own access point is set up with a 128-bit WEP key to encrypt data, MAC filters to allow
only clients with specific MAC addresses to connect, static IP addresses are used and no
SSID is broadcasted in beacon packets. It could be considered a relatively sane setup
where an onion-layer approach has been implemented with available resources.

Warning: Only test your own access point, it is illegal to break into someone elses network
without permission!
My aim in this excercise is to:

• find out the SSID of the access point

• find out the used WEP key
• look at captured data for information
• get a foothold on the network

I start monitoring and find the network with SSID broadcast disabled. By viewing the data
capture I see that it has one client connected to it. I also identify that the network is using
WEP encryption.

By viewing packet dumps, we are able to see that the access point sends beacon packets
without the SSID included, and that the traffic is indeed WEP encrypted when the client
sends packets.

102393 0us BSSID:00:cf:ab:52:ab:bf DA:ff:ff:ff:ff:ff:ff SA:00:cd:ab:52:ab:bf

Beacon () ESS CH: 6, PRIVACY
0x0000: 9921 5210 0000 0000 6400 1100 0000 0104 .!R.....d.......
0x0010: 8284 8b96 0301 0605 0401 0300 002a 0107 .............*..

093536 WEP Encrypted 117us BSSID:00:cf:ab:52:ab:bf SA: 00:03:33:ab:da:b2 DA:

00:cfd:ab:52:ab:bf Data IV:34a31a
0x0000: 1c29 2a00 7178 1d73 340a 20cc 4af7 c557 .)*.qx.s4...J..W
0x0010: abff f259 ff83 e6c9 a3ff 369b aa37 aa4d .(.Y......6..7M.
0x0020: f9fe 9e2c cc59 57a1 4dbb e9b6 def4 bb28 ...,.YW.M.....E(
0x0030: d6cf 8fcf fc37 9c37 50cf 5b9e 294e 2144 ...U|7.7P.[.)N!D

My first target is to learn the SSID of the access point, so I decide to use the deauth-attack
that works by sending lots of forged packets that tells a client it has been de-authorized by
the access point. At the same time I monitor the traffic to pick up the SSID when the client
re-authenticates to the access point. In the packet dumps we can't unfortunately see our
own injected deauth-packets but we can see how the the client probes for the access point
and the access point responds.

006671 0us Probe Request (victim) [1.0* 2.0* 5.5* 11.0* Mbit]
0x0000: 0006 7669 6374 696d 0104 8284 8b96 ..victim......

001019 248us Probe Response (victim) [1.0* 2.0* 5.5* 11.0* Mbit] CH: 6, PRIVACY
0x0000: 9de1 6255 0100 0000 6400 3104 0006 7669 ..bU....d.1...vi
0x0010: 6374 696d 0104 8284 8b96 0301 062a 0107 ctim.........*..

After watching the network for a while, I conclude that the network activity is not sufficient
for capturing 300,000 packets in a decent time. There is however some small activity going
on, maybe the user is surfing the Internet or chatting with someone. I will generate more
encrypted traffic, by identifying and replaying ARP-requests back to the network rapidly. I
reach to about 300,000 packets after ten minutes.
I execute the statistical attacks against the pcap file and after a while the attacks have
found the used WEP-key that is:

markoisdapimp

After successfully finding the WEP-key I am now able to decrypt the capture file for further
study. I can for example see browsing habits. If the user has used any cleartext protocols,
like pop3 or a webmail site that doesn't utilize SSL, the credentials can be gathered and
used for questionable things, like reading the user's emails or sending emails in the name
of the user.

008887 IP (tos 0x0, ttl 128, id 21691, offset 0, flags [DF], proto: TCP (6),
length: 442) 10.10.10.2.1055 > 21.3.18.4.80: P, cksum 0xae7d ( correct),
1:403(402) ack 1 win 64512
0x0000: 4500 01ba 54bb 4000 8006 248a c0a8 3205 E...T.@...$...2.
0x0010: d91e b42c 041f 0050 0798 504b 5c63 8ca6 ...,...P..PK\c..
0x0020: 5018 fc00 ae7d 0000 4745 5420 2f20 4854 P....}..GET./.HT
0x0030: 5450 2f31 2e31 0d0a 486f 7374 3a20 7777 TP/1.1..Host:.ww
0x0040: 772e 6c69 7175 6964 696e 666f 2e6e 6574 w.liquidinfo.net

I also collect nameserver information from the dump by looking for protocol udp and port
53 packets that reveal the used nameserver(s) in the environment. I set my machine to
use the nameservers to ensure that DNS resolves properly. Then I give iwconfig the WEP-
key (markoisdapimp) and SSID (victim) of the target network, and put the interface into
Managed mode. I seem to be able to connect to the access point for a brief moment, but
association fails.

Probably the target network is using MAC filtering, as I normally should be able to
associate properly. I start monitoring again to see if there is more clients on the network,
but I encounter no new clients. The one I deauthed earlier has disconnected from the
network, meaning that I can use it's MAC address to connect (highlighted above).

I use ifconfig to set the MAC address of the client and try to connect again. I am able to
associate, but I am not able to get an IP via DHCP. I suspect now that the network uses
static IP-addresses, which I already have an idea of (highlighted above), so I give ifconfig
a similar IP as the IP already encountered. In case the real user connects again, there
starts to come problems on the network, so I can quickly disconnect off the network.

I am able to do a DNS-query so I am able to send at least some packets into the Internet
and have a foothold on the network. From here I could start enumerating if there is any
wired hosts connected, what the hosts are and so on, you get the idea.
Conclusion
WEP is insecure. Use rather WPA for protecting the wireless traffic. If WPA is not
available, use whatever you have, but remember that WEP is quite easily cracked most of
the time. A good option in such situations would be to set up a VPN-machine and require
usage of VPN to ensure the traffic is encrypted.

2001-2007 Liquid Information, under Creative Commons.

http://creativecommons.org/licenses/by/2.5/