Forum

Hi.

I'm fairly new to the wireless LAN world, and was assigned to administer our two wireless lans. We are using Cisco 1210 AP's, WLSE and tacacs.
Can some one explain how to correct TKIP local, and TKIP remote MIC failures? I haven't been able to find a clear answer using search engines, or Cisco.

Any help would be great.

Dave

TKIP failures usually occur when the four way handshake is not complete. Usually the error logs on the AP should give u a brief on which stage TKIP fails.

MIC failures could be due to lot of interference and noise in the network or even due to multipath .. Basically the bit getting corrupted somehow somewhere...

Wireless Gurus here should give more info on this :)

---

dlmus33 Escribi?3:

Can some one explain how to correct TKIP local, and TKIP remote MIC failures? I haven't been able to find a clear answer using search engines, or Cisco.

A TKIP MIC failure is when the Michael hash on the received frame does not properly validate. When TKIP was designed, a hashing algorithm was needed to protect the integrity of transmitted packets. Traditional hashing algorithms such as SHA1 and MD5 could not be used as they were CPU-intensive (remember that this has to be done for EACH packet received and transmitted). Neils Ferguson wrote the Michael hashing algorithm to answer the need for a hashing mechanism that provides a reasonable level of security, and is very fast, working within the constraints of legacy hardware designed to only accommodate WEP.

Michael does have several faults, where the security of the algorithm is less than the actual hash size (64-bits), making it possible to brute-force the MIC in only 2^29 operations. In order to mitigate this attack, the IEEE 802.11i working group added something called TKIP Countermeasures, where if the AP receives 2 packets with invalid Michael hashes within 60 seconds, it must disconnect all users and not accept any traffic for 60 seconds.

In Cisco's implementation of TKIP, two failed MIC packets will actually trigger a shutdown for 2 minutes. I've never figured out why they shutdown for 2 minutes instead of 60 seconds. If this happens on a Cisco AP, you'll see a syslog message similar to:


DOT11-TKIP_MIC_FAILURE_REPEATED: Two TKIP Michael MIC failures were detected within 60 seconds on dot11Radio 0 interface. The interface will be put on MIC failure hold state for next 120 seconds


The TKIP countermeasures are a GOOD THING! If not for TKIP countermeasures, attackers would be able to replay TKIP packets very much like they did on WEP networks. It does represent a DoS attack vulnerability, but it is not simple for an attacker to trigger unless they know a valid Pairwise Temporal Key (PTK) for the TKIP network (nb: There are other ways to trigger this that require no special key knowledge, but I don't believe those techniques are public knowledge. PM me if you think you might be a victim of a 0-day here).

If you are seeing logging messages indicating Michael failures, it is most likely one of two things:

A malicious insider. A valid user on the network who has proper authentication credentials can easily trigger a Michael countermeasure or send packets with an invalid MIC, since they know the PTK. I hacked up some changes to the madwifi drivers to do this in testing, though I haven't publicly released those patches.

A broken driver. This gets my vote for most likely candidate. If the driver's algorithm for calculating TKIP MIC's is flawed, or they are not calculating the MIC over the correct portions of a frame (which changed with IEEE 802.11e/QoS), this error will be reported.

What to do about this issue? I recommend you identify the station that is triggering these errors, and upgrade the drivers for the wireless card. If it is a flaw in the handling of MIC, maybe it's fixed in a later version.

Shameless plug: You can check out my free tool, wifidenum (http://labs.arubanetworks.com/wifidenum) to scan Windows hosts over your wired network to report on the wireless drivers they have installed, and identify any vulnerable drivers that may exist.

HTH,

-Josh

Thanks Josh! This is more info than I've found ANYWHERE else. I love this forum!

hi,

Update latest drivers on client side & try makng session timeout to 0

Josh,

will windows firewall block wifidenum? I see that I need admin rights, but I'm also seeing RPC errors when running scans. I'm guessing that this is windows firewall.