Wi-Fi爆WPA2协定漏洞，用户提高安全三措施

据海外媒体报导：美国国土安全部旗下资安小组证实，已普及达 13 年的 Wi-Fi 协定“WPA2”遭爆严重漏洞，可能导致用户传输的各类加密资料曝光，包含信用卡、密码、讯息、视讯内容等。即使用户只是在家使用平常惯用的 Wi-Fi 刷 Facebook 动态，也可能有被骇的风险。
有资安人员释出了一份概念验证攻击 KRACK（Key Reinstallation Attacks），表示目前已使用达 13 年、在家用 Wi-Fi 网络十分普遍的加密协定“WPA2”，可能有非常严重的漏洞，能让黑客从 Wi-Fi 覆蓋范围内知悉用户的所有网络活动。
由于 WPA2 能加密用户在网络中传输的资料，让传输的内容即使被拦截，恶意黑客也无法得知用户在做哪些事，不过一旦 WPA2 协定被破解，用户在 Wi-Fi 传输的各类东西，包括信用卡、网站密码、讯息、照片、视讯通话，都有可能被黑客知悉。
此项漏洞亦已由美国国土安全部证实。该部门旗下的 Computer Emergency Response Team（电脑紧急应变小组）表示，由于漏洞存在于协定本身，影响范围很大，包括解密、HTTP 内容、TCP 超链接都受到影响。所幸，由于此漏洞是由荷兰天主教鲁汶大学（KU Leuven ）的研究人员发现，消息曝光前已经先保密数周，好让各家厂商有时间修复。
一般用户还能多做哪些事，让自己未来使用 Wi-Fi 时可以更安全一点？

首先，是实时升级手边装置与操作系统的安全性更新。
苹果方面，目前新版的 macOS 与 iOS 都已修复相关的漏洞。微软的 Windows 更新则已在 10/10 推送。Android 阵营则会慢上一些，到 11/6 才会有 Google Pixel 能先享用的安全更新，而其他 Android 装置则可能得“等上数周”。

二，如果自家路由器厂商有推出韧体更新档，用户也可以实时安装，或是直接购买较新的路由器。而如果是有点技术背景的用户，则可以考虑以 VPN 方式来建立安全连线，避免资料外流，或是避免使用客户端模式与 802.11r。

三，由于是 Wi-Fi 协定的漏洞，意味着黑客需要在路由器的特定讯号范围内才能窃取资料，因此用户外出时，应避免连线外面的公用 Wi-Fi，包括车站、卖场与连锁商店的服务。
不过鲁汶大学的资安专家也表示，虽然一般用户可能不太会注意路由器的韧体，但多数网站都会有一定的安全协定。只要定时更新手机或 PC 的安全性更新，一般来说不需多虑。

如果找不到修补程序该怎么办？
台湾赛门铁克首席资深技术顾问张士龙建议，可以暂时使用VPN（Virtual Private Network，虚拟私人网路）建立虚拟加密安全连线，包括个人电脑和手机用户都可以透过这个方法，避免资料被窃取。
张士龙说，WPA2在百货公司、星巴克等咖啡厅甚至企业内部的Wi-Fi网路都被广泛使用，因此几乎所有使用者都需要留意相关安全漏洞。
他也提醒消费者，在公共场所发现名称有free（免费）字眼的Wi-Fi网路，即使暗示可免费使用，也最好不要轻易连线，因为可能是骇客伪装的恶意无线网路，一旦连上去，消费者所有的网路活动都会被骇客掌握。
-------------------

WPA2: Broken with KRACK. What now?

On social media right now, strong rumours are spreading that the WPA2 encryption scheme has been broken in a fundamental way. What this means: the security built into WiFi is likely ineffective, and we should not assume it provides any security.

The current name I’m seeing for this is “KRACK”: Key Reinstallation AttaCK. If this is true, it means third parties will be able to eavesdrop on your network traffic: what should be a private conversation could be listened in to.

This has happened before with WiFi: who remembers WEP passwords? However, what is different this time around: there is no obvious, easy, replacement ready and waiting. This is suddenly a very big deal.

In truth, WPA2 has been suspect for some time now. A number of attacks against WPA2-PSK have been shown to be successful to a limited degree, WPA2-Enterprise has shown itself to be slightly more resilient (but doesn’t protect you from these problems).

