WPA2 Vulnerabilities, "KRACK", VU#228519

[schoolNetTech]

Hi,

So this has been blowing up on Twitter, and does seem to be a pretty serious flaw with WPA2 rendering it pretty unusable for a security perspective. A few sites referencing this issue:

• https://www.krackattacks.com/ (Researchers' GitHub Pages site)
• https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-tra...
• https://www.theregister.co.uk/2017/10/16/wpa2_inscure_krackattack/
• https://www.theguardian.com/technology/2017/oct/16/wpa2-wifi-security-vulnerable-hacking-us-governme...

Additionally, it looks like Ubiquiti have a firmware patch in the works to mitigate the issue.

For reference, here are the CVE numbers from the krackattacks.com page from above:

• CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
• CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
• CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
• CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
• CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
• CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
• CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
• CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
• CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
• CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.

What's the response from you guys regarding the possibility of getting this patched on our networks? (that is if a patch is possible, alternatively, what alternative authentication system do you recommend)

Cheers,

Rob

[Squuiid]

Other vendors (Ubiquiti, Aruba, and even Netgear!) have already released updated firmware patching this vulnerability.

Why is Meraki lagging behind?

[ModulusJoe]

I spoke to Meraki Support this morning and they stated the following:

The issue is mitigated in 24.11, which is released and stable at this time. They also recommended disabling 802.11r on all SSIDs as part of the fix.

[schoolNetTech]

Reply @ModulusJoe:

Ah, handy. That hasn't fed back to me yet. Good to hear that it was fixed. Wonder what their official press release will say...

[ruben_z8]

Sure??

Wireless firmware versions MR 24.11 changelog
Bug fixes
Low level stability issue caused AP to reboot (MR58)
Low level stability issue caused AP to reboot (MR66/MR16/MR18)
Low level stability issue caused AP to fail over to mesh erroneously (MR66/MR16/MR18)
Tuned L3 roaming broadcast discovery frames to reduce network overhead (All MRs)
Traffic routing improvements to reduce overhead on Ap resources when 1000+ clients are connected to the network
Low power mode incorrectly displaying (MR18/MR32/MR24/MR72/MR16)
Low level stability issue during SSID provisioning caused AP to reboot (MR16/MR18/MR66)
Live tool widget formatting resulted in false negative results with the RADIUS test widget on the Dashboard (All MRs)
Known issues
Condition under investigation causes lower than expected throughput on the 2.4GHz radio (MR26/MR34)
Condition under investigation causes 2.4GHz radios to become unresponsive (MR32/MR72)
Condition under investigation causes radios to become unresponsive for 5 seconds in high density networks (MR34/MR32/MR72/MR26)
Condition under investigation causes MR34/MR32/MR72/MR26 to become unstable and reboot
Condition under investigation causes client to end fast roam midway through EAPOL which causes the client connection to hang
Condition under investigation causes Outdoor APs in the IC Regulatory Domain to not broadcast channels on frequencies higher than 5.35 GHz (Channel 64)
Mesh peering issue and recovery issue causes mesh instability (MR42/MR52/MR53/MR84)
Wireless packet capture missing a number of 802.11 frames (MR42/MR52/MR53/MR84)
Other
Enhancements to 802.11r implementation

[Squuiid]

The MX64W has not been updated and is still vulnerable.
The last stable firmware for it, MX12.24, was released Dec 22, 2016.

[GreenMan]

---

@Squuiid wrote:

The MX64W has not been updated and is still vulnerable.
The last stable firmware for it, MX12.24, was released Dec 22, 2016.

---

MXs with built-in WiFi are not vulnerable, as they do not support 802.11r

[PhilipDAth]

@GreenMan that is a false sense of security saying it is not vulnerable because it does not support 802.11r.  The issue affects more than just 802.11r.  The issue is more fundamental.  An worse still - it is the clients that are most vulnerable.  It is more important to get every client patched.

[Warren]

My understanding was that it affected networks other than 802.11r.  But what do I know I'm not on the Meraki Engineering staff.

[PhilipDAth]

@Warren it absolutely affects more than just 80211r.  It fundamentally affects WPA[1|2].

[TheUnF]

My Z1 was updated today to MX 14.17:

Security appliance firmware versions MX 14.17 changelog

Security fixes

