Special gear isn't all that expensive. From a cursory view of the video and a skim of the paper, they're using hostapd, which means that they simply need a wifi adapter with a sufficiently-good driver. Anything with the RTL8188CUS seems to be pretty nice (that's what I'm using in a raspberry pi project, myself).

So - I agree with you that there's a barrier to entry, but it's not that big of a barrier.

Agreed. Not specialized equipment. Just something that lets you shoot raw frames and run as a WiFi AP. I have 2 such USB WiFi dongles in my bag for setting up such environments.

Give: http://www.tp-link.com/us/products/details/cat-5520_TL-WN722... a shot. It will let you setup an AP in a VM easily, etc. It is our currently anointed dongle for VM hosted MiTM setups.

I haven't tested it, but it should work fine if they are just using mods to hostapd.

Note that there are two versions of that dongle. The version 1 has Atheros Chip[1] with the best wi-fi support but version 2 has a Realtek chip[2] with subpar support. AFAIK it isn't possible to get version 1 of the dongle today.

My suggestion is Alfa AWUS036NHA (The last three letters are important!) which has AR9271 chip with great support with the ath9k driver.

[1]: https://wikidevi.com/wiki/TP-LINK_TL-WN722N

[2]: https://wikidevi.com/wiki/TP-LINK_TL-WN722N_v2

[3]:http://www.ebay.com/itm/ALFA-AWUS036NHA-802-11n-Wireless-N-W...

Hmmn, I wasn't aware. I will have to check and see, but it is probably I have a v1, since I have had it for a while. It has always taken a bit of effort and hunting to find WiFi cards with good chipsets that support monitor mode and AP modes painlessly (for WiFi frame capture, etc.).

Thanks for the info... I am a little disappointed, the ones we have been using are all very reliable and worked out of the box, so we must have the Atheros ones. It also seems impossible to order the older version specifically.

>It also seems impossible to order the older version specifically.

Yep. I've been trying for a while, but couldn't be sure if what I was looking at was version 1. Especially since the Alfa alternative is bulkier.

Arch Linux Wiki and Amazon comments are sometimes the best resources for hardware compatibility and reviews. Sort of amusing.

Also, confirming, everyone even as recent as a few months back seems to have gotten a 1.0 or 1.1 version, but newer ones are now 2.0

https://imgur.com/a/jcnbE (one from my bag).

On second read, timing requirements arent a thing if you are spoofing the network (obviously) so for that attack vector you don't need specialized hardware. (wont let me edit :( )

I do think it's an end-of-the-world type vulnerability, at least as far as Wi-Fi goes.

1) The paper claims confidentiality compromise allows the attacker to hijack a tcp connection: "allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data", this on all cases, even in the cases where it doesn't allow forgery (CCMP)

2) There's no such claim on the paper and according to the researcher, exploiting this on Android and Linux is trivial. Apparently also macOS. Did you see the video on their website?

3) There's no way for you to control this (apps, https stripping, for instance). Most importantly, there's no way for the average user to control this, short than using a VPN.

Again, as far as Wi-Fi security goes, seems pretty end-of-the-world to me. I don't think the huge attention this is getting is unwarranted.

Sky-is-falling is FUD:

The attack is a standard break exiting secure TCP connection and trick the target to re-create it to a host controlled by the attacker via arp poisoning or route hijacking. After that either convince target to accept a bogus cert or redirect to insecure connection. In the former case the issue is that browsers have way too many root CAs included in them and those CAs can issue certs for any domain; the issue in the second case is that users are not being paranoid enough.

That's not the attack at all. And there's nothing standard about it.

The attack is the fact that someone couldn't do this you're describing on any WPA-2 protected Wi-Fi network before, and now they can.

You have two school of thought here... optimist vs pessimist.

Remember that the attack affects mostly client implementations therefore still needs proximity to victim(s), this makes most of the end-of-the-world type scenarios impractical (they even state these on their QA) and leaves exploitation to direct/APT-groups alone.

Well I did mention it's "an end-of-the-world type vulnerability, at least as far as Wi-Fi goes".

I don't think it's a lot of consolation saying something along the lines of "Wi-Fi security is broken, but it's not so bad because it's Wi-Fi"

You should read "Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks" by Michal Zalewski to expand your universe on things you should be afraid pal.

Interesting book that can really burst your bubble on how bad things are and yet we are still here.

Yeah I've had 'Silence on the Wire' for awhile - brilliant book, although I confess I haven't ever been able to sit down and really read it end to end. But I'd say I'm familiar with the topics he talks about.