I have continued to update this as facts become clear. Please note:

• Credit for this goes to Mathy Vanhoef and Frank Piessens at KU Leuven, who have a great track record of discovering problems here. I want to be clear about this as I’ve be quoted incorrectly in a couple of places!
• www.krackattacks.com is now up! There is a list of vendor announcements being written, but remember all vendors are potentially affected. Few vendors appear to have updates ready 🙁
• All attacks appear to require a specific type of Man-in-the-Middle – this means in practice they are difficult to execute. Most of the worst scenarios are mitigated by this – another fault in WPA2 / WiFi will need to be found to make this a genuinely practical attack.
• Attacks against Android Phones are more damaging and full decryption is possible. Other platforms only allow a small amount of data to be recovered.
• Windows and Mac OS users are safer. Updates for other OSes will come quite quickly, the big problem is embedded devices for whom updates are slow / never coming
• For the very technical, the CVE list is at the bottom of this post.
• The main attack is against clients, not access points. So, updating your router may or may not be necessary: updating your client devices absolutely is! Keep your laptops patched, and particularly get your Android phone updated
• Correction: I’ve highlighted specifically that WPA2-Enterprise is vulnerable.
• If you have some great advice to share or corrections to this, please let me know!

Information here is good as of 2017-10-16 20:00 UTC.

So, this is going to be a horrible Monday morning for IT admins across the world. The practical question is: what now?

Keep Calm

Remember, there is a limited amount of physical security already on offer by WiFi: an attack needs to be in proximity. So, you’re not suddenly vulnerable to everyone on the internet. It’s very weak protection, but this is important when reviewing your threat level.

Additionally, it’s likely that you don’t have too many protocols relying on WPA2 security. Every time you access an https site – like this one – your browser is negotiating a separate layer of encryption. Accessing secure websites over WiFi is still totally safe. Hopefully – but there is no guarantee – you don’t have much information going over your network that requires the encryption WPA2 provides.

So, we’re alright?

In a word, No. There are plenty of nasty attacks people will be able to do this. They may be able to disrupt existing communications. They may be able to pretend to be other nodes on the network. This could be really bad – again, they won’t be able to pretend to be a secure site like your bank on the wifi, but they can definitely pretend to be non-secure resources. Almost certainly there are other problems that will come up, especially privacy issues with cheaper internet-enabled devices that have poor security.

You can think of this a little bit like your firewall being defeated. WiFi encryption mainly functions to keep other devices from talking on your network (the security otherwise has been a bit suspect for a while). If that no longer works, it makes the devices on your network a lot more vulnerable – attackers in proximity will now be able to talk to them.

Story for your boss

Keep it simple, and ideally get ahead of the game by communicating now. Re-iterate:

• this won’t let people who are not physically present into your networks;
• it’s unlikely any data is protected by the encryption WPA2 provides; in particular, accessing secure websites is still fine;
• think about increasing the level of security of the nodes on your network if possible – make sure your AV is up-to-date, firewalls turned on, etc.;
• if you’re paranoid about certain data or systems, turn off WiFi and switch to one of an internal VPN, a wired ethernet connection or mobile data (for WAN access);
• that you are on top of the situation and monitoring the best next steps.

In terms of what to do, in many ways, we’re at the behest of our vendors. If you have a high quality vendor (I would include companies like Ruckus and Cisco in this bracket, for example) I expect new firmware to be available very shortly to mitigate these problems. This may well result in incompatibility with existing devices: as a business, you will need to make a decision in that case (unless you need compliance with PCI-DSS or similar, in which case you likely have little choice).

Story for friends / family

This is where it gets really sucky. Lots of us have old routers at home, which have no chance of a firmware upgrade, and lots of WiFi equipment that may well not get a protocol upgrade if one is required. Right now, it sounds like all this stuff is going to be worthless from the perspective of encryption.

Reiterate the same points as above:

• secure websites are still secure, even over WiFi;
• think about setting your computers to “Public Network” mode – that increases the level of security on the device relative to “Private / Home Network” modes. Remember, if third parties can get onto our home networks, they’re no longer any safer than an internet cafe;
• if you’re paranoid about your mobile, turn off WiFi and use mobile data when necessary;
• it sounds like no similar attack against ethernet-over-mains power line is possible, so home networks based on mains plugs are problem still ok;
• keep computers and devices patched and up-to-date.

