Slashdot Mirror


WPA2 Security Flaw Puts Almost Every Wi-Fi Device at Risk of Hijack, Eavesdropping (zdnet.com)

A security protocol at the heart of most modern Wi-Fi devices, including computers, phones, and routers, has been broken, putting almost every wireless-enabled device at risk of attack. From a report: The bug, known as "KRACK" for Key Reinstallation Attack, exposes a fundamental flaw in WPA2, a common protocol used in securing most modern wireless networks. Mathy Vanhoef, a computer security academic, who found the flaw, said the weakness lies in the protocol's four-way handshake, which securely allows new devices with a pre-shared password to join the network. That weakness can, at its worst, allow an attacker to decrypt network traffic from a WPA2-enabled device, hijack connections, and inject content into the traffic stream. In other words: hackers can eavesdrop on your network traffic. The bug represents a complete breakdown of the WPA2 protocol, for both personal and enterprise devices -- putting every supported device at risk. "If your device supports Wi-Fi, it is most likely affected," said Vanhoef, on his website. News of the vulnerability was later confirmed on Monday by US Homeland Security's cyber-emergency unit US-CERT, which about two months ago had confidentially warned vendors and experts of the bug, ZDNet has learned.

40 of 262 comments (clear)

  1. Finally! by khandom08 · · Score: 5, Informative

    Public announcement from Mathy Vanhoef is https://www.krackattacks.com/ and his research paper can be found https://papers.mathyvanhoef.co....

    1. Re:Finally! by Solandri · · Score: 5, Interesting
      From the paper and blog:

      In practice, some complications arise when executing the attack. First, not all Wi-Fi clients properly implement the state machine. In particular, Windows and iOS do not accept retransmissions of message 3 (see Table 1 column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake. Unfortunately, from a defenders perspective, both iOS and Windows are still vulnerable to our attack against the group key handshake

      So basically, Windows and iOS were protected for implementing 802.11 incorrectly.

      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. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key. 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.

      While Android got screwed over by implementing it rigorously.

      This should also become a programming example of the difference between setting something to NULL vs setting it to zero. Instead of implementing the encryption key as a string, it shouldn've been implemented as a pointer to the string. And when the standard called for the key to be cleared, the value shouldn've been zeroed out (to prevent it from being recovered in memory), memory released, and the pointer set to NULL (so the software would know the value didn't exist anymore and wouldn't try to use it).

    2. Re:Finally! by bill_mcgonigle · · Score: 2

      So, strangely, it almost seems like Windows and iOS are doing the right thing here. Allowing replay of packet 3 is the source of the attack and actually makes no sense from a cryptographic standpoint. Crap on MS and Apple all you want, but someone was paying attention and said "nooooope".

      Yup. And they chose to not disclose the vulnerability they discovered.

      This is where a guild system would be a useful overlay on the corporate system.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  2. Going back to WEP by jfdavis668 · · Score: 5, Funny

    Since no one else uses it, WEP might protect you since people have given up looking for it.

    1. Re:Going back to WEP by lucasnate1 · · Score: 2

      Aircrack, which is pretty popular, can hack WEP in a few minutes.

    2. Re:Going back to WEP by Seven+Spirals · · Score: 2

      Having run aircrack, several variants such as aircrack-ng, airsnort, and other WEP cracking tools, I call bullshit. They are terrible tools and rarely work as "advertised". Yes, I've been able to occasionally crack a WEP key on an AP. So, it's not like they are completely garbage. However, if you actually use these tools you'll find that they don't work "in a few minutes" in all but the very best scenarios. In many cases, when the AP attacks that force clients to re-init their keys (and thus give you a chance at the key part of the hack) don't work at all. Many AP's have code to mitigate this. Again, I'm not saying WEP is secure, I'm saying the folks who are claiming it can *always* be done or suggest that it's super easy haven't actually tried it.

    3. Re:Going back to WEP by fisted · · Score: 2

      For cracking WEP, all you need is to capture enough traffic. If the network isn't busy enough, replay ARP requests.

      I'm saying the folks who are claiming it can *always* be done or suggest that it's super easy haven't actually tried it.

      And I'm saying they folks who claim what you claim don't understand the attack in question and hence failed to pull it off.

  3. Internet of Things by Kunedog · · Score: 5, Insightful

    This would be a good time to point out how many vulnerable (and probably forever unpatched) devices would result from the push for IoT.

  4. So which is it? by Solandri · · Score: 5, Informative

    the weakness lies in the protocol's four-way handshake, which securely allows new devices with a pre-shared password to join the network. [...] The bug represents a complete breakdown of the WPA2 protocol, for both personal and enterprise devices

    WPA2 enterprise doesn't use a pre-shared key. So which is it? Does the weakness lie with pre-shared key passwords? Or something else which also affects WPA2 enterprise?

    Ah, here we go. The answer is "it's complicated." I'm reading through it right now, but as a PSA:

    In the future can we link to original source articles or responses by authoritative organizations, instead of trade rags?

    1. Re:So which is it? by UnknowingFool · · Score: 2

      Watch the video by the security researcher. The attack is successful because it's a man-in-the-middle attack (MITM). In the video, the hacker tricks the target's device into joining a rogue "testnetwork" that is not the real "testnetwork". As a MITM attack, any PSKs or specific username/passwords are given up by the target because it thinks it is on the real network.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    2. Re:So which is it? by UnknowingFool · · Score: 3, Insightful
      Perhaps you should actually watch the video put out by the security researcher or the FAQ put out by Aruba Networks.

      Care to explain or are you using the opportunity to prove your account name?

      Coming from an AC, that is ironic. How about: YOU FIRST.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    3. Re: So which is it? by UnknowingFool · · Score: 2

      Bold claims from an AC who doesn't understand what an encryption key is.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
  5. TLDR; Replay packet 3 by complete+loony · · Score: 5, Informative

    Replay packet 3 in the 4 way handshake, and the client will encrypt two different payloads with the same key and nonce. A big mistake with most encryption methods.

    Worse, linux wpa_supplicant nulls out the key memory but still processes the replayed packet, causing the client to use a known (zero) key.

    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  6. Re:Use HTTPS: by pak9rabid · · Score: 2

    Any why should it? Are you accessing or supplying anything that's top secret?

    P.S. The user authentication page does submit the user credentials via HTTPS: https://secure.zdnet.com/user/...

  7. Re:How serious is this? How exploitable is it? by Racemaniac · · Score: 4, Interesting

    it's an attack on the client machine, not on the access point.
    it means that any unpatched device connected to a wifi network with WPA2 encryption can expect the same security as being connected to an unsecured wifi (anyone can eavesdrop your communication, or could inject stuff, ...).
    how easy it is to do, don't know yet, but it seems to be a feasible attack to carry out.

  8. Re:How serious is this? How exploitable is it? by 140Mandak262Jamuna · · Score: 5, Informative
    Not remotely exploitable. So it is not going to infect like the heartbleed or shellshock

    Need to build a device with the special software and come within range of a router to sniff the keys. Then can eaves drop on communication between router and client.

    It will take a day at least to build it and then one has to come physically close.

    Vulnerable places will be coffee shops, malls, airports etc. Stores that use wi-fi between cash registers and router would be the primary target. BTW Target had security cameras and cash registers talking to the same router using same passwords. If I remember it correctly.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  9. Re:How serious is this? How exploitable is it? by khandom08 · · Score: 2

    Can anyone shed any light on how serious this actually is? How easy is it to exploit this?

    I don't want some theoretical answer, either. I want to know in very practical terms.

    Is this as bad as the "Shellshock" bash bug and the "Heartbleed" OpenSSL bug were, where systems were being compromised within hours of these bugs becoming widely known?

    From the disclosure:

    When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.

  10. Re:How serious is this? How exploitable is it? by khandom08 · · Score: 5, Informative

    No it is an attack on both. Though it appears that patched clients would be safe while connected to an upatched AP.

  11. What the fuck is Google going to do about Android? by Anonymous Coward · · Score: 5, Insightful

    I'm really fucking concerned about how Google will fix this for Android, the most popular OS in the world.

    Recent stats are showing that only 0.2% of users are using Android 8.0, the latest version. Only about 18% are using Android 7.x releases. A whopping 32% are using Android 6.x! About 28% are using Android 5.x! About 21% are using Android 4.x!

    So like 80% of Android users are still using Android 6.x and earlier!

    If this problem can be avoided with a software fix, I think that Google should do everything they possibly can to get this fix to as many Android devices as possible.

    I'm sure some fools here will come along and just tell affected users to "buy a new phone" or some infeasible bullshit like that. Realistically, that's not happening. Users will continue to use their older devices. It will reflect badly on Android if it's susceptible to this wifi security issue, even on older devices.

    While they obviously can't provide updates to all of the Android devices out there, I really hope that Google will do what they can to get the fix to at least all Nexus and Pixel devices from the Nexus 4 onward.

    The most sensible solution would be to fix it in Android 8.x, and then port Android 8.x to the Nexus 4 and all devices after it. Then this release would be made available to those who wish to upgrade. Not only would this fix this wifi problem, but it would also help fix at least some of the serious version fragmentation that Android is currently experiencing.

  12. Re:Use HTTPS: by sims+2 · · Score: 2

    Well I have an ISP that likes to inject stuff into unencrypted connections is that not reason enough to prefer https sites?

    --
    Minimum threshold fixed. Thanks!
  13. Re:How serious is this? How exploitable is it? by Junta · · Score: 2

    an expect the same security as being connected to an unsecured wifi

    Not quite that bad. An unsecured wifi can have packets manipulated, and can snoop both directions. Here the attack cannot change any of the data and can only read one direction of the communication. Still pretty bad, but no reason to suddenly not care about open networks versus secured networks.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  14. Re:How serious is this? How exploitable is it? by Junta · · Score: 5, Informative

    And vice versa, a patched AP can prevent a client from breaking. One or the other side needs to prevent it, but either side by itself is sufficient.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  15. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 5, Interesting

    If this problem can be avoided with a software fix, I think that Google should do everything they possibly can to get this fix to as many Android devices as possible.

    Google can't do anything about that.

    It's the fucking telcos who are withholding updates from the end users. Even if you have the patched version on your hard drive, you can't install it, because your wireless provider won't let you. Verizon is the most egregious offender; as long as they continue to refuse to sell devices with unlocked bootloaders, the only way to install an update is when the telco feels like pushing it to the users.

  16. Re:How serious is this? How exploitable is it? by Junta · · Score: 4, Informative

    Note that I would *hope* point of sale equipment and security equipment would use TLS regardless of the media. If that were the case, then the WPA2 weakness would not suddenly provide access to that material.

    For a private laptop connecting to public wifi-hotspots, this attack is harder than just setting up another credible wifi hotspot. Any place where the wifi password is well known knowledge is never going to be rigorous security.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  17. Re:How serious is this? How exploitable is it? by Streetlight · · Score: 4, Insightful

    Some years ago it was reported that a large liquor store in our town was using unencrypted communication between cash registers and an on site computer. They got hacked by someone outside the store in the parking lot. After that discovery and for a while they were using the old fashion carbon paper swipe devices for embossed credit cards or took only cash. The problem was solved by replacing cash registers with ethernet wiring.

    The lesson here may be to use the ethernet connection on your laptop when possible for sensitive data use until its WPA2 software is updated. Oh, wait, most new laptops and certainly phones don't come with ethernet connectors and would require a dongle. Ah, the wonderful advances brought to us by ultra thin, lightweight portable computing.

    --
    In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
  18. Re:MitM are not newsworthy by UnknowingFool · · Score: 3, Insightful

    Man In The Middle attacks are not newsworthy and should not be making the front page of Slashdot, these are the equivalent of anti-Trump garbage that floods #fakenews sources.

    So a flaw that affects every single Wifi network isn't newsworthy? Repeat: Every single Wifi network. Facts don't matter then to you. From what I can tell not all vendors have supplied patches yet so most people are vulnerable as they are unpatched.

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
  19. Re:What the fuck is Google going to do about Andro by Streetlight · · Score: 4, Informative

    I'm not sure older devices have the hardware capable of supporting Android 8.0.0, aka, Oreo. Even phones a couple of generation old would likely would become unacceptably slow with the newer OS. A huge majority of Android devices are not Nexus or Pixel devices and generally not updated by the carriers. Even older Nexus devices are not guaranteed security updates by Google.

    The best thing might be for Google to provide appropriate security patch software for WPA2 for all versions of Android to carriers but it's likely they would never reach customer phones.

    --
    In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
  20. Re:How serious is this? How exploitable is it? by UnknowingFool · · Score: 2

    For a private laptop connecting to public wifi-hotspots, this attack is harder than just setting up another credible wifi hotspot. Any place where the wifi password is well known knowledge is never going to be rigorous security.

    The attack doesn't rely on knowing or compromising the password or securing the network at all. What happens is an attacker sets up "CafeNetwork" on a different channel than "CafeNetwork". A device can connect to rogue "CafeNetwork" assuming it is the real one. As a MITM attack, the rogue network can listen in on traffic. If the traffic was previously encrypted with HTTPS, it provides some security but it is not foolproof.

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
  21. Re:How serious is this? How exploitable is it? by SethJohnson · · Score: 5, Insightful

    "Not remotely exploitable."

    The security industry would define this as a remote exploit as it does not require physical access to any of the devices nor does it require the attacker to be logged into the target devices. While the attack would result in decrypting any clear text being sent over wifi, the saving grace is that an increasing amount of traffic is sent via HTTPS or SSL, which would provide an additional barrier to an attacker seeing login credentials for remote websites, etc.

    The most dramatic concern here is that non-HTTPS traffic is prone to injection of malware and exploitation of vulnerabilities on the client devices. Even if a user doesn't browse a sketchy website, suddenly a site like slashdot.org might seem to send code to a user's phone or laptop that could perform a remote code exploit.

    As 140Mandak suggests, it would be trivial to assemble a cheap box (think raspberry pi 3) that sits at a public wifi location and automatically attempts to hack all older Android phones that connect to the network.

  22. Re:How serious is this? How exploitable is it? by Gr8Apes · · Score: 2

    Running your own SSH tunnel for all communications is pretty standard when connecting anywhere. If it's not your wifi, it's not secure. That should be a mantra for everyone.

    --
    The cesspool just got a check and balance.
  23. Re:What the fuck is Google going to do about Andro by squiggleslash · · Score: 4, Informative

    The telcos have absolutely nothing to do with updates for Android phones, with the exceptions of those that they themselves have branded. It's the manufacturers who are responsible. Your comments were sort-of true for the previous generation of feature phones, but Android devices aren't something telcos have control over.

    The problem here is that manufacturers have few incentives, apparently, to keep Android devices up to date.

    --
    You are not alone. This is not normal. None of this is normal.
  24. Re:MitM are not newsworthy by barbariccow · · Score: 3, Insightful

    Why pay the troll to use his/her bridge when you can just step over the creek?

  25. Re:What the fuck is Google going to do about Andro by mattventura · · Score: 3, Insightful

    This was my main disappointment with Android. I had hoped that it would be google, not the carrier or handset manufacturer providing updates. The manufacturer would provide drivers for the hardware, but Google would take care of the rest, similar to how MS rather than a PC manufacturer handles Windows updates. Instead it’s a fragmented mess.

  26. Fix released for Linux by kbahey · · Score: 2

    A fix was just released for Linux (e.g. Ubuntu and derivatives).

    The phones and tablets will be the hard part here.

  27. Re:How serious is this? How exploitable is it? by Strider- · · Score: 2

    If it's not your wifi, it's not secure.

    To be honest, I don't get this. Who cares if a network operator, or the person sitting next to you at a cafe next to you is snooping your data? With the advent of https everywhere, the data between my computer and the server is encrypted and secure, regardless of whether the underlying transport is compromised.

    You always need to consider that the underlying network is insecure. I'll happily do my banking over public wifi, or satellite internet (where the packets are broadcast to the entire continent), because all an adversary sees is a stream of gobblygook.

    --
    ...si hoc legere nimium eruditionis habes...
  28. Re:How serious is this? How exploitable is it? by mikael · · Score: 2

    Many bar and restaurants have wireless card readers which use wi-fi.

    --
    Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  29. Lucky me!!! by Shotgun · · Score: 2

    I have one of the TimeWarner (now Spectrum) wifi modems. The thing will barely reach across my apartment, so I'm safe.

    --
    Aah, change is good. -- Rafiki
    Yeah, but it ain't easy. -- Simba
  30. Re:For now... by Junta · · Score: 2

    Tomorrow's news story: critical security flaw found in LTE!

    --
    XML is like violence. If it doesn't solve the problem, use more.
  31. Re:How serious is this? How exploitable is it? by Junta · · Score: 2

    Of course, I bothered to look at at least one version of the PCI DSS spec:

    This means all CDE data must be encrypted as suggested in PCI DSS
    Requirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such as
    AES that is used within WPA2 to provide confidentiality and integrity at the wireless link layer.
    Higher layer encryption methods such as SSL/TLS and IPSEC and could be used to provide endto-end
    cryptographic protection of card-holder data.

    So it *looks* like it may have considered WPA-2 built in encryption sufficient, but 'recommended' TLS/IPSEC.... So contrary to common sense there could be implementations with weakness...

    --
    XML is like violence. If it doesn't solve the problem, use more.
  32. Re:What the fuck is Google going to do about Andro by thegarbz · · Score: 2

    but Android devices aren't something telcos have control over.

    I take it you're not American? Yeah in most of the world the telcos in general don't get in the way much. However in America, the latest and greatest Android phones are telco specials, telco controlled, with telco specific firmware.

    For example if you're the owner of a Galaxy S7 in the USA you will have one of these models depending who you buy it from:
    SM-G930U
    SM-G930V
    SM-G930VL
    SM-G930AZ
    SM-G930A
    SM-G930T1
    SM-G930R6
    SM-G930R7
    SM-G930P
    SM-G930T
    SM-G930R4

    If you're in Europe / The rest of the world with the exception of South Korea you will have:
    SM-G930F
    Or the dual sim model: SM-G930FD

    Each of these have custom firmwares, and the US carriers are notoriously bad at providing firmware updates.
    Mind you all of this is irrelevant since the OP was quoting Android core OS versions and not security updates. Even KitKat phones still receive security updates through some vendors, and yes even American Telcos will sometimes roll these out to customers, albeit a bit later than the international firmware.