Total Pageviews

Saturday 28 October 2017

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

  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:
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:

Andrew von Nagy @revolutionwifi
Unpatched systems ARE an issue w/  . It comes down to use-case analysis, defense-in-depth practices, & risk analysis. 1/x
8:38 PM - Oct 17, 2017
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:
Wi-Fi infrastructure manufacturer security advisory websites:
Known patched products (in alphabetical order):
Patches announced for future release:
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:
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/
 
Share

Comments (35)

Newest First 
Preview POST COMMENT…
  
Hi Andrew,
Thanks for the very clear report. One thing I'm missing from the AP vendors is what to do with mesh, which is implemented as client in many cases. Would you say disabling the eapol retransmission will solve/mitigate the mesh question?
  
Hi Andrew, thank you for the great post and central repository for vendor patches!
I have put 3x videos together, because customers still ask for solutions and even when
the products are patched there are still WPA2-PSK CCMP/AES issues where the content
of data frames can be seen:
  1. RE: 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.
>> Still this issue exists when the password is known:
Video 1 - https://www.youtube.com/watch?v=by-sqK1gX00
See decrypted data frames within 5 minutes - Wi-Fi Decryption WPA2 PSK/CCMP-AES
(using Savvius Omnipeek, Wireshark, Netscout AirMagnet Wi-Fi analyser, Tamosoft Commview)
  1. RE: Mitigation / Workarounds. Patching takes time. Thank you for the detailed 10-steps approach and that's exactly what the Wi-Fi industry need to do, focus on solutions for our customers to maintain confidentiality and integrity for their wireless communication.
Here is a video about Rogue AP and Client containment (e.g. for large global enterprises, and in case they are unable to patch APs / Clients in a short time frame https://www.youtube.com/watch?v=upHWavutEfs Note: the demo is only showing wireless termination using an advanced (overlay/integrated WIPS system), but there are more possibilities not affecting the airtime (like wired/port suppression/acl/firewall, etc.)
  1. Other researchers of Germany and The Netherlands
    See the links in this video related to other WPA2-PSK CCMP/AES issues
    related to the password recovery.
    Video 3: https://www.youtube.com/watch?v=iRT3GXwFnwg
Ronald van Kleunen
  
As I read this I felt a sense of vindication in everything I understood about this vulnerability. Aside from the Android 'all zeros' vulnerability, I would LOVE to see someone demo the more typical M3 key re-insertion, the window of opportunity is so small and you need to know/guess the data from the 'other' packet with the same packet number which in itself is tricky (could be ARP, DNS, TCP, UDP, etc). Bravo on this page, probably the best one I have seen on this topic outside of the official Krack Attack site.
  
I wanted to thank you for providing accurate information. There is so much misinformation out there about what's affected and what steps should be taken that it's misleading so many people. Thank you for your commitment to accuracy!
  
I stuck in between patches and a VPN. what you guys recommend? i read a favorable content for VPN here https://goo.gl/Kbuq5T
  
I recommend VPN (if the organisation supports it, or any of the public VPN vendors). The reason is shown in this video: https://www.youtube.com/watch?v=by-sqK1gX00
(which means, you can patch APs and clients for "KRACK" but you the password issue still exists). A VPN will only help with Layer 4-7. If you do not use a VPN, you can use HTTPS (but with a Man in the middle attack) as shown by the Belgium researcher the SSL-stripper can remove the HTTPS portion).
  
Hi Andrew. If a client does not support 802.11h channel switch announcement I suspect that this will not work? I think CSA is not mandatory, so what about all this IoT stuff then?
A little bit unsure about this, so any enlighten will be good.
  
Hi Martin, the attacker could use many different methods to get a client to connect to them... deauth and be the strongest signal to the client as one example. There is no dependency on 802.11h channel switch announcements. Just kick a client off an AP and get them to connect to you any way possible.
  
So why were they using this as the method in the video? Just makes me wonder.
  
Martin, they are using 802.11h CSA in the video likely because that is an easy way to get some clients to move off the current AP and onto the attacker AP. If most clients support it, which I believe most do, then why not use that method rather than deauthing the client? :)
  