What for the future?

As I said before, this is a big problem, but not one that was unexpected. A number of encryption protocols have been problematic over the years; many of the implementations of those protocols have been even worse.

It’s clear to me that “Internet of Things” type devices will be the hardest hit. Devices with embedded WiFi for secondary functional purposes, like TVs and baby monitors, are unlikely to get proper updates. As a protocol problem, it’s possible we will be forced to choose between security and functionality, and many users will choose the latter – it’s a difficult problem to weigh.

I would love to say there’s an easy answer. I think it’s important that networks become increasingly software-defined, and that it makes sense that future standards focus on that runtime rather than the protocol itself. We cannot rely on vendors to keep devices up-to-date either (for many reasons), but previous attempts at standardising a runtime (like UEFI) aren’t promising, either technically or security-wise.

As consumers, we have to continually question the security credentials of devices we buy, and demand the best evidence of their security. This is a tough ask; even in the IT world, buying “secure” is difficult. In tech we must strive for better.

CVEs involved

If you don’t know what these are, don’t worry – they are the “official notifications” of a problem, if you like. If you have a vendor of WiFi equipment, you will want to ask them if they’re affected by any of these, and if so, what the solutions are:

• CWE-323
• CVE-2017-13077
• CVE-2017-13078
• CVE-2017-13079
• CVE-2017-13080
• CVE-2017-13081
• CVE-2017-13082
• CVE-2017-13083
• CVE-2017-13084
• CVE-2017-13085
• CVE-2017-13086
• CVE-2017-13087

PREVIOUS

Software architecture is failing

NEXT

Faster Continuous Integration with some stowage patterns

28 Comments

ADD COMMENT →

1. 
   

   WT

   > this won’t let people who are not physically present into your networks;

   Mobile phones with WiFI are an attack vector (that does not require physical presence)

   OCTOBER 15, 2017
2. 
   

   
   

   Alex

   Yeah, that’s a definite possibility. Personally, I rate the security of a device like the iPhone much higher than other wifi-based stuff, though, and it would be difficult to select a device in order to access a specific network – equally, if you don’t care about the specific network, the device probably has a selection of juicy wifi passwords already setup.

   I think you’ve just helpfully illustrated the big problem with KRACK, though: it changes the threat models sufficiently that suddenly we have to re-think the whole thing. Someone with a much better imagination than me may well be able to blow networks wide open with this flaw 🙁

   OCTOBER 15, 2017
3. 
   

   Simon

   Any paper or research on this?

   OCTOBER 15, 2017
4. 
   

   Ilitri

   But what these means? I mean for breaking a wep password there are thousands off tutorials online any 14year old kid can do it witouth any knowledge. But you cant do a attack like these thath easy no(i am not a expert just saying, maybe is a easy attack). Thanks for news.

   Viva hitlario.

   OCTOBER 16, 2017
5. 
   

   Mike

   I’ve been telling people for years that:

   1) WiFi is just another term for “radio”.

   2) No encryption is worth using unless the NSA uses it internally. And they aren’t using WEP or any flavor of WPA.

   3) you don’t want to put anything on radio that you wouldn’t want to see on the front page of the Los Angeles times, above the fold.

   4) Especially don’t do anything involving money or non-public information on radio (use a copper cable). I tell the home users to use a computer plugged into the back of the router).

   Mike

   OCTOBER 16, 2017
6. 
   

   Joe

   Source?

   OCTOBER 16, 2017
7. 
   

   Joe

   Does this impact wpa2 enterprise as well? We use wpa2 preshared key for our guest evironment :/. Hopefully Cisco is working on a patch release for its controllers.

   OCTOBER 16, 2017
8. 
   

   Roger J.

   My employer’s WiFi leaks up to a block away. We have multiple sites. All are in residential areas. (We see freeloaders on our hospitality network often.) Thus far nobody has made it to the corporate network. A process to use MAC authentication and device profiling is in the works. This just made the timeline to NOW.

   OCTOBER 16, 2017
