
Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse - fanfantm
https://www.krackattacks.com/
======
trustzone
Matthew Green's blog on why it happened and how it escaped detection is a
really good read.
[https://blog.cryptographyengineering.com/2017/10/16/falling-...](https://blog.cryptographyengineering.com/2017/10/16/falling-
through-the-kracks/)

~~~
ghettoimp
"One of the problems with IEEE is that the standards are highly complex and
get made via a closed-door process of private meetings. More importantly, even
after the fact, they’re hard for ordinary security researchers to access."

While I'm sure this can't take much of the blame, it sure strikes a chord. The
IEEE standards process seems insanely archaic and broken in the open-source
era.

~~~
nieve
It's been years since I was involved with the organization side of the
Standards Association, but there was a lot of frustration among staff because
the vendors (and stakeholders in general) often had a vested interest in
keeping the process broken. IEEE as a whole had a weird relationship with
Standards as well. A somewhat related example is that it took staff years to
get permission from all the vendors to release the full MAC address allocation
database after agreeing to keep it non-public. In general you can probably
assume that people who work for Standards are even grumpier about the whole
nightmare than people outside the process. It's sort of a perverse form of
regulatory capture where the "agency" is still trying to do the right thing,
but they're locked in by their constituency.

------
sequence7
As an Android user is there any mitigation for this other than ditching my
handset and switching to an iPhone or waiting (hopelessly) for a patch from my
vendor.

This really does highlight the absolute disaster zone that the Android handset
market has become as far as updates are concerned. I'm sure the Pixels will
get a fix relatively quickly but almost every other Android user is going to
be left in security limbo.

~~~
Ambroos
This is one of those things that should be better with modern handsets and the
security patch level for Android. Hopefully a fix for this is included in the
November set.

In general most bigger manufacturers have been somewhat decent in updating
their flagship devices. With a Sony flagship from the last 18 months for
example, you usually won't run more than two months behind on security
updates. Samsung is similar if I remember correctly. Hopefully a big exploit
like this will be enough of a kick in the butt to get manufacturers releasing
security updates faster.

~~~
sequence7
I have a HTC 10, a flagship device that's barely a year old the fact that I
now have to wait a couple a months for a patch to what is clearly a critical
vulnerability is just ridiculous. The fact that anyone without a flagship
device should now throw that phone away because it will probably never be
patched is despicable.

I totally agree with your hope that this will kick both the manufacturers and
Google in the butt enough to get something done about this. I don't like our
chances though!

~~~
Perseids
To underline your point, even my Nexus 5 (_from Google_), which is a little
less than 3 years old, will never receive security updates. And one of the
main reasons I chose the Nexus was to be sure to get updates on time. Except
for the security vulnerabilities, everything of the device is totally fine.
It's such a waste of resources… (In this case I at least have an alternative
in the form of Lineage OS, which will only cost me time and nerves for the
migration.)

~~~
endorphone
The Nexus 5 was released 4 years ago. At the same time the iPhone 5C was
released. The 5C also won't receive a patch for this.

There is a problem with handset abandonment, but this is true across all
vendors, and it does not underline sequence7's claim that this is solely an
Android problem.

~~~
pfg
To be fair, these two examples are both on the extreme end: The Nexus 5 being
one of the longest supported Android phones on the market, and the 5C having a
rather short support period, compared to other iPhones like the 5S, which was
released along with the 5C and got iOS 11. Security updates for the Nexus 5
also stopped shipping about a year earlier. There's still room for improvement
for Apple (5 years of security updates seems reasonable), but there's still a
large gap.

~~~
gsnedders
Has anyone ever taken a vendor to court on the basis of consumer rights and
not providing security updates and the product therefore not being fit for
purpose?

