21 ms·

Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

• IndrekR 9y ago
  Finally a way to get all IoT devices connected to WiFi! Remember, 'S' in IoT is for Security.
  • JoshuaRLi 9y ago
    > Remember, 'S' in IoT is for Security. One of the best quotes I've heard in a while.
• tinix 9y ago
  Some details here on the hostapd security disclosure page: https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-r...
• l2dy 9y ago
  Do we now need WPA3? No, luckily implementations can be patched in a backwards-compatible manner.
  • s17tnet 9y ago
    The problem is that tons and tons of devices will not receive update until they die.
    • StavrosK 9y ago
      Don't you only need to patch one end of the communication? Eg if phones are patched, they're safe, even if the AP is not. Then again, I didn't read the attack fully, this might be a client-only problem.
      • Khoth 9y ago
        Tons of phones won't be patched. Android phones generally only get system updates for a small portion of their lifespan.
    • pnutjam 9y ago
      You can mitigate with a vpn.
      • 0xfeba 9y ago
        How do I install a VPN on my IoT lightbulbs?
        • pcunite 9y ago
          My understanding is that only the light bulb's traffic will become decrypted. If you see it go from blue to red, without your consent, then you'll know. Otherwise, the Wifi password is still safe.
  • r1ch 9y ago
    It's a pity this didn't completely break WPA2 like how WEP was broken, now it will be years before there's any new security developments. Things like management frame authentication and dynamic client keys for open networks would be big improvements for the majority of use cases.
  • akerro 9y ago
    How many BT and Virgin home routers will be patched? Somewhere around 0?
    • dan1234 9y ago
      Both Virgin & BT force upgrade consumer routers overnight.
      • Sephiroth87 9y ago
        Latest Virgin upgrade was a year ago, so I'm not holding my breath...
        • dan1234 9y ago
          Mine last updated a couple of months ago, around the end of August. (V2.01.12, superhub2ac)
• dewey 9y ago
  > This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on. ... if transmitted over plaintext http
  • brango 9y ago
    Or if combined with some other vulnerabilities...
    • gcp 9y ago
      Somewhat pointless remark as WPA only protects up to the access point. Any vulnerability after that has wider implications regardless of the WPA status.
      • TheAdamAndChe 9y ago
        It's not really pointless. MiTM attacks become much easier to accomplish with something like sslstrip once access to the network is gained.
  • CityWanderer 9y ago
    Exactly, this particular sentence seems to overly dramatise the situation. Is this issue any different to using open wifi at a cafe, which many many people do, relying on HTTPS for their security? (This is an honest question)
    • ekimekim 9y ago
      At its worst, this attack reduces a protected network to an open wifi, yes. The risk is that you may do things on a protected network assuming it really is protected - this is more of a thing for organisations rather than consumers, for example organisations might have unprotected services accessible over their office wifi.
  • baby 9y ago
    Note that in the demo video they use SSLStrip to cancel attempts of websites to switch to https. The only protection here is HSTS (which is not enabled by most websites, but major ones like banks will usually have them) and manually typing https:// https:// in your address.
• brango 9y ago
  Is there a way I can install an open source phone OS on my old Android phones to keep them patched? I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two. Anyone got any suggestions for options?
  • xrisk 9y ago
    LineageOS has a moderately large selection of supported phones for a custom ROM and it has weekly updates. My two and a half year old Moto E has the October 5th security patches for Android.
    • gsnedders 9y ago
      > My two and a half year old Moto E has the October 5th security patches for Android. But it has very few kernel security patches: https://cve.lineageos.org/android_kernel_motorola_msm8610 https://cve.lineageos.org/android_kernel_motorola_msm8610
      • rightos 9y ago
        Look through the list yourself, but at least on my device, most of those kernel security issues aren't really of significant impact as apps don't have access to the APIs needed to trigger them and they're not remotely exploitable.
  • taspeotis 9y ago
    > I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two. You could just ... buy an iPhone and get timely security updates for years. EDIT: Downvote if you want, but if iOS 11 contains this security fix exclusively and not iOS 10, then an iPhone 5s bought on 20 September 2013 is going to get this fix. If Apple release an iOS 10 update and you bought an iPhone 5 on 21 September 2012 you're covered too.
    • la_oveja 9y ago