9. 
   

   Shane Grissom

   So for someone using MAC address security on their WIFI network, will they be protected still? Seems to me this would not impact that, since you are basically NOT using WPA-2 to secure your home network.

   Yes?

   OCTOBER 16, 2017
10. 
    

    Brad Lloyd

    Thank you for this excellent article. It is so well done and I’m very happy to promote it within my networks.

    OCTOBER 16, 2017
11. 
    

    
    

    Alex

    Not yet – this will be disclosed later today. I will update with proper links when I have them!

    OCTOBER 16, 2017
12. 
    

    
    

    Alex

    I don’t think we know how hard this will be yet, but what I’m reading is that it will be pretty easy. Apparently a series of different attacks will be published for different vendors, so it won’t be super-simple, but this stuff is so easy you automate the days…

    OCTOBER 16, 2017
13. 
    

    
    

    Alex

    Chatter on social media from a bunch of people I respect and know a lot about infosec. We’ll find out later if it’s good or not, but the abstract of the paper being presented doesn’t pull any punches.

    OCTOBER 16, 2017
14. 
    

    
    

    Alex

    I don’t know yet. It’s possible that Enterprise is better protected, but I wouldn’t say that for sure yet. It might depend on the vendor.

    OCTOBER 16, 2017
15. 
    

    
    

    Alex

    That’s a good start, although MAC can be spoofed 🙁 I wish I could suggest something easy – so far there’s nothing obvious.

    OCTOBER 16, 2017
16. 
    

    
    

    Alex

    As I said on another comment, if you can see the traffic on the network, you can see other MAC addresses and potentially spoof them. MAC Auth gives you better protection on wired, where the port is dead until you present a good MAC. I’m afraid I don’t know if this will help on WiFi!

    OCTOBER 16, 2017
17. 
    

    
    

    Alex

    Thank you Brad! I’m hoping that I can link to other experts as the news breaks as I’m not really an infosec person, but this is important to talk about, especially with less technical users.

    OCTOBER 16, 2017
18. 
    

    JUAN LUIS MARTEL

    It is very easy to repeat a radio signal with the same information.
    Military and police communication systems are being attacked using signal repeaters.
    It is about using a Raspberry Pi with an SDR pendrive, that listens and emits the base band, all the information in a package of radio frequency.
    Everything that goes by air, all communications can be broken using SDR.

    OCTOBER 16, 2017
19. 
    

    JMC

    Well, this is going to be interesting.

    If your home router supports it, you can give it a list of allowed MAC addresses and only let those MACs join the network.

    WPA2 is still useful to prevent casual interception

    OCTOBER 16, 2017
20. 
    

    KEC

    In what ways can this affect WiFi calling on phones through Google Fi, T-Mobile, and others? Say I have poor cell service so I rely in WiFi calling at home. Can someone with access to my network through KRACK listen in on calls?

    OCTOBER 16, 2017
21. 
    

    
    

    Alex

    If you’re using an app like WhatsApp or similar you’re fine. If you’re using standard VoIP you’re probably fine, although VoIP endpoints have often terrible security and I would worry about people being able to dial out without your knowledge. In terms of mobile range expanders, I don’t know – I would hope you’re ok, but I don’t know how they work underneath I’m afraid.

    OCTOBER 16, 2017
22. 
    

    Kai

    https://lirias.kuleuven.be/bitstream/123456789/547640/1/usenix2016-wifi.pdf
    I think this is the whitepaper regarding this.

    OCTOBER 16, 2017
23. 
    

    VD

    What about many home routers acting as DNS servers too?

    OCTOBER 16, 2017
24. 
    

    
    

    Alex

    I’ve seen that doing the rounds. That’s from 2016, and I think it’s a related problem, but the problem today is new.

    OCTOBER 16, 2017
25. 
    

    
    

    Alex

    Clearly a problem. DNSSEC sadly doesn’t give us much protection (a lot of infosec people I respect think that, as a protocol, it’s pretty broken). However, secure HTTPS websites should still be ok – you can forge a DNS record, but it’s much more difficult to forge a certificate. I think impersonating / taking over home routers is going to be a substantial problem here, though.

    OCTOBER 16, 2017
26. 
    

    Siva

    I use VPN for all my communication even in cellphone. Nothing to hide, and nothing to give is my moto.

    OCTOBER 16, 2017