• CVE-2017-11541
• CVE-2017-11542
• CVE-2017-11543
• CVE-2017-12893
• CVE-2017-12894
• CVE-2017-12895
• CVE-2017-12896
• CVE-2017-12897
• CVE-2017-12898
• CVE-2017-12899
• CVE-2017-12900
• CVE-2017-12901
• CVE-2017-12902
• CVE-2017-12985
• CVE-2017-12986
• CVE-2017-12987
• CVE-2017-12988
• CVE-2017-12989
• CVE-2017-12990
• CVE-2017-12991
• CVE-2017-12992
• CVE-2017-12993
• CVE-2017-12994
• CVE-2017-12995
• CVE-2017-12996
• CVE-2017-12997
• CVE-2017-12998
• CVE-2017-12999
• CVE-2017-13000
• CVE-2017-13001
• CVE-2017-13002
• CVE-2017-13003
• CVE-2017-13004
• CVE-2017-13005
• CVE-2017-13006
• CVE-2017-13007
• CVE-2017-13008
• CVE-2017-13009
• CVE-2017-13010
• CVE-2017-13011
• CVE-2017-13012
• CVE-2017-13013
• CVE-2017-13014
• CVE-2017-13015
• CVE-2017-13016
• CVE-2017-13017
• CVE-2017-13018
• CVE-2017-13019
• CVE-2017-13020
• CVE-2017-13021
• CVE-2017-13022
• CVE-2017-13023
• CVE-2017-13024
• CVE-2017-13025
• CVE-2017-13026
• CVE-2017-13027
• CVE-2017-13028
• CVE-2017-13029
• CVE-2017-13030
• CVE-2017-13031
• CVE-2017-13032
• CVE-2017-13033
• CVE-2017-13034
• CVE-2017-13035
• CVE-2017-13036
• CVE-2017-13037
• CVE-2017-13038
• CVE-2017-13039
• CVE-2017-13040
• CVE-2017-13041
• CVE-2017-13042
• CVE-2017-13043
• CVE-2017-13044
• CVE-2017-13045
• CVE-2017-13046
• CVE-2017-13047
• CVE-2017-13048
• CVE-2017-13049
• CVE-2017-13050
• CVE-2017-13051
• CVE-2017-13052
• CVE-2017-13053
• CVE-2017-13054
• CVE-2017-13055
• CVE-2017-13687
• CVE-2017-13688
• CVE-2017-13689
• CVE-2017-13690
• CVE-2017-13725

[GreenMan]

It certainly does, Warren but it's worth knowing that, of the 10 specific vulnerabilities, nine relate to Wi-Fi clients and one (CVE-2017-13082) to Access Points. This gets more complex though, as many APs also support 802.11 client-type features; e.g. workgroup bridging. This is not the case with Meraki Wi-Fi devices. To further complicate things, the AP vulnerability is specifically tied to 802.11r. Some Meraki Wi-Fi devices ((MX6xW and Z1/3) don't support 11r, hence no 2017-13082 fix for those models. @PhilipDAth is absolutely right, in the broader sense - all clients and all APs need checking.

[Squuiid]

@GreenMan It is refreshing to get such excellent responses from a vendor forum.
Thank you and well done Meraki!

[MM]

Hello,
Just curious about detection of that atacak. Is it possible to configure Air Marshal, so that we can detect issue with affected clients?

Thank you,

[GreenMan]

Hi MM,

Unfortunately it's not possible for WiFi infrastructure to detect WiFi clients which are vulnerable to the KRACK issues that relate to them  (see the last but one entry in our FAQs doc, covering this:     https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-...

[MM]

Thanks for "super fast" response.

[GreenMan]

No problem...   

[GreenMan]

---

@PhilipDAth wrote:

@GreenMan that is a false sense of security saying it is not vulnerable because it does not support 802.11r.  The issue affects more than just 802.11r.  The issue is more fundamental.  An worse still - it is the clients that are most vulnerable.  It is more important to get every client patched.

---

Hi Philip - while it is very true to say that clients are the most vulnerable, the original point made was about MX appliances with built-in Wi-Fi.    As neither MX6xWs, nor Z1/Z3, have client-type capability (e.g. WorkGroup bridge), then only the KRACK flaw affecting Access Points is pertinent to MX & Zs.  As that specific flaw is bound up with 802.11r - and neither MXs nor Zs support 11r   (11r being a roaming technology - whereas MX6xW provide 'standalone' Wi-Fi), there was nothing to fix.   Thanks for re-iterating a key takeway though;  get your clients patched ASAP!

[TheUnF]

Z1 is also not listed. I have one running MX 14.15 and not sign of a new vesion. Scheduler lists 13.24 as latest beta and 12.26 as stable candidate ... go figure why the version is lower than what I'm running.

[Warren]

That's how it is the with the firmware updater.  If you want options other than what is shown you have to call support.  Just be glad that the firmware version is no longer a "trade secret" and kept under lock and key by Meraki.

[ruben_z8]

Release notes 24.11 not advice that issue was fixed.