• asclepi 9y ago
  It seems that OpenBSD already patched their source code and that wasn't to the likings of the researcher. In the future he will now delay notifying OpenBSD of vulnerabilities. Why did OpenBSD silently release a patch before the embargo? OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: "In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging". Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
  • 0x0 9y ago
    Not the first time OpenBSD does not respect embargoes, for example https://lwn.net/Articles/726585/ https://lwn.net/Articles/726585/ and https://lwn.net/Articles/726580/ https://lwn.net/Articles/726580/
    • philippnagel 9y ago
      As a user I am completely fine with that.
      • nasduia 9y ago
        Even when the author states that now as a result of that selfishness OpenBSD won't get notified about vulnerabilities until well after everyone else?
        • cjsuk 9y ago
          What about the vulnerabilities that OpenBSD notice? Works both ways. And they have an active interest in such things and have discovered as much as any famous-for-five-minutes security researcher.
• acqq 9y ago
  "Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time." "Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack."
• philfrasty 9y ago
  „submitted for review on 19 May 2017“ ... „OpenBSD was notified of the vulnerability on 15 July 2017“ Can anyone explain the timeline of releasing such significant security findings? Why is it disclosed to the public 1/2 year after submitting to review? I'd guess the (publicly funded) research behind it is a lot older than that.
  • grabcocque 9y ago
    For a vulnerability of this magnitude, it's not unusual for a responsible disclosure to have a five month review window. e.g. Dan Kaminsky's discovery of DNS cache poisoning had a 5 month responsible disclosure embargo.
  • maxerickson 9y ago
    The intent is to have as many fixes available as possible at the time knowledge of the flaw becomes widespread.
    • philfrasty 9y ago
      Of course. From my understanding of research at public institutions there is a long period of time and steps between finding something interesting and submitting a paper for review. Why not disclose the vulnerability first to concerned parties and then write up a fancy research paper? Why the other way round? Only two explanations I could come up with: Either there must be a very short time frame between identification of the vulnerability and writing of the paper or there was further research needed. Or....I don't know
  • user5994461 9y ago
    July => October. It's 3 month. It's a reasonable delay if you have to alert lots of manufacturer and they need time to roll out critical patches to lots of devices.
    • greedo 9y ago
      Full disclosure is reasonable, and the only truly effective methodology. Anything else just allows vendors to delay or ignore.
• DrRobinson 9y ago
  Do I have to update the both the AP and the client or is one of them enough?
  • shimon_e 9y ago
    Client may be enough. Depends on the AP and only the manufacturer can accurately answer that question.
• deleted 9y ago
  [deleted]
• sinuhe69 9y ago
  Can I use MAC whitelisting to mitigate the attack?
  • eptcyka 9y ago
    MACs are easily spoofed.
  • makomk 9y ago
    Not really. As far as I can tell, the attack basically requires spoofed MACs anyway because the keys are derived in part from the MACs, so whitelisting won't get you much benefit if any at all.
  • d15b0ff178b085c 9y ago
    Nope, This will fool your client (eg: your phone) to connect to it, before it reaches your access point, then forward packets to your AP (basic man in the middle). On the other hand, I am wondering if it manages to correctly forward packages back to the AP if that has MAC filtering on...
  • billpg 9y ago
    No. You can't even use MAC white-listing to prevent unauthorized devices from connecting to your access point.
  • Tepix 9y ago
    Only against an incompetent fool.
• pingec 9y ago
  Correct me if I am wrong but basically the attack is against clients, not access points which means simply patching the AP will not do, one would have to patch all of the clients. And the AP patches that are now coming in are probably for client mode, so they fix a certain scenario when the AP is a client which is far from the common one?
  • YouKnowBetter 9y ago
    Correct for 98%. Clients are the weakest point in the scenario.
• jokoon 9y ago
  This is too big, I doubt it's not a backdoor.
