Slashdot Mirror
Microsoft Has Already Fixed the Wi-Fi Attack Vulnerability; Android Will Be Patched Within Weeks (theverge.com)
Microsoft says it has already fixed the problem for customers running supported versions of Windows. From a report: "We have released a security update to address this issue," says a Microsoft spokesperson in a statement to The Verge. "Customers who apply the update, or have automatic updates enabled, will be protected. We continue to encourage customers to turn on automatic updates to help ensure they are protected." Microsoft is planning to publish details of the update later today. While it looks like Android and Linux devices are affected by the worst part of the vulnerabilities, allowing attackers to manipulate websites, Google has promised a fix for affected devices "in the coming weeks." Google's own Pixel devices will be the first to receive fixes with security patch level of November 6, 2017, but most other handsets are still well behind even the latest updates. Security researchers claim 41 percent of Android devices are vulnerable to an "exceptionally devastating" variant of the Wi-Fi attack that involves manipulating traffic, and it will take time to patch older devices.
Grow up. The article links to the previous Slashdot story from earlier today and is still on the front page. The previous article links to a research paper explaining the vulnerability. For anyone who has looked at the front page this morning or even bothered to examine the links in the summary, it's blatantly obvious which vulnerability is being discussed here. Here's hoping you're modded -1 flamebait. You deserve it.
This is a high profile issue at the moment. I realize looking back at it in a few weeks may be worth that kind of comment, but there's been multiple slashdot articles on it today, and every tech news site is buzzing about it.
To fill your rage though,
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.
Note that each CVE identifier represents a specific instantiation of a key reinstallation attack. This means each CVE ID describes a specific protocol vulnerability, and therefore many vendors are affected by each individual CVE ID. You can also read vulnerability note VU#228519 of CERT/CC for additional details on which products are known to be affected.
Worse, how many millions of Android handsets will never see this patch?
So now most Android devices are, and will continue to be, vulnerable to both BlueBourne and WPA2 KRACK, meaning that essentially they are wide open to anyone pilfering whatever they want off the device itself and as they communicate over the air. With most manufacturers abandoning updates in 3 years or sooner, and for the small pool of supported devices having very infrequent updates available, many times 3-6 months behind the curve, why do we allow this kind of chronic insecurity?
It's insane that we allow businesses to behave like this: Give everyone computing devices they use to run their lives - healthcare, credit, banking, social, BYOD work, etc. and leave them open like Swiss cheese.
So Microsoft "patched" this by not properly implementing the phase 3 handshake re-transmit as it's required in spec of 802.11i from the start.
Windows rejects retransmit requests, causing the attack to fail.
Android Will Be Patched Within Weeks
What percentage of Android will be patched?
The 18% with 7/Nougat or better,
the 50% with 6/Marshmallow or better,
the 78% with 5/Lollipop or better,
the 92% with 4.4/Kitkat or better?
https://developer.android.com/...
As a Nexus 5 owner, I'm not holding my breath on that being a true statement.
Sounds like a good fix to me. Instead of accepting retransmits, it's safer to restart the entire handshake.
"The key negotiation process needs to allow for the possibility of radio interference, so it permits the access point to re-send the message that is step three of the handshake. If an attacker sends a copy of this message, the client device will be tricked into reverting back to the original encryption key and initialization vector used at the start of the session. The client's next transmissions will have been encrypted with the same key as earlier transmissions, even though that key was only meant for a single use. That allows for a key reuse attack, which doesn't directly expose the underlying encryption key but does make it relatively easy to decrypt the data that was encrypted, especially if something is known about the structure of the messages that were both encrypted with the same key. IP packet headers, in turn, provide exactly that."
Yes, if the phase 3 handshake re-transmit required by the specification inherently enables a key reuse attack, then the flaw is not in the implementation, but the specification itself, and security would dictate that one refuse to enable that portion of the specification. Losing the ability to initialize a connection in a high RFI environment, which most installations attempt to avoid and mitigate, is an inconvenience. Having your traffic snooped is quite a bit more of an issue.
From what I understand, the attack is on the router, forcing it to re use known keys for encryption. How do the client devices fix this issue?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
And don't forget that the front page shows the most recent submissions first.
Thank you. This is actually what happened here.
As some of us have jobs and don't live in our mom's basements we tend to read the news after we're done and what do we get? This masterpiece of editorial work.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
wpa (2.1-0ubuntu1.5) trusty-security; urgency=medium
* SECURITY UPDATE: Multiple issues in WPA protocol
- debian/patches/2017-1/*.patch: Add patches from Debian jessie
- CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080,
CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087,
CVE-2017-13088
* SECURITY UPDATE: Denial of service issues
- debian/patches/2016-1/*.patch: Add patches from Debian jessie
- CVE-2016-4476
- CVE-2016-4477
-- Marc Deslauriers Mon, 16 Oct 2017 08:20:18 -0400
you can patch the issue on either side of the setup and this attack will fail so
P client and P router = no attack
N client and P router = no attack
P client and N router = no attack
N client and N router = PAWNED
Unless the patch was deployed before the vulnerability was exposed, the word "already" shouldn't be in the headline.
If you patch a client that client is safe.
If you patch an AP all clients using that AP are safe.
Wrong. There is no possible AP only patch that renders clients safe.