Problems? See this thread at archive.org.
How the KRACK attack destroys nearly all Wi-Fi security
Already addressed by DD-WRT http://svn.dd-wrt.com/changeset/33525
http://svn.dd-wrt.com/timeline
https://w1.fi/cgit/hostap/commit/?id=6f234c1e2ee1ede29f2412b7012b3345ed8e52d3
Kong builds (Broadcom) http://desipro.de/ddwrt/K3-AC-Arm/TEST/
-
Original Discovery Authors Paper on KRACK.
Key Reinstallation Attacks
Breaking WPA2 by forcing nonce reuse
Discovered by Mathy Vanhoef of imec-DistriNet, KU Leuven
https://www.krackattacks.com/
Introduction
Demonstration"We discovered serious weaknesses in WPA2, a protocol that secures all modern protected Wi-Fi networks. An attacker within range of a victim can exploit these weaknesses using key reinstallation atta cks (KRACKs). Concretely, attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted.
This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on. The attack works against all modern protected Wi-Fi networks. Depending on the network configuration, it is also possible to inject and manipulate data. For example, an attacker might be able to inject ransomware or other malware into websites.
The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. To prevent the attack, users must update affected products as soon as security updates become available. Note that if your device supports Wi-Fi, it is most likely affected. During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks. For more information about specific products, consult the database of CERT/CC, or contact your vendor."
The research behind the attack will be presented at the Computer and Communications Security (CCS) conference, and at the Black Hat Europe conference. Our detailed research paper can already be downloaded.
DetailsAs a proof-of-concept we executed a key reinstallation attack against an Android smartphone. In this demonstration, the attacker is able to decrypt all data that the victim transmits. For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher.
This is because Android and Linux can be tricked into (re)installing an all-zero encryption key ( see below for more info). When attacking other devices, it is harder to decrypt all packets, although a large number of packets can nevertheless be decrypted. In any case, the following demonstration highlights the type of information that an attacker can obtain when performing key reinstallation attacks against protected Wi-Fi networks:
Our attack is not limited to recovering login credentials (i.e. e-mail addresses and passwords). In general, any data or information that the victim transmits can be decrypted. Additionally, depending on the device being used and the network setup, it is also possible to decrypt data sent towards the victim (e.g. the content of a website). Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple's iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps."
Paper"Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):
Key reinstallation attacks: high level description
In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol. By manipulating cryptographic handshakes, we can abuse this weakness in practice.
Key reinstallation attacks: concrete example against the 4-way handshake
As described in the introduction of the research paper, the idea behind a key reinstallation attack can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.
Practical impact
In our opinion, the most widespread and practically impactful attack is the key reinstallation attack against the 4-way handshake. We base this judgement on two observations. First, during our own research we found that most clients were affected by it. Second, adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies. Decryption of packets is possible because a key reinstallation attack causes the transmit nonces (sometimes also called packet numbers or initialization vectors) to be reset to zero. As a result, the same encryption key is used with nonce values that have already been used in the past. In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted). In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.
The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to obtain the TCP sequence numbers of a connection, and hijack TCP connections. As a result, even though WPA2 is used, the adversary can now perform one of the most common attacks against open Wi-Fi networks: injecting malicious data into unencrypted HTTP connections. For example, an attacker can abuse this to inject ransomware or malware into websites that the victim is visiting.
If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets. Moreover, because GCMP uses the same authentication key in both communication directions, and this key can be recovered if nonces are reused, it is especially affected. Note that support for GCMP is currently being rolled out under the name Wireless Gigabit (WiGig), and is expected to be adopted at a high rate over the next few years.
The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked. Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent by the client. When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent towards the client. Finally, most of our attacks also allow the replay of unicast, broadcast, and multicast frames. For further details, see Section 6 of our research paper.
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.
50% of Android devices are vulnerable to this exceptionally devastating variant of our attack.
Assigned CVE identifiers
The following Common Vulnerabilities and Exposures (CVE) identifiers were assigned to track which products are affected by specific instantiations of our key reinstallation attack:
- CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
- CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
- CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
- CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
- CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
- CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
- CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
- CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
- CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
- CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
Tools"Our research paper behind the attack is titled Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 and will be presented at the Computer and Communications Security (CCS) conference on Wednesday 1 November 2017.
Although this paper is made public now, it was already submitted for review on 19 May 2017. After this, only minor changes were made. As a result, the findings in the paper are already several months old. In the meantime, we have found easier techniques to carry out our key reinstallation attack against the 4-way handshake. With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper.
We would like to highlight the following addendums and errata:
Addendum: wpa_supplicant v2.6 and Android 6.0+
Linux's wpa_supplicant v2.6 is also vulnerable to the installation of an all-zero encryption key in the 4-way handshake. This was discovered by John A. Van Boxtel. As a result, all Android versions higher than 6.0 are also affected by the attack, and hence can be tricked into installing an all-zero encryption key. The new attack works by injecting a forged message 1, with the same ANonce as used in the original message 1, before forwarding the retransmitted message 3 to the victim.
Addendum: other vulnerable handshakes
After our initial research as reported in the paper, we discovered that the TDLS handshake and WNM Sleep Mode Response frame are also vulnerable to key reinstallation attacks.
Selected errata
- In Figure 9 at stage 3 of the attack, the frame transmitted from the adversary to the authenticator should say a ReassoReq instead of ReassoResp."
Q&A"We have made scripts to detect whether an implementation of the 4-way handshake, group key handshake, or Fast BSS Transition (FT) handshake is vulnerable to key reinstallation attacks. These scripts will be released once we have had the time to clean up their usage instructions.
We also made a proof-of-concept script that exploits the all-zero key (re)installation present in certain Android and Linux devices. This script is the one that we used in the demonstration video. It will be released once everyone has had a reasonable chance to update their devices (and we have had a chance to prepare the code repository for release). We remark that the reliability of our proof-of-concept script may depend on how close the victim is to the real network. If the victim is very close to the real network, the script may fail because the victim will always directly communicate with the real network, even if the victim is (forced) onto a different Wi-Fi channel than this network."
" Do we now need WPA3?
No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point (AP), and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available. Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!
Should I change my Wi-Fi password?
Changing the password of your Wi-Fi network does not prevent (or mitigate) the attack. So you do not have to update the password of your Wi-Fi network. Instead, you should make sure all your devices are updated, and you should also update the firmware of your router. Nevertheless, after updating both your client devices and your router, it's never a bad idea to change the Wi-Fi password.
I'm using WPA2 with only AES. That's also vulnerable?
Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP). So everyone should update their devices to prevent the attack!
You use the word "we" in this website. Who is we?
I use the word "we" because that's what I'm used to writing in papers. In practice, all the work is done by me, with me being Mathy Vanhoef. My awesome supervisor is added under an honorary authorship to the research paper for his excellent general guidance. But all the real work was done on my own. So the author list of academic papers does not represent division of work
Is my device vulnerable?
Probably. Any device that uses Wi-Fi is likely vulnerable. Contact your vendor for more information.
What if there are no security updates for my router?
Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
How did you discover these vulnerabilities?
When working on the final (i.e. camera-ready) version of another paper, I was double-checking some claims we made regarding OpenBSD's implementation of the 4-way handshake. In a sense I was slacking off, because I was supposed to be just finishing the paper, instead of staring at code. But there I was, inspecting some code I already read a hundred times, to avoid having to work on the next paragraph. It was at that time that a particular call to ic_set_key caught my attention. This function is called when processing message 3 of the 4-way handshake, and it installs the pairwise key to the driver. While staring at that line of code I thought “Ha. I wonder what happens if that function is called twice”. At the time I (correctly) guessed that calling it twice might reset the nonces associated to the key. And since message 3 can be retransmitted by the Access Point, in practice it might indeed be called twice. “Better make a note of that. Other vendors might also call such a function twice. But let's first finish this paper...”. A few weeks later, after finishing the paper and completing some other work, I investigated this new idea in more detail. And the rest is history.
The 4-way handshake was mathematically proven as secure. How is your attack possible?
The brief answer is that the formal proof does not assure a key is installed once. Instead, it only assures the negotiated key remains secret, and that handshake messages cannot be forged.
The longer answer is mentioned in the introduction of our research paper: our attacks do not violate the security properties proven in formal analysis of the 4-way handshake. In particular, these proofs state that the negotiated encryption key remains private, and that the identity of both the client and Access Point (AP) is confirmed. Our attacks do not leak the encryption key. Additionally, although normal data frames can be forged if TKIP or GCMP is used, an attacker cannot forge handshake messages and hence cannot impersonate the client or AP during handshakes. Therefore, the properties that were proven in formal analysis of the 4-way handshake remain true. However, the problem is that the proofs do not model key installation. Put differently, the formal models did not define when a negotiated key should be installed. In practice, this means the same key can be installed multiple times, thereby resetting nonces and replay counters used by the encryption protocol (e.g. by WPA-TKIP or AES-CCMP).
Some attacks in the paper seem hard
We have follow-up work making our attacks (against macOS and OpenBSD for example) significantly more general and easier to execute. So although we agree that some of the attack scenarios in the paper are rather impractical, do not let this fool you into believing key reinstallation attacks cannot be abused in practice.
If an attacker can do a man-in-the-middle attack, why can't he just decrypt all the data?
As mentioned in the demonstration, the attacker first obtains a man-in-the-middle (MitM) position between the victim and the real Wi-Fi network (called a channel-based MitM position). However, this MitM position does not enable the attacker to decrypt packets! This position only allows the attacker to reliably delay, block, or replay encrypted packets. So at this point in the attack, he or she cannot yet decrypt packets. Instead, the ability to reliably delay and block packets is used to execute a key reinstallation attack. After performing a key reinstallation attack, packets can be decrypted.
Are people exploiting this in the wild?
We are not in a position to determine if this vulnerability has been (or is being) actively exploited in the wild. That said, key reinstallations can actually occur spontaneously without an adversary being present! This may for example happen if the last message of a handshake is lost due to background noise, causing a retransmission of the previous message. When processing this retransmitted message, keys may be reinstalled, resulting in nonce reuse just like in a real attack.
Should I temporarily use WEP until my devices are patched?
NO! Keep using WPA2.
Will the Wi-Fi standard be updated to address this?
There seems to be an agreement that the Wi-Fi standard should be updated to explicitly prevent our attacks. These updates likely will be backwards-compatible with older implementations of WPA2. Time will tell whether and how the standard will be updated.
Is the Wi-Fi Alliance also addressing these vulnerabilities?
For those unfamiliar with Wi-Fi, the Wi-Fi Alliance is an organization which certifies that Wi-Fi devices conform to certain standards of interoperability. Among other things, this assures that Wi-Fi products from different vendors work well together.
The Wi-Fi Alliance has a plan to help remedy the discovered vulnerabilities in WPA2. Summarized, they will:
- Require testing for this vulnerability within their global certification lab network.
- Provide a vulnerability detection tool for use by any Wi-Fi Alliance member (this tool is based on my own detection tool that determines if a device is vulnerable to some of the discovered key reinstallation attacks).
- Broadly communicate details on this vulnerability, including remedies, to device vendors. Additionally, vendors are encouraged to work with their solution providers to rapidly integrate any necessary patches.
- Communicate the importance for users to ensure they have installed the latest recommended security updates from device manufacturers.
Users share a lot of personal information on websites such as match.com. So this example highlights all the sensitive information an attacker can obtain, and hopefully with this example people also better realize the potential (personal) impact. We also hope this example makes people aware of all the information these dating websites may be collecting.
How can these types of bugs be prevented?
We need more rigorous inspections of protocol implementations. This requires help and additional research from the academic community! Together with other researchers, we hope to organize workshop(s) to improve and verify the correctness of security protocol implementations.
Why the domain name krackattacks.com?
First, I'm aware that KRACK attacks is a pleonasm, since KRACK stands for key reinstallation atta ck and hence already contains the word attack. But the domain name rhymes, so that's why it's used.
Did you get bug bounties for this?
I haven't applied for any bug bounties yet, nor have I received one already.
How does this attack compare to other attacks against WPA2?
This is the first attack against the WPA2 protocol that doesn't rely on password guessing. Indeed, other attacks against WPA2-enabled network are against surrounding technologies such as Wi-Fi Protected Setup (WPS), or are attacks against older standards such as WPA-TKIP. Put differently, none of the existing attacks were against the 4-way handshake or against cipher suites defined in the WPA2 protocol. In contrast, our key reinstallation attack against the 4-way handshake (and against other handshakes) highlights vulnerabilities in the WPA2 protocol itself.
Are other protocols also affected by key reinstallation attacks?
We expect that certain implementations of other protocols may be vulnerable to similar attacks. So it's a good idea to audit security protocol implementations with this attack in mind. However, we consider it unlikely that other protocol standards are affected by similar attacks (or at least so we hope). Nevertheless, it's still a good idea to audit other protocols!
Is there a higher resolution version of the logo?
Yes there is. And a big thank you goes to the person that made the logo!
When did you first notify vendors about the vulnerability?
We sent out notifications to vendors whose products we tested ourselves around 14 July 2017. After communicating with these vendors, we realized how widespread the weaknesses we discovered are (only then did I truly convince myself it was indeed a protocol weaknesses and not a set of implementation bugs). At that point, we decided to let CERT/CC help with the disclosure of the vulnerabilities. In turn, CERT/CC sent out a broad notification to vendors on 28 August 2017.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
So you expect to find other Wi-Fi vulnerabilities?
"I think we're just getting started" — Master Chief, Halo 1
Here's every patch for KRACK Wi-Fi vulnerability available right now
Vendors are reacting swiftly to a vulnerability that lets attackers eavesdrop on your network traffic.
http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/
"Monday morning was not a great time to be an IT admin, with the public release of a bug that effectively broke WPA2 wireless security."
"As reported previously by ZDNet, the bug, dubbed "KRACK" -- which stands for Key Reinstallation Attack -- is at heart a fundamental flaw in the way Wi-Fi Protected Access II (WPA2) operates.
The security protocol, an upgrade from WEP, is used to protect and secure communications between everything from our routers, mobile devices, and Internet of Things (IoT) devices, but there is an issue in the system's four-way handshake that permits devices with a pre-shared password to join a network.
According to security researcher and academic Mathy Vanhoef, who discovered the flaw, threat actors can leverage the vulnerability to decrypt traffic, hijack connections, perform man-in-the-middle attacks, and eavesdrop on communication sent from a WPA2-enabled device.
US-CERT has known of the bug for some months and informed vendors ahead of the public disclosure to give them time to prepare patches and prevent the vulnerability from being exploited in the wild -- of which there are no current reports of this bug being harnessed by cyberattackers.
The bug is present in WPA2's cryptographic nonce and can be utilized to dupe a connected party into reinstalling a key which is already in use. While the nonce is meant to prevent replay attacks, in this case, attackers are then given the opportunity to replay, decrypt, or forge packets.
In general, Windows and newer versions of iOS are unaffected, but the bug can have a serious impact on Android 6.0 Marshmallow and newer.
The attack could also be devastating for IoT devices, as vendors often fail to implement acceptable security standards or update systems in the supply chain, which has already led to millions of vulnerable and unpatched IoT devices being exposed for use by botnets.
The vulnerability does not mean the world of WPA2 has come crumbling down, but it is up to vendors to mitigate the issues this may cause.
In total, ten CVE numbers have been preserved to describe the vulnerability and its impact, and according to the US Department of Homeland Security (DHS), the main affected vendors are Aruba, Cisco, Espressif Systems, Fortinet, the FreeBSD Project, HostAP, Intel, Juniper Networks, Microchip Technology, Red Hat, Samsung, various units of Toshiba and Ubiquiti Networks."" Apple: The iPhone and iPad maker confirmed to sister-site CNET that fixes for iOS, macOS, watchOS and tvOS are in beta, and will be rolling it out in a software update in a few weeks.
Arris: a spokesperson said the company is "committed to the security of our devices and safeguarding the millions of subscribers who use them," and is "evaluating" its portfolio. The company did not say when it will release any patches.
Aruba: Aruba has been quick off the mark with a security advisory and patches available for download for ArubaOS, Aruba Instant, Clarity Engine and other software impacted by the bug.
AVM: This company may not be taking the issue seriously enough, as due to its "limited attack vector," despite being aware of the issue, will not be issuing security fixes "unless necessary."
Cisco: The company is currently investigating exactly which products are impacted by KRACK, but says that "multiple Cisco wireless products are affected by these vulnerabilities."
"Cisco is aware of the industry-wide vulnerabilities affecting Wi-Fi Protected Access protocol standards," a Cisco spokesperson told ZDNet. "When issues such as this arise, we put the security of our customers first and ensure they have the information they need to best protect their networks. Cisco PSIRT has issued a security advisory to provide relevant detail about the issue, noting which Cisco products may be affected and subsequently may require customer attention.
"Fixes are already available for select Cisco products, and we will continue publishing additional software fixes for affected products as they become available," the spokesperson said.
In other words, some patches are available, but others are pending the investigation.
Espressif Systems: The Chinese vendor has begun patching its chipsets, namely ESP-IDF and ESP8266 versions, with Arduino ESP32 next on the cards for a fix.
Fortinet: At the time of writing there was no official advisory, but based on Fortinet's support forum, it appears that FortiAP 5.6.1 is no longer vulnerable to most of the CVEs linked to the attack, but the latest branch, 5.4.3, may still be impacted. Firmware updates are expected.
FreeBSD Project: A patch is actively being worked on for the base system.
Google: Google told sister-site CNET that the company is "aware of the issue, and we will be patching any affected devices in the coming weeks."
HostAP: The Linux driver provider has issued several patches in response to the disclosure.
Intel: Intel has released a security advisory listing updated Wi-Fi drives and patches for affected chipsets, as well as Intel Active Management Technology, which is used by system manufacturers.
Linux: As noted on Charged, a patch is a patch is already available and Debian builds can patch now, while OpenBSD was fixed back in July.
Netgear: Netgear has released fixes for some router hardware. The full list can be found here.
Microsoft: While Windows machines are generally considered safe, the Redmond giant isn't taking any chances and has released a security fix available through automatic updates.
MikroTik: The vendor has already released patches that fix the vulnerabilities.
OpenBSD: Patches are now available.
Ubiquiti Networks: A new firmware release, version 3.9.3.7537, protects users against the attack.
Wi-Fi Alliance: The group is offering a tool to detect KRACK for members and requires testingfor the bug for new members.
Wi-Fi Standard: A fix is available for vendors but not directly for end users.
WatchGuard: Patches for Fireware OS, WatchGuard legacy and current APs, and for WatchGuard Wi-Fi Cloud have become available.
Apple: Apple has patched the issue in iOS, tvOS, watchOS, macOS betas with fixes due to roll out to consumers soon.
At the time of writing, neither Toshiba and Samsung responded to our requests for comment. If that changes, we will update the story."
KRACK attack: Here's how companies are responding
Some companies already have updates to fix the Wi-FI flaw available, but others say it'll take a few weeks.
https://www.cnet.com/news/krack-wi-fi-attack-patch-how-microsoft-apple-google-responding/
"A serious Wi-Fi security flaw was revealed Monday, and it puts everything from your phone to your smart refrigerator at risk.
An exploit called KRACK, short for Key Reinstallation Attack, hits on a weakness in the code behind WPA2, a protocol that makes wireless connections work in practically every device. It was discovered by computer security academic Mathy Vanhoef and could allow hackers to eavesdrop on your network traffic, ZDNet reported on Monday.
The most important thing you can do is update your devices as patches become available. While some companies already have patches available, others say it could take weeks.
Here's a list of how companies and device makers have responded to KRACK so far."
Microsoft
"Microsoft released security updates on October 10th and customers who have Windows Update enabled and applied the security updates, are protected automatically. We updated to protect customers as soon as possible, but as a responsible industry partner, we withheld disclosure until other vendors could develop and release updates."
Apple iOS and Mac
Apple confirmed it has a fix in beta for iOS, MacOS, WatchOS and TVOS, and will be rolling it out in a software update in a few weeks.
Google Mobile
"We're aware of the issue, and we will be patching any affected devices in the coming weeks."
Google Chromebook
Wasn't available for comment.
Google Chromecast/ Home/ WiFi
"We're aware of the issue, and we will be patching any affected devices in the coming weeks."
Amazon Echo, FireTV and Kindle
"We are in the process of reviewing which of our devices may contain this vulnerability and will be issuing patches where needed."
Samsung Mobile
"As soon as we are notified of any potential vulnerabilities, we work closely to address those issues as quickly as possible. We are aware of this matter and will be rolling out patches to Samsung devices in the coming weeks."
Samsung TVs
Wasn't available for comment.
Samsung Appliances
Wasn't available for comment.
Cisco
Wasn't available for comment.
Linksys/Belkin
"Belkin Linksys, and Wemo are aware of the WPA vulnerability. Our security teams are verifying details and we will advise accordingly. Also know that we are committed to putting the customer first and are planning to post instructions on our security advisory page on what customers can do to update their products, if and when required."
Netgear
"NETGEAR is aware of the recently publicized security exploit KRACK, which takes advantage of security vulnerabilities in WPA2 (WiFi Protected Access II). NETGEAR has published fixes for multiple products and is working on fixes for others. Please follow the security advisory for updates.
"NETGEAR appreciates having security concerns brought to our attention and are constantly monitoring our products to get in front of the latest threats. Being pro-active rather than re-active to emerging security issues is a fundamental belief at NETGEAR.
"To protect users, NETGEAR does not publicly announce security vulnerabilities until fixes are publicly available, nor are the exact details of such vulnerabilities released. Once fixes are available, NETGEAR will announce the vulnerabilities from NETGEAR Product Security web page."
Eero
"We are aware of the KRACK flaw in the WPA2 security protocol. Our security team is currently working on a solution, and we expect to have more information available later today. We have built our cloud system to push over-the-air (OTA) updates for situations exactly like this, to ensure all of our customers get the most updated software available as quickly as possible with no action required on their part."
Here's Eero's blog post about the vulnerability.
D-Link
"On Oct. 16, 2017, a WPA2 wireless protocol vulnerability was reported. D-Link immediately took actions to investigate the issues. This appears to be an industry-wide issue that will require firmware patches to be provided from the relevant semiconductor chipset manufacturers. D-Link has requested assistance from the chipset manufacturers. As soon as patches are received and validated from the chipset manufacturers, D-Link will post updates on its website support.dlink.com immediately."
TP-Link
Wasn't available for comment.
Verizon
Wasn't available for comment.
T-Mobile
Wasn't available for comment.
Sprint
"Since Sprint's network operates on CDMA and LTE technology, not Wi-Fi, the KRACK vulnerabilities are not direct threats to those wireless networks. However, similar to any large company that utilizes Wi-Fi for internal business, we have taken steps to address the vulnerability internally to protect the company."
Ecobee
Wasn't available for comment.
Nvidia
Wasn't available for comment.
Intel
"Intel was notified by the Industry Consortium for Advancement of Security on the Internet (ICASI) and CERT CC of the identified Wi-Fi Protected Access II (WPA2) standard protocol vulnerability. Intel is an ICASI charter member and is part of the coordinated disclosure of this issue.
"Intel is working with its customers and equipment manufacturers to implement and validate firmware and software updates that address the vulnerability. For more information, please refer to Intel's security advisory on this vulnerability - INTEL-SA-00101"
AMD
Wasn't available for comment.
August
Wasn't available for comment.
Nest
"We are aware of the issue and will be rolling out patches to Nest products over the next couple weeks."
Ring
Wasn't available for comment.
Honeywell
Wasn't available for comment.
ADT
Wasn't available for comment.
Comcast
Wasn't available for comment.
AT & T
Wasn't available for comment.
Spectrum
Wasn't available for comment.
Vivint
Wasn't available for comment.
Lutron
Wasn't available for comment.
Lenovo
Wasn't available for comment.
Dell
Wasn't available for comment.
Roku
Wasn't available for comment.
LG Electronics
Wasn't available for comment.
LG Mobile
"Smartphone OEMs have to work very closely with Google to find solutions for OS-level vulnerabilities.
"Google is in the process of rolling out patches to carriers and manufacturers at this very moment but it takes time to cover all the major smartphone models.
"So it's hard to say exactly when a specific phone will get the fix but it's certainly being addressed."
LG Appliances
Wasn't available for comment.
GE
Wasn't available for comment.
Philips Hue
"The KRACK attack is against devices using the Wi-Fi protocol. We recommend that consumers use secure Wi-Fi passwords and install the latest patches on their phones, computers and other Wi-Fi-enabled devices to prevent such attacks. Since Philips Hue does not itself support Wi-Fi directly, it does not need to be patched because of this attack. Further, all our cloud account APIs are protected using HTTPS which offers an additional layer of security which isn't affected by this attack."
Kwikset
Wasn't available for comment.
Yale
Wasn't available for comment.
Schlage
Wasn't available for comment.
Rachio
Wasn't available for comment.
iHome
Wasn't available for comment.
Electrolux/Frigidaire
Wasn't available for comment.
Netatmo
Wasn't available for comment.
Roost
"All traffic to and from Roost devices is encrypted end-to-end using the latest SSL/TLS encryption. As such, we don't believe our devices are at risk of this attack. We suggest that our users follow the recommendations from the Wi-Fi Alliance to always use Wi-Fi encryption on their Access points and apply the latest software updates."
Control4
Wasn't available for comment.
Vulnerability Note VU#228519
Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse
https://www.kb.cert.org/vuls/id/228519
Solution: Install Updates"Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse, resulting in key reinstallation by a wireless access point (AP) or client. An attacker within range of an affected AP and client may leverage these vulnerabilities to conduct attacks that are dependent on the data confidentiality protocols being used.
Attacks may include arbitrary packet decryption and injection, TCP connection hijacking, HTTP content injection, or the replay of unicast and group-addressed frames."
The following CVE IDs have been assigned to document these vulnerabilities in the WPA2 protocol:
- CVE-2017-13077: reinstallation of the pairwise key in the Four-way handshake
- CVE-2017-13078: reinstallation of the group key in the Four-way handshake
- CVE-2017-13079: reinstallation of the integrity group key in the Four-way handshake
- CVE-2017-13080: reinstallation of the group key in the Group Key handshake
- CVE-2017-13081: reinstallation of the integrity group key in the Group Key handshake
- CVE-2017-13082: accepting a retransmitted Fast BSS Transition Reassociation Request and reinstalling the pairwise key while processing it
- CVE-2017-13084: reinstallation of the STK key in the PeerKey handshake
- CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake
- CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame
- CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame
An attacker within the wireless communications range of an affected AP and client may leverage these vulnerabilities to conduct attacks that are dependent on the data confidentiality protocol being used. Impacts may include arbitrary packet decryption and injection, TCP connection hijacking, HTTP content injection, or the replay of unicast, broadcast, and multicast frames.
The WPA2 protocol is ubiquitous in wireless networking. The vulnerabilities described here are in the standard itself as opposed to individual implementations thereof; as such, any correct implementation is likely affected. Users are encouraged to install updates to affected products and hosts as they are available. For information about a specific vendor or product, check the Vendor Information section of this document or contact the vendor directly. Note that the vendor list below is not exhaustive.
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
Microsoft has a tracking entry for Krack patches for all their OS's
CVE-2017-13080 | Windows Wireless WPA Group Key Reinstallation Vulnerability
Security Vulnerability
Published: 10/16/2017 | Last Updated : 10/18/2017
MITRE CVE-2017-13080
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
Scroll down to the Affected Products list with links to patches. MS uses different KB patch numbers across different OS's. Go to MS's page for a clean view of the list, here's a snapshot of the list today, with links:
Affected Products
The following software versions or editions are affected. Versions or editions that are not listed are either past their support life cycle or are not affected. To determine the support life cycle for your software version or edition, see the Microsoft Support Lifecycle.
Product Platform Article Download Impact Severity Supersedence
Windows 10 for 32-bit Systems 4042895 Security Update Spoofing Important 4038781
Windows 10 for x64-based Systems 4042895 Security Update Spoofing Important 4038781
Windows 10 Version 1511 for 32-bit Systems 4041689 Security Update Spoofing Important 4038783
Windows 10 Version 1511 for x64-based Systems 4041689 Security Update Spoofing Important 4038783
Windows 10 Version 1607 for 32-bit Systems 4041691 Security Update Spoofing Important 4038782
Windows 10 Version 1607 for x64-based Systems 4041691 Security Update Spoofing Important 4038782
Windows 10 Version 1703 for 32-bit Systems 4041676 Security Update Spoofing Important 4038788
Windows 10 Version 1703 for x64-based Systems 4041676 Security Update Spoofing Important 4038788
Windows 7 for 32-bit Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows 7 for x64-based Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows 8.1 for 32-bit systems 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows 8.1 for x64-based systems 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows RT 8.1 4041693 Monthly Rollup Spoofing Important 4038792
Windows Server 2008 for 32-bit Systems Service Pack 2 4042723 Security Update Spoofing Important
Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) 4042723 Security Update Spoofing Important
Windows Server 2008 for x64-based Systems Service Pack 2 4042723 Security Update Spoofing Important
Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) 4042723 Security Update Spoofing Important
Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows Server 2008 R2 for x64-based Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows Server 2012 4041690 Monthly Rollup Spoofing Important 4038799
4041679 Security Only
Windows Server 2012 (Server Core installation) 4041690 Monthly Rollup Spoofing Important 4038799
4041679 Security Only
Windows Server 2012 R2 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows Server 2012 R2 (Server Core installation) 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows Server 2016 4041691 Security Update Spoofing Important 4038782
Windows Server 2016 (Server Core installation) 4041691 Security Update Spoofing Important 4038782
List of Firmware & Driver Updates for KRACK WPA2 Vulnerability
https://www.bleepingcomputer.com/ne...-driver-updates-for-krack-wpa2-vulnerability/
Everything With Wi-Fi Has A Newly Discovered Security Flaw: Here's How To Protect Yourself | TIME
-
-
-
-
That's MS for you
I thought they started that practice during the upgrade times, but ended bundling the upgrade tool after the "free" time ended.
If you are on Windows 7/8.1, report the GWX Control Panel issue to the developer, maybe he can come up with another fix and publish a new version?
It's been a while, April 2016, since he came out with a new update, and his youtube channel hasn't had a new video for a year, but you might get him to respond.
Never10 is a tool similar to GWX Control Panel, I never tried it, but Gibson Research is still active on other things, they might respond if you ask for a fix - or maybe first try Never10 to see if it's still working after applying the Krack patch.
If you are running Windows 10, the O&O ShutUp10 tool has been updated for the new Creators Update to Version 1.6.1391, hopefully that fixes blocking Upgrades / Updates within W10:
O&O ShutUp10
Free antispy tool for Windows 10
https://www.oo-software.com/en/shutup10
It looks like the KB4041678 patch causes other problems too:
“Unexpected error from external database driver” error messages in Excel, Access, ODBC, cause by this month’s Windows patches
https://askwoody.com/tag/kb-4041678/
Microsoft has a tracking entry for Krack patches for all their OS's
CVE-2017-13080 | Windows Wireless WPA Group Key Reinstallation Vulnerability
Security Vulnerability
Published: 10/16/2017 | Last Updated : 10/18/2017
MITRE CVE-2017-13080
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
Scroll down to the Affected Products list with links to patches. MS uses different KB patch numbers across different OS's. Go to MS's page for a clean view of the list, here's a snapshot of the list today, with links:
Affected Products
The following software versions or editions are affected. Versions or editions that are not listed are either past their support life cycle or are not affected. To determine the support life cycle for your software version or edition, see the Microsoft Support Lifecycle.
Product Platform Article Download Impact Severity Supersedence
Windows 10 for 32-bit Systems 4042895 Security Update Spoofing Important 4038781
Windows 10 for x64-based Systems 4042895 Security Update Spoofing Important 4038781
Windows 10 Version 1511 for 32-bit Systems 4041689 Security Update Spoofing Important 4038783
Windows 10 Version 1511 for x64-based Systems 4041689 Security Update Spoofing Important 4038783
Windows 10 Version 1607 for 32-bit Systems 4041691 Security Update Spoofing Important 4038782
Windows 10 Version 1607 for x64-based Systems 4041691 Security Update Spoofing Important 4038782
Windows 10 Version 1703 for 32-bit Systems 4041676 Security Update Spoofing Important 4038788
Windows 10 Version 1703 for x64-based Systems 4041676 Security Update Spoofing Important 4038788
Windows 7 for 32-bit Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows 7 for x64-based Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows 8.1 for 32-bit systems 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows 8.1 for x64-based systems 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows RT 8.1 4041693 Monthly Rollup Spoofing Important 4038792
Windows Server 2008 for 32-bit Systems Service Pack 2 4042723 Security Update Spoofing Important
Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) 4042723 Security Update Spoofing Important
Windows Server 2008 for x64-based Systems Service Pack 2 4042723 Security Update Spoofing Important
Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) 4042723 Security Update Spoofing Important
Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows Server 2008 R2 for x64-based Systems Service Pack 1 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) 4041681 Monthly Rollup Spoofing Important 4038777
4041678 Security Only
Windows Server 2012 4041690 Monthly Rollup Spoofing Important 4038799
4041679 Security Only
Windows Server 2012 (Server Core installation) 4041690 Monthly Rollup Spoofing Important 4038799
4041679 Security Only
Windows Server 2012 R2 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows Server 2012 R2 (Server Core installation) 4041693 Monthly Rollup Spoofing Important 4038792
4041687 Security Only
Windows Server 2016 4041691 Security Update Spoofing Important 4038782
Windows Server 2016 (Server Core installation) 4041691 Security Update Spoofing Important 4038782
Added to other lists of patches / vendors:
http://forum.notebookreview.com/thr...passwords-and-much-more.809903/#post-10617335longknives likes this. -
-
-
-
Dude, get your own devices, cable modem and wireless router / wireless AP, and save a bunch of $ over the next 1-3 years.
The monthly charge for the modem and router, even if combined into 1 unit, is money down the drain.
And, like you are finding out, problems like this won't get fixed in a timely manner.
In fact, this is a good time to cancel the rental of their equipment - get your new stuff running first - you only need to call in to Comcast to enable you new modem's MAC address that faces Comcast, you read it off the bottom of the device - it'll say it on sticker.
Now you just need to find a router that has updated firmware with that fix
BTW, it's really the phone, laptop, etc wireless client that gets hacked, but it's good to have the router patched too.
Serious flaw in WPA2 protocol lets attackers intercept passwords and much more
Discussion in 'Security and Anti-Virus Software' started by j95, Oct 17, 2017.
