Overclock.net banner

[Ars] Severe flaw in WPA2 protocol leaves Wi-Fi traffic open to eavesdropping

4K views 54 replies 30 participants last post by  ahnon 
#1 ·
Quote:
According to a researcher who has been briefed on the vulnerability, it works by exploiting a four-way handshake that's used to establish a key for encrypting traffic. During the third step, the key can be resent multiple times. When it's resent in certain ways, a cryptographic nonce can be reused in a way that completely undermines the encryption.

A Github page belonging to one of the researchers and a separate placeholder website for the vulnerability used the following tags:

  • WPA2
  • KRACK
  • key reinstallation
  • security protocols
  • network security, attacks
  • nonce reuse
  • handshake
  • packet number
  • initialization vector

Researchers briefed on the vulnerabilities said they are indexed as: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088. One researcher told Ars that Aruba and Ubiquiti, which sell wireless access points to large corporations and government organizations, already have updates available to patch or mitigate the vulnerabilities.
https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/

This is very, very bad. Feels like everything software is being punched full of holes.
 
#2 ·
Will have to look at the patches that mitigate these vulnerabilities.

Still, I've always tried to make sure nothing sensitive of mine gets broadcast over the air, and prefer hardwired connections on my own networks wherever practical.
 
#3 ·
Quote:
Originally Posted by Omega X View Post

This is very, very bad. Feels like everything software is being punched full of holes.
This is what happens when people don't think about everything when designing a security protocol.
For the most part, they think about how they make the protocol, how both sides talk, but don't consider every time how it can be exploited.

Look at USB as a good example.
We all expect that when you connect the USB it will automatically open your storage or device, but don't they didn't consider how those automatic protocols can be used to hack into your system just with plugging a device, even after trying to put some security on it.

Software is its own worst enemy. Especially when it is a known protocol.
 
#4 ·
#6 ·
Quote:
Originally Posted by Omega X View Post

Regardless of what it was, it requires patching which is going to take a miracle. Some hardware makers won't patch a thing and will try to use it as a way to push new hardware.
Thats the biggest issue here, all of the wifi devices that wont ever see a patch. Million bux says all of those wifi/modem combos from ISP's never come close to being patched. I would be amazed if Android and Linux themselves dont see security patches, but it will take time for that to trickle down.

All in all though, this seems like an addressable issue.

No software or standard (security or otherwise) is perfect. This flaw is also a bit limited as it requires physical access/proximity, not impossible but much more likely to be used against a mobile device. Hopefully router vendors jump on fixing this and pass it down to many models.
 
#7 ·
Quote:
Originally Posted by ibb27 View Post

This is not a protocol bug, it's an implementation bug. Arstechnica spreads FUD.
https://marc.info/?l=openbsd-misc&m=150815062312041&w=2

Whole thread:
https://marc.info/?t=150814941400001&r=1&w=2
If the protocol is not "air tight" and allows implementation bugs, in my eyes, it is the same thing.
Especially when that bug pretty much exists now in almost every device.
Quote:
> But did every manufacturer make the same mistake then?

Yes.
If every implementation has the same bug, it is not just a bug in the implementation. It is a problem with the protocol itself that allows said bug.
If the definition of a safe to protect precious things from being seen, also accepts a transparent glass safe as a definition of safe to protect said precious things, the definition of the safe is wrong, unless it is more specific what a safe is and how it should be implemented.
 
#8 ·
Quote:
Originally Posted by Defoler View Post

If the protocol is not "air tight" and allows implementation bugs, in my eyes, it is the same thing.
Especially when that bug pretty much exists now in almost every device.
If every implementation has the same bug, it is not just a bug in the implementation. It is a problem with the protocol itself that allows said bug.
If the definition of a safe to protect precious things from being seen, also accepts a transparent glass safe as a definition of safe to protect said precious things, the definition of the safe is wrong, unless it is more specific what a safe is and how it should be implemented.
Blame tech companies, because most (if not all) of them use blindly open source implementation of code without check the correctness to the standard, even if they have more resources to do it, so...
 
#10 ·
Quote:
Originally Posted by SavantStrike View Post

Unless I've read this wrong, the standard contains the vulnerability.
Maybe standard have to be more strict and need corrections, I'm reading now research paper.
https://papers.mathyvanhoef.com/ccs2017.pdf

