Michael Countermeasures tracing

[Arseniy Chernov]

Hello Joshua,

Returning back to our short thread, I'd like to report that we've 
updated all stations' drivers (see below) and started monitoring that 
buggy RF environment 7 workdays ago.

The average amount of Michael errors in WPA-PSK has decreased 
dramatically, but still, there are some of them occuring daily (3...5 as 
we could notice, not followed by countermeasures). We still cannot 
understand why this takes place, but, however, we were able to solve our 
main problem.

For your interest:

(Sony VAIO series)
Intel PRO Wireless 2200bg Network Adapter driver v.9.0.3.0 (10/26/2005)

(IBM T series)
AMBIT Microsystems 802.11bg NIC Driver v. 4.1.102.1095

APs:

D-Link DWL-2100AP
Firmware v2.10eu release 0338


Thanks again for your bright and simple suggestion. We never knew Intel 
or IBM could produce buggy NICs, but it seems like they aren't angels, too.

Cheers!

Joshua Wright wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Arseniy Chernov wrote:
> 
>>I'm spending second week already trying to understand how should the 
>>trace of source of MIC error in a buggy RF environment be performed, 
>>hope to receive some advices here...
> 
> 
> It's interesting that you would ever see a Michael error.  The design of
> TKIP has a few different security features that would make it difficult
> for someone to craft a frame that would report an invalid Michael hash.
>  Specifically, I believe the TKIP RX handling process works as follows:
> 
> 1. Receive frame, examine sequence number.  If sequence number is too
> small, drop frame (mitigating replay attacks).
> 2. Implement key mixing function to decrypt the MPDU and check the ICV.
>  If the ICV is invalid, drop the frame.
> 3. Reassemble all MPDU's into the MSDU and calculate Michael hash over
> the contents.  If Michael hash is invalid, record and take
> countermeasures if necessary.
> 
> I see a few different possibilities where you would be experiencing
> Michael errors:
> 
> 1. An adversary is maliciously injecting malformed frames to DoS your
> network by triggering Michael countermeasures.  This isn't likely, as
> the attacker has to overcome the rules of sequence enforcement and
> maintaining the integrity of the ICV in order to make this happen.
> 2. Faulty AP implementation - if your AP isn't following the correct
> order of steps to decrypt and verify the contents of an MSDU (e.g. they
> are checking the Michael hash before they check the ICV), then a corrupt
> frame could cause this condition.
> 3. Faulty client implementation - If your client has a software flaw, it
> is possible that they aren't recording the Michael hash properly, or are
> not calculating the Michael hash over the correct fields.  I'd imagine
> this is the most likely case here - what client software and card are
> you using for your station?
> 
> Thanks for sharing these details.
> 
> - -Josh
> - --
> - -Joshua Wright
> jwright at hasborg.com
> 
> 2005-2006 pgpkey: http://802.11ninja.net/pgpkey.htm
> fingerprint: F00E 7A42 8375 0C55 964F E5A4 4D2F 22F6 3658 A4BF
> 
> Today I stumbled across the world's largest hotspot.  The SSID is "linksys".
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> 
> iD8DBQFDfchlTS8i9jZYpL8RAr1yAJ49LzjNVNjciLFaYuzK8rTBLU5+twCeNPTc
> hbPUkaydwB2weoCEIOvafiw=
> =8ECs
> -----END PGP SIGNATURE-----

-- 
Regards,
Arseniy Chernov
e-mail: ars at itconnection.ru
phone: +7 812 320-9850