Re: How to protect WLC 2112 from Krack vulnerability

Nishan Thevathason · ‎10-24-2017

Hi

I am using CISCO WLC 2112 in our enterprise network and as we all know about the krack threat or vulnerability. so i just need help to protect my WLC and AP's from this threat.

is there any need to upgrade hardware of WLC (Because WLC 2112 is end of support) or we can fix this threat in this WLC also.

Flavio Miranda · ‎10-24-2017

Hello @Nishan Thevathason

As per the compatibility Matrix, 2100 WLC has no upgrade after 7.X:

Cisco WLC Platform

First Support

Last Support

2100

4.2.x

7.x

Looks like this version dont show up on the Resolved Releases for Krack:

Resolved Releases
8.0.152.0
8.2.164.0 and higher
8.3.132.0 and higher
8.3.130.6 (escalation)
8.5.105.0 and higher

You may need to contact TAC to veirfy what you need to do:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

-If I helped you somehow, please, rate it as useful.-

Leo Laohoo · ‎10-24-2017

@Nishan Thevathason wrote:

I am using CISCO WLC 2112 in our enterprise network and as we all know about the krack threat or vulnerability. so i just need help to protect my WLC and AP's from this threat.

There are ten (10) vulnerabilities which makes up the KRACK vulnerabilities. Of the ten, only one (1) can be patched on the AP side. This one involves 802.11r and this feature was only introduced past 7.3.X.X. WLC 2100 does NOT support 7.3.X.X and 802.11r.

The most important question that needs to be asked is the wireless clients because 9 of the 10 vulnerabilities are found in the client-side. If the wireless clients are not thoroughly patched, then will get affected when they roam to a wireless network with 802.11r enabled.

Rasika Nayanajith · ‎10-24-2017

If you have 2112, then forget about upgrade as there is no fix released for 7.0.x

What you have to do is configure not to re-transmit those handshake keys (M3 specific to this CRACK) using "config advanced eap eapol-key-retries 0" CLI commands. Refer below blog post for comprehensive details about this threat & mitigation options.

http://www.revolutionwifi.net/revolutionwifi/2017/10/wpa2-krack-vulnerability-getting-information

(WLC2) >show advanced eap

EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000
EAPOL-Key Max Retries............................ 2
EAP-Broadcast Key Interval....................... 3600

(WLC2) >config advanced eap eapol-key-retries ?
<retries> Enter the number of retries between 0 and 4

(WLC2) >config advanced eap eapol-key-retries 0

You can verify using the same previous command

(WLC2) >show advanced eap

EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000
EAPOL-Key Max Retries............................ 0
EAP-Broadcast Key Interval....................... 3600

HTH

Rasika

*** Pls rate all useful responses ***

Nishan Thevathason · ‎10-25-2017

Hi thanku for your response.
may i know how this command mitigate the possibility of this attack.
May you explain for clear understanding please.

Rasika Nayanajith · ‎10-25-2017

Hi

There is 5 part video series explain all those vulnerabilities in detail

http://blog.mojonetworks.com/wpa2-vulnerability

In part 2 (https://youtu.be/m84zfALYcmU) , you will understand reason for those key installation issues for few vulnerabilies are through transmission of M3 key (from AP to client) in 4 way handshake. If you can configure AP to not to re transmit that M3 key, you will mitigate those issues.

That does not mean all 10 vulnerabilities will be addressed by that measure. So if you have 802.11r enable on your WLC, then you have to apply a patch (I do not think Cisco will release a patch for 7.x)

HTH

Rasika

*** Pls rate all useful responses ***

Rasika Nayanajith · ‎10-26-2017

Further to my previous response please see below. This is from the person who identified these vulnerabilities

https://www.krackattacks.com/#ap-mitigations

Can we modify an access point to prevent attacks against the client?

It's possible to modify the access point (router) such that connected clients are not vulnerable to attacks against the 4-way handshake and group key handshake. Note that we consider these two attacks the most serious and widespread security issues we discovered. However, these modifications only prevent attacks when a vulnerable client is connected to such a modified access point. When a vulnerable client connects to a different access point, it can still be attacked.

Technically, this is accomplished by modifying the access point such that it does not retransmit message 3 of the 4-way handshake. Additionally, the access point is modified to not retransmit message 1 of the group key handshake. The hostapd project has such a modification available. They are currently evaluating to which extend this impacts the reliability of these handshakes. We remark that the client-side attacks against the 4-way handshake and group key handshake can also be prevented by retransmitting the above handshake messages using the same (previous) EAPOL-Key replay counter. The attack against the group key handshake can also be prevented by letting the access point install the group key in a delayed fashion, and by assuring the access point only accepts the latest replay counter (see section 4.3 of the paper for details).

On some products, variants or generalizations of the above mitigations can be enabled without having to update products. For example, on some access points retransmissions of all handshake messages can be disabled, preventing client-side attacks against the 4-way and group key handshake (see for example Cisco).

HTH

Rasika

*** Pls rate all useful responses ***