From the research paper:
"... it is not because a protocol has been formally proven
secure, that implementations of it are also secure. In our case, the
model of the 4-way handshake used in formal proofs did not fully
reflect reality. This is because it did not define when the negotiated
session key should be installed. As a result, there was no guarantee
that a session key is installed just once. Only by reading real code
did we realize the formal model did not match reality, and that keys
may be reinstalled. In this regard, formal proofs may in fact be counterproductive:
once a protocol is formally verified, the community
may become less interested in auditing actual implementations."

The protocol IS secure, but the standard have flaws and ambiguities, and the implementations are not perfect.
 
#11 ·
Quote:
Originally Posted by Omega X View Post

Regardless of what it was, it requires patching which is going to take a miracle. Some hardware makers won't patch a thing and will try to use it as a way to push new hardware.
On October 16. CERT/CC/ICASI released a public announcement about discovered vulnerabilities in WPA2 handshake protocols that affect most WiFi users and all vendors world wide.
RouterOS v6.39.3, v6.40.4, v6.41rc are not affected!
It is important to note that the vulnerability is discovered in the protocol itself, so even a correct implementation is affected.
These organizations did contact us earlier, so we have already released fixed versions that address the outlined issues. Not all of the discovered vulnerabilities directly impact RouterOS users, or even apply to RouterOS, but we did follow all recommendations and improved the key exchange process according to the guidelines we received from the organizations who discovered the issue.
We released fixed versions last week, so if you upgrade your devices routinely, no further action is required.
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

And some hardware makers are ahead of the game.
 
#12 ·
Quote:
Originally Posted by Trippen Out View Post

On October 16. CERT/CC/ICASI released a public announcement about discovered vulnerabilities in WPA2 handshake protocols that affect most WiFi users and all vendors world wide.

RouterOS v6.39.3, v6.40.4, v6.41rc are not affected!

It is important to note that the vulnerability is discovered in the protocol itself, so even a correct implementation is affected.

These organizations did contact us earlier, so we have already released fixed versions that address the outlined issues. Not all of the discovered vulnerabilities directly impact RouterOS users, or even apply to RouterOS, but we did follow all recommendations and improved the key exchange process according to the guidelines we received from the organizations who discovered the issue.

We released fixed versions last week, so if you upgrade your devices routinely, no further action is required.

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

And some hardware makers are ahead of the game.
Yeah, researchers found the bug first on OpenBSD, and OBSD has patch on 30 August.
https://www.openbsd.org/errata61.html - 6.1 errata #027
 
#16 ·
Netgear sent out a notice of their firmware update about a week ago. The update process takes a little over three minutes and is painless (if three minutes seems too long for you to endure, when you get to that point, go to the bathroom, get a snack, whatever, until it finishes).

Btw, if you are still using the default password, change it immediately! Even the most incompetent hacker can find out what the default password is and get into your system using it.
 
#17 ·
Quote:
Originally Posted by ibb27 View Post

This is not a protocol bug, it's an implementation bug. Arstechnica spreads FUD.
https://marc.info/?l=openbsd-misc&m=150815062312041&w=2

Whole thread:
https://marc.info/?t=150814941400001&r=1&w=2
Quote:
Originally Posted by SavantStrike View Post

Unless I've read this wrong, the standard contains the vulnerability.
https://marc.info/?l=openbsd-misc&m=150816469116173&w=2

Quote:
[prev in list] [next in list] [prev in thread] [next in thread]

List: openbsd-misc
Subject: Re: About WPA2 compromised protocol
From: Lampshade
Date: 2017-10-16 13:53:27
Message-ID: dyaiuwmppkyjgapvdews () yoxg
[Download message RAW]

Stefan Sperling:
> Also this was *NOT* a protocol bug.
> arstechnica claimed such nonesense without any basis in fact and
> now everybody keeps repeating it
frown.gif


Actually, the researcher claimed that are in the standard itself.

https://www.krackattacks.com/
The weaknesses are in the Wi-Fi standard itself, and not in individual prod=
ucts or implementations. Therefore, any correct implementation of WPA2 is l=
ikely affected.

Some paragraphs remarks about OpenBSD in a direct way.