• peterwwillis 9y ago
  "This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on." As much as this is a scare tactic to get people to demand vendor patches, it's been true for https for a while. Browsers don't have any trick (that I know of) to enforce https on first connection. HSTS is defeated by simply rejecting connections to https - the user will retry the site from different devices and destroy their hsts cache in order to reach the site. Assuming the site used hsts.
  • pfg 9y ago
    All major browsers implement a HSTS preload list[1] to get around the first connection problem. Manually deleting the HSTS pin for a site is quite involved and not something I'd expect most users to do. [1]: https://hstspreload.org/ https://hstspreload.org/
    • peterwwillis 9y ago
      Preload lists are not a realistic solution (you can't preload the whole internet) and a sufficiently complicated site will be subverted due to 3rd party dependencies. And does uninstalling a browser not clear the hsts cache?
      • twitchyliquid64 9y ago
        You can't preload the whole internet, but by getting the top xx thousand you get 99% of all Chrome users traffic. Its not perfect, but it is very, very effective.
      • pfg 9y ago
        Perfect is the enemy of good. A large portion of sensitive traffic is protected by HSTS today, and the preload list compresses well. By the time it'll become a problem, we'll hopefully be at the stage where HTTP is treated as insecure anyway. I'm not certain if uninstalling a browser clears the cache (do uninstalled browsers retain their profiles?), but preloaded sites would not be affected - they're included in the browser binary. Either way, let's not act like there's a massive hole in HSTS because there's a possibility that users might go as far as reinstalling their browser to visit a not-preloaded HSTS-enabled site that's being targeted.
• baybal2 9y ago
  Can somebody explain why replay attack protection of WPA2 is not working in this case? Aren't any out of order packets thrown away?
• pmontra 9y ago
  > For example, an attacker might be able to inject ransomware or other malware into websites. A reason to use https even for the most basic websites, including the ones embedded in IoT devices on local networks.
• gsich 9y ago
  How are fullmac devices patched? Don't they require firmware flashing or some sort?
• SaltySolomon 9y ago
  The research talks a lot about how it somewhat depends on the implementation of the wireless client, but only in regards to Linux and OpenBSD, anybody know what the status on the Windows implementation is?
  • ac29 9y ago
    >anybody know what the status on the Windows implementation is? Seconding this. I wonder if it is something fixable at the OS level, or if individual WiFi drivers need to be updated too. Would love to see someone throw together a list of OS', Routers, and other WiFi stuff that is known to be patched/unpatched/unknown.
    • ac29 9y ago
      Answering my own question: looks like someone is tracking it over here: https://char.gd/blog/2017/wifi-has-been-broken-heres-the-companies-that-have-already-fixed-it https://char.gd/blog/2017/wifi-has-been-broken-heres-the-com... Microsoft's status is unclear at the time of writing.
  • dfox 9y ago
    I'm not sure that there even is "Windows implementation" of this. For a long time each driver implemented it's own 802.11 stack.
    • yuhong 9y ago
      I believe that the code for the 4-way/group key handshakes etc is part of Windows even in XP, though there was the option of using your own supplicant before Vista.
• alkonaut 9y ago
  What's the practical impact here? What do I do with a normal house with routers, laptops, smartphones etc? Are manufacturers like linksys, d-link issuing patches now or will it be enough to have windows/os x/iOS/android updates enabled? Or do I need both?
  • YouKnowBetter 9y ago
    Await your client to be patched. Routers are not so much the problem (unless in Range Externder modus).
• baybal2 9y ago
  Quick googling found out that at least one guy did come very close to realizing that 4-way handshake should have hard replay protection: http://slideplayer.com/slide/5762070/ http://slideplayer.com/slide/5762070/ On page 30 of the presentation: "Authenticator may (or may not) re-use ANonce"
• YouKnowBetter 9y ago
  Stop panicking (unless you need your daily dose of the End of the World drama). From the source: In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones. Source: https://www.krackattacks.com/ https://www.krackattacks.com/
  • madshiva 9y ago
    Some people don't want read all the articles and tend to panic. It's why if there's any security issue we need a list about action to reduce risk, when, how, etc. otherwise people still we dispute about it's feasible or not and then finally the journalist will explain how to fix the risk. I like to read the whole article but then sometimes it's very hard to check if it's truly feasible or it's just a panic mode, for example when wannacry come out the information was a mess.
• sequence7 9y ago
  As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.
  • janvdberg 9y ago
    Use an always-on VPN?
  • Ambroos 9y ago
    This is one of those things that should be better with modern handsets and the security patch level for Android. Hopefully a fix for this is included in the November set. In general most bigger manufacturers have been somewhat decent in updating their flagship devices. With a Sony flagship from the last 18 months for example, you usually won't run more than two months behind on security updates. Samsung is similar if I remember correctly. Hopefully a big exploit like this will be enough of a kick in the butt to get manufacturers releasing security updates faster.
    • sequence7 9y ago
      I have a HTC 10, a flagship device that's barely a year old the fact that I now have to wait a couple a months for a patch to what is clearly a critical vulnerability is just ridiculous. The fact that anyone without a flagship device should now throw that phone away because it will probably never be patched is despicable. I totally agree with your hope that this will kick both the manufacturers and Google in the butt enough to get something done about this. I don't like our chances though!
      • Perseids 9y ago
        To underline your point, even my Nexus 5 (_from Google_), which is a little less than 3 years old, will never receive security updates. And one of the main reasons I chose the Nexus was to be sure to get updates on time. Except for the security vulnerabilities, everything of the device is totally fine. It's such a waste of resources… (In this case I at least have an alternative in the form of Lineage OS, which will only cost me time and nerves for the migration.)
• Tepix 9y ago
  Here is the commit that landed the fix for LEDE today: https://git.lede-project.org/?p=source.git;a=commit;h=bbda81ce3077dfade2a43a39f772cfec2e82a9a5 https://git.lede-project.org/?p=source.git;a=commit;h=bbda81...
• kenaddams 9y ago
  i don't get how they can run a mitm attack without knowing the secret passphrase, can someone explain this in laymans terms?
  • gruez 9y ago
    Because you are replaying the packet, which doesn't need the key.
    • kenaddams 9y ago
      thanks that makes sense
• DyslexicAtheist 9y ago
  the post https://www.theregister.co.uk/2017/10/16/wpa2_inscure_krackattack/ https://www.theregister.co.uk/2017/10/16/wpa2_inscure_kracka... mentions: > As Hudson notes, the attacker would have to be on the same base station as the victim, which restricts any attack's impact somewhat. If I understand it correctly then there has to be a connection already present for the attack to work?
• danilocesar 9y ago
  > For ordinary home users, your priority should be updating clients such as laptops and smartphones. So even if you patch all the devices in your house/company/whetever you can't be safe... Then yours aunt's un-patched android connects into your wifi and put all your network in risk. Or maybe that not-so-old security camera or SmartTV that will never be patched. Time to move all those guys to an isolated vlan...
  • cjg_ 9y ago
    The WPA key is not recovered so it should only affect the unpatched client.
    • danilocesar 9y ago
      I wasn't even thinking about the key. I was thinking about compromising a device using a targeted tcp hijack. And then using that device to compromise the rest of the network. Long shot tough.
      • cjg_ 9y ago
        Sure that might be possible, for example to serve some malware to that device. More likely is that a device you allow onto your wifi already have some malware from earlier.
• user5994461 9y ago
  One thing to clarify, does the attack require the attacker to be already connected to the AP?
  • kzahel 9y ago
    No, that was explained in the demonstration video.
• DyslexicAtheist 9y ago
  Linux patches are out https://twitter.com/vanhoefm/status/919853110700531712 https://twitter.com/vanhoefm/status/919853110700531712
• aaronaarzelbart 9y ago
  So how will this be fixed?
• creatrixcordis 9y ago
  "This is achieved by manipulating and replaying cryptographic handshake messages." so that means that the mac address has been spoofed to make the AP think that he is always talking to the same mac address. If I'm plugged into the router directly then i should be good because it eliminates the wifi handshake. So even though other devices on the wifi network could be affected, the node that is plugged in is safe against this?
  • nullbyte 9y ago
    Well yeah, you'd always be safe against these types of attacks if you're wired in. Even on Ethernet.
    • nullbyte 9y ago
      *even on WEP Is what I meant to say. Haven't had coffee yet, sorry.
    • creatrixcordis 9y ago
      So if i use my wired in node as an ssh tunnel out to the "internets" to tunnel all traffic from my wifi connected nodes then this mitigates the issue till updates come through?
      • kzahel 9y ago
        Yep! That's what I'm doing right now.
      • Fnoord 9y ago
        That's a feasible option on laptops running macOS or Linux, but not for Android clients. Running a SSH VPN (tunneling all traffic) requires root and has a severe performance penalty (which you will notice on your battery). You'd notice it on the laptops as well, but I guess that matters less. Funny enough, OpenBSD didn't impleemnt WPA(2) for a while. Instead, they were forcing their users to use IPsec and OpenSSH instead.
        • 9y ago
• ShinyCyril 9y ago
  Does anyone know if Apple release security fixes for Airport? I know it isn’t actively developed, but you’d hope they’d release critical security fixes as they still sell them.
  • bjpbakker 9y ago
    The main attack targets 4-way handshakes, so doesn't target access points. You should worry about updating your clients, not your AP. Source: https://www.krackattacks.com/ https://www.krackattacks.com/
    • ShinyCyril 9y ago
      Fortunately most access points will be fine, but those performing client functions (eg repeaters) will need updating.
• orblivion 9y ago
  I'm not sure I understand the concern with breaking WiFi. Okay, so you're vulnerable to snooping and injection by people in the same coffee shop or your neighborhood. But you're already vulnerable to that from anybody on the Internet between you and the site. HTTPS solves both of these. Am I missing something?
  • ascagnel_ 9y ago
    Security in layers, and because locally-hosted content may not always be sent over HTTPS (because people love to cut corners).
  • EvanAnderson 9y ago
    There's a treasure-trove of data and metadata in your DNS requests, destination IP addresses, and traffic analysis. You're not just vulnerable to snooping either, but also traffic injection. You're exposing a much larger attack surface by losing the layer of security provided by WPA2.
  • Jach 9y ago
    Lots of sites aren't on https yet. Some never will be. Additionally there could be intranet communications no one bothered to secure, so maybe the company email's POP server was never configured to send text encrypted.
    • orblivion 9y ago
      Yeah, Intranet is a good example.
  • XorNot 9y ago
    How encrypted is your average home network, really?
  • wyldfire 9y ago
    In practice, the points where you're most susceptible to MITM/interception are the initiation and termination endpoints. Most of these connections terminate in a data center/hosting providers, which should generally have decent security and plenty of disincentives for snooping. However, homes, coffee shops, airports, etc -- those are places where someone could execute this attack successfully. You're right that any transit router could intercept your connection and do these things but in practice those routers are "reasonably" well secured.
• twitchyliquid64 9y ago
  This is not an end-of-the-world type vulnerability. 1. Does not affect long-term credentials - certs, wifi passwords are still safe. Rather, confidentiality (secrecy) from client --> AP is affected, and in some cases packet forgery is possible (integrity). 2. Actually accomplishing this attack, for now, requires special and expensive hardware (med to high range SDR gear). Its also not that reliable outside of a lab environment. 3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack. If it isnt, fix it. This is a great moment for you to fire up wireshark and audit the traffic going over your wireless link. If its not adequately protected and you care about it, fix it.
  • cm2187 9y ago
    Also doesn't it require the attacker to have access to your wifi already? If that's the case, it's a hazard for connecting in a Starbucks or on your mobile service wifi, but you would be safe on your home or corporate wifi (unless the attacker is a colleague or relative!).
    • snerbles 9y ago
      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.
      • macawfish 9y ago
        You're freaking me out with that scenario
      • ibmthrowaway218 9y ago
        Except the attack doesn't get you access to their wireless network. It allows you to redirect someone from their wireless network to your own (spoofed) wireless network and then you can snoop the traffic.
        • lightedman 9y ago
• accnt4frms 9y ago
  Is it possible to adapt these attacks to HTTPS protocol?
• shimon_e 9y ago
  Already patched in Arch linux. Just updated all my systems.
• dboreham 9y ago
  "This can be abused to steal sensitive information such as credit card numbers, passwords" This really isn't true (because that kind of information is protected by TLS) and the article is highly disingenuous to not say so. Nobody has trusted WiFi encryption as protection for sensitive information for more than a decade.
  • discreditable 9y ago
    Demonstration video has the researcher sniff passwords from match.com, which uses TLS. The catch is they aren't using HSTS and so they are vulnerable to sslstrip.
    • pnutjam 9y ago
      True, using a vpn gives you control over "an" encryption layer for your traffic, relying on the sites https will always be less ideal.
  • cpach 9y ago
    Did you watch the demo video[1]? Apparently some sites (Vanhoef’s example was Match.com) are suspectible to MITM by using Moxie Marlinspike’s sslstrip tool[2]. [1] https://youtu.be/Oh4WURZoR98 https://youtu.be/Oh4WURZoR98 [2] https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip
• andygambles 9y ago
  Have I got this right in lay-mans terms. The client is forcibly disconnected from the WiFi network and reconnects to the attackers network instead. The attacker doesn't need to know the WPA2 password but it accepts the connection setting the encryption to zeros. The client thinks it is connected to the original wifi network and continues as normal. Wifi traffic is intercepted and unencrypted.
  • ibmthrowaway218 9y ago
    > The client is forcibly disconnected from the WiFi network and reconnects to the attackers network instead. The client is tricked into moving to what it thinks is the same WiFI network running on a different channel, but is actually the attackers network instead. > The attacker doesn't need to know the WPA2 password but it accepts the connection setting the encryption to zeros. The attacked doesn't need to know the WPA2 password and (for Android and Linux clients) the client then defaults to an encryption key of all zero bytes. > The client thinks it is connected to the original wifi network and continues as normal. Yes. > Wifi traffic is intercepted and unencrypted. Wifi traffic is intercepted and can be decrypted (since the encryption key - all zero bytes - is now known).
    • rconti 9y ago
      Just the traffic between the impacted client and the network, right? Because each client is using a different key (has to be, if we're able to reset just one client's key to all zeros)
  • g-clef 9y ago
    Not quite: The attacker watches for the initial client->AP encryption negotiation (or forces it by forcing a disassociate), records one step of that negotiation and replays it to the client. That has the side-effect of causing the client->AP traffic to re-use encryption keys. Since WPA2 encryption is a stream cipher, re-using keys opens it up to a known-traffic analysis attack, which allows a listener to decrypt the traffic. So, the user is still connected to their existing AP, but since they're re-using keys, attackers can decrypt the client->AP communication. There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients. (Good TLDR here: https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/ https://blog.cryptographyengineering.com/2017/10/16/falling-... )
• api 9y ago
  This once again shows why complexity is evil in cryptography. The likelihood of a vulnerability in a cryptosystem increases exponentially with the number of state transitions it has. http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf
• chmars 9y ago
  The Wi-Fi Alliance has published an official statement: 'There is no evidence that the vulnerability has been exploited maliciously […].' That is probably about to change … https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-se...
  • willstrafach 9y ago
    That is very strange for them to say. Unless someone is sitting around collecting full take packet captures of everything going on around them and looking through it all, there would be no way to be aware of this.
• whyever 9y ago
  > OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo. I'm not convinced it was a bad decision. Why would you want to leave your users vulnerable? It's possible that this has been exploited in the wild.
  • sp332 9y ago
    This probably hasn't been exploited in the wild. Anyway the point of coordinating disclosure is to leave fewer people vulnerable overall. If one team releases a patch early, attackers can analyze the patch and start using the vulnerability against unpatched systems. Waiting for everyone to patch at once closes that window.
    • nradov 9y ago
      How can you state that it probably hasn't been exploited in the wild with any degree of confidence? It's possible that the same flaw was found and exploited years ago by black hat hackers and/or state security services. We have no way to know whether this actually happened, or even estimate the probability.
      • sp332 9y ago
        Because it hasn't been seen before, it's not likely that it has been exploited. Even after knowing about the flaw for a while, the Wi-Fi Alliance says there is no evidence that this was used maliciously before. https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-se... We can't know absolutely but with all the attention wifi has gotten since the days of war driving, there's a good chance it would have been caught.
• masswerk 9y ago
  Now, the OS of processor management units like Intel AMT and the AMD equivalent also incorporate wireless stacks. What are the chances of them becoming effectively fixed?
• gok2 9y ago
  So is there any precautions I should take with my macbook and iphone?
  • SadWebDeveloper 9y ago
    Not really just use LAN over WLAN and wait for patches for both of your devices
• deleted 9y ago
  [deleted]
• Sephiroth87 9y ago
  Assuming neither client and router is upgraded, can this be mitigated my making the SSID hidden, so the attacker wouldn't know which AP to spoof?
  • crshstsh 9y ago
    hidden APs can be easily seen
    • Sephiroth87 9y ago
      Thanks, didn't know that :)
  • SadWebDeveloper 9y ago
    The attack doesn't need to know the SSID to find and replay the affected packet.
• trustzone 9y ago
  Matthew Green's blog on why it happened and how it escaped detection is a really good read. https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/ https://blog.cryptographyengineering.com/2017/10/16/falling-...
  • davidkuhta 9y ago
    > Representation of the 4-way handshake from the paper by He et al. Yes, I know you’re like “what?“. But that’s why people who do formal verification of protocols don’t have many friends. +1 for a good read, really enjoyed his writing style. For those unfamiliar, Matthew Green is a cryptography researcher and professor at Johns Hopkins. Edit: TIL John's' Hopkins ty /u/dEnigma
    • dEnigma 9y ago
      It's actually "Johns Hopkins". The story behind the name is somewhat interesting: http://www.hopkinsmedicine.org/about/history/history1.html http://www.hopkinsmedicine.org/about/history/history1.html
  • ghettoimp 9y ago
    "One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access." While I'm sure this can't take much of the blame, it sure strikes a chord. The IEEE standards process seems insanely archaic and broken in the open-source era.
    • rphlx 9y ago
      It is, arguably, pretty broken even in some closed-source arenas. For instance if your objective is to have the IEEE first define thorough, carefully reviewed standards which are then closely and widely implemented throughout an entire industry, 25G and 50G Ethernet were abject failures.
    • nieve 9y ago
• esaym 9y ago
  Looks like mikrotik already fixed theirs a couple of weeks ago as well: https://forum.mikrotik.com/viewtopic.php?f=21&t=126695 https://forum.mikrotik.com/viewtopic.php?f=21&t=126695
• praxis23 9y ago
  Anyone already posted "2 unit tests, 0 integration tests"? [1]. It's funny, because 4WS actually had security proofs, which considered all the pieces in isolation, but never in symbiosis. [1] https://gfycat.com/HotOrangeCoypu https://gfycat.com/HotOrangeCoypu
• JoshuaRLi 9y ago
  Some resources for those who want to keep updated on vendor patch status: https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathread_check_back_often_for_updated/ https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathr... https://github.com/kristate/krackinfo https://github.com/kristate/krackinfo
  • bradleyjg 9y ago
    What's the general approach to the fix? Insist on a new handshake if a client sees a duplicate message #3? Just keep going with the old sequence number? It seems like vendors need to eventually come to some consensus on how to change the protocol instead of each fixing it in their own way.
• progman 9y ago
  > how did this attack slip through, despite the fact that the 802.11i handshake was formally proven secure? So, we cannot trust even formal verification? > it’s a factual statement. In formal analysis, definitions really, really matter! If lack of definition implies flaws in formal verification, does that mean we need an additional formal verification of formal verification? Update: > We need machine-assisted verification of protocols, preferably tied to the actual source code that implements them. Haskell, here is your opportunity :-)
  • twinkletwinkle 9y ago
    Formal verification all the way down. I'm a complete layman in this field, but mustn't it bump against the Incompleteness Theorem at some point? There's no way to prove your definitions.
    • progman 9y ago
      The critical point is specification vs. implementation. Any difference creates a loophole which can be abused.
  • ecesena 9y ago
    > So, we cannot trust even formal verification? it's explained in the article, 2 unit tests, 0 integration tests. The formal verification appears to prove correctness of the 2 pieces independently, but not of the composition. > Haskell, here is your opportunity :-) you're just moving the problem to the correctness of the compiler.
    • petters 9y ago
      > you're just moving the problem to the correctness of the compiler But it would be a huge leap forward.
