New KRACK Attack Against Wi-Fi Encryption

Mathy Vanhoef has just published a devastating attack against WPA2, the 14-year-old encryption protocol used by pretty much all Wi-Fi systems. It's an interesting attack, where the attacker forces the protocol to reuse a key. The authors call this attack KRACK, for Key Reinstallation Attacks.

This is yet another of a series of marketed attacks; with a cool name, a website, and a logo. The Q&A on the website answers a lot of questions about the attack and its implications. And lots of good information in this ArsTechnica article.

There is an academic paper, too:

"Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2," by Mathy Vanhoef and Frank Piessens.

Abstract: We introduce the key reinstallation attack. This attack abuses design or implementation flaws in cryptographic protocols to reinstall an already-in-use key. This resets the key's associated parameters such as transmit nonces and receive replay counters. Several types of cryptographic Wi-Fi handshakes are affected by the attack. All protected Wi-Fi networks use the 4-way handshake to generate a fresh session key. So far, this 14-year-old handshake has remained free from attacks, and is even proven secure. However, we show that the 4-way handshake is vulnerable to a key reinstallation attack. Here, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying handshake messages. When reinstalling the key, associated parameters such as the incremental transmit packet number (nonce) and receive packet number (replay counter) are reset to their initial value. Our key reinstallation attack also breaks the PeerKey, group key, and Fast BSS Transition (FT) handshake. The impact depends on the handshake being attacked, and the data-confidentiality protocol in use. Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged. Because GCMP uses the same authentication key in both communication directions, it is especially affected.

Finally, we confirmed our findings in practice, and found that every Wi-Fi device is vulnerable to some variant of our attacks. Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.

I'm just reading about this now, and will post more information as I learn it.

EDITED TO ADD: More news.

EDITED TO ADD: This meets my definition of brilliant. The attack is blindingly obvious once it's pointed out, but for over a decade no one noticed it.

EDITED TO ADD: Matthew Green has a blog post on what went wrong. The vulnerability is in the interaction between two protocols. At a meta level, he blames the opaque IEEE standards process:

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. Go ahead and google for the IETF TLS or IPSec specifications -- you'll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.

The IEEE has been making a few small steps to ease this problem, but they're hyper-timid incrementalist bullshit. There's an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they've been public for six months -- coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.

This whole process is dumb and -- in this specific case -- probably just cost industry tens of millions of dollars. It should stop.

Nicholas Weaver explains why most people shouldn't worry about this:

So unless your Wi-Fi password looks something like a cat's hairball (e.g. ":SNEIufeli7rc" -- which is not guessable with a few million tries by a computer), a local attacker had the capability to determine the password, decrypt all the traffic, and join the network before KRACK.

KRACK is, however, relevant for enterprise Wi-Fi networks: networks where you needed to accept a cryptographic certificate to join initially and have to provide both a username and password. KRACK represents a new vulnerability for these networks. Depending on some esoteric details, the attacker can decrypt encrypted traffic and, in some cases, inject traffic onto the network.

But in none of these cases can the attacker join the network completely. And the most significant of these attacks affects Linux devices and Android phones, they don't affect Macs, iPhones, or Windows systems. Even when feasible, these attacks require physical proximity: An attacker on the other side of the planet can't exploit KRACK, only an attacker in the parking lot can.

EDITED TO ADD (11/13): The official link to the paper blocks anonymous users. Here's an alternate.

Posted on October 16, 2017 at 8:39 AM • 129 Comments

Comments

TatütataOctober 16, 2017 9:31 AM

That was exactly what I needed to cheer me up for the week (if SCROTUS will allow us to survive until Friday), but if I understand correctly, you do need some known plaintext to get this attack to work.

Could a stopgap measure be to fill the old nonces with random data instead of resetting them to zero, leaving everything else untouched?

For the marketing aspect, "Krack" isn't nearly as sexy as "Heartbleed".

Bob Dylan's Infected ToemailOctober 16, 2017 9:56 AM

"To prevent the attack, users must update affected products as soon as security updates become available..."

OH HA HA HA HA....

If this attack works as billed it is a safe bet that 75% of devices will /never/ be updated.

(quote from official website)

Ewan MarshallOctober 16, 2017 10:06 AM

Basically there will be patches forthcoming for client devices to check nonce is actually a nonce in the handshake (openBSD is already patched), in the mean time the most guaranteed fix is to run anything on the network over a TLS tunnel like VPN to the router. And yeah, bets are off on if IOT devices will ever be fixed and most don't support setting up a VPN for all traffic, remember it is the internet of insecure things.

PeteOctober 16, 2017 10:09 AM

Expecting any RF protocol to be secure forever is a bad idea.

At least with wired ethernet, there is some level of physical access needed by attackers ... assuming all the other devices on the network are secure.

Perhaps we all need to use VPNs, even on our LANs, just to raise the bar a little. I2P FTW?

John PentaOctober 16, 2017 10:49 AM

The concern I have is this: We know that most devices will never, ever be updated. Most devices, more to the point, cannot be updated in this regard, as I understand it.

So the security value of publishing this far and wide is...what?

TimHOctober 16, 2017 10:59 AM

@John Penta: You presume that the authors are only people to have discovered this yet. On a different presumption that a lot of security services know about it already, then what?

GrauhutOctober 16, 2017 11:17 AM

@John: "We know that most devices will never, ever be updated."

I updated some internet zone access points some hours ago.

Quality never goes out of style and you get what you pay for.

And people only learn if it hurts. :)

Grammar NaziOctober 16, 2017 11:45 AM

Clive, before you chime in, please install a spell checker.

It's just hard to focus on brilliancy when it looks like it's written by a teen on a phone.

Who?October 16, 2017 11:52 AM

I love this part:

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.

This time Theo is right, bugs like these ones must be fixed as soon as possible. There is no reason for delaying them. An embargo, as a concept, is against security—artificial delays are unaceptable, as it is collecting bugs for the intelligence community.

Why should OpenBSD 6.2 be released without these important bug fixes? Is it just because manufacturers do not care about security and delay these important fixes for months?

Who?October 16, 2017 12:26 PM

@ Philip

This one is the reason we need a compromise from industry to fix all security-related bugs that are discovered. A business that sells a vulnerable device should have a legal responsibility—they should fix their products, or get a fine if not.

SpellucciOctober 16, 2017 12:28 PM

@Grammar Nazi, I see what you see with respect to Clive's spelling, but have an idea about why this might be. That is, using software that lets one add a spell checker can mean using software which is less secure. Using Notepad, without a spell checker, can be more secure. He may simply be being secure in the way he writes, and isn't security something we all desire?

RachelOctober 16, 2017 12:48 PM

Grammar Nazi. I'm glad that Clive has stated he has thick skin. but perhaps an attitude of being grateful for the extraordinary output Cluve volunteers here is more appropriate and more useful - to yourself. And did you happen to read of the physical condition Clive endures 24/7 ? finally to be quite honest I have no concept of the grammar and spelling errors you speak of. His writing is more , more than fine.
I'd suggest you be quiet and enjoy the brilliance.

Clive RobinsonOctober 16, 2017 12:49 PM

One question that needs to be thought about is the role the FCC has had in reducing the ability of users to replace the firmware in their wireless routers etc.

The secondary question that arises is that of boycotting of the entities that supply wireless equipment that can not be upgraded.

In particular in the UK --and I would assume other places-- ISPs from cable and phone companies supply "their" wireless APs. These will almost certainly not get upgraded by the users and I suspect it is doubtful the ISPs will either.

Which brings us around to the question of "liability" for the usage of such a router for questionable or illegal activities...

TatütataOctober 16, 2017 12:58 PM

Let's consider the speling [TM] errors as a form of authenticating signature. Some of the alternate word renditions are sheer brilliance, voluntary or otherwise.

Decent WiFi in a NHS facility, is that what you get for 350 megaquids/week? When I got ill a while back wireless was too costly to spend too much time browsing. Fortunately there was in that place enough raucus at every hour to keep me awake (and my organs also played their part), so I didn't fear too much getting my laptop nicked.

Get well soon!

GrauhutOctober 16, 2017 1:22 PM

@Bruce: "The attack is blindingly obvious once it's pointed out, but for over a decade no one noticed it."

We all HOPE that for over a decade no one noticed it! :)

ModeratorOctober 16, 2017 1:37 PM

@Grammar Nazi, plenty of smart folks are loose spellers. Please keep your irritation to yourself.

802.11October 16, 2017 1:55 PM

This attack relies on you having the PMK and being able to control the Nonce created by the AP, unless I'm reading this wrong. If you already have the PMK, getting a connections PTK isn't difficult. If an AP isn't generating nonces, randomly that's concerning. I don't see a possible vulnerability if you deploy it over 802.1X, pmk's would be unique per client. Over Pre-shared keys, don't expect any true security unless the key is generated in a cryptographically secure way.

EtienneOctober 16, 2017 1:55 PM

When I set up my wireless AP I wanted more security than what was provided by WiFi. I use OpenVPN on my workstations to connect with the Firewall (pfSense) on the LAN, and also users from the WAN. Thus users can VPN into the network via WiFi or via the Internet.

Even my Android has openVPN, so all seems to be painless using this method.

WhyOctober 16, 2017 2:14 PM

>Why should OpenBSD 6.2 be released without these important bug fixes? Is it just because manufacturers do not care about security and delay these important fixes for months?