27. 
    

    Shaun Clarke

    I can’t believe some people think they are OK if they use MAC address authentication. The MAC address of your clients are actually not encrypted, so anyone can use a passive sniffer to get the MAC addresses of legitimate devices on your network even if your network is encrypted. In addition, you don’t even need 3rd party tools to assign a “user-defined” MAC address to an interface.

    OCTOBER 16, 2017
28. 
    

    
    

    Alex

    Unfortunately it’s advertised and described as a security feature. It doesn’t offer much protection, and I’d traffic can be sniffed it’s basically useless.

    
    

FROM https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/
--------------------------------------------

WPA2 KRACK Vulnerability, Getting Information

I'm sure everyone who does anything with networking or Wi-Fi has heard about the announced WPA2 KRACK vulnerability. I'd like to start a collection of useful information in one single place.

The Main Points You Need to Know

1. Wi-Fi Protected Access (WPA2) has a very technical vulnerability in how it distributes encryption material that could be used by an attacker in physical proximity as a starting point to try to leverage other unrelated vulnerabilities to hijack application sessions. There is a very small window of exposure of the first few frames after the client associates to an AP and installs the encryption key.
2. WPA2 encryption is NOT broken, attackers cannot decrypt Wi-Fi traffic in bulk... with one serious exception:
3. Android, Linux, and other clients using the open-source wpa_supplicant software library can be tricked into using an all-zero encryption key, meaning effectively no encryption. Android devices are the serious concern with these vulnerabilities!
4. Remediation requires installing software patches. Some are out already, some are not, some may never be (depending on manufacturer support). See the patch section below.
5. A workaround exists to mitigate the issues... patching APs. But this is not a complete workaround, just minimizes exposure. Clients are still vulnerable when they are on other Wi-Fi networks that aren't patched.

My Opinion - the attack vector for all systems (except Android and Linux) is very small. This is a security vulnerability that should be handled with calm, not overreaction. This isn't WEP protocol flaws part deux. Apply patches to clients that will have them published and review defense-in-depth practices if clients are no longer supported or won't receive patches (e.g. IoT, legacy operating systems). Take this as an opportunity to review the security and compliance program within your organization as a whole; usually these types of situations provide the impetus and justification for maturing such programs.

Overview of the Basics

There are 9 vulnerabilities that are client related and 1 that is AP / Infrastructure related. The vulnerabilities revolve around improper reuse of the encryption keystream because an attacker acts as a man-in-the-middle (MiTM) and blocks certain encryption key negotiations early on during the negotiation between AP and client, triggering the AP to retransmit a request for confirmation that the encryption key was installed properly by the client. Most clients, when receiving this retransmitted request will reset their encryption Packet Number (PN) counter, which is supposed to ensure each frame has a unique encryption keystream used to protect the data (if it's reused, that's a weakness cryptographically). However, the client may have already started sending data frames, so when the PN is reset but the same encryption key is used, then subsequent data frames may reuse the same keystream. When the encryption keystream is reused, and the client transmits different frames with the same keystream, it becomes easier for an attacker to decrypt those frames. The resulting impact is that an attacker can potentially decrypt very specific frames that are sent right after association and reuse the same keystream (due to the attack); these frames likely contain well-known content (e.g. can be guessed) which is what allows decryption of the frame(s) that used the same keystream, which would practically speaking be ARP, DHCP, or TCP SYN packets. Using decrypted TCP SYN frames, the attacker could then try to leverage other unrelated vulnerabilities and attacks to hijack an application session. Wi-Fi data in general CANNOT be decrypted. Most importantly, as the author states, "Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake." One big exception to this is how Android and Linux clients using wpa_supplicant version 2.4 and above handle the replay scenario by installing an encryption key of all zeros, allowing full decryption of all data sent by the client.

All are effectively implementation issues by allowing reuse of keystream material, meaning software patching can fix them! Of the 9 CVE's related to clients, the most serious of them (7 of the 9, related to the 4-Way Handshake and Group Handshake) can be mitigated with AP / Infrastructure updates as a workaround, but the infrastructure won't be able to determine if failure is from packet loss issues or attack. A few can't be mitigated by AP patches (Peer-Key and tunneled direct link setup [TDLS]), which are peer-to-peer related vulnerabilities, but these methods of communication are rare and practically never used in my experience. The long-term fix is definitely client software patching. Patching Wi-Fi drivers can also fix 2 of the 9 client vulnerabilities (see Intel driver information below). The 1 CVE related to AP / Infrastructure is related to 802.11r Fast Transition - if you have it enabled you should patch ASAP. If not, no big deal. Many, many thanks go to Hemant Chaskar, Mojo Networks, and Pentester Academy!

