Oh Great, WPA2 Is Broken

WPA2, the standard security for Wi-Fi networks these days, has been cracked due to a flaw in the protocol. Implications stemming from this crack range from decrypting Wi-Fi, hijacking connections, and injecting content. It’s fair to say, WPA2 is now Considered Harmful. The paper is available here (PDF).

This is a proof-of-concept exploit, and like all headline-making network security stories, it has a name. It’s called KRACK, for Key Reinstallation Attack. The key insight to this exploit is a vulnerability in the handshaking between routers and devices to establish a secure connection.

This is not the first time the researchers behind this exploit have found holes in WPA2. In a paper published by the KRACK researchers at the USENIX Symposium last August (PDF), they showed that the Random Number Generator used in 802.11 is flawed, ill-defined, and insecure. The researchers have also spoken at 33c3 on predicting WPA2 Group Keys.

The practical consequences of a poor definition and implementation of an RNG can be found in consumer hardware. The researchers found that in MediaTek-based routers, the only source of randomness is the current time. Meanwhile Broadcom-based routers do not use the RNG proposed by the 802.11 spec, but instead take the MD5 of the current time in microseconds. The researchers do not mention if the current time is a secret.

So what do we do now?

This has happened before. In 2001, WEP, the Wi-Fi security protocol many security-ignorant people are still running, was cracked in much the same was as KRACK. This quickly led to the development of Aircrack, and in 2003, the Wi-Fi Alliance rolled out WPA and WPA2. Sure, you can still select a deprecated security protocol for your router, but the problem of WEP hacking is as solved as it’s ever going to be.

The early 2000s were a different time when it came to wireless networks, though here in 2017 Wi-Fi permeates every cubic inch of our lives. Everything and everyone has Wi-Fi now. This is going to be a bit bigger than cracking WEP, but it remains possible to patch devices to ensure that this exploit is rendered useless. Install those security updates, people! Of course there will still be millions of unpatched devices in a year’s time, and for those routers, IoT baubles, and other wireless devices, turning on WPA2 will be akin to having no security at all.

That said, this isn’t a world-ending Armageddon in the way the botnet of webcams was. You will only be vulnerable if an attacker is within range of your router, and you will still be secure if you’re accessing secure websites. However, turning off Wi-Fi on your phone, relying on mobile data, not ignoring HTTPS cert warnings, and plugging into an Ethernet port might not be a bad idea.