For example, under the Consumer Rights Act 2015 in the UK the product must
last for as long as a reasonable person would expect it to, and Apple's
interpretation of that is five/six years (see
[https://www.apple.com/uk/legal/statutory-
warranty/](https://www.apple.com/uk/legal/statutory-warranty/)).

~~~
techdragon
I'm always tempted by this, I have time, I know people, but the thing is, you
agree too far to many contracts by starting to use such a device, that just
navigating the initial waters to find a path to sue anyone is a complete non-
starter. I'm not able to tilt at this windmill. Hopefully the Purism phone
succeeds and I can buy one. Till then ill keep buying a top of the line Apple
phone each 4-5 years when support runs out.

~~~
fphhotchips
If it's anything like Australian Consumer Law, it's _really really difficult_
to sign away those rights. In fact, even attempting to tell a customer that
they can sign away those rights can result in company ending fines.

~~~
bigiain
Hmmm, might have to lead with this line of reasoning when I ask Samsung here
in Australia why my S6Edge doesn't have an update for this in a reasonable
timeframe...

------
pingec
Correct me if I am wrong but basically the attack is against clients, not
access points which means simply patching the AP will not do, one would have
to patch all of the clients. And the AP patches that are now coming in are
probably for client mode, so they fix a certain scenario when the AP is a
client which is far from the common one?

~~~
YouKnowBetter
Correct for 98%. Clients are the weakest point in the scenario.

------
IndrekR
Finally a way to get all IoT devices connected to WiFi!

Remember, 'S' in IoT is for Security.

~~~
JoshuaRLi
> Remember, 'S' in IoT is for Security.

One of the best quotes I've heard in a while.

------
YouKnowBetter
Stop panicking (unless you need your daily dose of the End of the World
drama).

From the source: 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.

Source: [https://www.krackattacks.com/](https://www.krackattacks.com/)

~~~
madshiva
Some people don't want read all the articles and tend to panic. It's why if
there's any security issue we need a list about action to reduce risk, when,
how, etc. otherwise people still we dispute about it's feasible or not and
then finally the journalist will explain how to fix the risk. I like to read
the whole article but then sometimes it's very hard to check if it's truly
feasible or it's just a panic mode, for example when wannacry come out the
information was a mess.

------
alkonaut
What's the practical impact here? What do I do with a normal house with
routers, laptops, smartphones etc?

Are manufacturers like linksys, d-link issuing patches now or will it be
enough to have windows/os x/iOS/android updates enabled? Or do I need both?

~~~
YouKnowBetter
Await your client to be patched. Routers are not so much the problem (unless
in Range Externder modus).

------
philfrasty
„submitted for review on 19 May 2017“ ... „OpenBSD was notified of the
vulnerability on 15 July 2017“

Can anyone explain the timeline of releasing such significant security
findings? Why is it disclosed to the public 1/2 year after submitting to
review? I'd guess the (publicly funded) research behind it is a lot older than
that.

~~~
maxerickson
The intent is to have as many fixes available as possible at the time
knowledge of the flaw becomes widespread.

~~~
philfrasty
Of course.

From my understanding of research at public institutions there is a long
period of time and steps between finding something interesting and submitting
a paper for review.

Why not disclose the vulnerability first to concerned parties and then write
up a fancy research paper? Why the other way round?

Only two explanations I could come up with: Either there must be a very short
time frame between identification of the vulnerability and writing of the
paper or there was further research needed. Or....I don't know

------
whyever
> 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.

I'm not convinced it was a bad decision. Why would you want to leave your
users vulnerable? It's possible that this has been exploited in the wild.

~~~
breakingcups
Seems rather prisoner-dilemma-ish[1].

Up until now, there were no indications that this was being exploited
publicly. After a flaw like this gets known (whether through a coordinated
disclosure or through OpenBSD's early patch) you can be assured people will be
exploiting this.

Do you both stay silent and take the minor risk of your users being vulnerable
for a short time longer whilst patching and disclosure is being coordinated
with all parties (-1/-1), or do you "betray party B" but get your own users
secured as soon as possible (-3, 0).

I think coordination makes more sense in a flaw as big as this.

1:
[https://en.wikipedia.org/wiki/Prisoner%27s_dilemma](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma)

~~~
sp332
And be sure to note the iterated version which is where things get interesting
[https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#The_itera...](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#The_iterated_prisoner.27s_dilemma)
You can already see it in this case, where Theo "defecting" leads to less
cooperation in future rounds.

~~~
Yen
For those who missed the FAQ,

> To avoid this problem in the future, OpenBSD will now receive vulnerability
> notifications closer to the end of an embargo.

i.e., _explicitly signalling_ that this researcher intends to play "defect"
with OpenBSD in future rounds, should future rounds occur.

------
brango
Is there a way I can install an open source phone OS on my old Android phones
to keep them patched? I'm not prepared to keep buying new phones just because
manufacturers only provide intermittent updates for a year or two.

Anyone got any suggestions for options?

~~~
taspeotis
> I'm not prepared to keep buying new phones just because manufacturers only
> provide intermittent updates for a year or two.

You could just ... buy an iPhone and get timely security updates for years.

EDIT: Downvote if you want, but if iOS 11 contains this security fix
exclusively and not iOS 10, then an iPhone 5s bought on 20 September 2013 is
going to get this fix. If Apple release an iOS 10 update and you bought an
iPhone 5 on 21 September 2012 you're covered too.

~~~
la_oveja
and force me to use some propietary-built webkit? Nah, thank you.

~~~
ec109685
If you build it yourself, you can use whatever browser you want.

~~~
pritambaral
Can one install their own web rendering engine on iOS?

~~~
wolfgke
In principle yes (if it is not against the app store guidelines). But if
submitted as an app, it cannot use JIT compiling for security reasons. This
will make the speed of JavaScript execution very non-competitive to WebKit.

~~~
bzbarsky
It's not just JIT. Quoting from [https://developer.apple.com/app-
store/review/guidelines/](https://developer.apple.com/app-
store/review/guidelines/) section 2.5.2:

    
    
      Apps should be self-contained in their bundles, and may
      not read or write data outside the designated container
      area, nor may they download, install, or execute code,
      including other apps.
    

So your can't ship a JS interpreter either, even without a JIT.

And section 2.5.6:

    
    
      Apps that browse the web must use the appropriate WebKit
      framework and WebKit Javascript.
    

So you just can't have a web browser not using the built-in WebKit, period.

As far as I can tell, you can install a web rendering engine that is not the
built-in WebKit, as long as you only use it for HTML/JS that come with your
app. At that point the JIT caveat applies.

~~~
ec109685
You can ship a JS interpreter, it just can’t download code from the internet
and run it (yes this makes shipping a browser in the App Store impossible).

But regardless, with your own device, you can run whatever code you want on
it.

------
chmars
The Wi-Fi Alliance has published an official statement:

'There is no evidence that the vulnerability has been exploited maliciously
[…].'

That is probably about to change …

[https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-
se...](https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-
update)

~~~
willstrafach
That is very strange for them to say. Unless someone is sitting around
collecting full take packet captures of everything going on around them and
looking through it all, there would be no way to be aware of this.

------
andygambles
Have I got this right in lay-mans terms.

The client is forcibly disconnected from the WiFi network and reconnects to
the attackers network instead.

The attacker doesn't need to know the WPA2 password but it accepts the
connection setting the encryption to zeros.

The client thinks it is connected to the original wifi network and continues
as normal.

Wifi traffic is intercepted and unencrypted.

~~~
g-clef
Not quite: The attacker watches for the initial client->AP encryption
negotiation (or forces it by forcing a disassociate), records one step of that
negotiation and replays it to the client. That has the side-effect of causing
the client->AP traffic to re-use encryption keys. Since WPA2 encryption is a
stream cipher, re-using keys opens it up to a known-traffic analysis attack,
which allows a listener to decrypt the traffic. So, the user is still
connected to their existing AP, but since they're re-using keys, attackers can
decrypt the client->AP communication.

There's no need for a second AP in all this, just someone in range of the
client who can replay packets to the clients.

(Good TLDR here:
[https://blog.cryptographyengineering.com/2017/10/16/falling-...](https://blog.cryptographyengineering.com/2017/10/16/falling-
through-the-kracks/) )

~~~
CapacitorSet
>There's no need for a second AP in all this, just someone in range of the
client who can replay packets to the clients.

How would you drop packet 3 without a new AP?

~~~
g-clef
You don't. You record it and replay it. You _want_ the client to get the same
packet 3 over and over.

~~~
NemosDemos
Are you sure about that? From the paper (section 3.3):

> Note that the adversary cannot replay an old message 3, because its EAPOL
> replay counter is no longer fresh.

And a related update from the TLDR post you originally referenced (which I
believe is causing confusion):

> Update: An early version of this post suggested that the attacker would
> replay the message. Actually, the paper describes forcing the AP to resend
> it by blocking it from being received at the client. Thanks to Nikita
> Borisov for the fix.

------
dewey
> This can be abused to steal sensitive information such as credit card
> numbers, passwords, chat messages, emails, photos, and so on.

... if transmitted over plaintext http

~~~
baby
Note that in the demo video they use SSLStrip to cancel attempts of websites
to switch to https.

The only protection here is HSTS (which is not enabled by most websites, but
major ones like banks will usually have them) and manually typing
[https://](https://) in your address.

~~~
technion
I'm seeing HSTS on 0/3 of Australian banks (I'm even seeing RC4 on one of
them).

[https://www.ssllabs.com/ssltest/analyze.html?d=commbank.com....](https://www.ssllabs.com/ssltest/analyze.html?d=commbank.com.au&s=54.192.142.239&latest)
[https://www.ssllabs.com/ssltest/analyze.html?d=nab.com.au&s=...](https://www.ssllabs.com/ssltest/analyze.html?d=nab.com.au&s=164.53.221.205&latest)
[https://www.ssllabs.com/ssltest/analyze.html?d=westpac.com.a...](https://www.ssllabs.com/ssltest/analyze.html?d=westpac.com.au&latest)

~~~
stephen_g
Commonwealth's online banking is actually at my.commbank.com.au and does have
HSTS -
[https://www.ssllabs.com/ssltest/analyze.html?d=www.my.commba...](https://www.ssllabs.com/ssltest/analyze.html?d=www.my.commbank.com.au)

CUA does have it -
[https://www.ssllabs.com/ssltest/analyze.html?d=ob.cua.com.au](https://www.ssllabs.com/ssltest/analyze.html?d=ob.cua.com.au)

Bankwest does but has some awful problems elsewhere -
[https://www.ssllabs.com/ssltest/analyze.html?d=ibs.bankwest....](https://www.ssllabs.com/ssltest/analyze.html?d=ibs.bankwest.com.au&s=203.37.86.1&latest)

But yeah, Westpac and NAB don't, and in addition to the ones you tested, ANZ
and St. George don't have it either. That's pretty unacceptable really.

------
acqq
"Our attack is especially catastrophic against version 2.4 and above of
wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will
_install an all-zero encryption key instead of reinstalling the real key. This
vulnerability appears to be caused by a remark in the Wi-Fi standard that
suggests to clear the encryption key from memory once it has been installed
for the first time._ "

"Because Android uses wpa_supplicant, Android 6.0 and above also contains this
vulnerability. This makes it trivial to intercept and manipulate traffic sent
by these Linux and Android devices. Note that currently 41% of Android devices
are vulnerable to this exceptionally devastating variant of our attack."

------
JoshuaRLi
Some resources for those who want to keep updated on vendor patch status:

[https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathr...](https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathread_check_back_often_for_updated/)

[https://github.com/kristate/krackinfo](https://github.com/kristate/krackinfo)

~~~
bradleyjg
What's the general approach to the fix? Insist on a new handshake if a client
sees a duplicate message #3? Just keep going with the old sequence number?

It seems like vendors need to eventually come to some consensus on how to
change the protocol instead of each fixing it in their own way.

------
SaltySolomon
The research talks a lot about how it somewhat depends on the implementation
of the wireless client, but only in regards to Linux and OpenBSD, anybody know
what the status on the Windows implementation is?

~~~
ac29
>anybody know what the status on the Windows implementation is?

Seconding this. I wonder if it is something fixable at the OS level, or if
individual WiFi drivers need to be updated too.

Would love to see someone throw together a list of OS', Routers, and other
WiFi stuff that is known to be patched/unpatched/unknown.

~~~
ac29
Answering my own question: looks like someone is tracking it over here:
[https://char.gd/blog/2017/wifi-has-been-broken-heres-the-
com...](https://char.gd/blog/2017/wifi-has-been-broken-heres-the-companies-
that-have-already-fixed-it)

Microsoft's status is unclear at the time of writing.

------
rightos
Those running the popular ESP8266 and ESP32 boards for various IoT devices: a
fix has been published for the RTOS running on those boards. If you're
building devices on these platforms, try to get this out to your customers as
soon as possible.

[http://espressif.com/en/media_overview/news/espressif-
releas...](http://espressif.com/en/media_overview/news/espressif-releases-
patches-wifi-vulnerabilities-cert-vu228519)

------
progman
> how did this attack slip through, despite the fact that the 802.11i
> handshake was formally proven secure?

So, we cannot trust even _formal_ verification?

> it’s a factual statement. In formal analysis, definitions really, really
> matter!

If lack of definition implies flaws in formal verification, does that mean we
need an additional formal verification of formal verification?

Update:

> We need machine-assisted verification of protocols, preferably tied to the
> actual source code that implements them.

Haskell, here is your opportunity :-)

~~~
ecesena
> So, we cannot trust even formal verification?

it's explained in the article, 2 unit tests, 0 integration tests. The formal
verification appears to prove correctness of the 2 pieces independently, but
not of the composition.

> Haskell, here is your opportunity :-)

you're just moving the problem to the correctness of the compiler.

~~~
petters
> you're just moving the problem to the correctness of the compiler

But it would be a huge leap forward.

------
pmontra
> For example, an attacker might be able to inject ransomware or other malware
> into websites.

A reason to use https even for the most basic websites, including the ones
embedded in IoT devices on local networks.

------
baybal2
Quick googling found out that at least one guy did come very close to
realizing that 4-way handshake should have hard replay protection:
[http://slideplayer.com/slide/5762070/](http://slideplayer.com/slide/5762070/)

On page 30 of the presentation: "Authenticator may (or may not) re-use ANonce"

------
Cyphase

        Wonderfully Poetic Acronym
        ---
    
        WPA Privacy Attack!
    
        Wi-Fi Protected Access
        Wasn’t Programmed Appropriately
        Wads of Potential Attacks
        Wireless Public Access
        Without Prior Allowance
        Well, Pretty Apocalyptic
        WoPA!
    
        When Patches Arriving?
        Wardrivers, Present Arms!
        Weaponized Privacy Assault
        Wardriving’s Productive Again
        Wide-open Point of Access
        Wrecks Privacy Automatically
        Welcome, Protocol Attackers
    
        Where Patches, Admin?
        Worthless Privacy Attempt
        Wrong Protocol, Admin
        Won’t Protect Anything
    
        Weak Privacy Attempt
        Waste of Precious Attention
        Wins Prying Award
    
        Wired Past, Again

------
ShinyCyril
Does anyone know if Apple release security fixes for Airport? I know it isn’t
actively developed, but you’d hope they’d release critical security fixes as
they still sell them.

~~~
bjpbakker
The main attack targets 4-way handshakes, so doesn't target access points. You
should worry about updating your clients, not your AP.

Source: [https://www.krackattacks.com/](https://www.krackattacks.com/)

~~~
ShinyCyril
Fortunately most access points will be fine, but those performing client
functions (eg repeaters) will need updating.

------
creatrixcordis
"This is achieved by manipulating and replaying cryptographic handshake
messages." so that means that the mac address has been spoofed to make the AP
think that he is always talking to the same mac address.

If I'm plugged into the router directly then i should be good because it
eliminates the wifi handshake. So even though other devices on the wifi
network could be affected, the node that is plugged in is safe against this?

~~~
nullbyte
Well yeah, you'd always be safe against these types of attacks if you're wired
in. Even on Ethernet.

~~~
creatrixcordis
So if i use my wired in node as an ssh tunnel out to the "internets" to tunnel
all traffic from my wifi connected nodes then this mitigates the issue till
updates come through?

~~~
Fnoord
That's a feasible option on laptops running macOS or Linux, but not for
Android clients. Running a SSH VPN (tunneling all traffic) requires root and
has a severe performance penalty (which you will notice on your battery).
You'd notice it on the laptops as well, but I guess that matters less.

Funny enough, OpenBSD didn't impleemnt WPA(2) for a while. Instead, they were
forcing their users to use IPsec and OpenSSH instead.

~~~
creatrixcordis
Debian repos and inherently Ubuntu's repos also have wpa_supplicant 2.4, we
will see if they update to 2.6 or release a patch. Probably patch before 2.6.

It would be nice if there was a rule which package repos and distros would
adhere to. The rule would adapt, such as all the packages that have had a
security issues, will always be required to be updated to the latest versions
in the next release or sooner. As vulnerabilities are discovered, the list of
packages would grow and hopefully would prevent some future attacks. Obviously
it's not full proof but every little bit counts.

~~~
iam-TJ
There has always been a rule for bug-fix and security updates:

Apply the minimum necessary change to solve the problem.

This means cherry-picking the mainline patches where possible, or back-porting
them where modification is required for them to apply (and work as intended)
on older releases.

Especially with older versions it often isn't possible to update to a later
upstream release because that depends on later versions of other packages. The
dependencies can rapidly multiply to affect tens or even hundreds of packages.

Ubuntu patches were prepared and released within 4 hours of the security team
being aware of the vulnerability. Same goes for Debian.

~~~
creatrixcordis
where do i go to get the patch?

i looked here and i don't know where to pick up the patch also ran update
manager in my ubuntu distro but no dice :(

[https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909](https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909)
[http://people.canonical.com/~ubuntu-
security/cve/pkg/wpa.htm...](http://people.canonical.com/~ubuntu-
security/cve/pkg/wpa.html)

~~~
creatrixcordis
just dropped, woohoo :)

------
l2dy
Do we now need WPA3?

No, luckily implementations can be patched in a backwards-compatible manner.

~~~
s17tnet
The problem is that tons and tons of devices will not receive update until
they die.

~~~
StavrosK
Don't you only need to patch one end of the communication? Eg if phones are
patched, they're safe, even if the AP is not. Then again, I didn't read the
attack fully, this might be a client-only problem.

~~~
Khoth
Tons of phones won't be patched. Android phones generally only get system
updates for a small portion of their lifespan.

------
DrRobinson
Do I have to update the both the AP and the client or is one of them enough?

~~~
shimon_e
Client may be enough. Depends on the AP and only the manufacturer can
accurately answer that question.

------
praxis23
Anyone already posted "2 unit tests, 0 integration tests"? [1]. It's funny,
because 4WS actually had security proofs, which considered all the pieces in
isolation, but never in symbiosis.

[1] [https://gfycat.com/HotOrangeCoypu](https://gfycat.com/HotOrangeCoypu)

------
Tepix
Here is the commit that landed the fix for LEDE today:

[https://git.lede-
project.org/?p=source.git;a=commit;h=bbda81...](https://git.lede-
project.org/?p=source.git;a=commit;h=bbda81ce3077dfade2a43a39f772cfec2e82a9a5)

------
twitchyliquid64
This is not an end-of-the-world type vulnerability.

1\. Does not affect long-term credentials - certs, wifi passwords are still
safe. Rather, confidentiality (secrecy) from client --> AP is affected, and in
some cases packet forgery is possible (integrity).

2\. Actually accomplishing this attack, for now, requires special and
expensive hardware (med to high range SDR gear). Its also not that reliable
outside of a lab environment.

3\. Everything you care about _should_ be going over TLS, which mitigates all
effects of this attack. If it isnt, fix it.

This is a great moment for you to fire up wireshark and audit the traffic
going over your wireless link. If its not adequately protected and you care
about it, fix it.

~~~
cm2187
Also doesn't it require the attacker to have access to your wifi already? If
that's the case, it's a hazard for connecting in a Starbucks or on your mobile
service wifi, but you would be safe on your home or corporate wifi (unless the
attacker is a colleague or relative!).

~~~
snerbles
Totally safe, until your local war-driver sniffs out your insecure device and
comes back at two in the morning to upload illegal content via your ISP.

~~~
ibmthrowaway218
Except the attack doesn't get you access to their wireless network. It allows
you to redirect someone from their wireless network to your own (spoofed)
wireless network and then you can snoop the traffic.

~~~
lightedman
If it works in one way what reason is there to think it won't work the
opposite direction? This flaw is in the protocol itself.

------
DyslexicAtheist
Linux patches are out
[https://twitter.com/vanhoefm/status/919853110700531712](https://twitter.com/vanhoefm/status/919853110700531712)

------
noir04
I'd assume that all vendors would be busy getting KRACK fixes out, but instead
ASUS focuses on adding Facebook functionality to their routers..

[https://www.asus.com/Networking/RTAC68U/HelpDesk_BIOS/](https://www.asus.com/Networking/RTAC68U/HelpDesk_BIOS/)

------
hunter2_
There is a lot of talk along the lines of "at least important things use HTTPS
now." Well, for WAN traffic, that's largely true. For corporate/university
intranets, not so much. For example, SMB (network shares) only supports
encryption as of version 3.0, and a server admin who disables handshaking
below v3.0 is disallowing Windows clients below 8.

    
    
        if (win7 && smb && wpa2) then vulnerable to password theft

------
DyslexicAtheist
the post
[https://www.theregister.co.uk/2017/10/16/wpa2_inscure_kracka...](https://www.theregister.co.uk/2017/10/16/wpa2_inscure_krackattack/)
mentions:

> As Hudson notes, the attacker would have to be on the same base station as
> the victim, which restricts any attack's impact somewhat.

If I understand it correctly then there has to be a connection already present
for the attack to work?

------
danilocesar
> For ordinary home users, your priority should be updating clients such as
> laptops and smartphones.

So even if you patch all the devices in your house/company/whetever you can't
be safe... Then yours aunt's un-patched android connects into your wifi and
put all your network in risk. Or maybe that not-so-old security camera or
SmartTV that will never be patched.

Time to move all those guys to an isolated vlan...

~~~
cjg_
The WPA key is not recovered so it should only affect the unpatched client.

~~~
danilocesar
I wasn't even thinking about the key. I was thinking about compromising a
device using a targeted tcp hijack. And then using that device to compromise
the rest of the network. Long shot tough.

~~~
cjg_
Sure that might be possible, for example to serve some malware to that device.
More likely is that a device you allow onto your wifi already have some
malware from earlier.

------
sengork
This might be a good time to switch off main SSID and exclusively use Guest
SSID which is a feature in many routers. At least it would help to isolate
wired computers away from the common wifi network. One could then safely use
weird computers for sensitive communication.

It might also be a good time to invest in NIC dongle manufacturers considering
how many systems only ship with wifi.

------
api
This once again shows why complexity is evil in cryptography. The likelihood
of a vulnerability in a cryptosystem increases exponentially with the number
of state transitions it has.

[http://cr.yp.to/talks/2015.10.05/slides-
djb-20151005-a4.pdf](http://cr.yp.to/talks/2015.10.05/slides-
djb-20151005-a4.pdf)

------
baybal2
Can somebody explain why replay attack protection of WPA2 is not working in
this case? Aren't any out of order packets thrown away?

------
orblivion
I'm not sure I understand the concern with breaking WiFi. Okay, so you're
vulnerable to snooping and injection by people in the same coffee shop or your
neighborhood. But you're already vulnerable to that from anybody on the
Internet between you and the site. HTTPS solves both of these.

Am I missing something?

~~~
Jach
Lots of sites aren't on https yet. Some never will be. Additionally there
could be intranet communications no one bothered to secure, so maybe the
company email's POP server was never configured to send text encrypted.

~~~
orblivion
Yeah, Intranet is a good example.

------
tinix
Some details here on the hostapd security disclosure page:
[https://w1.fi/security/2017-1/wpa-packet-number-reuse-
with-r...](https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-
replayed-messages.txt)

------
esaym
Looks like mikrotik already fixed theirs a couple of weeks ago as well:
[https://forum.mikrotik.com/viewtopic.php?f=21&t=126695](https://forum.mikrotik.com/viewtopic.php?f=21&t=126695)

------
gsich
How are fullmac devices patched? Don't they require firmware flashing or some
sort?

------
ryao
Just a FYI. Certain enterprise access points that implement counter measures
against rogue APs should be able to thwart this attack. Here is a link to
documentation of the feature in one such vendor’s products:

[https://docs.ruckuswireless.com/unleashed/200.5/t-EnablingDi...](https://docs.ruckuswireless.com/unleashed/200.5/t-EnablingDisablingRogueAPDetection.html)

The AP will begin broadcasting deauth frames against the rogue AP as long as
it sees it. There are probably some edge cases, but I would expect either the
rogue and real APs will fight over the clients indefinitely (thwarting
information leaks) or the attack code will trigger an exception and crash
because what programmer would expect the client to immediately disconnect?

~~~
ryao
This project seems to enable the same thing on commodity hardware:

[https://github.com/moha99sa/EvilAP_Defender/wiki](https://github.com/moha99sa/EvilAP_Defender/wiki)

Setup some RPis with WiFi dongles and you can likely make a perimeter defense.
IANAL and I do not know how the FCC would view this, although I imagine it is
not worse than the Ruckus APs that can do this, yet still passed their
certification.

This is not a substitute for patching devices, but it might help somewhat with
devices that will never be patched.

------
gok2
So is there any precautions I should take with my macbook and iphone?

~~~
SadWebDeveloper
Not really just use LAN over WLAN and wait for patches for both of your
devices

------
masswerk
Now, the OS of processor management units like Intel AMT and the AMD
equivalent also incorporate wireless stacks. What are the chances of them
becoming effectively fixed?

------
sinuhe69
Can I use MAC whitelisting to mitigate the attack?

~~~
makomk
Not really. As far as I can tell, the attack basically requires spoofed MACs
anyway because the keys are derived in part from the MACs, so whitelisting
won't get you much benefit if any at all.

------
yuhong
Interestingly, the paper mentions that CCMP is affected less than TKIP/GCMP,
but not the FAQ.

------
user5994461
One thing to clarify, does the attack require the attacker to be already
connected to the AP?

~~~
kzahel
No, that was explained in the demonstration video.

------
shimon_e
Already patched in Arch linux. Just updated all my systems.

------
Paianni
This was fixed in OpenBSD back in August.

------
Sephiroth87
Assuming neither client and router is upgraded, can this be mitigated my
making the SSID hidden, so the attacker wouldn't know which AP to spoof?

~~~
crshstsh
hidden APs can be easily seen

~~~
Sephiroth87
Thanks, didn't know that :)

------
accnt4frms
Is it possible to adapt these attacks to HTTPS protocol?

------
ryanpcmcquen
Oh goodie.

------
aaronaarzelbart
So how will this be fixed?

------
asclepi
It seems that OpenBSD already patched their source code and that wasn't to the
likings of the researcher. In the future he will now delay notifying OpenBSD
of vulnerabilities.

 _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._

~~~
0x0
Not the first time OpenBSD does not respect embargoes, for example
[https://lwn.net/Articles/726585/](https://lwn.net/Articles/726585/) and
[https://lwn.net/Articles/726580/](https://lwn.net/Articles/726580/)

~~~
gizzlon
" _As a compromise, I allowed them to silently patch the vulnerability._ " The
way I read that they broke no embargo

~~~
cyphar
They were pressured by OpenBSD to do so, and regret it. That doesn't mean they
broke embargo, but it also doesn't reflect well on them. Do you think Theo
would've respected the embargo if they had said "no, do not patch until the
embargo date?"

~~~
brians
Yes. He would have tried to persuade them, perhaps cut out the researchers to
persuade CERT.

------
kenaddams
i don't get how they can run a mitm attack without knowing the secret
passphrase, can someone explain this in laymans terms?

~~~
gruez
Because you are replaying the packet, which doesn't need the key.

~~~
kenaddams
thanks that makes sense

------
jokoon
This is too big, I doubt it's not a backdoor.

------
dboreham
"This can be abused to steal sensitive information such as credit card
numbers, passwords"

This really isn't true (because that kind of information is protected by TLS)
and the article is highly disingenuous to not say so.

Nobody has trusted WiFi encryption as protection for sensitive information for
more than a decade.

~~~
discreditable
Demonstration video has the researcher sniff passwords from match.com, which
uses TLS. The catch is they aren't using HSTS and so they are vulnerable to
sslstrip.

~~~
pnutjam
True, using a vpn gives you control over "an" encryption layer for your
traffic, relying on the sites https will always be less ideal.

------
peterwwillis
_" This can be abused to steal sensitive information such as credit card
numbers, passwords, chat messages, emails, photos, and so on."_

As much as this is a scare tactic to get people to demand vendor patches, it's
been true for https for a while.

Browsers don't have any trick (that I know of) to enforce https on first
connection. HSTS is defeated by simply rejecting connections to https - the
user will retry the site from different devices and destroy their hsts cache
in order to reach the site. Assuming the site used hsts.

~~~
pfg
All major browsers implement a HSTS preload list[1] to get around the first
connection problem. Manually deleting the HSTS pin for a site is quite
involved and not something I'd expect most users to do.

[1]: [https://hstspreload.org/](https://hstspreload.org/)

~~~
peterwwillis
Preload lists are not a realistic solution (you can't preload the whole
internet) and a sufficiently complicated site will be subverted due to 3rd
party dependencies. And does uninstalling a browser not clear the hsts cache?

~~~
pfg
Perfect is the enemy of good. A large portion of sensitive traffic is
protected by HSTS today, and the preload list compresses well. By the time
it'll become a problem, we'll hopefully be at the stage where HTTP is treated
as insecure anyway.

I'm not certain if uninstalling a browser clears the cache (do uninstalled
browsers retain their profiles?), but preloaded sites would not be affected -
they're included in the browser binary. Either way, let's not act like there's
a massive hole in HSTS because there's a possibility that users might go as
far as reinstalling their browser to visit a not-preloaded HSTS-enabled site
that's being targeted.

~~~
peterwwillis
I'm not saying it's a massive hole, i'm saying it's an easily preventable hole
that the entire industry is ignoring for unknown reasons. One simple URI
change could make HSTS obsolete and fix the hole with no need for awkward
workarounds and half-measures. Nobody has yet explained to me why "good
enough" is better than "fixed".

