RE: WEP attacks based on IV Collisions

From: Jeremy Junginger (jj_at_act.com)
Date: 06/02/04

  • Next message: Jerry Shenk: "RE: USB delivered attacks - lessons learned/summary (so far)" 
    To: <ivan.arce@coresecurity.com>, <pen-test@securityfocus.com>
Date: Wed, 2 Jun 2004 08:09:17 -0700

    Good Morning!

    I hope this thread isn't dead yet...I could use a little help digesting this
    whole inductive WEP attack thing...allow me to regurgitate the WEP encryption
    process just to make sure I'm understanding that part correctly:

    1) The original packet consists of [802.11 header] + [host (L3) data]
    2) CRC-32 is computed for [host (L3) data] and is appended as the [ICV (4
    bytes)]
    3) The [host data] + [ICV] are fed into the RC4 stream cipher, using the [(IV
    3 bytes) + (Secret 5/13 bytes)] as the key.
    4) The original [802.11 header] + [IV] + [Ciphertext] output from step 3
    constitutes the new WEP encrypted packet.

    Assuming that is basically correct, the mechanics of how one recovers the key
    stream from intercepted WEP traffic are giving me some trouble. The root of
    the problem for me is recognizing encrypted packets as known packet types
    (ARP, DHCP DISCOVER/REQUEST, etc). The article makes it seem trivial to
    recover the an initial pseudorandom string:

    "Generally, the attacker can accomplish this (stream recovery) using network
    protocol structure and external information such as media access control
    address and message size to guess the plaintext." (Sounds like ARP to me,
    and that makes sense. We all know what an ARP broadcast should look like)

    and

    "Perhaps the simplest example is network traffic for dynamic host
    configuration protocol session...particularly DISCOVER and REQUEST, are easy
    to identify even when encrypted and have highly predictable fields including
    all of the IP header and most of the UDP header." (No brainer here, DHCP is
    predictable)

    The theory makes sense. We all know what a DHCP DISCOVER and REQUEST look
    like (LLC, IP Header, UDP Header), and that the known fields can be used as
    known plaintext to mount an attack on the RC4 stream cipher, but is that what
    we're doing to get the key stream?

    If that is the case, it appears that we can get our n bytes of key stream
    just by having a single packet, right? Just convert both the plaintext and
    ciphertext to binary, and figure out what you need to XOR the plaintext with
    to get the ciphertext, one bit at a time to recover the key sequence of n
    bytes, right?

    But before I can even think about the key, I need to figure out how to
    identify these encrypted DHCP? Anyone know?

    Okay, let's say I figure out how to identify these packets, and that I've
    recovered hmmm...let's say 11 bytes of the key stream (from 8 bytes from LLC
    and SNAP plus 3 bytes from IP header). From here, I should be able to inject
    a 7 byte (n-4) message into the network, using the part of the key stream I
    know, right? Okay, if that's right, let's move on to the next section,
    extending the key stream. Here goes...(expecting a lot of red ink in the
    replies)

    1) Generate an 8 byte (n-3) message that generates a predictable response (8
    byte ICMP packet? What shall we use here?)
    2) Compute the ICV for the new message (just CRC32 the message), and append
    the first 3 bytes (Now we have an 11 byte message)
    3) Combine the 11 byte message from step 2 with the known key stream
    4) Transmit a 12 byte message, using the 11 bytes from step 2 and a guess at
    the final byte. Repeat until response is received.
    5) XOR the 12th byte with the last byte of the correct ICV computed in step
    2. That's the next key stream byte.

    As you can see, I'm a little confused about some of this stuff. If you guys
    can shed any light on it, that would be very helpful.

    If you are feeling really generous, perhaps we can work through an example of
    a WEP encrypted DHCP DISCOVER or REQUEST packet as an example, in order to
    recover some key stream bits. Anyone care to whip up an encrypted DHCP
    packet for the list so we can work through an example?

    Thanks for your time and patience, and I look forward to your response(s).

    -Jeremy

    -----Original Message-----
    From: Ivan Arce [mailto:ivan.arce@coresecurity.com]
    Sent: Monday, May 10, 2004 10:49 PM
    To: pen-test@securityfocus.com
    Subject: Re: WEP attacks based on IV Collisions

    Nick Petroni and Bill Arbaugh have outlined an active attack that would give
    you full access to a WEP encrypted wireless LAN without knowledge of the
    secret key. It relies on the lack of integrity checks for the wireless
    packets which lets an attacker inject arbitrary packets into the LAN without
    being detected.

    The attack does not require you to crack any WEP key and uses the fact that
    WEP wrongly uses CRC for integrity checks, this lets an attacker mount an
    inductive attack to gradually recover additional bits of a pseudorandom
    stream provided that N bytes are initially recovered with a known plaintext
    attack. They cite ARP and DHCP requests as effective for this inital
    recovery. BTW, you dont really need to *inject* packets for the inital
    recovery.

    Full description of the attack appeared on:
    "The Dangers of Mitigating Security Design Flaws: A Wireless Case Study" Nick
    L. Petroni Jr. and William Arbaugh IEEE Security & Privacy magazine vol1. num
    1., January/February 2003

    A powerpoint presentation is available at:
    http://www.cs.umd.edu/~waa/wepwep2-attack.html

    I am unaware of publicly available tools that implement the attack. This
    might be old news but I am quite surprised that it is not mentioned as
    popular and widely used as passive attacks focused on cracking keys.

    -ivan

    Joshua Wright wrote:

    >
    > One IP address always exists on every IP network - 255.255.255.255.
    > I've
    > been successful at accelerating weak IV collection by injecting ICMP
    > Echo requests to the broadcast address on some networks, I'm sure there
    > are plenty of other opportunities without know the network number.
    >
    > Fun stuff.
    >
    > -Josh 

    -- 
