Forum

Hello guys,

For good/testing reasons I want an AP to activate MIC failure countermeasure so I need to forge a TKIP MIC Failure. Which tools are available to do it?

Thanks

If you capture one station's TKIP with MIC encryted packets and try to replay them to the AP, that should do it. With MIC, typically each packet is signed so playing them back out of sequence (i.e., in any sequence other than from the original device's session) should generate a failure.

Joel

Hii Joelb

Are you sure we can generate MIC faliure like this ? and also how will I know packet is dropped becoz of MIC failure ?

Can u plz further explain on this ?

On IOS-based APs, MIC failures will generate these types of errors:

Error Message   
DOT11-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet
(TSC=0x0) received from [mac-address].
Explanation: TKIP Michael MIC failure was detected on a unicast frame decrypted locally with the pairwise key.

Error Message   
DOT11-TKIP_MIC_FAILURE_REPORT: Received TKIP Michael MIC failure report from the
station [mac-address] on the packet (TSC=0x0) encrypted and protected by [key] key.
Explanation: The access point received an EAPOL-key from a station notifying the access point that TKIP Michael MIC failed on a packet sent by this access point.

Error Message   
DOT11-TKIP_MIC_FAILURE_REPEATED: Two TKIP Michael MIC failures were detected
within [number] seconds on [interface] interface. The interface will be put on MIC
failure hold state for next [number] seconds.
Explanation: Because MIC failures usually indicate an active attack on your network, the interface will be put on hold for the configured time. During this hold time, stations using TKIP ciphers are disassociated and cannot reassociate until the hold time ends. At the end of the hold time, the interface operates normally.

I assume there is some report you can run from either the AP's GUI or WLSE that will show you a summary of MIC failures as well.

For controller-based APs, in WCS you can just go to Reports > Security > Summary and you'll see the Client Security Related alarms that include WPA MIC errors. If you click on the number for the active alarms, it will take you to a report of all clients that are generating MIC alarms and explain why they are being generated. If you click client MAC address of this message it will show you something like this:

The AP '00:0b:85:xx:xx:xx' received a WPA MIC error on protocol '0' from Station '00:13:02:xx:xx:xx'. Counter measures have been activated and traffic has been suspended for 60 seconds.

Here we see a client that has incurred MIC failures (likely due to an invalid cert) and the client has been denied access for 60 seconds.

Hope that helps,
Joel

Thanks for your comments Joel. I didn't have time to test it yet. In my first test I just tried to replay some TKIP data but the MIC failure didn't occur. I haven't tried to replay them in a inversed order.
Have you ever reproduced a MIC failure?
By the way, according to IEEE 802.11i section 8.3.2.4.1 item b) 3)

8.3.2.4.1 TKIP countermeasures for an Authenticator
3) If less than 60 s have passed since the most recent previous MIC failure, the Authenticator shall
deauthenticate and delete all PTKSAs for all STAs using TKIP. If the current GTKSA uses
TKIP, that GTKSA shall be discarded, and a new GTKSA constructed, but not used for 60 s.
The Authenticator shall refuse the construction of new PTKSAs using TKIP as one or more of
the ciphers for 60 s. At the end of this period, the MIC failure counter and timer shall be reset,
and creation of PTKSAs accepted as usual.

all TKIP clients will suffer the countermeasures, not only the one who caused it.

Ok, so, in my first comment I said:

If you capture one station's TKIP with MIC encryted packets and try to replay them to the AP, that should do it.

The keyword there being "should". Now that it's been banged around by some of my peers, we're finding that simply replaying the packets won't create a MIC failure. Why? Welllll... it's not quite as easy as I first thought (which is a good thing, otherwise it'd be a simple feat to kick off a MIC Failure Denial of Service). Here's why it doesn't work (thanks to Devin on this assist).

TKIP validation follows these steps:
1) FCS validation
2) Sequence number enforcement
3) Legacy ICV (32-bit CRC) check enforcement (a WEP holdover)
4) Michael check

If you replay a packet, it will fail the sequence number test. If you modify the source address and replay it, it is subject to the same sequence number test for the station being spoofed, otherwise it is denied if the source is not associated.

So, bottom-line, it's tough just to get to the point where the MIC failure is generated. There are ways to do it but this is not the forum to discuss that.

Joel

Since the replies on this topic are a bit old, maybe anyone can tell me how I can force a station to send corrupted MIC frames? Is there a tool to do this?