First, go read the security researcher's website on the attack details:
https://www.krackattacks.com/

The author, Mathy Vanhoef, has also released a test script for the AP-related 802.11r vulnerability (this is related to the 1 AP vulnerability of the 10 released):
https://github.com/vanhoefm/krackattacks-test-ap-ft

It should be noted that these vulnerabilities were responsibly disclosed to manufacturers in July, which is a large reason there are patches available on day zero (Oct. 16th)! Thank you to Mathy Vanhoef for his work to find and report these issues in a way that helps improve Wi-Fi and in a manner that minimizes customer impact!

Second, read these articles and watch these videos by experts:

• Mojo Networks / Pentester Academy Videos: http://blog.mojonetworks.com/wpa2-vulnerability
• Aruba Blog: http://community.arubanetworks.com/t5/Technology-Blog/WPA2-Key-Reinstallation-Attacks/ba-p/310045
• Aruba FAQ: http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007_FAQ_Rev-1.pdf
• Wrightcore: http://wrightcore.com/blog/viewPost/4/27

Third, here's the US-CERT page collecting information on vendors affected:
http://www.kb.cert.org/vuls/id/228519

Fourth, the Wi-Fi Alliance is enhancing future testing and certification for this vulnerability:
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update

Remediation

Patching systems will be important over the coming hours/days/weeks/(what you take longer than a week or two to patch?!?). Client systems are the most affected, but infrastructure systems also have a few related issues requiring patching too.

1. Patching client systems is the ultimate fix for the 9 client vulnerabilities.
2. Patching APs is the ultimate fix for the 1 infrastructure vulnerability

See the software patch section below for information on manufacturer patch availability.

Mitigation / Workarounds

Patching takes time. Here are some workarounds you can take until all clients can be patched:

1. AP Configuration - investigate your WLAN vendor to see if they provide users control over the EAPOL settings. If they do, set the EAPOL retries setting to 0 (zero) in order to prevent the AP from retransmitting message 3 of the 4-Way Handshake, which will prevent the client from "reinserting" the PTK encryption key and resetting their Packet Number counter. For example, on a Cisco WLAN you use the following command:
   wlc> config advanced eap eapol-key-retries <value>
2. Patch APs - this holds potential to mitigate 7 of the 9 client vulnerabilities when they are connected to your Wi-Fi network. It is still unclear if AP vendors' patches will change default EAPOL settings to mitigate the client issues, so this may or may not prove effective. Regardless, when clients are connected to other Wi-Fi networks they could still be vulnerable.
3. Review Security, Compliance, and Risk Assessment in your organization:
   Security should never be reliant on a single point of protection. Utilize "Defense-In-Depth" practices to provide multiple points of protection. 
   1. Review Business Reliance - how critical are the unpatched and vulnerable devices to your business? What business applications rely on their use? What data can these devices and applications access? Establish how important the devices are to your business operations or efficiency. This will help you weigh the risks involved with continued use of the devices and access to corporate data versus the cost of data breach. One last aspect: does your organization include budget for risk of loss or data breach?
   2. Assess Application Security - if users are using corporate applications, review them for additional layers of security, such as HTTPS, SSL, TLS, etc. Additional layers of security and encryption can protect sensitive application data even if specific clients are vulnerable to these Wi-Fi attacks.
   3. Review Network Access - what access do these devices have on your network infrastructure? Are they segmented from network resources that they don't require access to by traditional network firewalls, or can they be? Can access be restricted to minimize risk of data breach? Is restricting access through a VPN a viable option to provide an additional layer of security for sensitive data access by vulnerable devices until they can be patched? Should vulnerable devices be prevented from accessing the corporate network completely until patched (perhaps especially for Android and Linux)?
   4. Review Network Defenses - are wireless or wired intrusion detection, intrusion prevention, or application layer firewalls in place that can monitor for suspicious behavior and alert or prevent attacks? What would it take to add these capabilities? It should be noted that these attacks rely on a man-in-the-middle (MiTM) attacker AP, which is easily detected and alerted on by most enterprise wireless networks without an overlay IDS/IPS. Review what capabilities your wireless system has to alert on honeypot APs using your SSID, evil twin APs, and spoofed MAC addresses. For examples of WIPS mitigation see Jim Vajda's blog here and Mojo Network's "countermeasures | part 5" video here.
   5. Review Logging, Correlation, and Alerting Systems - are there centralized or aggregated logging systems in place that can correlate suspicious behavior across multiple systems and provide visibility into how an attacker may be moving through your network and systems?
   6. Review Incident Response Procedures - if network, application, and logging/alerting systems are in place, what is the incident response process? Is it mature, does your staff know how to handle incidents properly and quickly when they arise?
   7. Security Policies and Procedures - do you have security policies and procedures that cover the use of these devices for business purposes, Wi-Fi access, data classification and handling, etc.? Now would be a great time to ensure these policies are in place and up-to-date. It would also be a great time to make sure the policies are enforced throughout your IT environment.
   8. Security Awareness - users are typically the weakest link in data security. Does your organization have a security awareness program to educate users on data security practices? Consider making a special awareness campaign for this Wi-Fi issue and getting easy-to-understand (non-technical) information out to your users with clear instructions.

