here - crws.co.uk

Mobile & Wireless: WEP Cracking Lab
INTRODUCTION:
The purpose of this lab was to investigate the security of WEP encryption, with an aim to breaking the
encryption system to reveal the passphrase used within a communications link. This lab will bring to
light some of the possible attacks and methods that are used against WEP encryption, along with some of
the popular tools used to carry out these attacks.
RESEARCH:
WEP (Wireless Equivalency Privacy) is an encryption system that is known to be insecure, yet it is still
used within business and public communities alike. WEP is insecure primarily due to its short IV
(Initialisation Vector) length [1]. The IV within WEP has a length of 24 bits, therefore it can be shown
that there are only 224 possible combinations for the IV to go through, this equates to 16777216
combinations. Although this seems high, when it is considered that a wireless link can send thousands of
packets per second and the likely hood of each packet having a different IV is high, then the number of
combinations available soon dwindles. Once all of the combinations have been used WEP begins to reuse the previous combinations, it is this action that makes WEP weak as it introduces patterns within the
encrypted output which makes cryptanalysis possible, thus leading to the encryption being broken. A
quick and dirty analysis of the IV situation would be as follows:
Wireless link with assumed 1000 packets per second
different IV for each packet assumed ∴ 60,000 packets per minute
16777216
= 279.62 minutes to use all available combinations
60,000
∴
279.62
= 4.66 hours
60
The above calculation gives a rough indication of how long it would be before a wireless network
generating 1000 packets per second starts to reuse old IVs. It can be imagined that for a large network of
many users this total would soon come down in size, resulting in reoccurrence of IVs within an hour or so
[1].
Many of the WEP cracking tools looked at within this lab exploited the IV flaw within WEP. The tools
found tended to fall into two main categories, non intrusive and intrusive. The non intrusive tools
passively capture packets from the wireless network until enough packets have been captured for analysis.
This method of cracking is hard to detect as no intrusion on the wireless network is needed, its downfall is
that it takes a long time if the number of packets generated on the wireless network is low. The intrusive
tools on the other hand use a number of methods to inject malicious packets onto the wireless network
while capturing any resultant packets, thus artificially increasing the IV use with excessive traffic. This
method is highly intrusive and can be evident on the wireless network under attack. However it is quicker
than its passively capturing counter part.
A search of the internet for phrases such as “cracking WEP” and “802.11 cracking” brought back many
tutorials, methods and tools. From the wealth of websites some individual and collective toolsets became
apparent. The following are a list of the most prominent toolsets found at the time of investigating.
COMMUNICATION NETWORKS, YR 4
-1-
•
•
•
•
•
•
•
Auditor (http://www.remote-exploit.org/index.php)
Backtrack (http://www.remote-exploit.org/index.php)
Knoppix STD (http://www.knoppix-std.org/)
Whax (http://www.remote-exploit.org/index.php)
Aircrack (http://tinyshell.be/aircrackng/wiki/index.php?title=Main_Page)
Kismet (http://www.kismetwireless.net/)
Airsnort (http://airsnort.shmoo.com/)
From the list above Auditor, Bactrack, Knoppix STD and Whax were all collective toolsets and were
based on a Linux live CD distribution which was pre-configured with the tools already in place to crack
WEP. Aircrack and Kismet were individual tools that made up part of the attack on WEP. Aircrack is
used to decrypt the packets captured from a wireless network to give the passphrase (Key), while Kismet
is used to identify and capture packets from wireless networks. Airsnort on the other hand was a tool to
passively capture packets from the wireless network, while at the same time decrypting them to give the
passphrase.
Leading up to the lab all of the toolsets above were used, to asses the ease of use and suitability for the
investigation. Some initial toolsets to be dropped were Knoppix STD, Auditor and Backtrack. Knoppix
STD was dropped due to the lack of tutorials available. Auditor on the other hand was dropped as some
of the tools did not seem to work with the hardware tested with. Backtrack which was in beta testing
when used, was dropped as it was full of bugs and limited due to driver issues (no packet injection). A
Window’s version of Airsnort and Aircrack was found. However the Airsnort for Window’s was shown
to be crippled compared to the Linux version, as it used more processor and could only deal with 11b
networks [2]. With the limitations and the time issue involved with having to wait while enough packets
were generated Airsnort was also dropped. Aircrack in its Window’s form was dropped too for its poor
performance when compared to its Linux counter part. The only toolset left was that of Whax, which was
one of the Linux live CD toolsets. Whax was the most stable and contained the most support for wireless
network cards. In testing if a card failed to work with Whax, like the Netgear WG511T which was used,
it was easily resolved with a boot command of “linux pci=assign-busses” which enabled the Whax live
CD to both find and utilise the card.
After looking at many of the tutorials found, a mix of the tutorials found at the following sites were used;
•
•
•
http://www.remote-exploit.org/index.php/Tutorials#128_Bit_Wep_cracking
http://www.grape-info.com/doc/win2000srv/security/aircrack-2.3.html
http://www.crimemachine.com/tutorial.htm
After practicing with the use of the methods and tools suggested within these tutorials, it was suggested to
utilise an intrusive attack method. Within the chosen attack method the attacker forces a temporary
authentication to the wireless access point using Aireplay. Once authenticated the attacker begins
injecting packets using Aireplay to increase the IV rate while capturing the resultant packets using
Airodump. Once enough packets are collected Aircrack is used to decrypt and find the passphrase. At
this point it is worth noting that Aircrack can be used while capturing is taking place, as Aircrack will
automatically read any new data placed within the packet capture file. This results in a more efficient
attack making the attack quicker, as packets are only collected until the passphrase is found. Another tool
used within the tutorials was that of Airmon.sh, which was used to place the wireless card into
promiscuous mode to enable packet capturing. It was the afore mentioned technique which was to be
used within the lab.
COMMUNICATION NETWORKS, YR 4
-2-
PROCEDURE:
Initial Test Equipment –
Netgear WG511T network card
Orinocco Classic Gold 11b network card
Linksys WAP54G Wireless Access Point
Lab Equipment –
Samsung X50 laptop (Intel(R) PRO/Wireless 2915ABG)
Advent 7036 laptop (Prism GT)
Netgear WAG102 Wireless Access Point
Tools –
Advent laptop – Whax Live CD (Airmon/Aireplay/Aircrack/Airodump)
Samsung X50 – Netstumbler
CLIENT SIDE:
To begin with the Access Point (AP) had to be set up. To make sure of no collisions with any other AP’s
in terms of channels and interference Netstumbler was used to identify local AP’s and the channels used
(as shown in fig 1.1).
fig 1.1
Using Netstumbler it was decided to set the AP to utilise channel two as it was believed this would be
least likely to cause any problems. To make identification easier the AP’s SSID (Service Set Identifier)
was changed so that it would make it distinguishable from the other AP’s in the area. In fig 1.2 the
channel and SSID settings can be seen from the AP’s configuration interface found at
http://192.168.0.232.
fig 1.2
As can be seen from fig 1.2 the AP’s SSID was renamed to WA and the channel was set to channel two.
Now that the AP was easily identifiable to the group, the attention was turned towards security. The
security page of the configuration interface is shown within fig 1.3. The screen capture shows that the
COMMUNICATION NETWORKS, YR 4
-3-
AP’s network authentication was set to shared key and the security was set to 64 bit WEP encryption,
with a passphrase of ‘password’.
fig 1.3
At this point it should be noted that the attacking machine (Advent laptop) was already up and running
and trying to partially authenticate with the AP (authentication shown later). However the AP was
denying all requests to partially authenticate with it, this was believed to be down to the network
authentication security setting. With the given problem of authentication the AP’s network authentication
was set to ‘Open System’ as shown in fig 1.4.
fig 1.4
Once the network authentication was changed to ‘Open System’ the attacking machine could partially
authenticate with the AP. This setting was changed to facilitate the investigation of WEP, as the security
of the AP was not the focus of the investigation. With the security settings in place all that was left was
to configure the Samsung X50 to utilise the AP. A new preferred network was added with all of the
relevant security settings applied to the Window’s wireless network interface (fig 1.5).
COMMUNICATION NETWORKS, YR 4
-4-
fig 1.5
fig 1.6
Once configured the Samsung connected without any problems to the AP, as can be seen from fig 1.6
showing the Samsung X50 connected to WA. This was all that was needed to be done to set up the client
and the AP for the investigation.
ATTACKER SIDE:
On the Attackers side Whax was launched, when loaded a terminal was opened and the ‘switch-to-hostap’
command was executed as shown in fig 2.1. This command restarted the PCMCIA card manager and
loaded the Hostap driver (used when dealing with Prism chipset).
fig 2.1
Once Whax was running with the Hostap driver in place, Airmon was executed to find all wireless
interfaces on the laptop (fig 2.2). Airmon found the internal wireless device and identified the device
correctly as having a PrismGT chipset, it had also found the device’s interface handle ‘eth0’. Once it had
been established that the chipset and driver were correct Airmon was launched again from the terminal,
this time with the arguments ‘start eth0’, which instructed Airmon to start the eth0 wireless device in
monitor mode (promiscuous). This monitor mode enabled the interface to passively monitor all traffic,
no matter what channel it was on, thus enabling capturing to be feasible.
COMMUNICATION NETWORKS, YR 4
-5-
fig 2.2
With eth0 in monitor mode the following command was executed from the terminal ‘airodump eth0 out5
2 1’. The Airodump command told Airodump to capture packets from the ‘eth0’ interface and save them
to an output file called out5, the number two represents which channel to listen to and the number one
tells Airodump to only capture IVs to keep the size of the log file down.
fig 2.3
As can be seen in fig 2.3 packets were being captured from channel two, however for some unknown
reason other channels were being shown while capturing even though only channel two had been
specified. It was believed that this was because the other channels were open and had no security.
Although the other channels were shown there was no sign of capturing packets from the open channels.
At this point the client (Samsung laptop) was connected to the AP and the attacker (Advent laptop) was
setup and capturing any IV packets from channel two. As the SSID broadcast feature had not been
switched off it was known that the AP’s SSID or ESSID was ‘WA’, it was also shown that both the client
(Samsung laptop) and the AP’s MAC (Media Access Control) addresses were found. From this point
Aireplay was used, from within a new terminal Aireplay was launched with the following arguments
‘aireplay -1 30 –e WA –a 00:0F:B5:D7:2C:4B –h 0:1:2:3:4:5 eth0’ (fig 2.4). These arguments told
Aireplay to try and authenticate every 30 seconds with the AP which had an SSID of ‘WA’ and a MAC
address of 00:0F:B5:D7:2C:4B using a spoofed MAC for itself of 0:1:2:3:4:5, the final argument tells
Aireplay which interface to output the packets to.
fig 2.4
It was this authentication stage that was not possible using the AP with network authentication set to
‘Shared Key’. It was believed that the AP required full authentication including WEP passphrase before
dealing with clients in shared key mode, hence why it would not allow a partial authentication like the
open system. Once the authentication attack had been launched the attacker’s machine kept a constant
partial authentication with the AP, as can be seen within fig 2.5.
COMMUNICATION NETWORKS, YR 4
-6-
fig 2.5
Once the authentication attack got an ‘Authentication successful’ messages Aireplay could commence
with its other attack method. This time Aireplay was used with ‘-3’ and ‘-x 600’ arguments, these
arguments told Aireplay to use attack method three and to send 600 packets per second. Attack method
three was an ARP replay attack, whereby the attacker sends replays of captured ARP packets to the AP at
a rate specified by the ‘-x’ argument. Sending these ARP packets prompts the AP to respond causing an
increase in IV use as the AP in this case would have to respond to 600 packets per second, which would
equate to 600 IVs a second, this can be seen in fig 2.6. Basically attack method three was just packet
injecting and keeping the network traffic artificially high, while this attack was taking place the responses
from the AP were being captured for later decryption via Airodump which was still running.
You will note in fig 2.6, that attack method three was first used with the spoofed MAC of 0:1:2:3:4:5, this
method works. However there was a limitation to using the spoofed MAC, in that it was not fully
authenticated with the AP and would systematically have to keep reconnecting via the authentication
attack, so overall fewer packets could be injected in this case. Alternatively a man-in-the-middle attack
seemed to have more success, where the ARP packets being injected used the spoofed MAC address of a
client already connected to the AP, in this case the Samsung laptop. So instead of using 0:1:2:3:4:5 the
client’s MAC of 00:0E:35:B0:E8:06 was used.
fig 2.6
Fig 2.6 shows an overall injection of 1039806 packets in around 30 minutes, as previously stated all of
resultant packets produced by the injected packets were captured and stored in a file called out5.
Many tutorials suggest that for 64 bit WEP a capture of 500,000 packets was advisable, but to be on the
safe side 763346 packets were collected. Now with the required amount of packets Aircrack was used to
decrypt the passphrase from the collected IV packets.
Fig 2.7 shows the command used to launch Aircrack, the arguments ‘–x’ tells Aircrack not to crack the
last two keybytes, as for the ‘-0’ argument there is no explanation with the program help documentation
to explain what it instructs Aircrack to do (possibly a Fudge factor setting). The last two arguments
identify which interface was used in the capturing and what the output file was called, Aircrack takes this
data and loads all of the IVs captured and begins a bruteforce attack on the data it has.
COMMUNICATION NETWORKS, YR 4
-7-
fig 2.7
In this scenario Aircrack asked which network to find the passphrase for, again this was not expected as
only channel two was being monitored so therefore there should have only been packets from channel
two. It could only be concluded that the other channels were listed as they had no encryption. It can also
be seen from fig 2.8 that the only channel to have any IVs captured from, was that of channel two, where
it can be seen that a total of 632388 IVs were found.
fig 2.8
Once the correct network and AP were selected, in this case selection one, the bruteforce attack could
begin. An interesting point to make note of was that although 1039806 packets were injected, only
632388 IVs were collected, which was still above the 500,000 packets suggested to retrieve the
passphrase of 64 bit WEP. The extra packets are believed to be beacons from the AP that do not contain
an IV. Fig 2.9 shows a capture of the bruteforce attack and completion, due to the weakness of the
passphrase and the number of packets collected it took no time at all to break the WEP encryption as can
be seen from the Aircrack’s sequence timer (top left near Tested Keys).
fig 2.9
The found WEP passphrase was ‘F2:C7:BB:35:B9’, if compared to the beginning configuration value of
the AP as shown in fig 1.4, it can be seen that the passphrase was indeed ‘F2:C7:BB:35:B9’.
CONCLUSION:
The investigation within the lab was successful in breaking 64 bit WEP which had a weak password, it
must be noted though, that this was the lowest form of security to be obtained from WEP. Alternatively
128 bit WEP could be used, which although still flawed would have sustained an attack for longer. While
researching for this lab it had became apparent that whether an encryption system was strong or not, the
primary downfall tends to be the password/passphrase used with the encryption. This was said as a
number of tools claim to break WPA, which was the replacement for WEP, however the majority of these
tools merely carry out a dictionary attack. This same dictionary attack could be used on WEP with the
same success, simply because if the passphrase or password can be found within a dictionary the likely
hood is that the dictionary attack will find it. Many websites like the following;
COMMUNICATION NETWORKS, YR 4
-8-
http://neworder.box.sk/search.php?srch=wordlist, have dictionaries available for such tasks that list
typical passwords from pets names to places and current slang words. This form of attack is not breaking
the encryption but bypassing it through poor password management. This aside the WEP encryption
although weak and flawed would still be useable with other security systems, if used in conjunction with
VPN or a radius authentication server, WEP can be part of a formidable security system. For extra
security without the extra cost, MAC filtering could be employed, however this is not full proof as MAC
spoofing will bypass this security. Other methods to increase security with WEP would be to use a
‘Shared System Authentication’ as shown within this lab. This option may be dubious as the initial tests
with the Linksys WAP54G AP utilised a ‘Shared System Authentication’ and it did not block the
authentication attack. This may be down to firmware issues or any other possible reason and would
require further proving. It would also be wise to disable the SSID broadcasting as this will make hacking
the wireless link that little bit harder, thus increasing the security of the link. The final two points that
would make a WEP protected system’s security stronger are a well planned password management policy
and active network monitoring. If network monitoring had taking place within the lab, it would have
been evident that the wireless link was under attack. The intrusive nature of the packet injection attack
caused a spike in traffic in terms of packets sent per second. This spike in traffic furthered with the
spurious MAC authentication of 0:1:2:3:4:5 with the AP, would of heightened suspicion that an attack
was taking place giving the network admin chance to block the MAC or pull the plug.
REFERENCES:
[1]
[2]
http://www.wi-fiplanet.com/tutorials/article.php/1368661
http://www.grape-info.com/doc/linux/config/aircrack-2.3.html
BIBLIOGRAPHY:
http://www.wifigeek.net/forum-8.html
http://www.michiganwireless.org/tools/aircrack/
http://cyberjedi.net:8080/~no7up4u2/aircrackbeta.html
http://neworder.box.sk/search.php?srch=wordlist
http://www.crimemachine.com/tutorial.htm
http://www.remote-exploit.org/index.php/Tutorials#128_Bit_Wep_cracking
COMMUNICATION NETWORKS, YR 4
-9-