[schoolNetTech]

As I have mentioned, I get the distinct feeling that this may be because a patch to this issue was silently rolled into OpenBSD far earlier than other developers were allowed to. If Meraki OS is BSD based, it could have got the patch then. (Source: https://www.krackattacks.com)

[pjc]

Comments from other community memebers that version 24.11 does include a fix. 

Can Meraki provide official statement here to confirm that fix is included in 24.11 ??

[ModulusJoe]

@ruben_z8 No they don't explicitly call it out but if it was a silent deploy, like OpenBSD, that is to be expected. Also the last line item "Enhancements to 802.11r implementation" is pretty vague 🙂

[schoolNetTech]

@ModulusJoe even just the system stability improvements could have meant pulling in patches from upstream

[MrJosefK]

https://www.krackattacks.com

[MRCUR]

@ModulusJoe Was Support suggesting that moving to 24.11 wasn't enough and that disabling 802.11r is ALSO required? 

[ModulusJoe]

They did, but reading the official post it sounds like that needed to be disabled before and can be re-enabled post install of the fix version.

[schoolNetTech]

As an update, I have raised a support case covering this issue on my account, and I have been told Meraki will provide an update on the issue "shortly".

Has anyone been able to try to exploit this vulnerability yet? I am offsite, so can't at the moment, however OpenBSD has been patched for ages so we *may* potentially already be patched depending on what the upstream for the Meraki network OS is. Wasn't Meraki mesh originally based off of OpenWRT (based off FreeBSD) or something when it was in research stages at MIT?

[Warren]

9:45am EST - spoke with support - he said it has not been resolved for the MX64W series, and then presumably the Z1 as well.  He said that they hope to have an announcement in 30 minutes or so.  

[Richard24]

I've just received this response from Meraki Technical support:

Our engineering team have informed me that the fix for this is in firmware MR25-7 and above. You may schedule the firmware upgrade from within the "Network-Wide -> Configure -> General -> Firmware Upgrades" section of Dashboard.

[TheUnF]

Got this message from support:
 
---------- Forwarded message ----------
From: support@meraki.com <support@meraki.com>
Date: Thu, Oct 19, 2017 at 9:39 PM
Subject: Cisco Meraki Case 02119545: Z1 update for "KRACK", VU#228519 [ ref:_00D606uBw._5000d1FpHsv:ref ]

Greetings,

Thank you for contacting Cisco Meraki Technical Support.

The firmware upgrade for the 802.11r aka KRACK/WPA2 vulnerability did come out but it was for Wireless Appliances that offer 802.11r.

Since Z1 appliances do not support 802.11r, we do not need to upgrade firmware for this particular issue.

Also I am attaching some documentation regarding KRACK/WPA2 vulnerability:

   802.11r Vulnerability FAQ
   https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-...

Please let me know if you have any other questions or concerns and and I'd be happy to help.

Thank you,

Best Regards,

Roshan Shankar 
Cisco Meraki Technical Support

[MarcoS · Accepted solution]

Hi all,

Please refer to the following article for an explanation of the vulnerability and the firmware fix:

https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-...

UPDATE 2pm PDT 16 Oct: Our blog post is the source of the most up-to-date information; please refer there first. 

Regards,

Marco

[MRCUR]

@MarcoS Thank you!

[Squuiid]

@MarcoS, the MX64W has not been updated and is still vulnerable.
Can you clarify what Meraki recommends for the MX64W and MX65W models?
Thanks.

[MarcoS]

Hi @Squuiid,

You can find this information at the very end of the document linked above.

"Are MX devices with wireless capabilities affected?
No. MX devices do not support 802.11r and are not affected by the vulnerability."

Regards,

Marco

[Squuiid]

@MarcoS Apologies, I had missed that, and thanks for the quick reply.
Meraki's response to this has been exemplary and a model to other vendors.
Thank you.

[MRCUR]

@Squuiid @MarcoS Agreed! This is really great to see how well prepared Meraki was for this. 

[Adam]

Looks like this is linked on the dashboard now.

IMPORTANT SECURITY UPDATE: A new security vulnerability in 802.11r has been recently discovered and documented as CVE-2017-13082 that makes Access Points with 802.11r enabled vulnerable to attacks. Click here to learn more. A list of any affected networks can be found in the Help menu. If you do not use 802.11r, you are not affected.

[Squuiid]

If only Cisco had been as prepared with their Aironet devices:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa
Fix release date for almost all current products is listed as TBD.

[PhilipDAth]

Do realise that fixing the infrastructure devices is not enough. Every single client has to also be fixed. In fact, fixing the clients will have a greater impact than patching the infrastructure devices.