It's normal to need help with the security, compliance and risk assessment, especially for smaller organizations. Find a specialist to help you formalize and mature these if necessary!

I covered many of these organizational security, compliance and risk assessment points on Twitter as well. See the thread that starts with this tweet:

 Follow

Andrew von Nagy @revolutionwifi

Unpatched systems ARE an issue w/ #WPA2 #KRACK. It comes down to use-case analysis, defense-in-depth practices, & risk analysis. 1/x

8:38 PM - Oct 17, 2017

•  11 Reply
 
•  Retweets
 
•  22 likes

Twitter Ads info and privacy

Known Impact Assessments

Android 6.0 and above implementations appear to be especially vulnerable to the worst variants of the attack that include decryption of actual client transmitted frames (e.g. one-way traffic)!
41 percent of Android phones are vulnerable to 'devastating' Wi-Fi attack
https://www.theverge.com/2017/10/16/16481252/wi-fi-hack-attack-android-wpa-2-details

Apple and Microsoft appear to only be affected by a subset of the vulnerabilities.  iOS and Windows are not vulnerable to the one set of exploits because they don’t accept retries of handshake message 3. Specifically, they don't allow key reinsertion of the PTK used for unicast frames and unique to each client, but are still vulnerable to the GTK group key reinsertion variant. This is much less concerning.
https://www.macrumors.com/2017/10/16/krack-wifi-vulnerabilities-patched-apple-ios-macos/

Apple appears to have patched this vulnerability in previous "beta" releases for iOS, MacOS, and tvOS. We are still waiting for the patch to be released into a "public" release.
http://appleinsider.com/articles/17/10/16/apple-confirms-krack-wi-fi-wpa-2-attack-vector-patched-in-ios-tvos-watchos-macos-betas

Note - Apple's policy is not to discuss security issues until a patch is released. You might want to follow Apple-centric providers as well, such as my employer Foundation Technologies: https://fndtn.com/2017/10/16/security-alert-wpa2-and-krack/

Microsoft released patches for all currently supported operating systems on Oct. 10th with their regular monthly patch cycle: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080 and
https://www.theverge.com/2017/10/16/16481818/wi-fi-attack-response-security-patches

Staying Abreast of Software Patches

Wi-Fi client manufacturer security advisory websites:

• Android: https://source.android.com/security/bulletin/
• Apple: https://support.apple.com/en-us/HT201222
• Microsoft: https://portal.msrc.microsoft.com/en-us/security-guidance and
  https://technet.microsoft.com/en-us/security/advisories

Wi-Fi infrastructure manufacturer security advisory websites:

• Aerohive: https://www3.aerohive.com/support/security-center/security-bulletins.html
• Aruba: http://www.arubanetworks.com/support-services/security-bulletins/
• Cisco & Meraki: https://tools.cisco.com/security/center/publicationListing.x#~Vulnerabilities
  Cisco also posted this blog about the vulnerabilities, but no patch info: https://blogs.cisco.com/security/wpa-vulns