It takes time to analyze the vulnerability and see if your implementation is vulnerable, implement a fix, test it against the myriad of field configurations out there, and then notify the system admins to roll out this fix. Security is critical but so is stability. In enterprise, an update that brings down infrastructure or introduces new vulnerabilities is just as disastrous as leaving this problem unpatched. Imagine the out roar if Microsoft pushed out a patch that fixed the problem but caused the OS to BSOD every time the wifi tried to connect.

Giving at least 12 notice weeks to work on the problem before announcing is a good enough compromise between the conflicting needs of swiftness and stability, especially if there's no indication that it's been exploited in the wild.

The issue with OpenBSD patching it silently and early on is that now attackers can see the source code of the fix and quickly realize what the fix protects against. Theo was being foolish in this regard; he was putting dogma and personal feelings in lieu of pragmatic reality.

AJWMOctober 16, 2017 2:22 PM

"The attack is blindingly obvious once it's pointed out, but for over a decade no one noticed it."

s/noticed/publicly announced/

It could have been noticed over a decade ago, for all any of us know.

MitchOctober 16, 2017 2:26 PM

On another ominous security note, a researcher discovered that telecom companies are providing real-time customer name, address, phone, and geolocation info to third party vendors by connecting mobile IPs to real users:

https://medium.com/@philipn/want-to-see-something-crazy-open-this-link-on-your-phone-with-wifi-turned-off-9e0adb00d024

https://news.ycombinator.com/item?id=15477286

These vendors are ostensibly in the business of preventing fraud through verification, but their handling of this news is very duplicitous and there doesn't appear to be proper safeguard and consent procedures in place.

TatütataOctober 16, 2017 2:31 PM

It takes time to analyze the vulnerability and see if your implementation is vulnerable, implement a fix, test it against the myriad of field configurations out there, and then notify the system admins to roll out this fix. Security is critical but so is stability.

Well, the following update manager message just popped up on one of my boxes using an Ubuntu-derived distributions:

WPA and WPA2 are methods for securing wireless networks, the former using IEEE 802.1X, and the latter using IEEE 802.11i. This software provides key negotiation with the WPA Authenticator, and controls association with IEEE 802.11i networks.
This update contains 1 package: wpasupplicant

The "Krack" official announcement was just hours ago.

Is it the OpenBSD patch that is making its way through, or an independent patch? (Or an altogether unrelated update?) The *nix environment update bowel motions are not entirely clear to me.

JeffOctober 16, 2017 2:35 PM

I would like clarification. If the device I'm using now (an iPad) is patched but the access points I use around my city are not, and I protected? And if I'm protected, does it matter to me if any other clients using the same access point are patched?

Not sureOctober 16, 2017 3:07 PM

@Tatütata

I can't remember seeing BSD in the change log so I'm guessing this was an Arch package that got down streamed to Debian> Ubuntu

Have tried searching for the changelog but I can't find it :|

If anyone knows how to view the old changelogs let me know please as I tried a quick search and a look around in var\log

GrauhutOctober 16, 2017 3:21 PM

@Tatütata: Afaik Theo has his own WPA stack.

Seems parts of the patches to wpa_supplicant were made by the vuln researcher himself and applied around 21 hours ago.

https://w1.fi/cgit/hostap/

Looks like your update was related.

Not sureOctober 16, 2017 3:25 PM

Haven't read the change log fully but the attack relies on forcing the client to reinstall and existing key so I'm guessing the fix here is for the device to reject old keys or anything with a nounce value of 0

If you are talking to the other clients on the network then probably but I'm guessing it would only be one way i.e. anything encrypted in there direction.

For public wifi change your mac address and use a vpn! Not just for security changing MAC can get you an extra 15 minutes free indefinitely.

Vincent L GambinoOctober 16, 2017 3:29 PM

@Mitch - re: On another ominous security note...
Demos are gone, as predicted, but not needed to be a bit freaked. "Your privacy is very important to us..." Yeah, right. Or, why I maintain a throwaway, pay-as-I-go, phone bought for cash and registered to a fictitious entity. Of course, knowing and predicting precisely when I should use my "nobody" phone is an ongoing challenge.

TatütataOctober 16, 2017 3:41 PM

Thanks.

Most of the mods address the straight deletion of a facility called "peerkey", which is stated to have never worked at all. Dead code.

The actual patch actually seems to be only a few lines long.

Don't knowOctober 16, 2017 4:05 PM

@Grauhut

Thanks for links probably the shortest web link I've ever seen.

Brian Krebs has just done a short piece on this too.

Link

Suprise suprise android is the most vuln with google not deciding to patch until november 6th

source

TatütataOctober 16, 2017 6:18 PM

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings.

And many corporate participants in these committees have a vested interest in pulling the standard in their direction, rather than honestly attempting to obtain a best-of synthesis of the various proposals on the table. I am personally aware of several cases where patent applications were filed immediately before important meetings.

If your proposal actually makes it into the standard, then you bought yourself some leverage over the other players, and once the other participants realize what has been going on, the concrete has hardened and it's quite hard to go around. The IP policies of standard setting organizations result in the formation of patent pools, creating barriers to entry for new players, and the occasional squabble within the club about FRAND access.

A random check entering "WPA2" in the patent database search mask returns US9491621B2, issued to Qualcomm, a company whose conduct this observer repeatedly found somewhat short of admirable.

Claim 13, which I find representative, reads as follows:

13. A method for communicating data in a wireless communications network, comprising:
transmitting a beacon to a station, the beacon comprising a Wi-Fi Protected Access II pre-shared key (WPA2-PSK) authentication type;
receiving an authentication request from the station, the authentication request comprising the WPA2-PSK authentication type, a first secure attribute exchange (SAE) information element, and a station nonce;
transmitting an authentication response to the station, the authentication response comprising the WPA2-PSK authentication type, the first SAE information element, and an access point nonce;
generating a pairwise master key (PMK) identifier based on the first SAE information element;
receiving an association request from the station after generation of the PMK identifier, the association request comprising a key confirmation derived from the PMK identifier and a second SAE information element; and
transmitting an association response to the station in response to receiving the association request, the association response comprising the key confirmation and the second SAE information element.

Notwithstanding other problems with patentability, I have some doubts whether this subject-matter was actually new on 10 September 2013. But is it? You don't really get wiser reading the application, which doesn't really explain what the alleged problem actually was with the prior art, and what improvement this alleged invention is supposed to bring. So you would have to invest much ressources to understand what they're after, and why.

The harried USPTO examiner based his arguments on older patent documents rather than the IEEE standard documents. Either he doesn't have access to them, or it just takes too much effort to work with them in the allowed time.

ETSI makes available a lot of its working documents, the problem here is that there are so many versions floating around that it's hard to keep an overview.

The Krack vulnerability seems to be caused by both specification and implementation issues. How do you get things right in that context?

TatütataOctober 16, 2017 6:34 PM

The code is apparently still being worked on, the changelog linked above shows several new changes (commits and mods) made just in the last few hours.

DanielOctober 16, 2017 7:11 PM