• yuhong 9y ago
  Interestingly, the paper mentions that CCMP is affected less than TKIP/GCMP, but not the FAQ.
• rightos 9y ago
  Those running the popular ESP8266 and ESP32 boards for various IoT devices: a fix has been published for the RTOS running on those boards. If you're building devices on these platforms, try to get this out to your customers as soon as possible. http://espressif.com/en/media_overview/news/espressif-releases-patches-wifi-vulnerabilities-cert-vu228519 http://espressif.com/en/media_overview/news/espressif-releas...
• hunter2_ 9y ago
  There is a lot of talk along the lines of "at least important things use HTTPS now." Well, for WAN traffic, that's largely true. For corporate/university intranets, not so much. For example, SMB (network shares) only supports encryption as of version 3.0, and a server admin who disables handshaking below v3.0 is disallowing Windows clients below 8. if (win7 && smb && wpa2) then vulnerable to password theft
• Cyphase 9y ago
  Wonderfully Poetic Acronym --- WPA Privacy Attack! Wi-Fi Protected Access Wasn’t Programmed Appropriately Wads of Potential Attacks Wireless Public Access Without Prior Allowance Well, Pretty Apocalyptic WoPA! When Patches Arriving? Wardrivers, Present Arms! Weaponized Privacy Assault Wardriving’s Productive Again Wide-open Point of Access Wrecks Privacy Automatically Welcome, Protocol Attackers Where Patches, Admin? Worthless Privacy Attempt Wrong Protocol, Admin Won’t Protect Anything Weak Privacy Attempt Waste of Precious Attention Wins Prying Award Wired Past, Again
