Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Vista
Wireless Security
All Ur WiFi(WPA) R Belong 2 PacSec Nov 07 2008 06:57AM
Dragos Ruiu (dr kyx net) (1 replies)
Re: All Ur WiFi(WPA) R Belong 2 PacSec Nov 08 2008 04:53AM
Richard Farina (sidhayn gmail com) (1 replies)
Re: All Ur WiFi(WPA) R Belong 2 PacSec Nov 09 2008 03:27PM
Joshua Wright (jwright hasborg com)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I believe it is up to 15 packets depending on client implementation. I
> know that sounds a bit odd, but section 6.1.1.2 of iee802.11-2007
> explains a bit about it. A bit beyond my understanding and it would
> seem like the clients shouldn't allow it, but I'm told it sometimes
> works for 15 packets.

A copy of the IEEE 802.11-2007 specification (which is effectively a
roll-up of all ratified specifications into a single document including
802.11i, 802.11e, etc) is available at:

http://standards.ieee.org/getieee802/download/802.11-2007.pdf

The 15 packet replay opportunity is interesting. In 802.11-2007, the
traffic ID (TID) subfield is bits 0-3 of the QoS control field. Three
bits are used for the user priority (UP), with the remaining bit used to
differentiate the use of coordination functions, either Enhanced
Distributed Coordination Access (EDCA), Hybrid Coordination Function
Controlled Channel Access (HCCA) or HCCA/EDCA mixed mode (HEMM).

Essentially, this is a method for controlling the policy of data beyond
the 8 UPs. 802.11-2007 clearly states that if no traffic specification
(TSPEC) is used, the UP should be set to 0, which would prevent an
attacker from leveraging an additional 8 injected packets with this
attack. However, this would appear to be implementation-specific, and
it would not surprise me if STA's implemented this as 16 different TKIP
Sequence Counters (TSC) for simplicity, thus enabling 15 transmission
attack opportunities.

One of the significant failures enabling this TKIP attack is the poor
security practice of allowing a STA to enforce sequence enforcement
across multiple queues without any validation between queues. IMHO,
this should never have happened, and represents a significant failure on
the part of the 802.11e working group. I'll share more about this
dereliction at a later time.

My sincere congratulations to Erik Tews and Martin Beck for this
discovery. It's certainly inconvenient for administrators managing TKIP
networks, but I strongly believe we are all better served with this
attack being widely publicized.

- -Josh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkkXAUkACgkQapC4Te3oxYwSOwCfWVpLZ2opqGUfZPU/wUfPrYhx
wOUAoI1qzmXbMsB4/e8CYPlr75FaZ28L
=jmsh
-----END PGP SIGNATURE-----

[ reply ]







 

Privacy Statement
Copyright 2008, SecurityFocus