---
To strive, to seek, to find, and not to yield.
- Alfred, Lord Tennyson Ulysses,1842
Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES
46 Farnsworth Street
Boston, MA 02210
Ph: 617-399-6980
Fax: 617-399-6987
ivan.arce@coresecurity.com
www.coresecurity.com
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
-----------------------------------------------------------------------------
-
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off
any course! All of our class sizes are guaranteed to be 10 students or less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of in-the-field pen
testing experience in our state of the art hacking lab. Master the skills of
an Ethical Hacker to better assess the security of your organization. Visit
us at: http://www.infosecinstitute.com/courses/ethical_hacking_training.html
-----------------------------------------------------------------------------
--
  • Next message: Jerry Shenk: "RE: USB delivered attacks - lessons learned/summary (so far)"

    Relevant Pages

    • Re: Home office with WiFi: do I need Spotlock?
      ... Nobody will accidentally crack WEP. ... security. ... attack is that the "man in the middle" attack requires hearing both ... it appears that Spotlock is just a VPN ...
      (alt.internet.wireless)
    • [TOOL] Aircrack-ptw - WEP Cracking Tool (ARP)
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Aircrack-ptw - WEP Cracking Tool ... WEP is a protocol for securing wireless LANs. ... In 2004 a hacker named KoReK improved the attack: ...
      (Securiteam)
    • Re: Whats the bottom line on RC4??
      ... >>to use RC4 in the way you've proposed, after the WEP disaster. ... and the method of generating the nonce appeared broken. ... the referenced attack does not rely on repeated nonces, ... > With respect to David Hopwood, and a lot of respect to you, I'm ...
      (sci.crypt)
    • Tricky question...
      ... connected to a switch and to each of the access points one laptop is ... associated to AP1 using WEP1) to perform a Man-in-the-Middle attack ... I am thinking that WEP only encrypts the data that travels trough the ... clear text between the AP and the switch?? ...
      (comp.security.misc)
    • RE: Wireless wep crackin on windows
      ... WEP attacks based on IV Collisions ... would give you full access to a WEP encrypted wireless LAN ... It relies on the lack of integrity checks for the wireless packets ... The attack does not require you to crack any WEP key and uses ...
      (Pen-Test)