• ryao 9y ago
  Just a FYI. Certain enterprise access points that implement counter measures against rogue APs should be able to thwart this attack. Here is a link to documentation of the feature in one such vendor’s products: https://docs.ruckuswireless.com/unleashed/200.5/t-EnablingDisablingRogueAPDetection.html https://docs.ruckuswireless.com/unleashed/200.5/t-EnablingDi... The AP will begin broadcasting deauth frames against the rogue AP as long as it sees it. There are probably some edge cases, but I would expect either the rogue and real APs will fight over the clients indefinitely (thwarting information leaks) or the attack code will trigger an exception and crash because what programmer would expect the client to immediately disconnect?
  • ryao 9y ago
    This project seems to enable the same thing on commodity hardware: https://github.com/moha99sa/EvilAP_Defender/wiki https://github.com/moha99sa/EvilAP_Defender/wiki Setup some RPis with WiFi dongles and you can likely make a perimeter defense. IANAL and I do not know how the FCC would view this, although I imagine it is not worse than the Ruckus APs that can do this, yet still passed their certification. This is not a substitute for patching devices, but it might help somewhat with devices that will never be patched.
• sengork 9y ago
  This might be a good time to switch off main SSID and exclusively use Guest SSID which is a feature in many routers. At least it would help to isolate wired computers away from the common wifi network. One could then safely use weird computers for sensitive communication. It might also be a good time to invest in NIC dongle manufacturers considering how many systems only ship with wifi.
• deleted 9y ago
  [deleted]
  • deleted 9y ago
    [deleted]
• ryanpcmcquen 9y ago
  Oh goodie.
• beauk 9y ago
  Is this a correct summary of this issue? Very much like a a copy-cat rouge open (non wep/wpa/wpa2) access point could be set up to trick wireless clients, and become a man-in-the-middle device, this attack, because of way WPA/WPA2 protocol lets nonces get reset to 0 with the same key, they can therefore can be predicted, and a WPA/WPA2 device can essentially become a MITM. And in the same way a public WAP can be used more securely, a VPN and HTTPS (assuming it's implemented correctly on the server), and SSH or other tunneling encryption standards, can be relied upon to mitigate this attack.
• Paianni 9y ago
  This was fixed in OpenBSD back in August.
• noir04 9y ago
  I'd assume that all vendors would be busy getting KRACK fixes out, but instead ASUS focuses on adding Facebook functionality to their routers.. https://www.asus.com/Networking/RTAC68U/HelpDesk_BIOS/ https://www.asus.com/Networking/RTAC68U/HelpDesk_BIOS/