• Extreme Networks: https://extremeportal.force.com/ExtrArticleDetail?n=000018005
• Mist Systems: https://support-portal.mist.com/hc/en-us/articles/115002801334-FAQ-on-Wi-fi-vulnerability-announced-on-October-16th-2017
• Mojo Networks: http://www.mojonetworks.com/wpa2-vulnerability
• Ruckus / Brocade: https://www.ruckuswireless.com/security and
  http://www.brocade.com/en/support/security-advisories.html
  Ruckus also posted an initial blog with advice here, but no patch info: 
  https://theruckusroom.ruckuswireless.com/wi-fi/2017/10/16/commonsense-approach-uncommon-problem/
• Ubiquiti: https://community.ubnt.com/t5/UniFi-Updates-Blog/FIRMWARE-3-9-3-7537-for-UAP-USW-has-been-released/ba-p/2099365

Known patched products (in alphabetical order):

• Aerohive (Oct. 16th code release, other code trains coming soon): 
  https://www3.aerohive.com/support/security-bulletins/Product-Security-Announcement-Aerohives-Response-to-KRACK-10162017.html
• Aruba Controllers and Instant: 
  http://www.arubanetworks.com/support-services/security-bulletins/
  Aruba has provided free software updates without requiring an active support contract. Download patched software versions on their support site:
  http://support.arubanetworks.com/LifetimeWarrantySoftware/tabid/121/Default.aspx
• Cisco & Meraki (Oct. 16th code release for specific AP models and code trains, others coming Oct. 20th): 
  https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa, Also Meraki blog here: https://meraki.cisco.com/blog/2017/10/critical-802-11r-vulnerability-disclosed-for-wireless-networks/
• Intel Wi-Fi Drivers: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00101&languageid=en-fr
• Microsoft (Oct. 10th patch Tuesday included fixes): https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080 and
  https://www.theverge.com/2017/10/16/16481818/wi-fi-attack-response-security-patches
• MikroTik: https://forum.mikrotik.com/viewtopic.php?t=126695
• Mojo Networks: http://www.mojonetworks.com/wpa2-vulnerability
• Ubiquiti: https://community.ubnt.com/t5/UniFi-Updates-Blog/FIRMWARE-3-9-3-7537-for-UAP-USW-has-been-released/ba-p/2099365
• WatchGuard (Oct. 15th some AP models patched, additional models will be patched Oct. 30th): https://www.watchguard.com/wgrd-blog/wpa-and-wpa2-vulnerabilities-update

Patches announced for future release:

• Apple coming soon, patches in developer beta already: 
  http://appleinsider.com/articles/17/10/16/apple-confirms-krack-wi-fi-wpa-2-attack-vector-patched-in-ios-tvos-watchos-macos-betas
• Google Android (coming soon, possibly Nov. security bulletin? Unconfirmed.): 
  https://www.cnet.com/au/news/google-to-patch-krack-impacted-devices-in-the-next-few-weeks/
• Google Pixel (Nov. 6, 2017): https://www.theverge.com/2017/10/16/16481818/wi-fi-attack-response-security-patches
• Mist Systems: the company has placed a broadcast message on their support portal login webpage notifying customers of the 802.11r vulnerability and stating that they will be releasing a patch soon. No details provided yet. https://support-portal.mist.com/hc/en-us/articles/115002801334-FAQ-on-Wi-fi-vulnerability-announced-on-October-16th-2017

Also, I'm not tracking every manufacturer, only the most prominently deployed from my perspective. There are a few sites compiling a detailed list tracking patches from a multitude of manufacturers that you may want to check out:

• Bleeping Computer: https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/
• Kristate Github Repository: https://github.com/kristate/krackinfo#vendor-response-complete

Cheers,
Andrew

P.S. - From a standards development standpoint, the IEEE is taking renewed heat for a notoriously closed process and peer review. There is an interesting take on that here:
https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/

16 Likes 

Share

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

Key Reinstallation Attacks

Breaking WPA2 by forcing nonce reuse

Discovered by Mathy Vanhoef of imec-DistriNet, KU Leuven

FROM https://www.krackattacks.com/