Andrew is right. It is not channel related (as mentioned in other blogs, etc.). Several ways to do the it "RF-jamming" (OSI-layer 1), "DeAuth/Dissassociate" (OSI Layer 2) many tools and systems are available. Better anntenna's / Tx power by the MITM (to let clients associate to them), Honeypot, Wi-Fi PineApple, Karma, etc. (these work well with Open System Authentication), with WPA2-PSK CCMP/AES it is a bit more challenging but shown in the video at https://www.krackattacks.com/
  
Andrew, great summary. One little detail - hasn't SSL been deprecated in favor of TLS? ('assess application security' paragraph)
  
Hi Steve, don't get lost in the weeds :) The point is that application security can help mitigate this attack.
  
Thank you Andrew, very good summary.
Maybe it would be nice to add some link about the situation of the Linux world.
  
Hi German, I've added a few more details about wpa_supplicant which is used on Linux. Cheers!
  
Cisco's fixed releases and ETAs for other 8.x code trains are now published:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa
Even customers without active service contracts can upgrade.
  
Thanks Jiri! I've updated the post accordingly.
  
"Of the 9 CVE's related to clients, ALL can be mitigated with AP / Infrastructure updates as a workaround"
Do you have any idea if the vendors are actually adding something that mitigates these 9 CVE's, or are they only addressing the 802.11r Fast Transition vulnerability?
And of course, thank you very much for providing all of this information.
  
Hi Max, quick update is that only 7 of the 9 can be mitigated by the AP infrastructure. I've updated the blog post above to correct that error. If the AP doesn't retransmit EAPoL message 3 of the 4-Way Handshake or retransmit frames in the Group-Key Handshake, then it can prevent the MiTM attack when clients are connecting to patched APs. I would expect AP manufacturers to fix this along with the 802.11r vulnerability related specifically to APs, but I don't have confirmation of that yet. I have questions out to manufacturers to clarify and will update when I know more.
Cheers,
Andrew
  
There is nothing that can be done in infrastructure side to prevent attack to client, only to detect if it was attempted.
Check how things are done here to attack: client auth to AP.. then someone just sniffs the EAP exchange, and replays M3 back to client after it is already sending traffic
Or the M5 (for GTK)…
There is no way that AP can prevent someone to hear the EAPoL, and to TX it again
AP/WLC can detect that client sent again the M4 at a weird time.. and report this, and trigger reauth, etc but as this attack is sent without using the infrastructure, nothing you can do to prevent them, only to see the effect
  
Incorrect. The EAPoL M3 (and M2/M4) include a MIC integrity check as well as a Key Replay Counter (KRC). The attacker cannot simply replay the initial M3 message from the Authenticator (AP) since the KRC will be the same and the client will discard it. The attack relies on the attacker MiTM AP blocking (not forwarding) the M4 frame to the AP, and the AP then retransmitting M3 with an incremented KRC and valid MIC that the client will accept, thus reinstalling the PTK and resetting the Packet Number (PN) used in the keystream generation for individual frame encryption.
So... patched APs can protect clients from these vulnerabilities if they modify their behavior to not retransmit M3.
  
Andrew you are absolute right! Thanks for this answer _ Please read this WORKAROUND for a Cisco environment
1. Clients which are slow or may drop initial processing of EAPoL M1. This is seen on some small/slow clients, which may receive the M1, and not be ready to process it after the dot1x authentication phase, or do slower
2. Scenarios with bad RF, or WAN connections between AP and WLC, that may cause a packet drop at some point on transmission towards client.
In both, the outcome would be that an EAPoL exchange failure will be reported, and client will be deauthenticated, it will have to restart association/authentication processes
To lower probabilities for this issue, a longer timeout should be used (1000 msec), to give time for slow clients to respond. The default is 1000 msec, but could have been set lower by customer on some scenarios.
There are two mechanisms available to configure this change.
Global, available in all releases
Per WLAN, available from 7.6 to latest
Global option is simpler, and can be done in all releases, the impact is across all WLANS in the WLC
Per WLAN, allow a more granular control, with the possibility to limit which SSIDs get impacted, so the changes could be applied per device types, etc, if they are grouped on specific wlans, it is available from version 7.6
For example, it could be applied to a generic 802.1x WLAN, but not into a voice specific WLAN, where it may have a larger impact