131 thoughts on “Oh Great, WPA2 Is Broken

    1. Not at all. Just means disabling any sort of hardware encryption and using application based encryption instead. This works for home-wifi as well. Just put the wifi on a DMZ and only allow a tunnel to the bastion for internet.

      Yeah, it sucks, but at least it doesn’t make you think that you’re immune, since WPA2 is on. That horse has done gone.

      1. didn’t Reaver crack WPA2 back in 2011 by traffic analysis? I don’t think your average joe is bothered setting up application level end to end security or port knocker type authentication layers. History simply repeats itself, all wireless equipment out today is essentially garbage, something new will come out, people will adopt it gradually while relying on unsecure access for ‘legacy iphones’ belonging to the bosses wife. hardware makers will be the winners, “the worse the product, the more we get paid” – Stringer Bell

        1. “History simply repeats itself”

          Only in people not listening to what is and isn’t being provided. Sorry if that sounds harsh, but the root question is why would you expect anything different from what you were told would happen?

          Encryption, and even locks, do not provide security forever. Both do nothing more than try to provide a minimum amount of time before predicted technology advances make them no longer secure.
          By definition that means every form of encryption and every type of lock *will* at some point no longer stand up to tools available at a time in the future and need replaced before then.

          Sure it sucks when those predictions are off by not accounting for exploits in protocol or implementation, which lowers the minimum time from what was originally stated. But it isn’t like such a time wasn’t going to happen in the first place, the only question is “when”. When something unexpected happens and that time is bumped up, it just means you need to enact your planned upgrade process a bit sooner. You did make a plan to handle the stated time your encryption would no longer protect you, right?

          Yes, that means ALL types of encryption will need replaced in the future. That was stated as fact before you picked what you are currently using, so being surprised at it happening is the primary failure here.

          If you’re looking for a form of encryption to protect you forever, such a thing does not exist. It never did exist. It very likely will never exist and even if it was going to it would be so far in the future that it isn’t going to help you personally.

          I’m sorry if this isn’t good enough for you. It isn’t good enough for me either, but it’s all we have to work with. Compared to using nothing at all it’s still the better option.

          1. This has nothing to do with things being hacked because of advancement of technology, this is just a stupid design flaw from the get-go and it’s just a freak thing that someone who was willing to let us know found out eventually.
            The question of course is how long has this been exploited and misused by the spooks? Could be years, could be that they somehow forced this design flaw in the first place.
            If the right person had looked this flaw could have been found the day they released the specs for WPA.

          2. You discount the possibility of forever-encryption as too far off to be worth considering, but are apparently totally A-OK with considering 256 bit AES as good as broken purely on the basis of processing power improvements.

            Also, I giggled at “Encryption, and even locks.”

  1. “relying on mobile data”
    Please explain how mobile protocols are not either broken already or just “secured” via blackboxing.
    Extra points for listing possible attack vectors and clandestine opportunities that a closed source baseband chip monopoly has to offer.

    1. Cellular protocols are more protected by their black box nature, licensing fees to get documentation and NDAs. If you want to get your hands on the specs you are going to have to sign an NDA and cough up likely thousands of dollars for licensing fees.

      Original GSM is out in the wild now, and people have built their own cellular networks. look up Burning Man Camp Papa Legba on youtube, you’ll see an experimental cellular network they setup out there several years back. Also GSM is completely broken encryption wise as well.

      1. While I’m not a fan of the way the cellular industry works, they’re doing a lot better than IEEE and there’s no black box to speak of. With a quick google I just found a list of PDFs of every cellular standard published by 3GPP and 3GPP2, on their respective websites. From the 3GPP site: “3GPP specifications are published – free of charge – up to four times a year following [quarterly meetings].” So, not exactly NDAs and licensing fees. Whereas I had to search through archives at my university’s library to find a PDF of the 802.11 standard, and it was covered in warnings about being used only by one person. I have no idea how much the library paid for that access, but it sure wasn’t free.

      1. CAN the esp chip be updated? I doubt it, personally.

        I keep asking, when people propose they use some hack chip like the esp for real products: what is your UPDATE STORY? do you even have a credible one?

        with hardware ip stacks like this one, you can’t fix it. you can only throw it away and start new ;(

        so again, hardware unpatchable comms stacks are a dead end. maybe people will start to listen to us when we stay these things next time.

        of course, china wont listen or care. their idea of an ‘update’ is to sell you another bit of crappy hardware, not fix th old one.

        and the US companies are not much better. phones are usually abandoned and not given real updates.

          1. That last part makes no sense, the key exchange communication would use the protocol both know, so any old client will force any AP to use the old protocol and then someone can inject into that communication.
            And if that AP accepts old protocol to use old devices then if you found the PSK you can connect any device to it.

          2. The protocol isn’t broken, there’s just a way of tricking the link into re-using an old encryption key. If *either* end knows how to recognise this state, they can force a new key to be generated and used. It’s only when both sides blindly use the old key that the communication becomes vulnerable.

        1. This is awesome news! Does anybody know how I go about actually “patching” my selfmade ESP8266-based IOT gadgets when all I know how to do is use the Arduino IDE? I suppose the Arduino core for ESP8266 would have to get patched, so to speak, with that ESP8266-patch. Right…?

    1. Sslstrip does nothing but rewrite https requests to http. If you are explicitly trying to access a https site your browser will error out. If you are foolish enough to continue despite the warning then that’s on you. Almost all sensitive sites will not even allow a http request anyways so sslstrip is worthless except in the most poorly secured websites and if the person is a dolt.

      Just turn on https-everywhere and browse worry free.

      1. I don’t know the tool, but I assume it will proxy http requests to https? Otherwise many sites will break since they offer different things via SSL and plaintext. Strict transport security will prevent it of course.

  2. One more reason to have everything encrypted on top of the WPA2 encryption. I already use VPNs on several locations, I will just use those even more now. The only issue might be that using such vulnerability, someone may be able to get on my home network, and although unable to read my transmission, use it to launch attacks.

  3. You will only be vulnerable if an attacker is within range of your router, and you will still be secure if you’re accessing secure websites.

    Provided someone doesn’t do some DNS shenanigans on you… whilst TLS certificate validation ought to pick that up, there have been a number of high-profile cases where someone’s screw-up have left subsets of users wide open to all kinds of spoofing attack.

    1. You will only be vulnerable if an attacker is within range of your router, and you will still be secure if you’re accessing secure websites.

      Actually, if your neighbor has a vulnerable access point on their network, an attacker could use it to remotely attack your devices. The attacker doesn’t need to be physically anywhere nearby.

  4. I always considered WAP, GSM, WPA, rot13, etc as minor speed bumps like a mechanical lock on a house or car, they can all be cracked or picked eventually just like multimedia crypto always does. SSH is pretty safe as is HTTPS as long as you keep your updates current.
    Maybe it comes from the old days where I was out nakedly transmitting ax25 packet radio along with my callsign. Just be careful what personal information you transmit and always be a little paranoid that your crypto or comm method is being cracked/listened to.

    1. Doesn’t MAC address filtering (dropping all but known MAC addresses) and static DHCP based on MAC address make the network more difficult to hack/access? Disabling WiFi at times you are not needing it, turning devices off and tracking network connections will also help reduce risk.

      Assuming everything is hackable and readable on the internet/network is probably the safest bet when considering security and risk mitigation. If somebody is really hell bent on accessing your network then nothing is really secure.

        1. Yes, but it is one more hurdle which an attacker has to overcome. Sure, if you are the NSA or some other big juicy target, it is not sufficient, but on a block with 10 other access points, if you have WPA2 and MAC filtering, chances are any would-be attacker would just go to the next house over.

          (This is the same argument as home security systems, in fact… they are not insurmountable, but they present enough of a hassle to hopefully cause criminals to try an easier target).

          1. “Yes, but it is one more hurdle which an attacker has to overcome. Sure, if you are the NSA or some other big juicy target, it is not sufficient, but on a block with 10 other access points, if you have WPA2 and MAC filtering, chances are any would-be attacker would just go to the next house over.”

            Changing your MAC address is not only trivial for an attacker, it is part of standard opsec. Filtering will not deter an attacker. That’s just a variable in the equation.

          2. Yes, but only if your only risk is that you may be a randomly selected target because you are less likely to be compromised if surrounded by much softer targets. You can exploit this behavioural factor by setting up a cheap router as a honeypot, and when it gets owned (gets a connection) you know there is an attacker about and can make some automated decisions about how to handle that. Better to not have an insecure protocol though…

      1. But if you can crack WPA it is easy to spoof a whitelisted mac address.
        Mos wifi drivers at least in Linux allow that.
        It is all down to making it annoying and hoping that the colored hat is just bored or sees and easier target.
        Worst case is a bored lonely but technically capable neighbor or paps/cops/goons/spies getting paid to bug you for something they consider cause.
        Best defense is to avoid the notice of the Eye of Sauron, otherwise even the resources of a big corp or nation state might not be enough.

        1. all zero encryption key != empty certificate
          A ctrl+f on the page reveals not one mention of the word “certificate”.

          From the linked article:
          “Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key.”

          The very next line:
          “This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time.” Linux’s only mistake was following the spec. This seems to imply that other operating systems are off-spec and that Linux has anything but a lousy implementation.

          1. And now one can see why there’s more to programming than just being a glorified translator. Domain knowledge and experience helps in working out the ramifications of doing things a certain way, or not.

        2. Linux actually followed the specs it says, the specs meant clearing the temporarily stored value, leading to an empty string when it was accessed again (against expectation).
          Now if that is stupid is another matter, if you blindly follow specs and there is a chance you could have foreseen the result then the coding was sloppy. If it was really unexpected that the now-cleared entry would be needed again then it was correct to clear it to defeat maliciously grabbing it.

          1. Addendum: Mind you you could code in that it was never used again ever, that would be the proper way.
            But hey this is where the hacks come from, the many many unforeseen factors that get abused because they are unforeseen.

      1. A weakness that means that an attacker under some circumstances can reset the key to a previous key. Yes. Not good.

        But the key is still unknown to the attacker, at best they can improve the likelihood of cracking the stream key by using statistical modelling AFAIK. That is what is needed to inject messages into the stream.

        The real problem is when the key can be read or set to a known value. That is the case for the Linux implementation that set the key to zero. THAT is a huge problem.

        1. Not really. The type of encryption algorithm allows a lot of things when you reuse a key/nonce pair. In case of GCM it is a complete break, in CCM you can decrypt but not create new messages. For TKIP I don’t know.

    1. The other way around. It’s because the standard is broken, and Linux and Android implemented it verbatim, while other operating systems had their own ideas how to implement it incompletely.
      But that doesn’t mean that they’re safe.

  5. The WPA2 encryption algorithm is NOT broken. The implementation is broken, but that can be fixed with a code update. It’s not like WEP where it cannot be fixed and we need a new algorithm.

    1. Close… the implementations are all vulnerable in different ways *because* they followed an ambiguous spec. The core crypto is fine, so you’re correct that it doesn’t need to be replaced like WEP did, but the fix to the implementations involves going slightly beyond/away from what the spec officially says.

  6. Wow, does the word sensation mean anything to you?

    Yes, this is bad. No, it’s not the end of WPA2. Not even close. And no, it does not even require routers to be patched. Only one party needs to be patched to make this attack impossible. I’m sure there will be an update for Windows soon, so you’ll be fine.

    This problem exists in implementations simply because the standard wasn’t clear enough. Yes, you could call it an attack on the standard, but that would hardly be realistic. The attack works by injecting packets that should not be received while there already is a connection. The standard dictates how these packets should be handled, but not when they should be accepted.

    This problem can be patched without breaking backwards-compatibility and some vendors actually don’t need to patch anything because they already assumed (strictly speaking incorrectly) that those packets should be ignored when connected.

    Either way, if either your AP or your client is patched, you’re fine.

    1. https://market-ticker.org/akcs-www?post=232470


      The flaw itself is not hard to patch but there’s a severe problem with this particular issue because an utterly huge number of devices use “allegedly-secure” WiFi and many of them don’t ever get updated. In addition you don’t need physical access to attack a device using this, of course — you need merely to be within WiFi range of it.

      Consider this: Virtually every cellphone out there has WiFi in it and many are orphaned by their manufacturers, receiving no future updates at all. These devices, along with nearly all “consumer” WiFi access points in homes and small businesses will never be fixed.

      The impact of this flaw means that the majority of consumer cellphones now in-service will never receive a patch for this and will remain vulnerable until they are discarded by their owners, and in addition the majority of consumer and small-business WiFi access points will never be patched and will remain vulnerable for years if not a decade or longer.

      As things stand right now commercial WiFi networks in places such as bars, restaurants and other retail environments are extraordinarily vulnerable as these tend to rely on embedded software, some of which will probably not be patched and most of these networks carry sensitive customer data including credit card swipe data. PCI requires encrypted storage and transmission but if the encryption is in fact worthless then the integrity of these networks are in big trouble. The recent proliferation of “at table” tablets for bill paying and similar is going to make this much worse than it would otherwise be.

      Our failure as a nation to force chip cards across-the-board, unlike virtually every other country (chip cards have a one-time negotiated key used for transactions and thus “capturing” them is of little value) is likely going to result in severe exposures across the retail landscape for the next several years.


      This one is “that good.”

      Oh by the way, when the WPA2 “standard” was being debated and discussed may we examine who was in the room? I have to wonder why this wasn’t caught a long time ago, given that WPA2-AES/TKIP/etc has been around now for a hell of a long time. When something this nasty is found you have to wonder if the process was corrupted either negligently or on purpose.

      Note that the US media has thus far ignored this story; I saw it in The Guardian.

      Gee, I wonder why…

      1. I said, and I’ll say it again: Yes, this is bad.

        But it’s not the end of the standard, as it is easy to patch. And it’s not WEP-bad. Your network key is still secure.Even with unpatched devices all around me, I still cannot get the network key. “All” I can do is decrypt your communication and change a few things in your packets. When you’re gone, I loose all access.

        Also, this attack requires the original access point to be out of range. Tricks like having the strongest transmitter won’t work, as the client will still receive both signals and will not be able to understand what’s happening. Jamming the original isn’t going to work either, since I still need to be able to talk to it to make the attack work. Creating a second network with a different SSID “REAL free wifi” won’t work either.

        And even if I manage to destroy the antenna of the original access point without destroying the AP itself, and place my device on top of it, which admittedly is still plausible though risky, I’d still have to hope no one notices my attack. Half of the patches I’ve looked at today inform the user of such attempts.

        So, yes, this is BAD. But it’s not WEP-bad. The scenario pictured in your excerpt is never going to work. There isn’t a single payment provider that relies on a restaurant owners WPA settings for secure communication. They rely on technology like SSL/TLS and other encryption schemes. Yes, you’ll be able to capture an encrypted stream of data. No, you won’t be able to do a thing with it. You might as well have generated random data.

      2. The reason this wasn’t fixed a long time ago is very simple – the IEEE puts the 3000+-page spec behind a paywall set at a price that essentially allows only those with corporate/institutional backing to read it. That’s why this went a decade or more without being noticed.

        1. No sneaking in is what you do after designing it on purpose first.

          As for the TSA master key, some TSA fool dangled his keys in front of a high res camera, and after that anybody could make copies, that’s just typical TSA nincompoopery I think.

  7. Some quotes form the PDF:
    “Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.”

    “..This vulnerability appears to be caused by a remark in the 802.11 standard that suggests to clear parts of the session key from memory once it has been installed”

    “Because Android uses a modified wpa_supplicant ,Android6.0 and Android Wear 2.0 also contain this vulnerability. As a result, currently 31.2% of Android devices are vulnerable to this exceptionally devastating variant of our attack ”


    ” Even enterprise networks rely on the 4-way handshake. Hence, all protected Wi-Fi networks are affected by our attacks.”

    At least with things like android there is a chance on an update, but some router manufacturers simply end their support as short as a month after they sold a router because they released a new model, and you’ll have to install custom firmware to stay ahead of the game, which many don’t know about.

    1. You can always phish for it once you have access. Load up a fake admin page with a notification that their router is vulnerable to this attack. Have them provide the password, and you’re set.

  8. Hmm, the WPA2 KRACK paper author sat on the information for ~two plus months to get an academic credit for their paper, then disclosed it “privately” to some 100+ companies and organisations and asked them to sit on the information silently for 5 months (to give everyone time to work on patches and solutions). OpenBSD silently released their update in August. And finally they disclosed the information of the flaw to the general public.

    To me many things sounds wrong in that process.

    1. It’s not great, true.
      But it might be the best we can do.

      If they can’t delay a little to get academic credit, academics (who bring a lot of skill to the table) won’t do it. The way universities run now, no papers = no go.

      If they release the bug immediately, the manufacturers (who will likely be a bit slow due to internal processes and, if we’re lucky, testing) will be in a straight-up race with the black hats. I don’t want to be in that race.

      Normally the bugs aren’t so thoroughly distributed, though, which makes the list of warned parties quite large.

      Don’t forget to update your IOT lightbulbs, fridge, toaster, car, microwave oven, door locks, underpants, mechanised tie rack, {NSFW} etc. (And what will you do with the devices that can’t be upgraded?)

      1. Remembering that as recently as 5 years ago, whitehats would warn companies, and they’d do SFA… and that would go on until blackhats found it independently and they were forced to respond, or the whitehats gave them a deadline or released it out of impatience.

        1. Yeah, sometimes I guess you need a stick.

          Unfortunately development time is limited, and there is often a lot of time pressure, and the security never becomes a priority. Most customers don’t demand security information (let alone assurances) – yet.

    2. You can see the logic, but 5 weeks for the whole thing would be a better way to go.
      I mean if it’s so critical then they can put people on it immediately (take them from other projects) and even if it takes them 7 or 8 weeks, the hackers also need time to code their hacks anyway so they would be slow in catching up too, so you release the info after 5 weeks and let the world deal.

      I picked 5 weeks based on my expectation of how long it would take to code a initial patch and test it.

    3. Responsible disclosure sounds wrong? The only reason it took so long is that almost EVERY wifi device is affected. That’s a lot of companies to inform and wait for patches. Vulns in single programs could be put under a much tighter release deadline.

    1. I get the joke, but talking of microseconds and based on the local clock it seems to me you do create a range of hundreds or thousands of possible values for an attacker to try at least.
      Not sure that matters though in terms of hackability.

      1. Better than nothing, but if you know it with at most half a second off that is 1 million microseconds. Or around 20 bits of entropy, or a password of around 3.4 characters. So basically nothing.

  9. Surprised at how anyone would equate this to the WEP crack and how little it’s understood by the writer. We’re months away from any REAL concern, since the only way the exploit works is within strict parameters under extremely rare conditions. The authors themselves call it a “theoretical” risk. No need to go unplug all your IoTs – not yet anyway. By the time an exploit is viable, most routers will be patched (yes you can fix it from the router). And everyone should always use HTTPS anyway – if you’re not, then, well, you probably leave all your doors and windows unlocked too.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.