I'm disappointed in Nick Weaver and others who I have read who are trying to deprecate the seriousness of this attack. The first thing they do is to tell you not to worry about the attack because the attacker needs physical proximity. Huh? Physical proximity is a thing easily gained. It seems as if they are assuming that the bad guys is some guy in some third world country. Nonsense. Once this attack gets coded into aircrack your threat model is the script kiddie next door, not the elite hacker from Timbuktu. The second thing these naysayers would have you believe is that there really is no reasons to worry about it because it doesn't seriously affect Windows or iOS. Forget, for a moment, the extraordinary classist bias in those remarks (poor people use android and we don't need to worry about them) the deeper irony is that it makes the mistake that Matthew Green points our is the root cause of this attack: viewing things in isolation. The number of people who own only Apple and Windows devices and allow only those devices on their network is vanishingly small...everyone knows someone who uses Linux or Android and as soon as they are on your network you can kiss that network goodbye.

What this attack will do--within in the span of the next few months--is to make wardriving a respectable occupation again. While there were current attacks against WPA2 those attack were too random to make wardriving useful to criminals and overally inquisitive geeks. The cultural and legal impact of having to change one's threat model to the guy next door and not just the guy in some other country is huge. The equilibrium just got punctuated.

https://en.wikipedia.org/wiki/Punctuated_equilibrium

WhyOctober 16, 2017 7:12 PM

@Tatütata
Dunno if Ubuntu has already pushed out the update; I can only say that debian has already:
_____________________________________________________________________
wpa (2.3-1+deb8u5) jessie-security; urgency=high

* Non-maintainer upload by the Security Team.
* Add patches to fix WPA protocol vulnerabilities (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):
[....]
-- Yves-Alexis Perez Sat, 14 Oct 2017 14:11:26 +0200
_____________________________________________________________________
However it wouldn't surprise me at all if the Debian people had been in touch with Canonical and let them know about a major security fix like this was coming down the pipe.

Check under /usr/share/doc/wpasupplicant/; if Ubuntu or your derivative didn't mess with the packaging, there should be a changelog there.

TatütataOctober 16, 2017 7:38 PM

Thanks for the tip, here's what it says here:

wpa (2.4-0ubuntu6.2) xenial-security; urgency=medium

* SECURITY UPDATE: Multiple issues in WPA protocol
- debian/patches/2017-1/*.patch: Add patches from Debian stretch
- 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 stretch
- CVE-2016-4476
- CVE-2016-4477
* This package does _not_ contain the changes from 2.4-0ubuntu6.1 in
xenial-proposed.

-- Marc Deslauriers Mon, 16 Oct 2017 07:58:48 -0400

I note that the urgency classification isn't the same.

AnonOctober 16, 2017 9:23 PM

I keep reading conflicting and highly mis-leading information.

Some sources say it is a "break" (it isn't), while others say it only affects clients. Huh? The handshake is compromised, so it would seem ALL devices are affected.

The only vulnerability that does appear to be client-related is the zero-key attack, but that seems to be a separate vulnerability to the key replacement.

Now the for the question to which we all want to know the answer: how the heck did this happen, and why was it never spotted until now?

T BensonOctober 16, 2017 10:22 PM

I've read the articles and watched the video describing how Krack works, the video is useful. I still don't understand how this exploit works. Explanations welcome. I understand the key reinstall issue described. It's the other impacts and potential access I don't understand well.

I get that this will have a huge impact on Internet safety far and wide, but being human I of course wonder how to protect myself. In my little bubble.

I walked around my property today and found that my Wifi signal is more widely available outside my premises than I'd hoped. We all love strong signal, but this issue makes me wonder: Is my network in more danger from our phones and tablets or drive by trouble?

I'd love for my old router to let me set a Range limit, say 50 feet in radius, but its' setting options are as dumb as any Linksys router.

Can anyone give me a clear idea of what is most at risk here--is it my router's vulnerability or the devices I connect with that are the major problem? It sounds like all of the above from the articles, and also that my network could be hijacked to handle MIM or traffic that I don't want.
Any teachers out there? Big picture? How bad is this?

I understand that this can effect everything from businesses to banks to Gov to ...everything. Need clearer Big Picture.

Thanks,
T

FrancesOctober 16, 2017 10:40 PM

I've been reading this blog for years although most of it is way over my head. Clive's spelling has always been iffy but I think it has improved a lot since I first read the site. I guess he has taken his fingers in hand and told them to behave! Clive, it occurs to me that you should write your autobiography, if only for your son; you seem to have been involved in a lot of interesting, and possibly historic, situations.

65535October 17, 2017 12:06 AM

@ Grauhut

"We all HOPE that for over a decade no one noticed it! :)"

Do you mean some entity like NSA did notice and exploited this replay attack but keep quiet because it was a nice zero day?

@ Clive Robinson

"in the UK --and I would assume other places-- ISPs from cable and phone companies supply "their" wireless APs. These will almost certainly not get upgraded by the users and I suspect it is doubtful the ISPs will either. Which brings us around to the question of "liability" for the usage of such a router for questionable or illegal activities... "

That is an interesting aspect. The UK want to keep the sheepeople under surveillance?

Worse old equipment a lot of which will probably be never patched.

Next, to the nuts and bolts of the paper:

https://papers.mathyvanhoef.com/ccs2017.pdf

Page five table 1 shows an alarming chart. It shows mesg3 replay attacks possible on all systems but iOS 10.3.1, Windows 7 and 10. That is bad.

But, as far as I can see no complete list of AP or routers that are vulnerable has been compiled [but I may just not be up on this and all tech websites]. What is the real risk of this replay attack succeeding?

Given pages 12 to 16, Table 3 to countermeasures and discussion there seems be race condition that must be met during the MiTM attack and other complications which would mitigate replay attacks - but also are clever work abounds to those obstacles, what is the real risk?

Matt Green and Weaver seem to think the risk may not be high. But, how high is it given a lot of financial transaction occur a cafe's and other WiFi hot spots?

Can anybody show me the extract hardware and software with which I could reproduce the replay attack in this paper?

I know the attacker must be in the sending area of an attackable Wifi hotspot but would directional or boosted antenna used by the attacker make the replay attack more feasible?

All experts take a chance at answering the above.

Mike BarnoOctober 17, 2017 12:51 AM

@ Grammar N@2i, [@ Clive, @ moderator, @ Tatütata, @ Rachel, @ Steve, etc.]:

Part of me is a proofreader and editor who catches most everything that isn't standard American or British English or US legalese. However mostly I put far more value on the fact that Clive puts more useful, experience-based, thought-out, and independently researchable content onto this site than anyone except @ Bruce, our host. I prefer informative content in somewhat-sloppy form over unhelpful noise, no matter how precisely spelled.

Except the worst political wars, people using this forum have kept a good signal-to-noise ratio. Having to decode bits of spelling and grammar in the good content is similar to having to wade through bits of product spam and trollbot posts and ranters in order to read the informative content.

Get well, Clive, and cope while healing. If you have recordings of friends' original music, that's what helped me most after a bicycle crash.

sitaramOctober 17, 2017 12:53 AM

On physical proximity:

Apart from what "Daniel" said (about aircrack and script kiddies), almost every previously compromised laptop or desktop is also a potential attacker.

I don't see any place for complacence on "physical proximity" grounds.

T BensonOctober 17, 2017 1:31 AM

@sitaram complacency is not a good word to describe efforts to deal with this issue.

Everyone is trying to figure out how to do their part to mitigate this problem. The issue now involves every cell phone, every device, ...every IoT there is. In my zone, we only have to check known cell phones, laptops, tablets, and ...whatever else we've forgotten to think about, but also whatever is outside the gate trying to get in. God help the Enterprise network or large industry Wifi locales.

Physical proximity appears to be a key component here, at least for now. Don't dismiss the simple solutions.

best,
T

T BensonOctober 17, 2017 1:49 AM

Lightening it up a bit---as Blogs get kind of Loyal and fierce and argue over some dumb things sometimes:

"You don't Pull on Superman's Cape,
You don't spit into the Wind,
You don't Pull the Mask off an ole Lone Ranger,
and you don't mess around with
CLIVE

WaelOctober 17, 2017 1:55 AM

There were some weaknesses with the 4-way handshake protocol that were known a while back. I remebner reading about them a few years ago.

these attacks require physical proximity: An attacker on the other side of the planet can't exploit KRACK, only an attacker in the parking lot can.

Seriously? I would think could use an RF amplifier, a good line of site location say 5 miles away with a good ~ $50 parbolic antenna. I don't need to be at the other side of the world. I just need a good line of site. Sounds like an interesting project to work on. I think they'll be some modifications needed, though.

Or if you are working on a small budget, just remove that tinhat foil you're wearing and put it to goos use.

@Anon,

Now the for the question to which we all want to know the answer: how the heck did this happen, and why was it never spotted until now?

Because it was not meant to be.

WaelOctober 17, 2017 2:14 AM

@Grammar Nazi,

It's just hard to focus on brilliancy when it looks like it's written by a teen on a phone.

Fix your own grammar first! And why is your name "Grammar Nazi", if you're complaining about spelling? They are two distinct things, you know! It's hard to focus on logic, when it looks like it's written by a person sitting on a half-life aluminum bedpan, blowing spit bubbles!

Corsaro_cs001October 17, 2017 2:28 AM

@ Anon @ T Benson

KRACK attack is a client-side attack, so only clients or APs that work like a client (using them in repeater mode or using 802.11r) are vulnerable.

From KRACKattack's Q&A section:

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.


T BensonOctober 17, 2017 3:13 AM

@Corsaro_cs001
thanks, that helps me. I admit that I wouldn't know how to disable 802.11r without googling, but the priority seems to be clear--update the devices that connect to the network FIRST.

I'm afraid I'll brick the router if I do the update. Maybe in this case that can wait a bit, as I focus on the Client side. Also have not yet seen any updates for this issue for my router.

Thanks again! Appreciate the help and clarity!

handle_xOctober 17, 2017 3:54 AM

"And why is your name "Grammar Nazi", if you're complaining about spelling?"

Pedants unite! Form of : Irony!

Marc EspieOctober 17, 2017 7:39 AM

One crazy crazy fact about this attack.

Original paper was submitted May 19th.

May 19!

CERT have sat on this attack for five months.

How does this fit with reasonable disclosure ? this is a crazy delay.

Are there vendors who don't want to patch, no matter what ? Or is there some agency that had interest in keeping this under wraps, so that they could develop intrusion techniques based on it ?

Clive RobinsonOctober 17, 2017 7:40 AM

@ Wael,

Seriously? I would think could use an RF amplifier, a good line of site location say 5 miles away with a good ~ $50 parbolic antenna. I don't need to be at the other side of the world. I just need a good line of site.

I was thinking maybe a drone, or one of those planes owned by CIA front companies that fly funny routes above tech rich cities and areas, to get "a good line of sight".

Whilst it "might" only be the client that can be got at directly with this attack[1]... The thought occurs to me that once you've got a toe hold on the client you can then use it as a stepping stone out again onto the network...

The problem that I see currently is we have not had enough time to sit down and realy start "thinking hinky" about it ;-)

[1] As our host has been known to opinion from time to time "Attacks only get better with time".

BlutoOctober 17, 2017 7:41 AM

@65535:

> That is an interesting aspect. The UK want to keep the sheepeople under surveillance?

If an ISP wants to spy on its users it can do so upstream just as well...

It doesn't have to be nefarious, sometimes such equipment is simply part of the infrastructure. It makes sense to have standard equipment everywhere. Or to provide FTTB and offer routers with a FO port, because they're not common among end-users.

As a user, I actually prefer that the ISP provide and maintain FO routers, cable modems and such other highly specific equipment... as long as they keep them upgraded, allow you to disable or opt-out of the WiFi capability, and let you chain your own router.

Vincent L GambinoOctober 17, 2017 8:16 AM

@ Daniel
I can't address the first part of your question accurately without cracking the books, and as there are numerous others here who can skim it off cerebral cortex at will, and far better than I ever could, I won't waste my time (or yours.) Regarding your feature request for a distance-denominated signal strength setting on your AP, I would point out that signal strength at the client will depend on more variables than distance (e.g., when was your house built - what are the walls made of, and how thick?) I'm also not certain that the existing circuitry in most AP hardware would support that kind of modulation without extensive redesign.
-Vinnie

WaelOctober 17, 2017 8:55 AM

@Clive Robinson,

It makes interesting reading...

Yes, good information. They say it's an implementation bug, not a protocol bug as the original article mentioned, which might be the case. Doesn't negate the fact that there are weaknesses in the protocol.

The problem that I see currently is we have not had enough time to sit down and realy start "thinking hinky" about it

That's true. A weakness is like a hernia; it can't get better on it's own. It'll get worse, unless it's patched :)

@ handle_x,

Pedants unite! Form of : Irony!

Brilliant--but erroneous--observation! Form of : Cuteness!

Marc EspieOctober 17, 2017 9:22 AM

@Clive Robinson

Yep, I'm on a first name basis with Stefan.

Guess which project I'm part of, you've got one guess.

TatütataOctober 17, 2017 9:30 AM

Setting aside the implementation bug specific to Android et al, the way I understand the attack is that you need a supply of used keystream (from known plaintext) in order for it to work, which somewhat attenuates its gravity.

The site or the paper do not seem to delve into the practicalities of obtaining such a stream, and it doesn't seem too obvious how you could induce a juicy target to spew the beans from a drone or a windowless van parked outside.

You could have an accomplice on the inside, who may otherwise be unable to walk out with a USB stick containing the crown jewels, but could still serve his masters by performing a certain action at a certain time.

Another possibility could be a JavaScript payload on a trick page that pokes every IP address on the local LAN segment, until you find your target's MAC address, at which point you start shoving known data to it.

I think internet public access points at cafés and suchlike are more dangerous (especially if you're a hipster).

I was at a public library the other day, and tried saving a locally available resource to my disk. The PDF writer I was looking for was buried in the printer list in literally dozens of mostly Apple laptops advertising their available resources. Since the routers allow clients to communicate with one another, acquiring a a decent amount of keystream before you periodically resetting their WLANs shouldn't be difficult.

The prize on corporate networks wouldn't be the theft of your access credentials or your squeeze preferences, but resources within the moat, i.e., SMB and NFS servers, Lotus Notes databases, etc., where link encryption is mostly an afterthought. A state actor engaged in industrial espionage would go the extra length to access these.

The video mentions a certain spoofed message which is normally sent by the AP to redirect the client to a new channel. That sounds like a vector for a DoS attack. Application: improve your connection by throwing the hipsters off the channel.

JamesOctober 17, 2017 9:50 AM

Just a heads up for anyone in this thread who is using a stock ROM for android on an older phone and doesn't receive security patches often - I recommend switching to LineageOS. This bug has already been merged into all branches and patched for all builds dating past the 17th of October.

https://download.lineageos.org/

Who?October 17, 2017 11:00 AM

@ Why-Fi

Am i the only one who thinks we need a WiFi Protocol Competition ASAP?

No, I am sure you are not alone. However, with due respect, I do not think we need a Wi-Fi Protocol competition. We need Wi-Fi adopting well-established standards, no more cool in-house protocols that are breakable before the first units implementing them arrive to the market. This technology should take well-known and field tested protocols and encryption algorithms. It should be easy adapt them to the world of J. Clerk Maxwell.

DD-WRT KRACK Upgrade BenefitsOctober 17, 2017 11:51 AM

I've upgraded my modems DD-WRT 1200AC firmware to stop the KRACK WiFi malware:
ftp://ftp.dd-wrt.com/betas/2017/10-17-2017-r33525/

After rebooting I also enabled the new DNS-Crypt feature and selecting a server within the country.

The important concept here is the entire home network is open-source 256AES encrypted when using the Internet.
This implies no VPN client software on any computers (a piecemeal approach which I’m uncomfortable with).

Erik CarlseenOctober 17, 2017 12:52 PM

As a few others have pointed out, the notion that it requires an attacker to be in physical proximity shows a real lack of imagination. That the attacker must control a device with Wi-Fi capabilities within range is more correct. Now kick back and consider how many pwn3d devices there are out there. Then consider that unpatched Linux devices are susceptible to packet forgery (manipulation, injection, etc.), even if aes-ccmp is being used. Then consider that most IoT devices run Linux and will never be patched. Such devices include WiFi-enabled:
* Anything running Android that’s more than a year old, and at least half of everything else running Android
* Printers and copiers - lots of these out there!
* Handheld scanners (warehouse / retail environments)
* Point-of-Sale systems (very common now in small businesses)
* VoIP phones
* Streaming media players (Amazon Fire, Roku, Google ChromeCast, etc.)
* Gaming consoles (not XBox or PSx, but some of the cheap ones)
* Smart home devices (thermostats, lighting, refrigerators, doorbells, etc.)
* Smart televisions
* eBooks
* Security cameras
* Medical devices
* BYOD becomes an even bigger problem
* Any industrial control equipment running Wi-Fi – we can barely get them to stop using Telnet, for crying out loud.
* Heck, our NetScout Wi-Fi troubleshooting tool runs Android, so until it's patched it doubles as an attack vector when in use. :-)

Controlling a Wi-Fi-enabled device within range of one of these devices is almost as good as having a wired connection into their network. This is potentially the ultimate lateral attack platform – you can not only attack the home or office in question, but other homes or offices within KRACK attack range. Considering the Wi-Fi density in many urban and suburban areas, there are a lot of potential avenues here.

meOctober 17, 2017 1:06 PM

> "Go end-to-end or GTFO."

This. If you're not already operating as if everything beyond your network interface is hostile, you've already lost.

Eric SangerOctober 17, 2017 1:20 PM

Strange thing hardly anybody mentions is, that in accordance to get the needed MITM position you got to jam the AP. Not a trivial endeavour for several reasons ...

MikeAOctober 17, 2017 1:32 PM

Three issues for me:

1) "local attack" is, as others have mentioned, not so reassuring when I have 8 APs showing up as I type this. Three with obviously default names, and one xfinitywifi with no security at all. Once some script-kiddie hijacks one of my neighbors, can't they subvert their WiFi to attack mine? And, oh, look, the current ads in the throwaway newspaper are full of no-name APs and repeaters.

2) VPNs are only a partial solution. When I try to access gmail via VPN, it _very_ often coughs up a lung and complains about the new IP address.

3) My paranoid side can't help but wonder what other "enhancements" from the vendor's point of view will come bundled with that urgent security update. Every update from Apple, and many from Canonical both "giveth" and "taketh away". Dunno about MSFT, as I don't let my (few) Windows machines on my wired LAN, let alone my WiFi.

Clive RobinsonOctober 17, 2017 1:52 PM

@ Wael,

Doesn't negate the fact that there are weaknesses in the protocol.

Ambiguities in the protocol certainly.

One of the problems people exhibit when writing protocols theses days is "they don't walk the states" or worse have undefined states.

The other thing people are not doing is defining how things will fail and importantly when, and what to do with unexpected or out of order state changes, which leaves open windows of opportunity that can be exploited by someone "close in".

Even the simplest looking protocols can have temporal holes that a thoughtful attacker can use. Which means designing them can be hard work.

@ Marc Espie,

Guess which project I'm part of, you've got one guess.

Now let me think... ;-)

I thought your name was familiar, keep up the good work, there are a lot of people who read this blog who have benifited from yours and the other team members work.

As for the long disclosure date, like others I'm of the view the shorter the time a vulnerability is open the better.

As for "government agencies" needing time... What can I say that's printable, something about left hands and right hands springs to mind especially when they sit on both.

Clive RobinsonOctober 17, 2017 2:02 PM

@ AJWM,

It could have been noticed over a decade ago, for all any of us know.

And you get the cigar for why I think the "fix/disclosure" window should be short not long.

Especially if you take the viewpoint that the likes of the SigInt agencies such as GCHQ, NSA etc are happy to pay millions to their staff to analyse protocols for weaknesses thus potentialy be a decade ahead on the "noticed"...

JeremyOctober 17, 2017 2:15 PM

Nicholas Weaver is saying that normal people don't have to worry, but it SOUNDS like his reasoning is essentially "you probably chose a stupid, easily-guessable password anyway, so you were already defenseless even before this."

That's disturbing on several levels, but setting that aside, it prompts an actual technical question from me:

I was under the impression that the wifi password was there mostly to stop people from stealing your bandwidth; Bruce at one point was advocating using no password in order to allow neighbors to share your bandwidth if they want.

But this comment seems to imply that anyone with your wifi password can easily eavesdrop on all the traffic on that network, and even impersonate other devices on the network in order to inject traffic. Is this true? Why wouldn't every device on the network be using a unique session key to communicate with the router?

Clive RobinsonOctober 17, 2017 2:29 PM

@ Eric Sanger,

Strange thing hardly anybody mentions is, that in accordance to get the needed MITM position you got to jam the AP. Not a trivial endeavour for several reasons ...

Whilst I agree it's not trivial to do you don't have to fully jam the AP or client receiver.

You can also gain advantages by exploiting distance in various ways.

As I've mentioned before if it's possible within the laws of physics, then someone will get around to trying it. In the US in the past they have tried to suppress such information in various ways if you look at the history of TEMPEST or more recently EmSec you will see what they have done so presumably will do.

This makes it difficult to discuss these aspects in an open way especially on a US based blog.

WaelOctober 17, 2017 2:34 PM

@Clive Robinson,

The other thing people are not doing is defining how things will fail and importantly when

Security Principle violation at the implementation level. "Fail Safe", hard and fast?

DanielOctober 17, 2017 3:18 PM

@jeremy writes, "But this comment seems to imply that anyone with your wifi password can easily eavesdrop on all the traffic on that network, and even impersonate other devices on the network in order to inject traffic. Is this true?"

Yes it is true. There is a handy little program written more than a decade ago called SSLStrip that performs this magic. In effect a person performs a MITM attack on the LAN. In fact, if you watch the video closely SSLStrip is the program that the guy who discovered the vulnerability uses in his demonstration.

Once this hack gets coded into aircrack and the new version of aircrack gets coded into Kali Linux a person will need to push two keys to take possession of an unpatched device. Ok. Ok. push two keys is an exaggeration, I am sure. But not much of one. It will become a trivial exercise.

As for Bruce's comment, my guess is that what he was addressing is plausible deniability. If you run an open network that everyone can connect to then when the police come looking at your IP address they don't know which of the hundreds of people who connected is the guilty party.

Whether to turn encryption on or off on a local wifi network depends on your threat model. If your threat model is someone running a MITM attack on the LAN then it is better to encrypt the network. But if your threat model includes the police, maybe it is better to run the network open so to maintain some semblance of deniability. If your threat model includes both then you have a tough choice to make.

WaelOctober 17, 2017 3:20 PM

Something really puzzles me.

If it's an implementation bug, I would think it would apply to an OS or two. But all of them? Is code-cutting this prevalent?

If it's a specification or protocol bug then I understand. But an implementation bug on all these Operating Systems and embedded systems too? Steeeeeerange. I say it's a deliberate feature. :)

Marc EspieOctober 17, 2017 4:32 PM

@Why

Giving at least 12 notice weeks to work on the problem before announcing is a good enough compromise between the conflicting needs of swiftness and stability, especially if there's no indication that it's been exploited in the wild.

@Tatütata
The code is apparently still being worked on, the changelog linked above shows several new changes (commits and mods) made just in the last few hours.


obviously, the length of notice is not that relevant. Seems that 12 weeks is still not long enough. some people waited until disclosure to work on a patch.

That's always the case, and a long standing problem.

Most vendors out there will only fix security issues when pressured, and often after the cat is out of the bag.

Not being ready after two weeks on a problem of such a magnitude makes zero sense.

Besides, you can't embargo a security disclosure for twelve weeks without any leaks. Don't tell me you trust everyone who was informed of the issue.

So, patching early, even silently, is the way to go. Because once you've been informed of the issue, other people have been informed as well, and the clock is ticking until the bad guys know about it.

Anticipate Attacks and Take ChargeOctober 17, 2017 5:19 PM

IS any smart-phone ever secure? Are they typically compromised? Are they a security threat when connected to any secure/wired network?

Just drive down neighborhood streets at 2am and infect the clueless wireless morons (95%) who are always connected.

Comprehensive Solution
DD-WRT operating system allows router/modem owners to isolate Wi-Fi devices from each other AND from the regular wired network.

Those Who Know
Big data engineers strictly limited Internet access at home. Attacks are most effective while people sleep (ok they are only half-there at ANYTIME due to smart-phone addiction).
Some have a timer to power-off the HIGHLY un-secure ISP modem while others use a wireless remote A/C switch.

Paying the Price - Following the Crowd
The dual processor 1200ac modem was $50 refurbished last year. Now the price jumped to $140.

The Internet is so unsecure I've reverted to writing paper checks or pay over telephone. In most cases Google Analytics blocks payment while web-site owners remain clueless.

WaelOctober 17, 2017 6:00 PM

@Grauhut,

And fun for at least one IoT life cycle! :)

Must be eons! Ice age, Iron Age, and the longest era of them all will be IoT age. Medical devices? PnP: Plug and Pray at this point. Just like a lottery tocket, but in reverse odds. Everybody’s a winner except for the poor soles that get their hearts KRACKED... such a shellshock! My heartbleeds for them!

TatütataOctober 17, 2017 6:20 PM

Sheesh... Three different messages sent under different pseudonyms that proselytise for DD-WRT... Aw, come on...

But it's the client and not the AP that is targeted by the attack. Furthermore, there are many decent commercial routers out there out there that offer proper management functions, which wouldn't help THAT much here.

I also happen to have recent first hand experience with DD-WRT, and I was somewhat disappointed by its quirky, non intuitive, user interface, and intermittent problems on the wireless interface for which I don't have an explanation. And some choices are purely arbitrary, e.g. why should MAC addresses be partially masked on the status page, when they're absolutely needed elsewhere for configuration. Don't tell me it's a question of Datenschutz.

I'm planning to migrate to LEDE, once the implications of the reconciliation with openWRT project from which it had been forked become clear, and after the dust will have settled on the Krack updates. I don't want to update too often, for fear of bricking my hardware.

A FOSS router might nevertheless be useful for running a daemon that monitors the lower protocol layers for anomalies, which could help protect unpatched devices. The router itself might also run tests checking for vulnerability to the attack, and either issue a warning or outright refuse association with the device.

That would be better than nothing.

But there is still less to be worked up about than with Heartbleed or the "bash" privilege bug.

65535October 17, 2017 6:25 PM

@ Bluto

"If an ISP wants to spy on its users it can do so upstream just as well..."

That may be true in the UK. But, in the states there wire tapping laws that would hinder ISPs from doing so. Wire tapping is illegal in the States without a warrant [in theory].

Yes, Fiber to the building or house is golden. But, I have found most Fiber plans from ISPs to be expensive and contain a number TV channels that I will never use.

@ Wael

'I would think could use an RF amplifier, a good line of site location say 5 miles away with a good ~ $50 parbolic antenna. I don't need to be at the other side of the world. I just need a good line of site.'

That is a good comment. That was the question I was asking in my post. Great minds think alike... and all

@ Clive

'I was thinking maybe a drone, or one of those planes owned by CIA front companies that fly funny routes above tech rich cities and areas, to get "a good line of sight".'

That is a thought. In the states we constantly have drones flying over border areas. They can be heard by their relatively fast spinning propellers high in the sky. Drones have been in heavy use for 7 to 10 years. This may explain why the exploit was not disclosed... may be.

@ DD-WRT KRACK Upgrade Benefits

Good comment.

@ Erik Carlseen

"...requires an attacker to be in physical proximity shows a real lack of imagination. That the attacker must control a device with Wi-Fi capabilities within range is more correct. Now kick back and consider how many pwn3d devices there are out there..."

That is an interesting extension to this KRACK hack.

@ Marc Espie

"Most vendors out there will only fix security issues when pressured, and often after the cat is out of the bag."

Good comment. Sad but true statement.

@ Daniel

"In effect a person performs a MITM attack on the LAN. In fact, if you watch the video closely SSLStrip is the program that the guy who discovered the vulnerability uses in his demonstration. Once this hack gets coded into aircrack and the new version of aircrack gets coded into Kali Linux a person will need to push two keys to take possession of an unpatched device. Ok. Ok. push two keys is an exaggeration, I am sure. But not much of one. It will become a trivial exercise."

Nice comment.

That is somewhat like the question I was asking. I wonder what hardware and software combination the researchers were using to prove their theory. I would like to duplicate the experiment and see how feasible KRACK is in reality.

tdmOctober 17, 2017 11:59 PM

this from a "common" user:

1. several mentions of this exploit state that this vulnerability exist only when a bad actor is within physical distance of the wpa2 device signal. Not enought specifics are given for common users to understand that this does include not solely using public wifi spots such as cafes but also personally owned "home" gear, where the distances traveled by any standard 2.4 signal may well be in excess of 100 meters or more. Even more important are those home users who are in densely populated neighborhoods. I think is would be best to encourage all users of ANY wpa2 device to cease and to turn off wifi routers and devices until they apply firmware to fix the issue. Whether users will heed this advice of course, is questionable. But it would be the correct advice.

next, is another confounding issue also related to security and wifi devices that really need to be exposed. i will give a personal example.

I own two TP-link consumer products, archer c9 ac1200 and a wifi usb adapter (T4u).

As soon as I read about this vulnerability, I turned off the wifi switch on my C9 router and removed the T4U adapter. I also turned off wifi features on all of the android phones used in the house (two one plus devices, a chrome cast device, and some other silly IOT "toys")

Then I went to the TP Link website to locate any firmware updates to fix this vuln.

Here is what I found, and none of it was good.

A. TP LINK is investigating the vuln. THey have not released anything yet. That isn't very suprising. I suppose this will take some time to release them. But the glaring problem is that TP LINK has chosen not to even mention on any of its web site pages that this vulnerability exists. I did the chat thing, and got the standard mill. We are working on it. That was two days ago. Still, no mention of the problem.

B. In a security advisory page at TP LINK is an important notice that they are aware of non-official TP link websites. Apparently, there has been an effort to confuse users into wandering into websites that appear to be official. And so TP link has chosen to raise this issue. But here is the problem with that: the main official website is not https at all. So, how can one reasonably assume what the official website is at all, without this important check. ? Crazy right? it gets worse...much worse.

C. Now, I am looking at the support page, looking for the most recent drivers and firmware. Again, these pages are served as regular http public, read plain text, open...nothing secure. arggh. it gets much worse. You filter down to your appropriate driver and firmware and utlity and there is no hash checking file to verify file integrity. Nope, that also does not exist!

so, in my particular situation, what I find, is that not only has my router vendor not chosen to be open about the vuln, but they also serve drivers and firmware out in the open, with no means for the end user to verify file integrity. I suppose that is why my windows nags me that unknown application popup when I go to install the drivers.../s

I am posting this, for some advice actually.

In this situation, what advice can anyone here offer?

DigestizeOctober 18, 2017 12:07 AM

While it is a brilliant find, I believe the news media is overreacting to the threat it poses. It is not a serious issue where we need to replace WPA2, rather we simply need to patch our clients to stop key installation. You can find a quick summary about it here: https://goo.gl/oc3sfG

tdmOctober 18, 2017 1:39 AM

"Another possibility could be a JavaScript payload on a trick page that pokes every IP address on the local LAN segment, until you find your target's MAC address, at which point you start shoving known data to it"

- quoted from Tatütata

Actually, one only has to be an owner of a One Plus smart phone to have your target MAC address (and much much more) stolen from you..in plain sight, even. (to be fair, it was brought to my attention that the company below is not in isolation over stealing critical security data from its users, sigh..)

but anyway...check this out:

Or, as recently uncovered by chris moore, a security researcher, if you happen to be a One Plus smart phone user, the company has been found to be collecting secretly the following data from you:


OnePlus is collecting sensitive private data like IMEI numbers, mobile network names and IMSI prefixes, MAC addresses, and more. He (chris moore) discovered that his OnePlus 2 device was sending data to a HTTPS domain, which was transmitted to Amazon Web Services and belongs to OnePlus (open.oneplus.net domain).

I believe it was Verge that published first, but a quick search for chris moore+one plus will give you plenty of details about what he found.

sidenote: OnePlus has responded that they will "quit stealing" this data by the end of the month.

how charitable!

so, it doesn't take a classic bad actor to glean your data...all it really takes is a trusted vendor who secretly steals your data, and doesn't say anything about it.

if you care to examine this as a case, you may find it fits neatly into an overall pattern of many vendors that operate pretty much as hackers. of course, they will tell you this was in the interest of developing "after sale" product improvements...etc.

I learned my lesson on this..I can't really trust Chinese companies with important communications products. Well, certainly not One Plus.

and yes, One Plus deleted every single user opened post on their website that complained and asked the hard questions about this. You will not find any of the most detailed posts and hard questions on their website any longer. I just checked.

The fallout from India market (their largest market) I am told, was extreme. Apparently, this behavior has existed for well over 3 years. Noone really knows where this data was stored, if it was protected, or to whom and what parties it may have been shared or sold. We only have the word of Mr. Carl Pei, who assures us that is was securely uploaded and is solely contained within the parent company. Right...the confidence and trust in a company that steals this information without disclosing it, in the first place, evaporated. There is nothing really left, but distrust.

I give this company less than six months before it tanks.
Some claim it may not even make it before the expected delivery of its next gen phone in November.

I have made it my mission to post these facts about this company to any and all. I bought two of these phones of family members. Great price for awesome hardware and unlocked unbloated android.

Now, I understand why the cost was so low.

It's obvious now.

what isn't do obvious, but I am drawing the dots carefully, is that this kind of data, particularly the emac and other device serials are highly prized data for hacking activity.

I would not be surprised to find that this is somehow related to this Krack vuln exploit.

think about It...in terms that Tatütata suggested:

,,"until you find your target's MAC address, at which point you start shoving known data to it"

One Plus phones connected to wifi lan...sending that mac address (and god knows what else back to some private open.oneplus.net server...then gets routed back to AWS server...presumably encrypted.

the president has yet to explain at all, precisely what value or use, that kind of data has in "developing after sale improvements"..

I also have a serious doubt that this information was protected in isolation as he claims. In fact, if you read his response, it was as carefully massaged as any Hillary response you can imagine. and that took two days after the question came up. When you read his response, it read something along these lines, let me paraphrase:

"we WOULD like to announce we are discontinuing the collection of this kind of data based on the user complaints....we will continue to collect standard telemetry based on the common EULA agreement that allow One Plus to improve our customer experience"

we had the benefit of a few lawyers sit in that blog session and a linguist.

they both caught on to the clever "hillaried" response.

"we WOULD..." that can be taken to mean nothing really. it is more than a simple mistake when it takes a president two days to come up with a response..and this is what he delivered.

and ...that they would continue to collect telemetry data. This does not bode well with an already damaged reputation and distrust they created.

I watched over 400 unique users threaten class action suit. At the end of the session, it was obvious the ball was moving in that direction.

for me. it was simple..two tosses in the air, two shells in the 12 gauge..and two squeezes of the trigger. I call that gun control at its finest.

never do business with this company of any smart phone again our of china.

I know..that pretty much limits my choices to zero...

never going back.

Clive RobinsonOctober 18, 2017 3:53 AM

@ Marc Espie,

So, patching early, even silently, is the way to go. Because So, patching early, even silently, is the way to go. Because once you've been informed of the issue, other people have been informed as well, and the clock is ticking until the bad guys know about it.

There is another issue involved as well not just the clock ticking for the bad guys.

As we know our legal brethren are big on "best practice" when it comes to civil damages. Further they tend to go after those with deep pockets.

Thus a small and agile development team that makes a patch in a couple of hours and then gets it out very shortly there after, does not only it's customers/users good but other customers/users of other products good as well. Because the quick turn around makes a platinum plated gold rod for a legal type to beat the stuffing out of the large slow organisations that mainly exist because they play the monopoly/cartel game with patents and the like.

Which may be the reason the larger organisations etc have pushed for longer and longer disclosure periods, and as noted above rarely do a darn thing unless pushed by the knowledge being made public.

So as they say "Keep up the good work" digging away at the industry dinosaurs in all sorts of ways ;-)

jesisOctober 18, 2017 4:12 AM

+1 handle_x, sitarem, and others. Though perhaps that is unfortunately a level of nuance beyond the truly wide audience Schneier is targeting. Population densities mean that most average people in medium to large cities are living within range of 100 other devices. So if attacker on other side of the planet can manage to infiltrate any of those, there goes the physical proximity requirement.

OTOH my attitudes are evolving toward needing to see hard numbers and anecdotes of people effected by direct attacks. It may be that NSA sensor net is in range of everyone and detects all attacks, and it is really they who are responsible for who is victimized and how. Seems an outlandish theory, but... thats why seeing hard numbers on victims and attacks is important.

handle_xOctober 18, 2017 4:15 AM

"In this situation, what advice can anyone here offer?"

Get a better router if you're worried about it?

Clive RobinsonOctober 18, 2017 4:50 AM

@ 65535,

I would like to duplicate the experiment and see how feasible KRACK is in reality.

The problem is not how difficult it is currently, the question is how easy it will become once the tools have been made...

Mankind is a "tool making primate" our strength is that we are barely strong enough to survive. That is we had to learn to make tools or die out, and we got good at it. Somuch so turning moubtains inot islands in the sea to put airports on is just a matter of applying the right tools at the right time in the right way.

Untill recently our toolmaking ability was limited by the laws of nature as applied to physical forces and energy. Whilst that limitation still applies at the bottom of the computing stack, in most cases it's irrelevant. Even a teenager in his back bedroom can make tools in meer hours, all it takes is relevant experience, the ability to form ideas and the fleetness of fingers on the UI.

When my son was not even a teenager he got hooked on MineCraft, the speed he could build a complex building and gardens was frightening, it was like watching a wizzard at work. His interest was to use it as a CAD tool not a video game. He has since moved on to Kubernetes that even NASA use for training, and he's asking me questions even astrounautic engineers I know find hard to answer.

handle_xOctober 18, 2017 4:51 AM

@ jesis

I imagine Bruce was emphasizing that Krack needs local wifi access, not that it "can't" be done remotely with some additional cleverness. In that case you'd need to have already compromised something w/ wifi locally, that would require a separate vulnerability.
So if I'm reading his mind correctly he's internally consistent, not low-browing.

" thats why seeing hard numbers on victims and attacks is important. "

You won't likely in any real case see accurate data on that. IP sinkhole a botnet, maybe.

NSA have their own kracks and using them loosely on a widespread basis is a sure way to lose that advantage. Unless you're fooling around enriching something or have a botnet of your own or work on a strategic project, you really don't need to worry about the NSA because they really don't need to worry much about you. Chances are good they have a firm idea of what you're capable of hiding and decide you don't warrant a second look.
Anything you do is searched anyway of course by the xkeyscore robots.

Bet there are quite a few public revelations yet to be had about common net protocols.
Double or nothing the NSA won't be the one coming forward with them either.

handle_XOctober 18, 2017 5:26 AM

@Clive

"Untill recently our toolmaking ability was limited by the laws of nature as applied to physical forces and energy."

That limitation falls away entirely when we put AI in the place of human beings.
At that point the distance between virtual and physical will be negligible.
You can see how that's a dangerous prospective reality. Zuckerberg can't.

Inherent in tools of man is the potential for harm by misapplication of them.
Those include dependence - or war.

Put another way we've built impressive toolsets to be increasingly at the mercy of.
More and more each day our artificial monetary construct focuses our efforts on this.
Without limit, without awareness, without any concern except that incrementalism.
At some point we've become the tool and "it" our accepted master.

Nobody has written any effective ethical subroutines for AI. Just what are we progressing towards? Powerful tools without the wise hand to wield them appropriately.
Mountains into non-mountains. Seas into non-seas.

TitiOctober 18, 2017 5:37 AM

To comment about "opaque IEEE standards process": I worked many years ago on the 802.11v implementation and what I saw was a bit scary.

In this amendment, IEEE wanted to implement a way to inform the user connected to an AP why the session was about to expire, and added a field in a management frame (which are sent in clear) containing an URL for this purpose. The Wi-Fi driver on the user device was suppose to make this URL opened by a browser upon reception... which means for instance that anybody with a very simple setup could walk in an airport and send forged frames to all users around, and have their browser suddenly opening a phising page "enter your credit card number to extend your session".

Even the related Wi-Fi alliance testplan at this time was requesting for a station to open the webpage upon reception of the frame to validate the 11v amendment.

Most of people working on this (and participating to WFA testplans and IEEE standard redaction), when talking to them, were only half convinced there was a security issue there.

I stopped working in this area so I do no know for sure the end of the story, but fortunately I remember that most of 802.11v was finally discarded by WFA for other reasons, so you will probably never find any implementation of this.

This huge security breach has however been included in the latest 802.11 revision of 2016. Check for "Session Information URL", especially at "11.24.7.3 BSS transition management request".

Other ref: "Wi-Fi CERTIFIED Passpoint Release 2 Interoperability Test Plan
Version 0.19.19" Table 108 "Verify that the STA provides notification to user and launch a browser to the received Session Information URL. If not, FAIL"

TatütataOctober 18, 2017 8:32 AM

@grauhut:

wpad - 2016-12-19-ad02e79d-5
hostapd-common - 2016-12-19-ad02e79d-5 "

Er, why is the year "2016"?

Anyway,

1) The dust still hasn't settled yet. And again, the router can't do much about this failure, except when it is working in infrastructure mode, which is relatively rare.
2) I have more urgent things to right now
3) Changing the WRT is a crap shoot, I have no garantee I'll be better off. In any case, the capabilities of the manufacturer's default firmware were well beneath those of my previous 10y old router, which came from the same supplier.

A user posted on the LEDE page you referred to a this link to an AVM Fritz! press release that concludes with a polite criticism:

AVM hat von Krack am 16. Oktober Kenntnis erlangt. Das für solche Fälle vorgesehene Responsible-Disclosure-Verfahren wurde von den Entdeckern der Lücke leider nicht angewandt. AVM wird nach weiteren Untersuchungen und Tests Updates für WLAN-Repeater zur Verfügung stellen.

My translation:

AVM became aware of Krack on 16 October. Unfortunately, the Responsible Disclosure mechanism which is foreseen for such cases wasn't applied by the discoverers of the vulnerability. AVM will supply updates for WLAN-repeaters pending further tests and investigations

ModeratorOctober 18, 2017 8:57 AM

@DD-WRT KRACK Upgrade Benefits, @Anticipate Attacks and Take Charge, and @Reference Link, please use a single handle when participating in a discussion.

802.11October 18, 2017 10:12 AM

@ Jeremy

Every device creates a unique Temporal Key for encryption with the AP. However, each of these keys, when using the Pre-Shared Key/Password, is generated from the same source, the same PMK. The only difference is from the other non-secret materials added into the Key Derivation Function. These are nonces sent during the 4-way handshake and MAC addresses of the client and AP. That means if you already have the PMK (so having the password suffices) you can arbitrarily get another clients Temporal encryption key. If you are using an 802.1X/EAP implementation, each PMK generation is unique and generated from a TLS process (if any Wifi Alliance tested method but EAP-SIM or EAP-AKA are being used) between the client and authentication server.

DanielOctober 18, 2017 10:26 AM

Steve Bellovin has this comment up on his blog discussing remote KRACK attacks.

https://www.cs.columbia.edu/~smb/blog/2017-10/2017-10-16a.html

"I'm not certain how serious this is in practice; it depends on the proximity of vulnerable wired computers to interesting WiFi networks."

I have two thoughts about this comment. The first is that proximity is a function of population density. In other words, in a rural environment the 100 meter range of the average wifi router poses a real physical constraint, in a urban environment it becomes much less of a limiting factor. My second thought is that interesting networks are in the eye of the beholder. On one hand, if the attacker is a fraudster who wants to steal financial credentials then interesting becomes a synonym for wealthy. On the other hand, if the attacker is a malcontent who wants to hide his ip address in order to make a VOIP call to the police to swat someone then interesting becomes a synonym for any available network. It is this latter group of riffraffs who I think will benefit most from this attack because it will reduce the barriers to entry.

TatütataOctober 18, 2017 12:20 PM

Several stunts were described on this blog over the last few years involving the MIMO channel matrices, e.g., for spying on the fingers of a user typing on a keyboard.

I'm very sceptical about the practicality of these attacks.

However, detecting an intruding MITM, even if just for forensic purposes, appears to me well within the realm of the feasible for the garden variety router. Channel parameters such as RSSI would jump drastically when the MITM attempts to impersonate another client, and comparing the weighing matrices for the different clients would show when one should attempt to impersonate another. Correlating this info with the crypto handshake could result in a log entry.

The AP could also ping the clients, and keep track of the roundtrip delay, which shouldn't be difficult to measure especially if you send long frames.

A notional drone flying 5km away would imply a 33µs roundtrip delay to the AP. Double that if it's acting as a MITM. But could such a drone carry a decent directional antenna allowing it to pinpoint both AP and client in a given installation in some metropolitan area? The area within omnidirectional range of a notional drone flying 5-miles (8km) is of the order of 200km2.

handle_xOctober 18, 2017 1:14 PM

@Daniel

"I'm not certain how serious this is in practice; it depends on the proximity of vulnerable wired computers to interesting WiFi networks."

That catches between ear and brain on me also.

"I'm not certain how serious Ebola is in practice; it depends on the proximity of infected people to soon-to-be-infected people."

802.11October 18, 2017 2:19 PM

@Tatütata

Going by the paper, the MITM occurs on a different channel, not the channel the original AP is on. The AP wouldn't typically be scanning other channels unless it had some built in WIPS sensor feature.

TatütataOctober 18, 2017 2:57 PM

Going by the paper, the MITM occurs on a different channel, not the channel the original AP is on.

But the MITM will nevertheless communicate with the AP on the original channel.

802.11October 18, 2017 3:31 PM

@Tatütata

I don't see the impact of that, the client for this attack is switched to the channel of the MITM AP. The ping time would be negligible. I don't see it really distorting RSSI values for the AP either. But I may be missing something.

handle_xOctober 18, 2017 3:53 PM

IIAUC= if I am understanding correctly there's a passive way to accomplish this attack

The difference between impersonation and eavesdropping.

Single Handle - Remember personal info?October 18, 2017 3:58 PM

If your modems hardware is capable, the DD-WRT operating system will allow the user to set the Wi-Fi transmitted power levels from 1 to 100%.

The professional modem reviewers ALWAYS have the mindset more power and greater distances is beneficial. This coincides with Big-Data push for wireless everywhere. The end result is frequently over-saturated RF power in the neighborhood. This generates interference and may increase health risks. Hopefully the public can deduce too that much power also increases the security risk.

The handwriting was on the wall when Google mapping vehicles were caught in many countries slurping-up WiFi MAC address, passwords and indexing to GPS coordinates.

In my house the ISP modem wireless is ignored and the DD-WRT OS modem power is set to 1%. The RF signal quality still measures at least good with the free tablet Wi-Fi signal analyzer program.
To managing the RF spectrum, I try not to purchase devices where the Wi-Fi transmitter cannot be disabled. Removing antennas may further help.

The future looks worse as (the champion of privacy) Apple has recently made disabling Wi-Fi and Bluetooth difficult: wherever you go you will be tracked and possibly hacked. Good one Apple!

GrauhutOctober 18, 2017 3:58 PM

@tatütata: "AVM became aware of Krack on 16 October. Unfortunately, the Responsible Disclosure mechanism which is foreseen for such cases wasn't applied by the discoverers of the vulnerability."

Yes, would be nice to know if US-CERT informed CERT-BUND. :)

another_openwireless_fanOctober 18, 2017 6:20 PM

What's wrong, or good, with this setup with two routers ("'r'"), for a home or small business. r-isp ("'internet service provider'") is hooked up to the internet, of course:

r-isp --- r-purchased (double nat)

r-isp has nat and no wifi, afaik

r-purchased has WPA2 ssid "'encrypted'" which was given a 30 character strong password. In addition; the wifi ssid encrypted is never used; think of the the 30 character password for encrypted as being thrown in the trash.

Several production PCs (configured in a relatively paranoid mode) are wired with ethernet to r-purchased.

Is this setup relatively secure against Kracked. 60 people +- use ssid openwireless.org on an ongoing basis with the following proudly displayed to anybody in the area:
https://openwireless.org/important-information.html
some routers with guest networking
https://openwireless.org/routers.html
openwireless.org's home page
https://openwireless.org/

more on open wifi
https://www.schneier.com/blog/archives/2011/04/security_risks_7.html

and finally, to quote Bruce below from 2008 "This is not to say that the new wireless security protocol, WPA, isn't very good. It is. But there are going to be security flaws in it; there always are."
https://www.wired.com/2008/01/securitymatters-0110/


T BensonOctober 18, 2017 11:58 PM

So,
While you Experts ramble on about all the potential nightmares or lack thereof, and wax philosophical about the Universe of Security in General....some of us are trying to figure out best modest behaviors to help stave off a full scale attack on our local networks. Just basically how to lock the door for the moment, if that is all we have.

Did you hear that I am quite annoyed by your arrogance and less than forthcoming straight talk? Pompous arrogance does not usually result in increased Security and safety.
How impressive your useless intelligence is!

So Bimbo Dip that I am, I recommend to most:

1. Change your Router password to force an identification of who's coming in and who needs your Router.

2. Edit your Router MAC table rules and allow in only devices that you know to be legit. I know, I know, this can be a bitch trying to track it all down and deal with complaints--so BE IT. In the hopes that this feature works as advertised: add MAC addresses to your allowed devices and lock out any others. And good luck because all these companies lie like hell and their software interfaces suck on logic.

3. Check your System Logs and see who's attempting to connect. Did you forget anyone important? Or is there a bugger out there hounding your network?

4. Go ahead and waste time changing your laptop and tablet passwords: probably has no effect at all on this problem, but you are used to this dumb advice by now, and honestly, when is the last time you changed those passwords?

5. It's time. You need to review your STUFF. Do you have STUFF that should be deleted or encrypted? Do that NOW.
Do you have STUFF that should be just GONE? Do THAT NOW. Your Mom should never see that Stuff.

6. I got tired, I'll be back tomorrow to remind you to do the other stuff you should do right now, but why in the hell aren't all these experts reminding you of that right now? They are the Experts right?

Been doing this for 30 years, but still not useful, : I'm a woman.
Clean up your crap and check your logs, and check the logins and sys logs,
good luck ya'll.

Single Handle - MAC Filtering SuggestionOctober 19, 2017 9:44 AM

@T Benson
I appreciate your expertize and suggestions. No longer is it sufficient to create just Virtual Wireless Access Point to keep devices isolated from each other and from the wired network.
I just explicated added wireless MAC ID filtering setting ‘Permit only clients listed to access the wireless network’

The 2.4 and 5Ghz ‘real’ networks have zero MAC address listed so NO device can connect. Nice!

On the first 2.4 virtual network only the Android smart-phone. Too much of a risk with Google, Samsung, Verizon present.

On the second 2.4 VAP reside the two Fire tablets (no need to isolate them from each other).

This DD-WRT AES 256 encryption also prevents AT&T ISP from deep packet inspection. Whew!

I share your pain and frustration too. Thanks!

Crazy Note: Did not Microsoft forcibly share wireless passwords on Windows 10? ...

SomeoneOctober 19, 2017 9:48 AM

So the slender young masked man in phone rep attire who was running a leafblower in the full parking lot yesterday for a surprisingly long time, walking between cars, might have been up to no good?

I love these security warnings, especially when it's entirely unclear what a person can do about it that would make the situation better.

802.11October 19, 2017 10:31 AM

@TBenson

People discussing and trying to understand a serious vulnerability on an information security blog isn't arrogance, it's the point of the blog. To properly defend against it, we need to understand what IT is.

The best way to prevent this is to see if your device manufacturer has made an update, and update it. I know Mikrotik, for example, patched this months ago. For things like android, and honestly this should apply always not considering this event, avoid using wireless networks that aren't our own for anything sensitive like banking. Other networks are best for looking at cat videos, and not much more. Luckily, Mac and Windows aren't susceptible to the majority of this exploit.

1. This is a generally good suggestion anyways, but this attack works without knowing the password. It abuses a flaw in 4-way handshake implementations.

2. Mac Address spoofing is trivial, this isn't recommended unless you have legacy devices, say old barcode scanners.

3. Good advice if possible. But refer to 2, since identification relies on the MAC address. This also depends on your wireless network. If you only have the same 10 people logging in every day, this is more possible. If you have a larger network with new users or devices who normally join, forget about it.

4. Changing passwords is scary. Honestly though, this isn't that relevant to this attack.

5. I don't see how this is relevant to this attack

GrauhutOctober 19, 2017 12:13 PM

@Wael: 11. commandment!

I cannot confirm or deny that i own wifi equipment but if i had some it would be clean... :D

WaelOctober 19, 2017 12:23 PM

@Grauhut,

I cannot confirm or deny ...

Ten-Four! 10 points for you if you tell me why LE use the expression "I cannot confirm or deny ..." ;)

GrauhutOctober 19, 2017 12:34 PM

@Wael:

Glomar, or glamor, that is the question!
And, hypothetically,
if such LE were to exist,
the subject matter would be classified,
and could not be disclosed! :D

WaelOctober 20, 2017 2:03 AM

@65535,

That was the question I was asking in my post.

Proximity isn't such an insurmountable barrier. I’m surprised to see it presented as such... parabolic antennas / RF amplifiers aren’t the only method to overcome it!

Clive RobinsonOctober 20, 2017 1:21 PM

@ Handle_X,

You can see how that's a dangerous prospective reality. Zuckerberg can't.

The problem with Zuckerberg and his ilk is that they have created not just a "bubble market" but a "faux market" as well.

Analysing PII etc after all the mumbo jumbo is just "signal processing". That is you are trying to find a signal in noise. The main difference is they have no idea what the signal is...

This is the problem they are trying to use AI to solve. Overly simply you have a silo of data from which you randomly fill three or more buckets you then come up with an idea and you then analyze the data to find an indicative signal. You then test this signal on another bucket of data. If it works then you have an increased confidence in the rules the AI has come up with.

However these rules often lack what we would consider "logic". Back in the 1980's I was involved with the development of an infrance testing package that was called HULK for Helps Uncover Latent Knowledge. HULK as released only tested user supplied rule sets. However as part of the testing we came up with random rules that we thought were silly and tested them on data sets. As a result of this we found there was a strong correlation between the price of gold and the state of the tide at Tower Bridge London... Which in turn was based on the phase of the moon. So we joked that metal traders were secret werewolves. We joked about this with a journalist of the time (Niel Gaiman) and the MD of the company told a Finacial Times Journalist that there was a correlation between the gold price and the phases of the moon. Guess what that stopped realy quickly.

The point is not only is AI trying to find signals in noise even with a high apparent correlation, there may actually not be one, just coincidence in a sub sample.

Sanity checking AI found rules is at least as hard as comming up with sane rules in the first place... Which is tely a game of "shift the problem"...

You have to get this working before you tgink about adding very hard concept rule sets such as "morality".

Personly I think that in most cases we are still just as far away from a Hard AI solution as werr in the 70's. However Soft AI systems based on human designed rule sets still appear to be bowling along as fast as ever.

65535October 20, 2017 10:24 PM

@ Clive

"Mankind is a "tool making primate" our strength is that we are barely strong enough to survive."

Maybe, but my scripting skills are at the bat file level. I used to do some java and php but those days are over. I tend to re-code that I find works well.

@ Grauhut

Thanks that helps. I got kali and I'll get the other parts and see what I can do.

https://github.com/vanhoefm/krackattacks-test-ap-ft/blob/master/README.md

@ Wael

'Proximity isn't such an insurmountable barrier. I’m surprised to see it presented as such... parabolic antennas / RF amplifiers aren’t the only method to overcome it!'

That would be my thought also. With Clive's drone idea and some poster mention being highly densely populated area with 100 or APs in range I can see the possibilities.


WaelOctober 22, 2017 7:19 AM

@65535,

Or spray a spider web with conductive spray, then connect it with a matched coax to your repeater. Better yet: feed the spider some carbon and nickel ...

ttsOctober 23, 2017 5:25 AM

What are the practical implications of the Krack attack when using a burned dvd or cd of the latest download of Tails, LPS, or Knoppix?

Clive RobinsonOctober 23, 2017 6:53 AM

@ Wael, 65535,

Or spray a spider web with conductive spray, then connect it with a matched coax to your repeater


Or...

Put up a Ferris wheel in a park a mile or two away and use it just like a Lens for RF.

Mad as this might sound it actually happened for real during the cold war. The ElInt/SigInt spooks in the British mission there noticed that for three weeks a year they got Russian military command signals from deep in the heart of Russia,that they could not get at any other time. These signals were an absolute gold mine of information and thus the hunt was on to find the "why for only three weeks". One member of the ligation had children and took them to the annual fair and as the kids rode the Ferris wheel the penny dropped.

There was then some real horse trading went on with the owner of the wheel but eventually they came through and the wheel stayed put for many years.

On another note the Hospital ward Im on should today be no longer blessed with my presence making the laugh and looking happy. As I'm due to be sent out into the cold cruel world, but now "Bluetooth Enabled after minor surgery. The other patients have been a tough audience but making them smile if not actually laugh has been achived. This has caused me to upset one of the nurses, one gentalman who had pipes connected to all sorts of places, laughed enough to drop the bag which was collecting "his water" and it spilled all over the floor.

But the sound of good honest laughter is like a fine wine on a warm summer evening, over looking a gentle rolling valley, it liftd the spirt and that alone is worth a tablet or three.

WaelOctober 23, 2017 7:26 AM

@Clive Robinson, @65535,

it actually happened for real during the cold war.

Fascinating story!

but now "Bluetooth Enabled...

Be careful who you get paired with!

and it spilled all over the floor....

@Clive Robinson, @65535,

it actually happened for real during the cold war.

Fascinating story!

but now "Bluetooth Enabled...

Be careful who you get paired with!

and it spilled all over the floor....

Man, when you lose your laugh, you lose your bag!

MarkHOctober 24, 2017 3:28 PM

When I tried opening krackattacks.com, my browser showed:

"A secure connection cannot be established because this site uses an unsupported protocol"

Too funny!

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.