1 Global Config:

config advanced eap eapol-key-retries 0
(CLI only option)
The value can be validated with:
(2500-1-ipv6) >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....................... 120

2 Per WLAN Config:

X=WLAN ID
config wlan security eap-params enable X
config wlan security eap-params eapol-key-retries 0 X
  
Hi Wireless_kid, thanks for detailing the workarounds on the Cisco Airespace equipment. Setting the EAPOL-Key Max Retries to 0 effectively mitigates the client-related attacks (without a patch too)!
  
Both Cisco and Aruba have been clear they are implementing no such protections. Cisco was super clear they only fixed 802.11r issues, and Aruba had a confusing FAQ but has confirmed they aren't doing anything to protect clients and "If you aren't running 802.11r or using instant, no need to upgrade".
  
Hi "No Love4u" can you provide links to Cisco and Aruba being clear on this? It wasn't clear to me and I would like to see where I've missed this. Thanks!
  
This is a nice compilation, Andrew. Thank you for the effort.
  
Thank you Andrew. This helps a lot, and all the references you put help too. Thank you.
  
Extreme: https://extremeportal.force.com/ExtrArticleDetail?n=000018005
  
The demonstrated attack is only on WPA2 PSK not EAP. After reading through everything it doesn't look like WPA2 with EAP would be vulnerable, especially if the inner protocol is certificate-based. Did you come to the same or different conclusion?
  
Hi Joel. WPA-PSK and WPA2-PSK (the 4-way handshake) make uses of EAPoL Key frames (4 of them) it can be a bit confusing because of the "EAP" terminology.
(this is an issue with WPA/WPA2-PSK - https://www.youtube.com/watch?v=by-sqK1gX00), but I have not been able so far to test if the WPA/WPA2-ENTERPRISE encrypted frames can be decrypted.
For the "KRACK" issue and WPA-ENTERPRISE (TKIP/RC4), WPA2-ENTERPRISE (CCMP/AES) or WPA2-ENTERPRISE (CCMP/AES and TKIP/RC4) networks I am also not 100% sure if it is vulnerable based on which type of EAP-framework is used (and doing mutual authentication with client/server based certificates and tunnel based authentication).
But see here some other security issues with WPA/WPA2-ENTERPRISE related frameworks utilizing "Hostapd-wpe":
Hostapd-wpe supports the following EAP types for impersonation:
1. EAP-FAST/MSCHAPv2 (Phase 0)
2. PEAP/MSCHAPv2
3. EAP-TTLS/MSCHAPv2
4. EAP-TTLS/MSCHAP
5. EAP-TTLS/CHAP
6. EAP-TTLS/PAP
  • https://warroom.securestate.com/evil-twin-attack-using-hostapd-wpe/
  • https://www.youtube.com/watch?v=ioyFoZ-V9S0
  • https://www.youtube.com/watch?v=k-NtjV40zUM
FYI - Note there are many more EAP frameworks:
- EAP-MD5 (do not use it, everything is authenticated in clear text)
- PEAP (EAP-TLS)
- EAP-TLS (EAP-TTLS is already mentioned above)
- TEAP
- EAP-SIM
- EAP-AKA
- EAP-EKE
In most cases the client (Windows, Apple, Android, Blackberry) will come back with a security pop-up message on the screen (related to certificate validation), but it is so technical that most end-users ignore it and press "accept" as they want to connect to the network...
Hope it helps, but we need to find solutions for customers using Wi-Fi for their company confidential related communications (confidentiality, integrity and availability)
Ronald van Kleunen
  
Hi Joel, I believe both PSK and 802.1X networks are affected since the attacker is using a MiTM attack exploiting the 4-Way handshake as part of the PTK negotiation. Therefore, the method of acquiring the PMK (master) key is irrelevant. Everything that I have read seems to indicate that.
  
Hi Andrew. Does that also apply to EAP-TLS
  
Hi Tom, yes the PTK derivation using the 4 Way Handshake as well as the GTK handshake for group keys, IGTK for protected management frames, etc. are all used regardless of how the PMK was derived (PSK, 802.1X, or specific EAP type).
Note that at no time are the PSK or EAP credentials of any type exposed or compromised.


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

Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)