В связи с горячим обсуждением subj во всяких рассылках на всякий случай даю
ссылку на статью-первоисточник -
Авторы атаки просто используют знание протокола ARP и сами вставляют
ARP-запросы, чтобы побыстрее получить необходимые для анализа данные. Мораль
проста - надо использовать только WPA2.
The Internet Protocol (IP) is the most widely deployed network protocol. For
our attack to
work, we assume that version 4 (IPv4) of this protocol is used on the wireless
networks we
attack.
If host A wants to send an IP datagram to host B, A needs the physical address
of host
B or the gateway through which B can be reached. To resolve IP addresses of
hosts to their
physical address, the Address Resolution Protocol (ARP) [6] is used. This works
as follows:
Host A sends an ARP request to the link layer broadcast address. This request
announces
that A is looking for the physical address of host B. Host B responds with an
ARP reply
containing his own physical address to host A. Since the Address Resolution
Protocol a link
layer protocol it is typically not restricted by any kind of packet filters or
rate limiting rules.
ARP requests and ARP replies are of fixed size. Because the size of a packet is
not masked
by WEP, they can usually be easily distinguished from other traffic. The first
16 bytes of
cleartext of an ARP packet are made up of a 8 byte long 802.11 Logical Link
Control (LLC)
header followed by the first 8 bytes of the ARP packet itself. The LLC header
is fixed for
every ARP packet (AA AA 03 00 00 00 08 06). The first 8 bytes of an ARP request
are also
fixed. Their value is 00 01 08 00 06 04 00 01. For an ARP response, the last
byte changes
to 02, the rest of the bytes are identical to an ARP request. An ARP request is
always sent
to the broadcast address, while an ARP response is sent to a unicast address.
Because the
physical addresses are not encrypted by WEP, it is easy to distinguish between
an encrypted
ARP request and response.
By XORing a captured ARP packet with these fixed patterns, we can recover the
first 16
bytes of the key stream. The corresponding IV is transmitted in clear with the
packet.
To speed up key stream recovery, it is possible to re-inject a sniffed ARP
request again
into the network. The destination answers the request with a new response
packet that we
can add to our list of key streams. If the initiator and the destination of the
original request
have been both wireless stations, every reinjected packet will generate 3 new
packets, because
the transmission will be relayed by the access point. Because ARP replies
expire quickly, it
usually takes only a few seconds or minutes until an attacker can capture an
ARP request
and start reinjecting it. The first public implementation of a practical
re-injection attack was
in the BSD-Airtools package
It is even possible to speed up the time it takes to capture the first ARP
request. A deauthenticate
message can be sent to a client in the network, telling him, he has lost contact
with the base station. In some configurations we saw clients rejoining the
network automatically
at the same time flushing their ARP cache. The next IP packet sent by this
client will
cause an ARP request to look up the Ethernet address of the destination.
