Issue metadata
Sign in to add a comment
|
WPA1/2 all-zero session key & key reinstallation attacks
Reported by
vanho...@gmail.com,
Jul 14 2017
|
|||||||||||||||||||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS First, Chromium's version of wpa_supplicant can be tricked into installing an all-zero session key when connecting to a WPA1/2 network. This allows an adversary to perform a man-in-the-middle attack against Chromium, breaking any security that WPA1/2 is supposed to provide. Second, there's an issue in wpa_supplicant that allows an adversary to replay broadcast and multicast data frames. In the first vulnerability, the client (chromium) installs an all-zero session key when processing a retransmitted message 3 of the 4-way handshake. This happens because it clears the session key from memory after receiving the first message 3 (and after installing the session key for the first time). When the client then reinstalls the session key when processing a retransmitted message 3, it will install the now cleared (all-zero) session key. An attacker can abuse this by forcing the AP into retransmitting message 3 using a channel-based MitM attack (i.e. by blocking the arrival of message 4 and triggering a retransmission of message 3 - see below for details). This can also occur spontaneously when message 4 is lost due to background noise, causing the AP to retransmit message 3. The second vulnerability enables an adversary to trick the client (Chromium) into reinstalling an already in-use group key. This is accomplished by manipulating the group key handshake, which is used to distribute new group keys. More precisely, an attacker will force the AP into retransmitting a Group Message 1. This is done by blocking the arrival of Group Message 2 at the AP using a channel-based MitM attack (see below for details). The attack stores the retransmitted Group Message 1, without forwarding it to the client. The attacker then waits for the AP to transmit broadcast or multicast data packets. After this, the attacker can forward the stored Group Message 1. In response, the client will reinstall the group key, which lowers (or resets) the associated replay counters. As a result, the attacker can now replay the previously transmitted broadcast and/or multicast data packets. Summarized, the client should not reinstall an already in-use group key. VERSION All-zero session key vulnerability: - The vulnerability was first introduced in Chromium Version 50 [1]. - Exploit was tested against Chromium 58.0.3029.140. The vulnerable code is still present in the latest version (attacks against it are identical) [2]. Replay of broadcast and multicast traffic: - This is present in all versions of wpa_supplicant, and hence also in all versions of Chromium. - Tested against Chromium 58.0.3029.140. [1] https://chromium.googlesource.com/chromiumos/third_party/hostap/+/release-R50-7978.B/src/rsn_supp/wpa.c#644 [2] https://chromium.googlesource.com/chromiumos/third_party/hostap/+/master/src/rsn_supp/wpa.c#600 PATCHES Existing hostap commit ad00d64e7d8827b3cebd665a0ceb08adabf15e1e ("Fix TK configuration to the driver in EAPOL-Key 3/4 retry case") fixes the all-zero session key vulnerability. This bugfix was not treated as security critical by the hostap project, because it was not clear at the time that this bug could be abused by an attacker. The attached patch `wpasupp_gtk_reinstall.patch` prevents wpa_supplicant from installing an already in-use group key. This assures any sequence counters associated to the group key will not be reset or lowered, which in turn assures an adversary is unable to replay broadcast/multicast data frames. These patches also need to be sent upstream to the hostap project. I'm willing to do this, if that's OK? Note that other products are affected by variants of this attack. Hence we should coordinate the vulnerability disclosure, so that all affected parties have a chance to prepare patches. REPRODUCTION CASE The attached patch `hostapd_poc_allzero.patch` will trigger the all-zero session key vulnerability. More precisely, it causes the AP to always retransmit message 3 of the 4-way handshake. The AP then installs an all-zero session key. If the client (Chromium) is a vulnerable, it will also install an all-zero session key, meaning our AP will successfully decrypt any frames Chromium will transmit. If the client is not vulnerable, it will use the real session key to transmit data, while the AP uses an all-zero session key, meaning the AP will not be able to receive/decrypt any frames. Execute the following commands to patch hostapd and start the PoC AP: git clone git://w1.fi/srv/git/hostap.git breaking-wpa2-patches-report cd breaking-wpa2-patches-report git checkout hostap_2_6 git apply hostapd_poc_allzero.patch cd hostapd/ cp defconfig .config make -j 6 sudo ./hostapd hostapd.conf You will probably have to edit the line `interface=` in `hostapd.conf` to specify a Wi-Fi interface to use for the AP. After starting the AP, let chromium connect to the SSID testnetwork with as password abcdefgh. If chromium now connects to this AP, it will receive message 3 twice, and will install an all-zero session key. We modified the AP so it always installs an all-zero session key as well. Hence, if the AP can properly receive/decrypt traffic from the client, this confirms the client indeed installed an all-zero session key. Use wireshark/tcpdump to see if traffic is received properly by the AP. Note that if chromium is patched, the AP will not decrypt/receive traffic, because the AP is unable to decrypt the traffic using the all-zero session key. The attached patch `hostapd_poc_gtk.patch` will make the AP install the same static group key every 10 seconds. A patched client should not reinstall the already in-use group key. Execute the following commands to patch hostapd and start the PoC AP: git clone git://w1.fi/srv/git/hostap.git breaking-wpa2-patches-report cd breaking-wpa2-patches-report git checkout hostap_2_6 git apply hostapd_poc_gtk.patch cd hostapd/ cp defconfig .config make -j 6 sudo ./hostapd hostapd.conf You will probably have to edit the line `interface=` in `hostapd.conf` to specify a Wi-Fi interface to use for the AP. I used an Intel Wi-Fi NIC to run the AP. Note that with some Atheros NICs, there's a bug causing the AP *not* to reset the TKIP/CCMP sequence numbers when installing a new group key (meaning it cannot be used to test if the client is patched and rejects replayed messages). So I recommend using an Intel Wi-Fi NIC for the AP. To generate broadcast traffic you can use something like: sudo arping -I wlp0s20u2 -b 192.168.1.10 Use wireshark or tcpdump on the client to see if it receives these ARP requests. An unpatched client will receive all ARP requests. A patch client will receive ARP requests, *until the AP reinstalls the group key*. At that point, the AP will reuse old TKIP/CCMP sequence counters, which a patch client should reject. Note that only the AP ever transmits real broadcast frames. Clients first sent them as unicast frames to the AP, after which the AP will broadcast the frames to all clients. DETAILED BACKGROUND Android 6.0 is affected by the same all-zero session key installation vulnerability. Any Linux distribution that uses wpa_supplicant v2.4 or v2.5 is also affected by this vulnerability. Chromium 49 and below are vulnerable to a variant of the all-zero session key installation attack. There, an adversary can make the victim reinstall the session key. This causes the victim to reset sequence counters and nonces associated to the key, leading to nonce and keystream reuse (allowing e.g. decryption of traffic) as well as the ability to replay frames. Android 5 and earlier are also affected by this variant of the vulnerability. Any Linux distribution that uses wpa_supplicant v2.3 or earlier is similarly affected by this attack. To execute the attacks, an adversary must block certain messages from arriving at the AP. With a MitM position this would be easy. However, an ordinary MitM using a rogue AP with a different MAC address than the real AP does not work. This is because the negotiated session keys are tied to the MAC addresses. Instead, a channel-based MitM must be used, where the adversary clones the real AP on a different channel using the real MAC address. Packets can then be blocked by not forwarding them. Obtaining a channel-based MitM position is easy using Channel Switch Announcement beacons. These command the client to switch channels and can be forged. The attach file `real_attack_poc.patch` is my current PoC of this attack. It uses scapy to trigger the all-zero session key vulnerability, and hostapd to decrypt and inject traffic to the client. Though requiring some tweaking, the attack is surprisingly reliable. Nevertheless, to test whether a client is vulnerable when testing patches, it's much easier to use my patched hostapd which *simulates* a real attack. More details on performing a real attack can always be provided (e.g. example network traces).
,
Jul 15 2017
Tentatively assigning high severity. cernekee: could you please help triage this? We should forward this on to Android folks if they are also impacted.
,
Jul 15 2017
> Existing hostap commit ad00d64e7d8827b3cebd665a0ceb08adabf15e1e ("Fix TK configuration to the driver in EAPOL-Key 3/4 retry case") fixes the all-zero session key vulnerability. OK, so it looks like we're on hostapd v2.5 (Sept 2015) and this commit went in Oct 2015. The fix is present in 2.6. It's an easy UPSTREAM cherry pick (or at least it applies cleanly). I can push it whenever we're all comfortable patching the tree. > The attached patch `wpasupp_gtk_reinstall.patch` prevents wpa_supplicant from installing an already in-use group key. I would defer to the hostap authors on this, as I am not familiar with the code in question.
,
Jul 16 2017
,
Jul 16 2017
,
Jul 17 2017
> We should forward this on to Android folks if they are also impacted. Looking at the source trees, the latest Android is affected by the group key reinstallation vulnerability, but not by the all-zero session key vulnerability. >> The attached patch `wpasupp_gtk_reinstall.patch` prevents wpa_supplicant from installing an already in-use group key. > I would defer to the hostap authors on this, as I am not familiar with the code in question. How to best approach this, mailing this report to hostap with the people here in CC?
,
Jul 22 2017
>> The attached patch `wpasupp_gtk_reinstall.patch` prevents wpa_supplicant from installing an already in-use group key. > I would defer to the hostap authors on this, as I am not familiar with the code in question. I've mailed a vulnerability report to Jouni Malinen, the maintainer of hostap. This includes the suggested group key patch. I will keep you up to date on any progress.
,
Jul 25 2017
Is it possible to make this bug report accessible to Jouni Malinen: j@w1.fi? Then he can directly follow updates and comment.
,
Jul 25 2017
,
Jul 25 2017
Jouni might still have to "register" his email as a "google account" and then sign in to see it. Our "Partner Eng" team routinely does this - ie I don't know details off hand. But adding Jouni's email as CC should be enough to get him access. Is it ok it CC jetstream folks on this bug as well? I'd like to add sduvvuri@ or kkunduru@chromium.org. Or whoever is responsible for security of "Consumer Home" products.
,
Jul 26 2017
,
Jul 30 2017
cernekee: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 30 2017
> Is it ok it CC jetstream folks on this bug as well? I'd like to add sduvvuri@ or kkunduru@chromium.org. Or whoever is responsible for security of "Consumer Home" products. For me that's OK. Anyone responsible in one way or another can be CC'ed.
,
Aug 5 2017
> Jouni might still have to "register" his email as a "google account" and then sign in to see it. Our "Partner Eng" team routinely does this - ie I don't know details off hand. But adding Jouni's email as CC should be enough to get him access. That won't work. Can you add jkmalinen@gmail.com instead? Also, are you waiting on feedback from Jouni, or what's the next step?
,
Aug 14 2017
cernekee: Uh oh! This issue still open and hasn't been updated in the last 29 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 6 2017
,
Sep 13 2017
We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue? For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 27 2017
cernekee@ - what's your status on this? ejcaruso@, jorgelo@ - this sounds like an issue you're tracking elsewhere, can you take a look and confirm?
,
Sep 27 2017
This is being tracked in issue 762671. We can keep this open for tracking but work is happening on 762671.
,
Sep 27 2017
Actually, let's practice good bug hygiene and dupe.
,
Sep 27 2017
The fix for this was picked back to M61 a few weeks ago.
,
Sep 27 2017
Probably already taken into account, but to be sure: the embargo period is until 16 October.
,
Sep 27 2017
This bug is still restricted, as far as I can tell. While I'm here I'm removing what appears to be an incorrect email address for Jouni from the cc list.
,
Sep 27 2017
vanhoefm@: are you referring to embargo for posting public patches, for shipping fixes, or for making this bug public?
,
Sep 27 2017
jorgelo@: all three. CERT/CC and ICASI are coordinating the precise details of the disclosure process though (tracking ID VU#228519), so it's best to confirm the details with them. Note that this is for the general key reinstallation attacks against WPA2, which I assume is also being discussed in issue 762671. I suppose the specific case of the installation of all all-zero key can be silently patched for now by pulling the older and existing commit c742de3 (which has already been done).
,
Sep 27 2017
Yeah, we're tracking VU#228519 internally. The fixes for the general key reinstallation attacks against WPA2 will not be made public before Oct 16.
,
Sep 28 2017
,
Oct 16 2017
,
Nov 6 2017
Can I have a status update and some clarifications regarding: 1. When do you expect to release updates? I was planning to release a proof-of-concept script only after you released an update... 2. Can you clarify why reward-NA? 3. Can you clarify why the KRACK attack demo against Android got removed from YouTube, apart from just stating it contains "Harmful or dangerous content" and that it "incite violence or encourage dangerous or illegal activities that have an inherent risk of serious physical harm or death". Video was at https://www.youtube.com/watch?v=Oh4WURZoR98 and violated guideline was https://support.google.com/youtube/answer/2801964?visit_id=1-636455849317779664-4256849976&p=harmful_content_policy&hl=en&rd=1
,
Nov 6 2017
1. M62 has rolled out to stable for *most* devices (https://chromereleases.googleblog.com/2017/10/stable-channel-update-for-chrome-os_27.html). This update contains all the KRACK fixes. 2. Andrew can clarify why this was reward-NA. 3. We are not the Android team, nor the YouTube team, so we have no idea what happened to that video. Google has 75,000 employees. We only work on Chrome OS =).
,
Nov 8 2017
2. It was marked reward-NA since this was publicly disclosed before we released a patch. However, I'll get it in front of the VRP panel to take a look, given the timings at play here.
,
Nov 8 2017
1. I just reviewed the source code at https://chromium.googlesource.com/chromiumos/third_party/hostap/+/master/src/rsn_supp/wpa.c#600 Can it be that the latest patches are not backported yet? Because this code is still vulnerable to the installation of an all-zero encryption key (similar to how Android 7.0 and above are all vulnerable to the installation of an all-zero key). And some other edge cases also don't appear to be addressed yet. The following patch is essential to prevent the all-zero encryption key issue: https://android.googlesource.com/platform/external/wpa_supplicant_8/+/c66556ca2473620df9751e73eb97ec50a40ffd3e See the other patches of that change to cover extra edge cases. Context: roughly two weeks before the embargo ended we discovered a new attack to trigger the all-zero key vulnerability. The maintainer of hostap communicated this to Google (perhaps that info only reached Android folks). At least based on the above repository, those new patches aren't included yet. 2. OK. 3. In case you do happen to have a contact at YouTube, let them know it's a benign video and I'm actually helping Google. It's sad to see it being removed.
,
Nov 8 2017
Re-assigning to Eric to check the above patch.
,
Nov 8 2017
Looks like we might have dropped some stuff when we switched to the public repo. Thankfully this has not yet made it to stable, so M62 and M63 should be fine.
,
Nov 8 2017
Hi Marty, You're looking at the wrong branch. We now build wpa_supplicant out of the wpa_supplicant-2.6 repo, which can be found here: https://chromium.googlesource.com/chromiumos/third_party/hostap/+log/wpa_supplicant-2.6 "Prevent installation of an all-zero TK" is in this tree (https://chromium.googlesource.com/chromiumos/third_party/hostap/+/4630000a66506c4c77d19b8f0edd0aab0976d6f8) and the code there looks patched to me: https://chromium.googlesource.com/chromiumos/third_party/hostap/+/refs/heads/wpa_supplicant-2.6/src/rsn_supp/wpa.c#617 We can't move the old repo because OnHub is still using that and have a few dependencies which prevent them from moving to hostap 2.6 at this time. They had said they were going to backport patches but I'm not sure what happened there.
,
Nov 8 2017
I see, then I'll assume chromiumos is OK. Sorry for the confusion and thanks for double-checking.
,
Nov 8 2017
The OnHub dependency forced us to do some confusing stuff to allow us to uprev without them, so I totally understand. Thanks for keeping tabs on this!
,
Nov 29 2017
This bug is public now.
,
Nov 29 2017
,
Jan 8 2018
Any updates if it applies for a bounty? Also note the bug is not public yet.
,
Jan 27 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 8 2018
Is there an update regarding reward-topanel?
,
Mar 8 2018
Andrew, has the panel looked at this one?
,
Mar 8 2018
Thanks for the ping - we were coordinating with the other Google VRPs on this and I was waiting on an update. I shall ping them now. Cheers!
,
Apr 9 2018
Ping :) I don't mind waiting if this takes some coordination, but do keep me updated.
,
Apr 11 2018
,
Apr 16 2018
*** Boilerplate reminders! *** Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing. *********************************
,
Apr 16 2018
Hi vanhoefm@ - sorry for the delay. The VRP Panel decided to award $7,500 plus a $1337 bonus. A member of our finance team will be in touch to arrange payment.
,
Apr 16 2018
,
Apr 19 2018
Thank you! |
||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Jul 15 2017Labels: OS-Chrome