Paper
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 aga=
inst the 4-way handshake. With our novel attack technique, it is now trivia=
l to exploit implementations that only accept encrypted retransmissions of =
message 3 of the 4-way handshake. In particular this means that attacking m=
acOS and OpenBSD is significantly easier than discussed in the paper.

Some attacks in paper seem hard
We have follow-up work making our attacks (against for example macOS and Op=
enBSD) significantly more general and easier to execute. So although we agr=
ee that some of the attack scenarios in the paper are rather impractical, d=
o not let this fool you into believing key reinstallation attacks cannot be=
abused in practice.

How did you discover these vulnerabilities?
When working on the final (i.e. camera-ready) version of another paper, I w=
as double-checking some claims we made regarding OpenBSD's implementation o=
f the 4-way handshake. In a sense I was slacking off, because I was suppose=
d to be just finishing the paper, instead of staring at code. But there I w=
as, 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 mes=
sage 3 of the 4-way handshake, and it installs the pairwise key to the driv=
er. While staring at that line of code I thought =E2=80=9CHa. I wonder what=
happens if that function is called twice=E2=80=9D. At the time I (correctl=
y) guessed that calling it twice might reset the nonces associated to the k=
ey. And since message 3 can be retransmitted by the Access Point, in practi=
ce it might indeed be called twice. =E2=80=9CBetter make a note of that. Ot=
her vendors might also call such a function twice. But let's first finish t=
his paper...=E2=80=9D. A few weeks later, after finishing the paper and com=
pleting some other work, I investigated this new idea in more detail. And t=
he rest is history.=

[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic

Key Reinstallation Attacks Breaking WPA2 by forcing nonce reuse Discovered by Mathy Vanhoef of imec-DistriNet, KU Leuven


https://www.krackattacks.com/
 
#19 ·
... that $5 Wi-Fi connected clothes pin I bought in a Chinese pawnshop 5 years ago...
blushsmiley.gif
eek.gif
 
#22 ·
Quote:
Originally Posted by JackCY View Post

Since when people had an illusion WiFi is secure? It never was, never will be.
Since when have people had an illusion wired networks are secure?

Seriously folks, your "expectation to privacy" as the legal term goes shouldn't exist as far as the internet is concerned. It is inherently not a private space.
 
#23 ·
Quote:
Originally Posted by Mand12 View Post

Quote:
Originally Posted by JackCY View Post

Since when people had an illusion WiFi is secure? It never was, never will be.
Since when have people had an illusion wired networks are secure?...
Wired networks are more secure than Wi-Fi since Wi-Fi can be hacked by a nearby (drive by?) hacker getting lucky with your password (or having time to brute force their way in, such as from a nearby home). A wired network is harder to hack into.

My Wi-Fi got hacked by a neighbor once (they had to have brute forced my password to do so since it's not an easy one to guess). I shut that down quickly by changing my password, then mentioning to the neighborhood gossip that if I found out who it was, and claiming I would if they tired again, I would bring the police, the FBI, the Wrath of God, and my ugly temper down on them. Problem solved.
 
#24 ·
I thought this was already a well-known fact... just that, no one really broadcasts sensitive info over the wifi networks.
tongue.gif
Meh... maybe it's just common knowledge for I.T. guys? I'm probably confusing it with another thing.
redface.gif
 
#25 ·
Quote:
Originally Posted by Mand12 View Post

Since when have people had an illusion wired networks are secure?

Seriously folks, your "expectation to privacy" as the legal term goes shouldn't exist as far as the internet is concerned. It is inherently not a private space.
If your concept of "wired network" equates to "Internet access" then I guess I can agree with the sentiment, but the point is that wireless allows people outside of your physically secured space into your private network more directly than would a network that requires a physical attachment. Nobody has to break into your house. Nobody has to figure out how you find you online. Nobody has to exploit anything. You're just there, a simple password hash away.
 
#26 ·
I have only very sporadically used Wi-Fi and haven't used it at all for more than three years; it's simply turned off. Wi-Fi is a 24/7 attack vector more or less implemented in practice in equipment so that people never even try to reduce the risk, as in turning it off during sleeping hours or when people are out of the house. As to using public Wi-Fi access points outside the house, well, good luck with that, as it's even worse. Several institutions have shut theirs down for security reasons, such as the European Parliament. As it's usually said, there are no free lunches.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top