WLAN control is cracking WEP. As mentioned, wireless attacks do not start and
end with cracking WEP, as many security experts might tell you. However, if the
attacker cannot break WEP (if present), all he or she can do is disrupt the
network operations by DoS attacks on layers below the protocol WEP
implementation.
From the section dealing with WEP cracking tools, you have
probably gathered that there are three major ways of attacking WEP:
Because this book is a down-to-earth guide to wireless security
and hundreds of pages have already been written on WEP weaknesses and cracking
mathematics, we do not aim to provide a comprehensive guide to the mathematical
internals of WEP cracking attacks. Nevertheless, we believe it is important to
present some cryptological data on WEP as an act of homage to all researchers
who contributed to the WEP analysis and flaw enumeration.
WEP Brute-Forcing
Pure WEP keyspace brute-forcing with tools such as
wep_tools or
dwepcrack brute-forcing options is realistic only
against 40-bit WEP keys.
Even with this limited key size, it might take about 50
days on a single average Pentium III host. Nevertheless, an efficient
distributed attack against 40-bit WEP is possible and one should never
underestimate the potential of dictionary attacks, which are also applicable to
128-bit and higher WEP key size. In particular, it applies to the use of the
newer Wepattack tool that can run dictionary attacks against a single captured
data packet encrypted using WEP.
Tim has pointed out that the algorithm accepted as the
de facto standard for 40-bit WEP key generation by many wireless equipment
vendors is extremely flawed. It starts from folding a password string into a
32-bit number that reduces the keyspace from 240 to 232
bits. This number is employed to seed a pseudorandom number generator (PRNG which is used to derive
all four 40-bit WEP keys used on the network. Although the PRNG-generated
keyspace has a cycle length of 232 bits, because of the way the
values are derived from the PRNG, the actual cycle length of drawn values is
only 224 bits. To be more specific, a seed x produces the same keys as a seed x + 224. To make the situation even worse,
the method chosen to fold a password string into a 32-bit seed ensures that the
high bit of each of the four bytes always equals zero. The effect of these
weaknesses combined is that the algorithm can only generate 221
unique sets of WEP keys, corresponding to seeds between 0 and 0x1000000, which
do not have bits 0x80, 0x8000, or 0x800000 set. Thus, it takes 221
operations or less to crack any set of WEP keys generated from a password
processed with such an algorithm. In Newsham's observations, this corresponds
roughly to 90 seconds of cracking time on a 233-MHz PII or 35 seconds on a
500-MHz PIII; this is quite a difference if compared to 50 days of brute-forcing
without this flaw.
However, not all vendors used the vulnerable key generation
algorithm (to our knowledge, 3Com never did), 40-bit keys aren't used much
anymore, and there are tools that ensure proper 40-bit key generation. An
example of such a tool is dwepkeygen, included as part of BSD-airtools.
In addition, to crack WEP using wep_tools, a large (about 24 Gb) pcap-format
dump file is required. Thus, although Newsham's comments are interesting and
have their place in the history of wireless cryptanalysis, we do not recommend
trying the attack he developed or using brute-forcing in general against
128/104-bit WEP keys used by modern wireless networks.
However if
you have truly massive traffic dump files, trying a dictionary attack using
wep_tools or dwepcrack could bring success. Even better, you
can try your luck with a dictionary attack against a single captured data packet
or limited-size traffic dumps using Wepattack.
The FMS Attack
The most common attack against WEP is Scott Fluhrer, Itsik
Mantin, and Adi Shamir's (FMS) key recovery methodology discovered in 2001 (the
original paper entitled "Weaknesses in the Key Scheduling Algorithm of RC4" ). As you
already know, this attack was implemented first by the Wep_crack and then by
AirSnort. For those interested in how the attack algorithms work, we present a
brief explanation here. If you are already familiar with the FMS attack or
aren't interested in the "theoretical" cryptanalysis, feel free to skip this
section and move forward.
The FMS attack is based on three main principles:
-
Some IVs set up RC4 cipher the way it can reveal key information in
its output bytes.
-
Invariance weakness allows use of the output bytes to determine
the most probable key bytes.
-
The first output bytes are always predictable because they
contain the SNAP header defined by the IEEE
specification.
A WEP key can be defined as K=IV.SK where SK is the
secret key. The RC4 operation in a nutshell is K=IV.SK ---> KSA(K)
---> PRNG(K) XOR data stream. The scheduling algorithm KSA(K) works in
the following way:
Initialization:
For i = 0 \x{2026} N - 1
S[i] = i
j = 0
Scrambling:
For i = 0 \x{2026} N - 1
j = j + S[i] + K[i mod l]
Swap(S[i], S[j])
The PRNG works as:
Initialization:
i = 0
j = 0
Generation Loop:
i = i + 1
j = j + S[i]
Swap(S[i], S[j])
Output Z = S[S[i] + S[j]]
Some IVs initialize the PRNG the way the first byte in the
stream is generated using a byte from the secret key. Because the first data
byte that the PRNG output is XORed with is predictable (SNAP header), it is easy
to derive the first PRNG byte. The values we can get from weak IVs are only true
about 5 percent of the time; some are true about 13 percent of the time. Taking
into account the key size, it takes six to eight million packets of analysis to
determine the correct WEP key. The theoretical packets throughput maximum ("wire
speed") on the throughput-comparable to 802.11b LAN 10Base-T shared Ethernet is
812 frames per second (frame size of 1,518 bits). If we divide 6,000,000 by 812
we will get about 7,389 seconds or just above 2 hours necessary to accumulate
enough packets for efficient WEP cracking. However, as we will see, the reality
is different.
The basic FMS attack comes down to searching for IVs that
conform to the (A + 3, N - 1, X) rule, where A is the byte in the
secret key you are cracking, N is the size of the S-box (256) and X is a random
number. It is advised that the following equations are applied right after the
KSA:
X = SB+3[1] < B+3
X + SB+3[X] = B+3
The main problem is that such an equation is dependent on the
previous key bytes, so it must be applied to the entire packet dump for every
key byte that is tested. In its classical form, the FMS attack tests only the
first byte of the output because it is very reliable; we know that the first
byte of the SNAP header is nearly always 0xAA.
An Improved FMS Attack
To bypass this problem and optimize the FMS attack, H1kari of
Dasb0den Labs has analyzed the patterns of weak Ivs appearance and how they
relate to the key bytes they rely on. As he pointed out in the "Practical
Exploitation of RC4 Weaknesses in WEP Environments" article. a
basic pattern present can be defined as follows:
Definitions:
let x = iv[0]
let y = iv[1]
let z = iv[2]
let a = x + y
let b = (x + y) - z
Byte 0:
x = 3 and y = 255
a = 0 or 1 and b = 2
Byte 1:
x = 4 and y = 255
a = 0 or 2 and b = SK[0] + 5
Byte 2:
x = 5 and y = 255
a = 0 or 3 and b = SK[0] + SK[1] + 9
a = 1 and b = 1 or 6 + SK[0] or 5 + SK[0]
a = 2 and b = 6
Byte 3:
x = 6 and y = 255
a = 0 or 4 and b = SK[0] + SK[1] + SK[2] + 14
a = 1 and b = 0 or SK[0] + SK[1] + 10 or SK[0] + SK[1] + 9
a = 3 and b = 8
Byte 4:
x = 7 and y = 255
a = 0 or 5 and b = SK[0] + SK[1] + SK[2] + SK[3] + 20
a = 1 and b = 255 or SK[0] + SK[1] + SK[2] + 15 or
SK[0] + SK[1] + SK[2] + 14
a = 2 and b = SK[0] + SK[1] + 11 or SK[0] + SK[1] + 9
a = 3 and b = SK[0] + 11
a = 4 and b = 10
The resulting distribution pattern would be similar to
this:
Secret Key Byte
0 1 2 3 4 5 6 7 8 9 a b c
+ + + + + +
0 8 16 16 16 16 16 16 16 16 16 16 16 16
1 8 16 16 16 16 16 16 16 16 16 16 16
2 16 8 16 16 16 16 16 16 16 16 16
a 3 16 8 16 16 16 16 16 16 16 16
4 16 8 16 16 16 16 16 16 16
V 5 16 8 16 16 16 16 16 16
a 6 16 8 16 16 16 16 16
l 7 16 8 16 16 16 16 16
u 8 16 8 16 16 16 16
e 9 16 8 16 16 16
s a 16 8 16 16
b 16 8 16
c 16 8
d 16
8 - 8-bit set of weak ivs
16 - 16-bit set of weak ivs
+ - 2 additional x and y dependent 8-bit weak ivs
From this distribution a rough estimate of weak IVs per key
byte can be derived. There are other means of deriving this value as outlined in
the referenced article. However, the real catch is to find an algorithm that
will allow filtering out weak IVs
based on the secret key byte that they can attack. This can be done with an
algorithm similar to this:
let l = the amount of elements in SK
i = 0
For B = 0 ... l - 1
If (((0 <= a and a < B) or
(a = B and b = (B + 1) * 2)) and
(B % 2 ? a != (B + 1) / 2 : 1)) or
(a = B + 1 and (B = 0 ? b = (B + 1) * 2 : 1)) or
(x = B + 3 and y = N - 1) or
(B != 0 and !(B % 2) ? (x = 1 and y = (B / 2) + 1) or
(x = (B / 2) + 2 and y = (N - 1) - x) : 0)
Then ReportWeakIV
Such methodology effectively reduces the search time for each
key by at least 1/20, thus giving us the time necessary to crack WEP. Now you
don't need to collect 6,000,000 packets or more; half a million packets could be
sufficient! This is the improved FMS attack as implemented by BSD-airtools
dwepcrack; read its source code to discover and learn more.
The
practicality of WEP cracking attacks is still denied by many. There are
statements that, for example, a home or SOHO WLAN will not generate enough
traffic to collect a sufficient amount of weak or interesting IVs for the key
compromise in a reasonable time period. You just saw a methodology that can
significantly cut the necessary data collected and this methodology has been
implemented in a security auditing tool since the year 2001! However, even if
the most commonly used WEP cracking tool, AirSnort, is employed, the results can
be less than encouraging for the few remaining WEP enthusiasts. In our
experience it takes only 3,000 to 3,500 interesting IVs frames to break the WEP
key for either 64-bit or 128-bit WEP keys using AirSnort. The only difference
mentioned between cracking the keys of both sizes is the amount of time
necessary to collect these frames. It took 10 to 20 percent more time to collect
the necessary amount of interesting IVs frames to obtain a 128-bit key on a
testing wireless network. Our record of breaking a 64-bit WEP with AirSnort is 1
hour 47 minutes on a point-to-point 802.11b link with one of the hosts flood
pinging the other (approximately 300 packets per second). Such an attack
required 107 minutes * 300 packets/second = 1,926,000 packets, much less than
the 6,000,000 packets estimated theoretically. It could've been sheer luck, but
would you base your network security on guesswork considering how lucky or
unlucky an attacker might be?
On a large, corporate wireless network, 300 packets per second
is neither unusual nor unexpected, especially with 802.11a and 802.11g standards
offering higher bandwidth and network throughput. The presence of "chatty"
network protocols (RIP, link-state routing protocols "hello" packets, spanning
tree, HSRP, VRRP, NetBIOS, IPX RIP and SAP, AppleTalk, etc.) might dramatically
decrease the time needed to crack WEP. It also generates wireless traffic even
when no user activity is present. Imagine a large wireless Novell-based network
running NetBIOS over IPX and using three Cisco routers with turned-on hot
standby for failover resilience and enabled CDP (we have seen networks like this
in the United Kingdom on several occasions). Such a network does not have to be
the WLAN itself; leaking wired traffic on the wireless side is sufficient and we
have frequently seen access points plugged directly into the switch or hub.
Let's say there are 100 hosts on the network and no user activity present. In
one hour, every host will generate approximately 1,200 NetBIOS keep-alives, 40
IPX RIPs, and 40 SAPs, and each router will send 1,200 HSRP Hello packets and 60
CDP frames if the defaults aren't changed (they rarely are), as well as the
obvious 40 RIPs. Thus, the number of generated packets will be 100x(1,200+40+40)
+ 3x(1,200+60+40) = 131,900 packets per hour. Thus, accumulating the 2,000,000
packets necessary to crack WEP with AirSnort in our example will take
approximately 15 hours.
With dwepcrack as few as 500,000 packets might
be needed, which translates into approximately 3 hours, 47 minutes, without a
single user logged in! Remember that this network is both perfect and
hypothetical. In reality, a Novell server might send more than one SAP in 90
seconds because a single SAP packet can advertise up to seven services and the
server might run more. NLSP might be running and STP traffic could be present.
We frequently find networks with system administrators completely unaware of the
unnecessary and unused STP traffic on the network and some higher end switches
and even wireless access points have STP enabled by default. Mind the
traffic!
Finally, in some cases, old 802.11b cards use the same IV value
or start counting IV numbers from 0 each time the card is initialized and
increments these numbers by one. This also significantly cuts the time necessary
to crack WEP.
How about cracking WEP on 802.11a networks? It is essentially
the same. The only difference is that we aren't aware of decent 802.11a support
on BSD and AirSnort will not work with
ark_5k. However, you can save a
pcap-format 802.11a traffic dump file obtained using an Atheros chipset card in
the RFMON mode and tcpdump (or Kismet) and feed it to AirSnort or even dwepcrack
(after booting into BSD). If you want real-time WEP cracking on an 802.11a
network, use
wepcrack and the power
of
at/crond as we have
described. For example, you can pipe tcpdump output into
prism-getIV.pl
and then process the
IVFile.log file with
WEPCrack.pl.
