Professional Documents
Culture Documents
1. Introduction
This document will give a brief background on 802.11b based WEP weaknesses and
outline a few additional flaws in rc4 that stem off of the concepts outlined
in "Weaknesses in the Key Scheduling Algorithm of RC4" (FMS) and "Using the
Fluhrer, Mantin, and Shamir Attack to Break WEP" (SIR) and describes specific
methods that will allow you to optimize key recovery. This document is
provided as a conceptual supplement to dweputils, a wep auditing toolset,
which is part of the bsd-airtools package provided by Dachb0den Labs. The
basic goal of the article is to provide technical details on how to
effectively implement the FMS attack so that it works efficiently with both a
small amount of iv collection time as well as cracking and processing time and
to provide details on how other pseudo random generation algorithm (prga)
output bytes reveal key information.
2. Background
WEP is based on RSA's rc4 stream cipher and uses a 24-bit initialization
vector (iv), which is concatenated with a 40-bit or 104-bit secret shared key
to create a 64-bit or 128-bit key which is used as the rc4 seed. Most cards
either generate the 24-bit iv using a counter or by using some sort of pseudo
random number generator (prng). The payload is then encrypted along with an
appended 32-bit checksum and sent out with the iv in plaintext as illustrated:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 802.11 Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV[0] | IV[1] | IV[2] | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . SNAP[0] . . . . . | . . . . . SNAP[1] . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . SNAP[2] . . . . . | . . . . Protocol ID . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . Payload . . . . . . . . . . . . . . |
| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . 32-bit Checksum . . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After the data is sent out, the receiver simply concatenates the received iv
with their secret key to decrypt the payload. If the checksum checks out, then
the packet is valid.
2.1. Current Cracking Methods
Essentially, most of the wep attacks out there these days are either based on
brute forcing methods, often times including optimizations based on how the
key is generated or by using a wordlist, or through statistical analysis of
initialization vectors (ivs) and their first rc4 output byte, to setup
conditions in the rc4 key scheduling algorithm (ksa) that reveal information
about particular bytes in the secret key.
Tim Newsham's most effective cracking method stems off of the weaknesses in
the password based key generation algorithm used by most 40-bit cards and
access points. By taking advantage of this weakness, it reduces the 40-bit
keyspace down to 21-bit, which is trivial to crack (20-40 seconds with most
current-day machines). Also, wordlist attacks prove almost equally effective
on both 40-bit and 104-bit 802.11b networks, provided you have a decent list
of commonly used passphrases. Even without using these optimizations, you can
still exhaust the entire 40-bit keyspace in roughly 45-days on a decent
machine, or in a very reasonable amount of time using a distributed network of
machines.
Although this mode of attack can be applied to many networks out there, it
fails to be able to attack a properly secured 104-bit network, since the
amount of time required to brute force 104-bit is generally longer than an
attacker's great-grandchildren would want to wait.
Up until now, all open source wep cracking utilities that use the FMS Attack
have used an extremely limited mode of operation as described in FMS in
Section 7.1 "IV Precedes the Secret Key", and is also published by Wagner in
Wag95, which involves only looking for ivs that match:
(A + 3, N - 1, X)
This is a particular condition that works almost all of the time and is not
dependent on the preceding keys. However, as described later on in FMS in
Section A "Applying The Attack to WEP-like Cryptosystems", they recommend that
you use the following equation on the S permutation immediately after the KSA
to determine if an iv is weak:
This equation uncovers many more ivs than the 256 per key that most
implementations currently use. This was made obvious in SIR in Section 4.1
"Choosing IVs", but wasn't thoroughly expanded on about how to effectively use
a pool of logged ivs to successfully perform this attack in a reasonable
amount of time.
The main dilemmas with applying this equation to all of the IVs that you
collect are that you have to check all of your logged ivs at least once for
every key byte that you try, and that it takes a considerable amount of
resources to apply this algorithm to a set of 2,000,000 ivs. So, not only do
you have to do a large amount of processing, but also for an extremely large
set of possibilities.
Also, all of the current implementations only attack the 1st rc4 output byte,
mainly because it is the one that provides the most accurate information about
the key bytes. However, by attacking the other bytes, it can also provide
clues, although minute, to the static key that was used. This can sometime
provide enough statistical data to derive key bytes in cases when you aren't
able to collect a large amount of captured data, and have more time to spend
processing.
The main flaw with rc4 that hasn't been thoroughly expanded, is using
information provided by other bytes in the prga output stream. This attack is
similar to the FMS attack, but requires additional processing because you have
to also emulate portions of the pseudo random generation algorithm (prga) to
determine if an iv gives out key information in byte A. However, the bytes
that you can attack using this method directly depend on the bytes of the key
you have already recovered and are extremely hard to predict without excessive
processing. To demonstrate this, I will first provide background on the
current common mode of attack which attacks the first output byte and then
show how it can be expanded to other bytes.
The first byte attack works based on the fact that you can simulate part of
the ksa using the known iv and derive the values of elements in the S
permutation that will only change 1 - (e ** -X) of the time, where X is the
number of S elements that your attack depends on. This can be illustrated as
follows when attacking the first byte in the secret key (SK):
Definitions:
KSA(K)
Initialization:
For i = 0 ... N - 1
S[i] = i
j = 0
Scrambling:
For i = 0 ... N - 1
j = j + S[i] + K[i mod l]
Swap(S[i], S[j])
PRGA(K)
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]]
Simulation:
KSA - K = 3, f, 8, 1, 2, 3, 4, 5
Known Portion:
0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] K
3 0 i = 0, j = 0 + 0 + 3 = 3
0 1 i = 1, j = 3 + 1 + f = 3
d 2 i = 2, j = 3 + 2 + 8 = d
Unknown Portion:
f 1 i = 3, j = d + 1 + 1 = f
- Note that S[B + 3] always contains information relating to SK[B], since
SK[B] is used to calculate j.
PRGA - S = 3, 0, d, f, 4, 5, 6, 7, 8, 9, a, b, c, 2, e, 1
Unknown Portion:
0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] S[i] S[j]
3 0 d f 4 5 6 7 8 9 a b c 2 e 1 Unknown KSA Output
0 3 i = 1, j = 0 + 0 = 0, z = S[0 + 3] = f
In this instance, f will be output as the first PRGA byte, which is in turn
xor'ed with the first byte of the snap header. The first byte of the snap
header is almost always 0xaa, so we can easily derive the original f by simply
xor'ing the first byte in our encrypted payload with 0xaa. To reverse the f
back into the first byte of the SK that was used to generate it, we just
iterate through the KSA up until the point where we know the j and S[i] values
that were used to derive the f as provided in the previous demonstration. Once
the j and S[i] values are derived, we can easily reverse it to SK[B] as
illustrated:
Definitions:
Application:
By collecting many different SK[B] values the correct SK[B] values should
become more evident as more data is collected. Additionally, once we determine
the most probable value for the first byte in the secret key, we can apply the
same algorithm to cracking the next byte in the secret key, and continue until
we have cracked the entire secret key. In most implementations this method is
combined with brute forcing so the odds don't have to be perfect in order to
recover the key.
This section will demonstrate a set of new unique ivs that provide clues to
various bytes in the secret key and in some cases with greater probability
than the first bytes. I will first demonstrate what happens when rc4
encounters one of these ivs, and then provide methods for detecting them.
In this demonstration, I will use a weak iv that attacks the 2nd byte and show
how certain ivs setup the S permutation so that secret key information is
revealed in the 2nd byte of output. This method also applies to other output
bytes and can be expanded depending on which secret key byte you are
attacking. Here is what happens:
Simulation:
KSA - K = 4, c, c, 1, 2, 3, 4, 5
Known Portion:
0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] K
4 0 i = 0, j = 0 + 0 + 4 = 4
1 i = 1, j = 4 + 1 + c = 1
f 2 i = 2, j = 1 + 2 + c = f
Unknown Portion:
3 i = 3, j = f + 3 + 1 = 3
PRGA - S = 4, 1, f, 3, 0, 5, 6, 7, 8, 9, a, b, c, d, e, 2
Unknown Portion:
0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] S[i] S[j]
4 1 f 3 0 5 6 7 8 9 a b c d e 2 Unknown KSA Output
1 i = 1, j = 0 + 1 = 1, z = S[1 + 1] = f
f 4 i = 2, j = 1 + f = 0, z = S[f + 4] = 3
Then, since we also often times know that the second byte of the snap header
is 0xaa, we can determine the 2nd byte of prga output and reverse it back to
the original key, as demonstrated:
PRGA(K)
Initialization:
For i = 0 ... N - 1
P[i] = 0
P[B + 3] = 1
i = 0
j = 0
Generation Loop:
While i < A + 1
i = i + 1
j = j + S[i]
If i or j >= B + 3 Then Fail
Swap(S[i], S[j])
Output z = S[S[i] + S[j]]
P[i] = 1
P[j] = 1
Verification:
If S[i] + S[j] = B + 3 Then Success
Probability Analysis:
j = 0
For i = 0 ... N - 1
If P[i] > 0 Then j = j + 1
This algorithm also works almost identically to the equation for determining
if an iv is vulnerable to the first byte attack and can be expanded to
detecting ivs that reveal keys in any byte in the prga output. You can then
weigh the probabilities and determine if it is worth considering.
In tests, this method doesn't prove entirely useful, mainly due to the amount
of processing that is required to determine if certain ivs have this property.
Since each iv has to be checked for each previous secret key byte that you
try, it would probably be most practical to manually derive a table of
vulnerable ivs, so it doesn't require much work during key recovery.
In most cases it'd be more practical to collect more ivs and only use the
first bytes to perform key recovery, however in cases when you have a limited
set of sample data, it could greatly reduce the time required for recovery.
4. Implementation
This section will focus on practical methods for making use of all of the 1st
byte weak ivs without hindering performance. It will also cover optimizations
for applying brute forcing and fudging methods to greatly reduce cracking
time. The result of the optimizations will allow you to perform key recovery
with only 500,000-2,000,000 packets and < 1 minute processing time.
Although, in SIR it is mentioned that they were able to crack wep with a
similar number of packets, this mode of attack does not require that the wep
key be ascii characters, and isn't dependent on what key generator the victim
used.
The main problem with attacking wep using all of the first byte weak ivs, is
that the equation specified in FMS has to be applied to each of the ivs for
every key that you try. Since often times you'll have a total of 2,000,000
packets that you've collected and thousands of keys you need to try before you
find the correct one. It has thus far been impractical to use this mode of
attack, since it requires a large amount of memory as well as resources.
The way I have managed to get around this dilemma is by analyzing the patterns
of weak ivs and how they are related to the key bytes they rely on. This is
the basic pattern that I've found.
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
This pattern can then be easily expanded into an equation that covers a range
independent of what SK values you have. As a result, you have distribution
pattern similar to the one shown below:
From this, we can determine a rough estimate of how many total weak ivs exist
for each key byte. It can also be determined using the following equation:
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
Which should differ slightly from the previous weak iv estimation equation
since some ivs in the pattern overlap. By sorting these IVs into tables, you
can very easily narrow down the amount of ivs to search for each cracking
operation to a maximum of 852,736 ivs, or around only 101,654 when supplied
with a 2,000,000 packet capture file. This effectively reduces the search time
for each key by at least 1/20.
4.2. Fudging
When trying to recover keys using a capture file that doesn't statistically
provide enough immediate information to determine the secret key, it is common
to perform a brute force based on the most probable key bytes. Up until now
the fudge, or breadth, has been implemented as a static number that specifies
the range to search for each key byte. However, with > 2,000,000 samples and a
large amount of weak ivs for each byte the probability that the correct key
will be the most probable gets greater as you traverse through each byte. A
estimate of the probabilities for this are outlined below:
Therefore, it's most likely that once you reach byte 2, the key that seems
most probable, most likely is. This means that fudging is most likely not
required, or at the least should be reduced, the farther you move through the
bytes. This reduces the brute forcing time required considerably, since now it
is only necessary to fudge the first few bytes of the key, and the rest is no
longer necessary. I have found in most cases, because of this property of weak
ivs, it requires quite less packets than 2,000,000 to recover the key, and
in some cases you don't even require any statistics for the first couple bytes
of the secret key to perform this attack in a very reasonable amount of time.
5. Results
Using the outlined modifications, I've managed to crack wep using between
500,000 and 2,000,000 packets in under a minute, this is mainly due to the
time required for reading in the packets. Here is an example of a successful
attack using quite less than the 60 required ivs and only ~ 500,000 packets:
(!) insufficient ivs, must have > 60 for each key (!)
(!) probability of success for each key with (!) < 0.5 (!)
progress: ....................................
6. Conclusions
The best solution for securing your wireless networks is using traditional
wireless security to its fullest, but not relying on it. Manually enter in
your wep keys and don't use the key generator (or use dwepkeygen ;-Q), change
your wep keys frequently, use mac filtering and shared key authentication, and
label your wireless network as untrusted (and no, I don't necessarily mean set
your ssid to "untrusted"). Wireless networks, just like any other networks,
are proportionately insecure to the stupidity of the person managing them.
References