I'm not sure how that compares to the fact that WPA2 is completely insecure and trivial to decrypt on Android as "no, that is bad". Except maybe in a "well who trusts Wi-Fi security anyway?" to which I'd reply: "Actually, a lot of people. Including people on this thread".

I actually buy the argument that the RSA issue that affects YubiKey, that was announced today, is perhaps more important since it's harder to mitigate than using a VPN, but I don't know how bringing up silence in the wire makes this any less important.

Again, I haven't fully or detailedly read the book, so I could be wrong about that I guess.

> 3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack.

This is probably the biggest misconception.

Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS.

The author demonstrates using sslstrip to downgrade the connection of match.com to steal credentials.

How many people watch the green "secure" indicator in the URL bar to ensure it doesn't change mid-session?

How many thousands of apps don't even have such an indicator to observe?

How many millions of phones and APs will never get patched?

This is a severe vulnerability.

> Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS.

True. Yet another reason for us to push for it.

I have a chrome extension that sets the background-color of all form fields to red if the site it was served on or the ACTION attr are not https.

That said, pretty much every website in my day except for casual reading is pinned to TLS. APIs are the notable exception you pointed out, but otherwise HSTS is quite widely used, and especially effective with preload lists.

> How many thousands of apps dont have this indicator to observe?

Sure there will be some, but your standard Java apache client (along with 99% of the libraries used in Apps) dont have this kind of downgrade behaviour. If they expect validated https, they will fail without it.

> This is a severe vulnerability.

Yepp :D Not the end of the world. I think the main fallacy here is the implicit assumption that the link layer is secure. That has never really been the case and a broken wifi model is merely one more testament to this fact.

> How many thousands of apps don't even have such an indicator to observe?

I honestly never considered that one...

No, you do not need expensive hardware such as SDR to carry the KRACK attacks. Most plain standard WLAN adapters support AP mode, which is all you need to simulate the rogue network, as demonstrated in the video.

You still need proximity to the client, a powerful SDR will definitely improve reliability on real-life environments.

I stand corrected. Rogue AP / MiTM only needs a AP with the ability to send raw packets, gotcha.

Where did you find the information that it needs SDR? I couldn't find it in the paper (but I didnt fully read it) or the website.

Speculating. I don't think SDR is needed. Logically, all you need is a WiFi card that lets you do fairly standard things with the WiFi frames.

As far as I can tell that’s dangerous misinformation.

Most IoT devices never get patched. With this vulnerability you can just drive around and spy on webcams. I mean, that's pretty bad. It's enough to make me want to build rpi wifi-wired bridges/gateways for every IoT I own (which, thankfully, isn't all that many, but enough to annoy me).

Don't forget about HSTS. The author demonstrates in the video that you can sometimes bypass TLS if HSTS is not set up.

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

> Also doesn't it require the attacker to have access to your wifi already?

No it doesn't. Watch the video. It creates a clone of your network and tricks the victim's software stack to connect into it.

Nope. The man-in-the-middle attack it uses involves forwarding and replaying encrypted packets without decrypting the contents, so all it requires is that the attacker be within range of your wifi; they don't need any of your keys or passphrases.

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

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

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

You're freaking me out with that scenario

So, even if I'm using the extension HTTPSEverywhere I'm safe?

HTTPSEverywhere will not magically upgrade a site that doesn't serve HTTPS to HTTPS. If you connect to a site that doesn't support HTTPS, you are vulnerable.

Oh I see, Thanks for the answer! For what is useful the extension then?

The extension makes you use the HTTPS connection when the site you are connecting to is known to support HTTPS.

Websites can automatically redirect to HTTPS if the client connects on http, but many websites don't redirect

It has the option to block HTTP traffic, making sites that don't support HTTPS unusable.

You could create a separate "secure" profile and feel safe that all traffic is secured, while still being able to browse HTTP in another profile, for instance.

Theoretically. The extension can refuse to load sites that aren’t using HTTPS, but the real flaw is sites that use SSL instead of TLS. Attackers can reject SSL but they can’t do anything about TLS, so the security of your browsing would be affected by the website’s HTTPS configuration, and whether they use SSL, TLS, or both (the only 100% safe method is TLS only). I know for most people disabling SSL and going TLS-only isn’t high on their list of priorities so I expect this attack to be very successful on the internet as it is right now.

tcpdump -nw - | strings -n 6

Credit to https://twitter.com/marcan42

What exactly should a person who uses this command be seeing or looking for that would indicate a problem or not?