Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Communications Wireless Networking

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

Posted by msmash from the security-woes dept.
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.
This discussion has been archived. No new comments can be posted.

WPA2 Security Flaw Puts Almost Every Wi-Fi Device at Risk of Hijack, Eavesdropping More

WPA2 Security Flaw Puts Almost Every Wi-Fi Device at Risk of Hijack, Eavesdropping

Comments Filter:

  • Finally! (Score:5, Informative)

    by khandom08 ( 1319863 ) on Monday October 16, 2017 @09:13AM (#55376753)

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

    • this just goes to show who is paying attention :

      https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4

    • What the fuck is Google going to do about Android? (Score:5, Insightful)

      by Anonymous Coward on Monday October 16, 2017 @09:50AM (#55376975)

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

      Recent stats [android.com] 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.

      • Re:What the fuck is Google going to do about Andro (Score:5, Interesting)

        by Anonymous Coward on Monday October 16, 2017 @09:58AM (#55377035)

        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.

        • Comment removed (Score:5, Informative)

          by account_deleted ( 4530225 ) on Monday October 16, 2017 @11:01AM (#55377499)
          Comment removed based on user account deletion

          • Re: (Score:2)

            by MrL0G1C ( 867445 )

            This is where it goes wrong, android updates should be automatic for all phones that have android unless it's a driver issue, which this isn't.

            I don't depend on ASRock or Intel to update my OS, Why should I depend on Samsung? Windows updates itself fine, as does Linux. But not Android, and it's clearly a system that doesn't work and will leave literally 100s of millions of devices open to being trojaned.

            Things won't change until Mega-Corp A sues Mega-corp B or Little-Corp C for allowing their devices to be

          • Bullshit. Almost every carrier-sold device has a locked bootloader, and some are even SIM-locked.

            A locked bootloader prevents you from:
            1) Rooting the device.
            2) Installing Lineage|Cyanogen|Any-other-OS.

            Whereas a non-carrier branded device can usually be unlocked and the OEM has infrastructure in place to enable it - see Xiaomi, Motorola (Lenovo), etc.

          • 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 o

        • It's the fucking telcos who are withholding updates from the end users.

          How is this true of Wi-Fi-only tablets or unlocked phones? For example, what power does Comcast have to withhold updates from my Wi-Fi-only Samsung Galaxy Tab A? That'd be like Comcast withholding updates from a Windows PC.

      • Re:What the fuck is Google going to do about Andro (Score:5, Informative)

        by Streetlight ( 1102081 ) on Monday October 16, 2017 @10:24AM (#55377225) Journal
        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.
      • Google is still providing support for Android 7, and 6, and 5, and 4. IIRC support for 4 ends next year. Carriers and/or handset manufacturers are the ones withholding updates.

      • Re:What the fuck is Google going to do about Andro (Score:4, Insightful)

        by mattventura ( 1408229 ) on Monday October 16, 2017 @11:27AM (#55377687) Homepage
        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.

        • 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.

          Android 8 "Oreo" introduces Treble [android.com], which begins to refactor Android toward what you expected: a stable driver ABI.

      • Re: (Score:2)

        by alexo ( 9335 )

        Google stops providing security updates for their devices 3 years after they are first available.
        I know that my Nexus 5 phone will not get patched by them.

    • Re:Finally! (Score:5, Interesting)

      by Solandri ( 704621 ) on Monday October 16, 2017 @09:59AM (#55377049)
      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).

      • Setting a pointer to NULL would still leave the old key in memory, defeating the purpose of zeroing the key...

        • Re: (Score:2)

          by Shinobi ( 19308 )

          Read carefully: He said that setting the pointer to NULL would be in ADDITION to zeroing the key, to reduce the risk of the key remaining in memory. Now, let's just hope the compilers don't pull any "clever" tricks to undo those measures.

          • Maybe he meant that, maybe he didn't.

            difference between setting something to NULL vs setting it to zero

            "vs" does not mean "in addition to"

            the value shouldn've been zeroed out

            Since "should've" isn't a word I know of, I'm assuming the typo was omission of the "t" not the addition of the "n".

            Parent DOES say "and" later in that sentence, so as I read it he/she is +2 for meaning "instead of", +1 for meaning "in addition to", and +100 for just in general not forming a coherent statement.

            • You can attack his syntax all you want, but since he was clearly describing behavior different than the behavior of wpa_supplicant, the meaning is clear that he is suggesting the behavior he illustrates be used instead.

              • I am disagreeing with the person to whom I am replying's assertion that I have poor reading comprehension. My point on its own is completely true, so really the only question here is my ability to understand the parent's post, which my previous reply showed was not very legible. I'll admit that I did not inspect wpa_supplicant's code, nor do I trust without doing so the general terms used by a researcher. I'm not really sure why this has garnered so much attention, or why I'm even continuing to reply, but t

      • No matter how you represent the key syntactically (as a string, as a reference to a string, with an additional 'bool key_valid' parameter, in hex or in base64) the underlying bug is a state machine bug.

        What you've said is true, because you are using the nullity of the key to represent state information (in fact, every mutable variable represents ...drumroll... program state). Specifically, you are definition a state transition rule that says that you cannot install a null key (OK) and that when you install

  • Going back to WEP (Score:5, Funny)

    by jfdavis668 ( 1414919 ) on Monday October 16, 2017 @09:25AM (#55376825)
    Since no one else uses it, WEP might protect you since people have given up looking for it.

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

      • 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 chan

        • Re: (Score:3)

          by fisted ( 2295862 )

          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.

      • Pretty sure they were making a joke, Admiral Aspergers.

    • Except that all WIFI hotspots announce that they have WEP or WPA2 so people would immediately know you're an easy target.

  • Internet of Things (Score:5, Insightful)

    by Kunedog ( 1033226 ) on Monday October 16, 2017 @09:32AM (#55376867)
    This would be a good time to point out how many vulnerable (and probably forever unpatched) devices would result from the push for IoT.

  • So which is it? (Score:5, Informative)

    by Solandri ( 704621 ) on Monday October 16, 2017 @09:36AM (#55376897)

    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?

    • 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?

      The flaw has nothing to do with passwords or pre-shared keys. All WPA2 devices are affected because the flaw is in the WPA2 protocol.

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

      Because some of those links don't give you the overall summary but delves into details. As a security researcher you would might find those links useful. As a regular person, it doesn't help you understand the fundamentals like: Who is affected? Everyone using WPA2. Everyone.

    • Watch the video [youtu.be] 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.
    • It appears that it is "worse" for pre-shared keys (attacker can do more nasty), but there are still problems for the non-pre-shared-key cases. Thanks for the links. Funny that it was actually already fixed in more recent versions of wpa_supplicant, it just wasn't known that it was security-critical.

  • TLDR; Replay packet 3 (Score:5, Informative)

    by complete loony ( 663508 ) <Jeremy.Lakeman@nOSpaM.gmail.com> on Monday October 16, 2017 @09:36AM (#55376899)

    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.

  • I wonder about an almost off-hand remark in section 6.2.
    "6.2 Example Attack Scenarios
    Among other things, our key reinstallation attacks allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data [37]"

    This implies that a "read only" (decrypt only) attack allows attacker to hijack the TCP stream. Can someone with better understanding of the issue explain this point? How can TCP connection be hijacked/modified if attacker has no ability to insert

    • Re: (Score:2)

      by Junta ( 36770 )

      I suppose that *if*: you were snooping a network you could also spoof ip for without being in the middle, you could knock the legit user off the network and assume their identity to continue the tcp session as you spoof them.

      Though in that scenario, I'd imagine it easier to just set up a fake hotspot that looks legitimate ,since that generally would be the case in say a public wifi spot. Also, not sure how many things in this day and age that are remotely sensitive would trust mere ability to continue a TC

      • At this point in time, you need to assume that any traffic stream not encrypted (and authenticated) is being intercepted, and we know that a lot of it actually is. Relying on wifi encryption to keep you safe is not going to do anything for you.

        The reason this is big news is because 'security' auditors love wifi: it's an easy way to attack the system, and even if they're too incompetent to find any other vulnerabilities, they can still 'prove' to the CxO team that they've found a vulnerability and made the
    • Watch the researcher's video [youtu.be] or Aruba Network's FAQ [arubanetworks.com]

      • Re: (Score:2)

        by ugen ( 93902 )

        Interesting FAQ, but has nothing related to my specific question, unfortunately.

        • From the FAQ:

          Q: What is the impact?
          A: When used successfully against WPA2 with AES-CCMP (the default mode of operation for most Wi-Fi networks), an attacker can decrypt and replay packets in one direction of communication (from client to AP), but cannot forge packets and inject them into the network. When used against WPA-TKIP – an encryption scheme that already suffers from serious security weaknesses and is not recommended for use – an attacker can decrypt, replay, and forge packets

  • Would it not be possible to prevent by setting up a RADIUS server?

  • Seriously, the whole design process of WIFI "security" is almost as badly broken as that of mobile phone security. Anybody sane tunnels over these connections, using a VPN or SSH, or the like for anything critical.

    And for all those confused: No, this is not HTTP security, i.e. SSL or TLS on TCP-Level (ISO/OSI Leyer 4), this is link-level security for the WIFI connection, i.e. below IP layer but above hardware (ISO/OSI layer 2).

  • Luckily my LMDE distro got a new wpa_supplicant this morning, I think this is to fix this, if yes, this is great!

  • Fix released for Linux (Score:3)

    by kbahey ( 102895 ) on Monday October 16, 2017 @11:40AM (#55377747) Homepage

    A fix was just released for Linux (e.g. Ubuntu [ubuntu.com] and derivatives).

    The phones and tablets will be the hard part here.

  • Lucky me!!! (Score:3)

    by Shotgun ( 30919 ) on Monday October 16, 2017 @01:28PM (#55378459)

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

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close