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.

262 comments

  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 barbariccow · · Score: 1

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

    3. Re:Finally! by Shinobi · · Score: 1

      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.

    4. Re:Finally! by Anonymous Coward · · Score: 0

      Instead of implementing the encryption key as a string, it shouldn've been implemented as a pointer to the string.

      All strings are implemented like this:

      "a string" => { 'a', ' ', 's', 't', 'r', 'i', 'n', 'g' } => offset + (sizeof(char) * 0x0) = 'a', offset + (sizeof(char) * 0x1) = ' ', offset + (sizeof(char) * 0x2) = 's', offset + (sizeof(char) * 0x3) = 't', offset + (sizeof(char) * 0x4) = 'r', offset + (sizeof(char) * 0x5) = 'i', offset + (sizeof(char) * 0x6) = 'n', offset + (sizeof(char) * 0x7) = 'g', offset + (sizeof(char) * 0x8) = '\0'.

      You can't reference a string composed of multiple values at the hardware level without some pointer to it. It's an array of a datatype not a datatype in and of itself. (Granted if it was guaranteed to always be small enough, you could shove it into a float register or something, but lets avoid that discussion for the moment as no sane compiler will generate code like that.)

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

      The code in wpa_supplicant probably just didn't clear the pointer, but even so, if the function's job was to NULL the string out when it was done setting the key, then the same function should have been checking to see if the pointer was NULLed out before setting the key from it. (And if you are allowing someone to set an all zero key, you had best do some other check to make sure that was explicitly requested of you by the user before doing so.)

      That's the rub, the code must actually check for this condition. wpa_supplicant didn't check it, probably making the assumption that by the point that the key set command would be sent to the hardware, it had been checked multiple times already. The alternative for not checking is a segfault, assuming they cleared the pointer, which they didn't. So, Exploit Achieved. It's a double fault in the programmer.

    5. Re:Finally! by Wrath0fb0b · · Score: 1

      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 a key you must set it to NULL (OK). That's reasonable, although it's against the (ill-advised) logic of the 802.11 spec saying that MSG3 can be re-transmitted.

      In your state machine (and anyone else that implements it, regardless of whether they represent it in memory the way you suggest, link-level failures of MSG3 require that you go back to the start. Which is probably the simplest design that maintains the security properties that we want -- and the cost is fairly minor.

    6. Re:Finally! by barbariccow · · Score: 1

      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.

    7. Re:Finally! by Anonymous Coward · · Score: 1

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

    8. 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)
    9. Re:Finally! by bill_mcgonigle · · Score: 1

      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.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    10. Re:Finally! by barbariccow · · Score: 1

      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 this will be the last.

    11. Re:Finally! by swilver · · Score: 1

      This sounds more like a lack of unit testing... or perhaps, if programmers discovered this hole in the spec during implementation (which they often do), being overruled by incompetent members of committee.

    12. Re: Finally! by Brockmire · · Score: 1

      When someone makes up words, just walk away. There's no point arguing or correcting.

    13. Re: Finally! by Brockmire · · Score: 1

      This is an issue for association reliability. I was testing our WPA2 implementation a decade ago, and missing a MSG in the 4 way handshake is pretty common. I can only imagine it being much worse with more interference and more devices than my lab setting ages ago.

    14. Re:Finally! by thegarbz · · Score: 1

      The problem was one in the standard itself, and Windows wasn't immune to it. Though it is now. Microsoft patched it ahead of release last Tuesday, and only since then has Windows ignored the re-transmissions.

    15. Re:Finally! by Anonymous Coward · · Score: 0

      I've never considered any WiFi secure and have thus taken precautions. I'm now wondering whether those are enough.

      My WiFi can't communicate with any of my internal machines except via a VPN port which can only go to my internal VPN host. Am I good or does this leave the client so vulnerable that the VPN credentials can be compromised?

    16. Re:Finally! by Anonymous Coward · · Score: 0

      Too bad they implemented in C instead of Java where they would not have had this problem.

  2. Use HTTPS: by Anonymous Coward · · Score: 0

    As long as you use HTTPS protocol, the eavesdrop will be limit to what web site you visit, but not content of website. Nice workaround.

    1. Re:Use HTTPS: by Meneth · · Score: 1

      Good thing the article is served via HTTPS, eh? Oh wait, zdnet, supposedly a techology news site, DOES NOT SUPPORT HTTPS!

    2. Re:Use HTTPS: by Anonymous Coward · · Score: 0

      Yeah and how does that protect an SMB share? Better hope you're fully patched and have strong passwords.

    3. Re:Use HTTPS: by Anonymous Coward · · Score: 0

      As long as you use HTTPS protocol, the eavesdrop will be limit to what web site you visit, but not content of website. Nice workaround.

      I wonder what the workaround is for organizations who felt the need to appease the wireless generation, and run WiFi on corporate networks?

      Not every networking protocol can be encapsulated in HTTPS (just ask Active Directory), and eavesdropping to learn even internal hostnames is elevating risk.

      Cue the mandatory VPN tunneling policy for all wireless connections in 3...2...

    4. Re:Use HTTPS: by Anonymous Coward · · Score: 0

      Huh? Here's the serial number of the sha256 cert issues to slashdot.org from Let's Encrypt for the https connection I'm currently using. Why do you say https isn't supported?

      03 6c ca 28 d3 67 81 56 1c 8d e6 31 9f 9f d4 ad f0 60

      Did you mean to say Unicode?

    5. Re:Use HTTPS: by jabuzz · · Score: 1

      Maybe enable encryption in SMB? What you are still using SMB1, well more fool you then. It's 2017 the world has moved on.

    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:Use HTTPS: by Lunix+Nutcase · · Score: 1

      Not if the attacker was also able to man-in-the-middle attack you as well.

    8. Re:Use HTTPS: by Anonymous Coward · · Score: 0

      When you say Unicode did you miss that the GP was talking about zdnet and not slashdot ?

    9. Re:Use HTTPS: by unrtst · · Score: 1

      Not every networking protocol can be encapsulated in HTTPS ...

      Exactly. I was going to mirror an above AC who said, "I'm surprised that this still needs saying on an allegedly technical forum", but he was implying HTTPS was all you needed (wrong).

      ... (just ask Active Directory)

      OH FFS! That's one of the easiest ones to move to a secure protocol - LDAPS (it even has its own extra protocol version that adds the SSL/TLS, but can also upgrade an LDAP connection via TLSStart).

      Plenty of traffic is sent in the clear, and those are all better examples than HTTP/HTTPS and LDAP/LDAPS.

      SSL attacks generally require a man-in-the-middle position, which this hack can provide. That should be a bigger concern.

    10. Re:Use HTTPS: by Anonymous Coward · · Score: 0

      Huh? Here's the serial number of the sha256 cert issues to slashdot.org from Let's Encrypt for the https connection I'm currently using. Why do you say https isn't supported?

      03 6c ca 28 d3 67 81 56 1c 8d e6 31 9f 9f d4 ad f0 60

      Did you mean to say Unicode?

      He said ZDNET does not support https. Get some fucking reading comprehension, you're embarassing yourself.

    11. 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!
    12. Re:Use HTTPS: by Junta · · Score: 1

      Of course, strictly speaking LDAPS isn't over https. Of course it is over TLS which is the actual relevant part of the discussion (before someone goes off on insisting that LDAP needs to be over *http*).

      Of course, it should be considered a grave problem if any sensitive data relies upon the security of the LAN, considering a large chunk of network access is over an untrusted hotspot (no, that WPA2-PSK in the store with a legit-looking captive portal or the passphrase on the wall, or really any internet connection when you get down to it is not trusted).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    13. Re:Use HTTPS: by Anonymous Coward · · Score: 0

      When you say Unicode did you miss that the GP was talking about zdnet and not slashdot ?

      Indeed I did! Thanks for the heads up. My apologies to the GP.

    14. Re:Use HTTPS: by Lunix+Nutcase · · Score: 1

      Reading comprehension? Do you have it?

  3. The obvious answer by Anonymous Coward · · Score: 1

    Don't use wifi, or wired, or bluetooth, or zigbee, or zwave. Instead live in a cabin in the middle of the woods aware from technology, just don't pull a Kaczynski, please.

    1. Re:The obvious answer by Anonymous Coward · · Score: 0

      *away

  4. Looks like that CAT 5 is looking better every day by Anonymous Coward · · Score: 1

    At least for in the home !

  5. The Web is not the Internet by Anonymous Coward · · Score: 0

    I'm surprised that this still needs saying on an allegedly technical forum.

  6. Updates by Anonymous Coward · · Score: 0

    As of a few hours ago, some vendors are already offering beta updates. EOL-ed devices are fucked as usual,. Hopefully there's a way at the AP level to detect and block clients that haven't been patched for this vulnerability, or if it's even possible... As I know, backwards compatibility inherently exists between patched and unpatched so as to not break the WPA2 standard.

  7. 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 khandom08 · · Score: 1

      Right and with tools like kismet/or whatever they're using now, it's rather easy to determine which AP you will attack based upon protocol.

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

    4. Re:Going back to WEP by ckatko · · Score: 1

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

    5. Re:Going back to WEP by Lunix+Nutcase · · Score: 1

      Pretty sure they were making a joke, Admiral Aspergers.

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

    7. Re:Going back to WEP by Anonymous Coward · · Score: 0

      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.

      I don't know about always, but the time I tried it I remember cracking a WEP network was trivial when I finally found a working combination of OS, drivers, software and hardware.

    8. Re:Going back to WEP by Anonymous Coward · · Score: 0

      Yeah I have been able to crack 128 bit WEP keys is about 30 minutes using those same tools. I guess your definition of "super easy" and "in a few minutes" are different than mine.

    9. Re:Going back to WEP by Anonymous Coward · · Score: 0

      Aircrack got me free internet throughout college.

    10. Re:Going back to WEP by Anonymous Coward · · Score: 0

      You might want to learn how to use the tools better, back in the day i was able to crack my own WEP key in usually less than 5 minutes no matter how "secure" of a password I had chosen.

      Not that there is really a point to WEP cracking these days. It is so rare to see out in the wild these days. A lot of the older WEP only APs are probably long since failed due to bad caps and the like. Most of the stuff that has shipped in the last half decade comes with WPA on by default. Question will be how many of these vulnerable WPA APs will be in the wild unpatched for some time? It has only been recently that some of the vendors have started putting auto updates on their routers/aps. Up until I got my linksys WRT1200AC router, patches were still being done the old fashioned visit in manufactures website, download the .BIN file and flash, Now they will auto update and restart themselves overnight. And since we are past the bad cap fiasco in the early 2000's some of this hardware might actually have a chance of lasting more than a couple years.

    11. Re:Going back to WEP by Anonymous Coward · · Score: 0

      You obviously didn't use methods like ARP replaying to speed up the gathering of enough data to crack it quickly. Using that method there was no key I could not crack in less than 5 minutes.

      If you aren't ARP replaying, then you are relying on how busy the WEP network is, If it is seldom used it might take hours or days, or minutes if someone is in the middle of a large file transfer or streaming. WEP cracking is all about capturing as many packets as possible as quickly as possible.

    12. Re:Going back to WEP by Anonymous Coward · · Score: 0

      Could turn off SSID broadcast. It's not bulletproof but for the casual cracker there will be much lower hanging fruit blasting out its SSID

    13. Re:Going back to WEP by Anonymous Coward · · Score: 0

      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.

      That's not for WEP. As you've been told, WEP is very easy to crack. One packet captured is enough to allow you to brute force the password. Enough data (not really that much) and you can always crack it. Luckily, almost no one uses WEP any more. Most people use WPA or hopefully WPA2 now. As you say, those are (were) harder to crack.

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

      Wrong. I understand the attack fully. What I'm telling you is that the methods used to create spurious traffic are being mitigated. The target AP temporarily stops responding to ARP requests at a useful rate to generate adequate traffic. Work on your reading comprehension. It would appear *you* illustrate exactly what I'm saying: someone who read about the attack, but hasn't tried it widely or recently.

    15. Re: Going back to WEP by Brockmire · · Score: 1

      Sure, if you're an idiot, you can believe that does anything more than sweet fuck all.

    16. Re:Going back to WEP by fisted · · Score: 1

      Then you add in a little pationce, let the clients and their constant telemetry build up a useful amount of traffic themselves.

      Personally I have of course never attacked any WEP network myself, but a friend of a friend did a healthy amount of that and told me all about it.

      You're right in that it's been a while since, then again, ARP replay is only one/the most obvious way of generating traffic. There is a lot of packets that when replayed will still produce some sort of a response (if only ICMP or TCP RST) so I doubt this is actually as difficult to pull off these days as you say.

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

      You can't simply generate any type of traffic. It works based on a weakness in the key scheduling algo which needs ciphertext from the initialization vector. That's why replaying ARP usually works, it resets the state in such a way that new IV's are generated. Just grabbing random ciphertext out of the air won't do squat unless it's got that bit of conversation present. That's also why manufacturers have limited the number of responses to ARP "who-has" requests to mitigate the attack, make ARP spoofing less effective, and generally screw up the attack and make it either untenable or take for-freakin-ever. Maybe "your friend" who actually spent some time on the metal and actually *tried* it can give you a clue. I never said cracking WEP was impossible, I'm saying it's oversimplified by blow-hard 37337 h0x0xrs who have never tried it but talk a good game online and is now mitigated to be a bigger PITA. I've been *plenty* successful at doing it and I do security scans on a regular basis, which include this type of activity. Folks just aren't keeping up with the state of where WEP cracking is *today* and just hand wave it off saying it can be done easily in a few seconds, which isn't true very often these days.

    18. Re:Going back to WEP by fisted · · Score: 1

      If grabbing a random ciphertext [that I know is an ARP request] off the air and replaying that results in the AP receiving a legitimate ARP request, then why can't I grab a ciphertext that I know (or suspect) to be, say, a DNS request directed at the AP, out of the air and replay that in order to make the AP see another such DNS request that it's going to reply to?

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

      Of course you *can* replay the traffic. That's not the point. The point is that a device with mitigation code can slow down the ARP responses to a level that you simply can't do it fast enough to gather enough of of the traffic with IV's in-session to crack the keys without spending days or weeks gathering the data. This was the original point - the current WEP attacks are often mitigated and take way longer than they did previously making them much more onerous to pull off (not impossible, just extremely inconvenient).

    20. Re:Going back to WEP by fisted · · Score: 1

      Okay, but if grabbing a random ciphertext [that I know is an ARP request] off the air and replaying that results in the AP receiving a legitimate ARP request, then why can't I grab a ciphertext that I know (or suspect) to be, say, a DNS request directed at the AP, out of the air and replay that in order to make the AP see another such DNS request that it's going to reply to?

  8. Re: Can't wait for WPA3... by Anonymous Coward · · Score: 0

    Sounds like itâ(TM)s the new WEP.

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

    1. Re:Internet of Things by Anonymous Coward · · Score: 0

      This will be a biggie. Especially for arduino type stuff that the average arduino code monkey can't even access or doesn't know enough about the wifi layer to patch it. It is going to take patches from the hardware manufactures and libraries to be updated and the code monkey recompiling their code with the IDE patched for the vulnerability.

      If you are using an arduino to talk to something like an ESP8266 serially, then you are totally reliant on the binary blob in that ESP8266 getting updated and knowing how to update it. My guess if you are using an ESP8266 in this manner you probably haven't a clue. If you have a clue, ditched the arduino and are running your code directly on the ESP8266 (its hell of a lot more capable platform used this way than arduino for those not in the know), then just the libraries being updated in the IDE and code recompile should probably fix it.

    2. Re:Internet of Things by thegarbz · · Score: 1

      Sure by while you're pointing that out also point out that:
      a) you've only broken the first layer of defense and will likely have several other layers to overcome (e.g. SSL)
      b) it's an IoT device, so ... by all means please hack me and turn my heater up.

      This is WiFi snooping. You shouldn't be doing ANYTHING you don't want monitored over WiFi even if your WiFi is encrypted without using some secondary layer of defense (e.g. VPN, SSL, both, etc).

    3. Re: Internet of Things by Anonymous Coward · · Score: 0

      Oh that's what you think the vulnerability of IoT is?
      Doing the thing it's made to do?
      No, it'll be used in mining and DDoS attacks and to pivot to other devices since it's already in your network.

      You already admitted your device could be hacked, don't expect hackers to do what you would do with your device.

  10. How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

    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?

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

    2. 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
    3. 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.

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

    5. 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.
    6. 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.
    7. 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.
    8. 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
    9. Re:How serious is this? How exploitable is it? by khandom08 · · Score: 1

      According to Vanhoef, when using WPA-TKIP or GCMP for encryption the bad actor can decrypt, forge and inject packets.

    10. 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.
    11. 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.

    12. 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.
    13. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      fantastic, so we moved from the "i can crack your wep so i have some conectivity in case of an emergency" into the "i can crack your wpa2 and since i wont have your wifi pass then i will sslstrip, ettercap and whireshark the FUCK out of you"

      i dont know you guys, but the conectivity alternate timeline was cooler and nicer to me

      this attack is pretty useless unless you are a total asshole, you cannot even be a simple collector of wifi passwords with this thing (a simple hobby like any other)

    14. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      I try to do this often, I use sshuttle which is a nice fast ssh-tunnel as VPN (faster than actual VPN protocols in-fact due to un-nesting of TCP packets.).

      I have this on a system wide key-binding... but even so, using it for everything always eats up some overhead and more significantly can add significant latency. So you naturally end up turning it off most of the time and then unfortunately forget to turn it on when it's important.

    15. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      I would 'HOPE' point of sale equipment was wired and not WIFI.

    16. 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...
    17. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      what about someone browsing your computer... not everything is about the Internet.

    18. 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
    19. Re:How serious is this? How exploitable is it? by tepples · · Score: 1

      Note that I would *hope* point of sale equipment and security equipment would use TLS regardless of the media.

      If a server on a LAN doesn't have its own FQDN, what certificate would its TLS use? Well-known CAs require a FQDN.

    20. Re:How serious is this? How exploitable is it? by KiloByte · · Score: 1

      If it's not your wifi, it's not secure. That should be a mantra for everyone.

      Why would I trust "my" wifi either? There's too many devices in the house, some of which are unpatchable by everyone other than the vendor (ie, no patches, ever).

      But that's not a concern: if you are already prepared for anyone outside trying to hijack your connection, the first hop is not any different.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    21. Re:How serious is this? How exploitable is it? by Marxist+Hacker+42 · · Score: 1

      Isn't that what endpoint vpn tunneling is for?

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
    22. Re:How serious is this? How exploitable is it? by Gr8Apes · · Score: 1

      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?

      Because, for starters, you get around the whole MITM should any of this be compromised. Furthermore, as I use keys, the entire process is relatively secure and more importantly, it's transparent and easy to use. Finally, there are things you do that may or may not be across secure links, and I'm perfectly find with everything being guaranteed to be at least secure to a known connection.

      --
      The cesspool just got a check and balance.
    23. Re:How serious is this? How exploitable is it? by Gr8Apes · · Score: 1

      The other end of my connection is 100/100 minimum with low latency to the backbone, so the small additional latency over the whatever wifi connection to begin with normally isn't an issue.

      --
      The cesspool just got a check and balance.
    24. Re:How serious is this? How exploitable is it? by Gr8Apes · · Score: 1

      Probably because my internal wifi is relatively locked down to known MACs, etc. Yes, stuff can be spoofed, but I just don't have that level of paranoia. If it came down to that, I think I'd have bigger issues to worry about. However, that said, the number of devices in my house on wireless is less than a handful. almost everything is hard-wired.

      --
      The cesspool just got a check and balance.
    25. Re:How serious is this? How exploitable is it? by ebyrob · · Score: 1

      It's what layered security is for, sounds like yours is working if you use VPN tunneling over your Wifi...

      It's still good to fix that bad layer before something else fails though.

    26. Re:How serious is this? How exploitable is it? by Junta · · Score: 1

      That's my point, that this attack is only valuable if you don't know the PSK. In most public wifi locations, you know the PSK. (Simplified to speak only to WPA-PSK).

      So the juicy targets would mostly be home networks and corporate wireless that laptops get on. Practically speaking though it would be much easier for PoS to reliably be secure regardless of the user, they probably send credit cards through telnet or some crap.

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

      Disclaimer, I *hope* but realistically these things may be lax.

      TLS on private networks is a well known entitiy. The usual flow is using an extra CA to validate the certs that has no meaning outside that private network.

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

      Didn't catch the part about GCMP, hopefully for once sluggish wifi implementations being behind the curves mean most are using CCMP.

      TKIP should already not be in use for many reasons.

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

      and card data is never supposed to be transmitted in clear text, or they fail PCI DSS

    30. 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.
    31. Re:How serious is this? How exploitable is it? by slinches · · Score: 1

      Couldn't somebody do that with any public wifi network as soon as they get the password? I mean, this will make it harder for the wifi provider to shut the malware server down as changing passwords won't work, but it still only allows access to join the network.

      --
      Knowledge Brings Fear
    32. Re: How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      Many corporate WiFi networks are visible outside their building or floor.

    33. Re:How serious is this? How exploitable is it? by Drakonblayde · · Score: 1

      It's not a single attack vector. There are multiple CVE's for this. Some attack vectors do involve the AP, most involve the client. Both should be patched.

    34. Re:How serious is this? How exploitable is it? by thegarbz · · Score: 1

      Defense in depth. If you come to my house I will happily give you my wifi access code. It's only 1 small part of the security process.

    35. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 1

      A patched AP won't fix this. This is an attack against WiFi clients only.

    36. Re:How serious is this? How exploitable is it? by UnknowingFool · · Score: 1

      That's my point, that this attack is only valuable if you don't know the PSK. In most public wifi locations, you know the PSK. (Simplified to speak only to WPA-PSK).

      Knowing the PSK does not mean you can snoop on someone else's traffic unless you've compromised the AP. Whether you know the PSK of "CafeNetwork" does not mean you can listen to John Doe using the same network. This attack lets you eavesdrop on a device.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    37. Re: How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      The ap vector only applies if the ap is actiong as a client to another ap (forwarding)

    38. Re: How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      Yes because everything ever done on the internet involves a web server. Sigh.

    39. Re: How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      My computer don't let others 'browse' it just because they are on the same net. Why should it?

    40. Re:How serious is this? How exploitable is it? by Junta · · Score: 1

      If you know the PSK, then you can set up your own AP with the same SSID as the legit AP. The client doesn't know which one is the 'correct' "CafeNetwork". You don't have to compromise the AP to do that, you have enough knowledge to impersonate it. In both cases the client wants to get to the internet, so it's not like that AP provides something uniquely qualifying it other than the correct PSK.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    41. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      It may technically be using both the AP and client to do the attack but only the client is affected by the attack.

      All the attack is doing is making the client connect to a rogue network instead of the one it intended to connect to.

      How could it be used to exploit anything on the AP?

    42. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      Under WPA2 the pre-shared key is only for authentication. Each client still negotiates for their own private encryption key. The discovered attack lets you break that individually negotiated encryption key.

      Now, of course, if you know the pre-shared key you can possibly do other attacks like ARP spoofing on the wifi network, or setting up another access point with the same SSID and pre-shared key to trick people to join your router instead.

    43. Re:How serious is this? How exploitable is it? by Anonymous Coward · · Score: 0

      Not totally true. A patched AP would still allow an attacker to connect the client to their own network. The attacked client wouldn't have access to the internal network of the AP but would still be vulnerable to MITM attacks on the Internet (the attacker would just route the client via their own Internet connection).

    44. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      Didn't catch the part about GCMP, hopefully for once sluggish wifi implementations being behind the curves mean most are using CCMP.

      TKIP should already not be in use for many reasons.

      CCMP always had higher security bounds than GCMP. GCMP exists for speed only because it is parallelizable and GCM was initially introduced for ethernet linksec as a workaround for the OCB patents. There is still no compelling reason for GCMP in 802.11. Modern logic is perfectly capable of keeping up with CCMP.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    45. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

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

      Yet the shiny new PCI-DSS compliant card payment machine we got recently for the store had a sticker on the bottom proudly proclaiming it used triple DES. I shit you not.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    46. Re:How serious is this? How exploitable is it? by Darinbob · · Score: 1

      Which in a roundabout way exposes the flaw in removing end user options from many operating systems. Today you basically get a choice of "WPA2 Enterprise" or "WPA2 Personal", without finer grained option (ie, advanced options). Users are being trained to just click the networks that have a lock symbol, but not think further than that.

    47. Re:How serious is this? How exploitable is it? by Darinbob · · Score: 1

      Except you can have a rogue router that is rerouting your data to a false facade of your bank. Sure, it might show up as bogus if you're paying attention, but not a lot of people are trained to mistrust everything and double check every time.

    48. Re:How serious is this? How exploitable is it? by tepples · · Score: 1

      So how would a non-technical user understand how to install the extra CA's root certificate on each of his devices? From where would he download this certificate in the first place, if the local WLAN isn't secure?

    49. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      What else would you use to encrypt 8-byte long sequence, which after decryption still looks like random data?

      Triple DES is used to encrypt your PIN, which is stored in the following manner:

      PIN may be from 4 to 12 digits long. Let's assume 1234.

      First you create pin-block sequence 4C1234FFFFFFFFFF, where 4C is constant (min and max length of PIN), and Fs are padding. Then you XOR it with PAN, which is also secret, so you end up with semi-random sequence, which rules out brute-force attack. Then you encrypt the whole thing with Triple DES.

      Obviously, the key is stored in special, tamper-proof module.

      Transaction journal, on the other hand, must be encrypted at least with AES-128, with key in safe memory as well.

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    50. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      >What else would you use to encrypt 8-byte long sequence.

      I would establish a secured session using authenticated key agreement and use that session to carry all the traffic.
      If the PCI pixies forbid me from having a secured session, I would randomize it with nonces to achieve what the PAN does without the additional key.

      But crypto protocol design is not a solo sport. You do it with a group like minded of cryptographers and implementers so you get it right.

      I read the PCI specs once. It was like they wrote a set of thousands of statements and then randomized the order. They are still true, but the structure and purpose it lost.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    51. Re:How serious is this? How exploitable is it? by UnknowingFool · · Score: 1

      If you know the PSK, then you can set up your own AP with the same SSID as the legit AP. The client doesn't know which one is the 'correct' "CafeNetwork". You don't have to compromise the AP to do that, you have enough knowledge to impersonate it. In both cases the client wants to get to the internet, so it's not like that AP provides something uniquely qualifying it other than the correct PSK.

      That's a lot of work to almost achieve the same thing but not really. If you set up a rogue AP, you still have to fool the target into thinking it is the same network. That requires the target to join the new network. Also setting a rogue AP does not send the same encryption key in the handshake unless you use this flaw. This flaw allows you to bypass all of that. Again, knowing the PSK or not knowing the PSK gives you nothing.

      If you don't believe me, set up your scenario and see for yourself. Your device doesn't automatically join your rogue AP. Thus it doesn't leak traffic.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    52. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      >What else would you use to encrypt 8-byte long sequence.

      I would establish a secured session using authenticated key agreement and use that session to carry all the traffic.

      Session between what and what? And is loading key in air-gapped secure room into secure memory separately by several security officers enough key authentication enough?

      I write user application for POS terminals for a living. I agree that the specs are all over the place, but cryptography is actually the only parted of it which is just fine.

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    53. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      >Session between what and what? The PoS terminal and the credit card processor. Isn't that what we were talking about?

      Disclaimer, I wrote the software for a PoS once. The shame still haunts me.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    54. Re:How serious is this? How exploitable is it? by Junta · · Score: 1

      I imagine that if I sat at a starbucks and made an AP called 'StarbucksWifi' or whatever, people would join and be totally oblivious to the network not being the same.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    55. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      Communication between POS and card processor goes via TLS, usually also over VPN. So content encrypted by TDES has another layer of encryption (or two) added when it leaves the POS device.

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    56. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      With RSA1024 according the printouts on our terminal. How many years ago was that deprecated?

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    57. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      2048 here.

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    58. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      So PCI certification is approving new devices with both 1024 and 2048?

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    59. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      At this point 2048 is minimum. https://comodosslstore.com/blo...

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    60. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      Which raises the question "Why when you buy a brand new PCI certified payment terminal in 2017, does it still use RSA1024?".

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    61. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      It is not allowed.

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    62. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      It is not allowed.

      Have you tried buying a PoS terminal recently? 1024 RSA, DES. The whole parade of 1990s bad crypto with a certified PCI sticker.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    63. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      Better yet, I work for a company that sells them.

      1024 RSA for TLS is not allowed and we would be in great trouble if it turned out we have it. It is used by some legacy EMV credit cards for dynamic authentication, but those cards are no longer issued and will soon all expire.

      3DES is only used for pinblock encryption and such encrypted pinblock is later encrypted further, along with the rest of transaction data, with AES.

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
    64. Re:How serious is this? How exploitable is it? by TechyImmigrant · · Score: 1

      That's interesting. There's a clear delta between what comes in the box and what the specs say. There's fame for a grad student in needling through that swamp of card swipers.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    65. Re:How serious is this? How exploitable is it? by darth.hunterix · · Score: 1

      On that I can offer no insight. On my end everything looks fine. Have you tried to reseal the package and open it again?

      --
      What is best in life? Hot water, good dentishtry and shoft lavatory paper.
  11. 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: 1

      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.

      --
      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: 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.
    3. Re:So which is it? by Anonymous Coward · · Score: 0

      What you say and what the articles say are not the same. Care to explain or are you using the opportunity to prove your account name?

    4. 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.
    5. Re: So which is it? by Anonymous Coward · · Score: 0

      Whos more fool, the fool or the one who replies to him?

    6. 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.
    7. Re:So which is it? by Anonymous Coward · · Score: 0

      The handshake is used to establish a temporary one-time key used to encrypt the data for the next $x minutes. You need the PSK or Enterprise to do the handshake but it isn't the same as they key established during the handshake. The attack lets you manipulate the handshake to reuse a previous key and thus have multiple keystreams encrypted with the same key. That then lets you use plaintext or differential attacks to crack what the key is, and therefore decrypt any of the data.

    8. Re:So which is it? by Anonymous Coward · · Score: 0

      You are a shitbag.

    9. Re:So which is it? by Xylantiel · · Score: 1

      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.

    10. Re:So which is it? by Xylantiel · · Score: 1

      From my reading it seems like not all scenarios require a MITM.

    11. Re:So which is it? by Anonymous Coward · · Score: 0

      Nope. PSKs are never sent over the network in a reversible encryption, hence the name "pre-shared". The attacker cannot get the password using this method, so cannot compromise your entire network and assuming you're using AES they can only listen to the targeted device. So if one device on the network is exploitable and another is not, they can listen in on the compromised one, but the other cannot be listened to.

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

      You didn't watch the video. It clearly shows a MITM attack.

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

      Nope. PSKs are never sent over the network in a reversible encryption, hence the name "pre-shared". The attacker cannot get the password using this method, so cannot compromise your entire network and assuming you're using AES they can only listen to the targeted device. So if one device on the network is exploitable and another is not, they can listen in on the compromised one, but the other cannot be listened to.

      Are you not assuming that a device never drops a connection to a wireless network and has to re-establish credentials? In re-establishing credentials, anything that device is sending to the real network might be sent to a fake network.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
  12. 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.
  13. nice work ! by johnjones · · Score: 1

    this just goes to show who is paying attention :

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

  14. Re:Fake news. by Anonymous Coward · · Score: 0

    F60.0

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

  16. Very cool paper (but something curious) by ugen · · Score: 1

    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 or modify packets at the wifi level (which is why that type of attack is "read only")?

    Amazing paper, though.

    1. Re:Very cool paper (but something curious) by Junta · · Score: 1

      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 TCP stream to protect anything.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Very cool paper (but something curious) by UnknowingFool · · Score: 1

      Watch the researcher's video or Aruba Network's FAQ

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    3. Re:Very cool paper (but something curious) by ugen · · Score: 1

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

    4. Re:Very cool paper (but something curious) by UnknowingFool · · Score: 1

      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

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    5. Re:Very cool paper (but something curious) by phantomfive · · Score: 1

      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 place more secure. They might not notice the open telnet port, but they got the public wifi!

      --
      "First they came for the slanderers and i said nothing."
  17. 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.

  18. Letting Putin view code? by Anonymous Coward · · Score: 0

    It's a good idea to revisit the arguments made when it was revealed that HP had been sharing it's security software with Putin's cyber inspectors.

    One of the common themes was : "it should be secure enough to withstand that", or "NSA should have checked it better so FSB couldn't hack it".

    Well here we have a protocol that's been published for years and years and in widespread use, and only now someones spotted the problem.

    It is not a good thing to have closed source software that's only inspected by malicious foreign attacking governments cyber security agents. There will *always* be overlooked security holes in these products and anything you do to make it easier for the attacker to spot those holes is weakening the security.

    HP should not be showing major security software used to secure the USA from a rogue country that has/is attacking its infrastructure.

    1. Re:Letting Putin view code? by viperidaenz · · Score: 1

      What does this have to do with closed source code? In this case, the closed source implementations are less vulnerable than the open ones.

  19. Re:Fake news. by Anonymous Coward · · Score: 0

    1JEiV9CiJmhfYhE7MzeSdmH82xRYrbYrtc

  20. Re:Fake news. by Lunix+Nutcase · · Score: 1

    Fnord fnord fnord!

  21. Certificates? by Anonymous Coward · · Score: 0

    Trying to find out if TLS certificates or Kerberos authentication are affected by this. If you're not using passwords, are you still vulnerable?

  22. Re:Fake news. by Anonymous Coward · · Score: 0

    df 5d 14 f4 21 64 17 1c 74 47 22 9c 14 c0 9d ca
    c2 5b 2f 06 ab 58 9f 49 a0 cb 9a 59 cb 39 00 de
    de f7 c8 f5 2c 21 55 af c2 16 be 45 c9 0f 42 5d
    ec 4b 21 96 17 f7 c7 b8 f7 b5 58 2d 24 ea 4e 1a

  23. What about if using RADIUS? by kandresen · · Score: 1

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

    1. Re:What about if using RADIUS? by Eldaar · · Score: 1

      As far as I know, it doesn't matter as long as a hacker can read all of the packets a client is sending. Even if the hacker can't forge packets, being able to decrypt them can cause loss of data confidentiality. This wouldn't affect a protocol that already encrypted the data (e.g. https), but anything that is relying on the wireless to do the encryption and would otherwise be plaintext is vulnerable.

  24. 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.
  25. And then, smart people never trusted WPA2 by gweihir · · Score: 1

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

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  26. Video showing exploit by Anonymous Coward · · Score: 0

    A video showing the exploit is available at http://www.securitytaco.com/20...

  27. 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
  28. It actually doesn't sound very serious by Anonymous Coward · · Score: 0

    This makes WPA2 "insecure" but (approximately) 100.00% of your applications that were written in the mid-1990s or later, already assume that the network is thoroughly compromised and utterly, completely untrustworthy. i.e for web browsing, the attacker next needs to break https. For email, they attacker has to break TLS. And so on.

    This is going to potentially affect people who use wifi combined with protocols like telnet over that wifi.

    In other words, if you play a MUD on your laptop at home, someone hiding in the bushes out front might be able to steal your character. (But if you were playing in public places, then you were already facing the same risk, even before WPA2 was compromised.)

  29. Debian fix? by Frederic54 · · Score: 1

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

    --
    "Science will win because it works." - Stephen Hawking
  30. Re:Fake news. by Streetlight · · Score: 1

    The router isn't the problem it's the Wi-Fi devices connected to the router. Examine the article carefully.

    --
    In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
  31. Re: Looks like that CAT 5 is looking better every by Anonymous Coward · · Score: 0

    Why limit yourself to 100mb connections?

  32. Most devices aren't vulnerable to hijacking by edxwelch · · Score: 1

    There's a pretty good write-up at Anantech: https://www.anandtech.com/show...
    Basically, they say the vulnerability is worse for some configurations more than others. If you use Android, or WPA-TKIP, or 802.11ad the attacker can do more damage. Normally it's only evesdropping of one side of the communication.

  33. Re: What the fuck is Google going to do about Andr by Anonymous Coward · · Score: 0

    They could also sell the latest Pixel phones at-cost, or even at a reasonable loss, to help make upgrading easier for users. There are lots of people who won't pay $700 for a new phone, but they would be willing to pay $300.

  34. Re:Fake news. by Anonymous Coward · · Score: 0

    That's amazing! I have the same combination on my luggage!

  35. Re: What the fuck is Google going to do about Andr by Anonymous Coward · · Score: 1

    Don't absolve google. I paid $500 for a Nexus 10 tablet a few years back. Straight-up google, through and through. No telco involved. Stopped getting updates a long while back and is slowly decaying to uselessness and, obviously, will not get patched.

  36. Re: What the fuck is Google going to do about And by Anonymous Coward · · Score: 1

    This is a silly solution. A bug in WPA2 should not require its corporate user to eat billions of dollars. Just force the telcos to issue the patches and then tell them they're done with this silly customizing-the-OS bullshit that no customers ever wanted.

  37. 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.
  38. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    And don't forget the non Google Android tablets that never get OS updates by the likes of Samsung, and the bastardised Android used in consumer devices like the NV shield and Amazon's Fire range. And let's be honest, Apple are going to use this to encourage buying new hardware for the iThing stuff, too.

  39. Pay attention to your browser! by Anonymous Coward · · Score: 0

    So, at the end of the day, if the browser shows the "secure" icon we're still secure correct? Or in other words, if the user pays attention to the browser windows and never enters information if the site says "not secure", they are secure.

    Why browsers still support password forms over insecure channels in beyond me.

  40. 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?

  41. Re: Looks like that CAT 5 is looking better every by UnknowingFool · · Score: 1

    Pffft. Cat 5 is so 2001. You can't even get it anymore. You can barely get Cat 5e which is gigabit. Many places will happily sell you Cat 6 though.

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
  42. 4g and vpn by Anonymous Coward · · Score: 0

    I use 4g on my tablet and phone and use a VPN. Who needs wpa2 anymore? Also just use ethernet and pc when doing bank transactions

  43. Re: What the fuck is Google going to do about Andr by Anonymous Coward · · Score: 0

    lol-k, when exactly do you think that Google turned into a charity?

  44. For now... by fyngyrz · · Score: 1

    For now, WRT the phone, turn off your WiFi, use data, and keep the "media" uproar to a minimum unless you have an unlimited data plan. That means no video, no music, no heavy pages, etc. unless you're willing to eat your data allowance pretty quick (that assumes you've been using wifi to keep from stuffing your phone provider's pockets.)

    In any event, watch your data consumption. Overages are a cash cow. And you are the cow.

    WRT your home system, use ethernet, and turn off wifi until / unless you know you've got the right level of patch / amelioration.

    The problem is not the Internet. The problem is wifi. So get off wifi.

    ...cell phone providers are going to love this.

    --
    I've fallen off your lawn, and I can't get up.
    1. 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.
    2. Re: For now... by Anonymous Coward · · Score: 0

      For video&music just use wifi. Who cares if that gets intercepted.

    3. Re:For now... by Anonymous Coward · · Score: 0

      That'w why I don't run full IP connectivity over my wifi or LTE. I have wifi clients and LTE endpoints IPSEC to the other end or to a know colocated server.

  45. Re: What the fuck is Google going to do about Andr by sound+vision · · Score: 1

    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.

  46. Client side problem only? by ameline · · Score: 1

    That may be true, but it looks like a change to the WAP can prevent the attack too --- It would be good for someone like Apple to patch their router firmware as well as the clients. That way your macbook can be fairly safe regardless of where you connect it, and your unpatched IoT things strewn about the house can also be secure -- so long as they only connect to your patched router/WAP..

    --
    Ian Ameline
  47. This is not a real thing. by Anonymous Coward · · Score: 0

    As an American I can tell you that this is the work of the CIA/NSA deep state crisis actors who want to try to make it seem like you need to patch your roter to be more secure when they really want to make it LESS secure. So yes when you care about securety DO NOT, I repeat, DO NOT, listen to this fake news about WPA2. Any patches you apply have been written by deep state crisis actors who want to use your personal information to for their secret agenda.

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

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

    1. Re:Fix released for Linux by thegarbz · · Score: 1

      Why? iOS has notoriously good update rates, and Android introduced a security update system way back in KitKat decoupling security from the current running version. (I got a security update for 5 year old KitKat tablet this year, and a 3 year old phone running 3 versions behind on Android only 3 weeks ago (I wish I made up those numbers, though I was being dishonest with the last one which actually has a release date of 5 weeks ago, but it wasn't pushed to my phone until 2 weeks later)).

    2. Re:Fix released for Linux by kbahey · · Score: 1

      You mean the Google Play Services thing?

      It was supposed to update certain things, but I don't know if it would reach deep enough to update things like wpa_supplicant.

      If you see an update that specifically says wpa_supplicant was updated, please post a reply.

    3. Re:Fix released for Linux by thegarbz · · Score: 1

      You mean the Google Play Services thing?

      No. That was introduced in Marshmallow.

      I mean how the security patch level is now completely independent of the Android version you are running. Just like which windows hotfix is installed is completely independent of which version of windows you are running.

      If you see an update that specifically says wpa_supplicant was updated, please post a reply.

      Put your own effort in. A list of CVEs patched each month in the security framework is published at source.android.com/security including every version of android to which it gets patched. It's on a monthly release cycle so check it in 2 weeks.

    4. Re:Fix released for Linux by kbahey · · Score: 1

      You are missing my point:

      Google issuing a fix for Android does not mean my Sony phone running 5.1.1 will get it.

      What is the exact mechanism that will send it to me? I only know of two: the phone manufacturer issuing a security update (and we all know that they have not been doing this), or Google Play Services, but you are saying that is not it. So how will it be pushed to phones that are not made by Google?

      Related: A list of affected vendors for KRACK quotes Google as saying "Android 6.0 and higher" is affected and that they will issue a fix in a few weeks. Does this mean 5.1.1 is not affected, or affected but they will not issue fixes?

  50. Re:What the fuck is Google going to do about Andro by Streetlight · · Score: 1

    I just read that Microsoft has fixed the problem in the latest updates (October, 2017 ?) for all supported Windows versions. Apple has done nothing according to the latest report. Some Google phones will be updated in the November security update. Other Android phones will depend on carriers to do the job, which is not likely unless pushed by Google, or someone else, to do so.

    --
    In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
  51. Jokes on them, I use wep! by Anonymous Coward · · Score: 0

    Jokes on them, I still use wep!

    1. Re: Jokes on them, I use wep! by Anonymous Coward · · Score: 0

      No I donâ(TM)t.

  52. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    If a telco has installed a particular brand of Android on the phone, and pretty much all of them do this so they can bundle particular apps, then they have to release an updated version after Android itself updates. It gets worse if the device manufacturer (Samsung does this) has its own flavor, requiring the device manufacturer to update before the carrier does.

    If Google releases an update, the only phones that get it immediately are those who aren't reliant on branded OS versions - i.e. the Pixel and Nexus. Some time later, current-gen phones will also get the update. Old-gen phones won't ever get the updates (unless they're Pixels) because no telco's going to make the effort to update an OS image for a device they're not currently selling.

  53. Re:What the fuck is Google going to do about Andro by MrL0G1C · · Score: 1

    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 used to attack their networks. And get awarded large damages. With situations like this one, they can't say they weren't warned.

    --
    Waterfox - a Firefox fork with legacy extension support, security updates and better privacy by default.
  54. Only newer OS are affected... by Anonymous Coward · · Score: 0

    Looks like an intentional decrypting "feature" was discovered by this Belgian researcher. How come only newer OS are affected? macOS Sierra, OS X 10.9.5 and almost all new Linux distro and BSD were affected/vulnerable while older OS like Win7, Vista, XP have correct implementation of WPA2 which doesn't re-transmit the message 3 on its 4-way handshake.

    First IPv6, now WPA2! New implementations were intentionally designed as vulnerable just so you can be snooped by Big Brother.

    1. Re:Only newer OS are affected... by GoingDown · · Score: 1

      It is more so that those older operating systems does not implement WPA2 correctly (eg. they do not support retransmission). Newer OSes (and ones which implement standard more tightly) are more vulnerable.

  55. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    I know anecdote isn't data, but I just had a samsung tablet updated to 7.1 last week.

  56. Re:MitM are not newsworthy by phantomfive · · Score: 1

    It's not a Man in the Middle attack: it's a mitm surveillance. It lets you read (but not modify) some of the traffic going by.

    --
    "First they came for the slanderers and i said nothing."
  57. Sensationalist Bullshit by zifn4b · · Score: 0
    Let's compare the guy's paper:

    The idea behind our attacks is rather trivial in hindsight, and can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh session key. It will install this key after receiving message 3 of the handshake. Once the key is installed, it will be used to encrypt normal data frames using a data-confidentiality protocol.

    to the article summary:

    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.

    Notice in the summary it says absolutely NOTHING about "When a client joins a network, it executes the 4-way handshake to negotiate a fresh session key." Translation: you have to join a BAD NETWORK in order for this exploit to work. Don't join questionable WIFI networks or have your devices automatically join open networks and you won't have a single problem. This is not the scenario where the FBI Surveillance Van can snoop your WIFI connection by doing a drive by.

    --
    We'll make great pets
    1. Re: Sensationalist Bullshit by Anonymous Coward · · Score: 0

      You're clueless. If you're in IT, resign immediately.

    2. Re:Sensationalist Bullshit by viperidaenz · · Score: 1

      or you could join a GOOD network, with a BAD guy within range, able to receive your wifi packets.

  58. Re:What the fuck is Google going to do about Andro by alexo · · Score: 1

    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.

  59. Take the children and yourself... by Anonymous Coward · · Score: 0

    And hide out in the cellar.
    By now the fighting will be close at hand.
    There's a gun and ammunition
    Just inside the door.
    Use it in emergency.

  60. Re: Looks like that CAT 5 is looking better every by Carewolf · · Score: 1

    Cat5 can do 1gbs, just not as far as cat6. Though last I looked into it cat6 was still an unofficial standard that guaranteed nothing.

  61. There is no TLS CA for DNS-SD by tepples · · Score: 1

    How would you go about encrypting communication between a browser on your desktop, laptop, tablet, or smartphone, and a web-based management interface on your router, printer, or network attached storage (NAS) device? These servers tend to lack a fully qualified domain name (FQDN), making them ineligible for a certificate from a major certificate authority (CA).

    tl;dr: There is no TLS CA for DNS-SD.

  62. Re:What the fuck is Google going to do about Andro by CrashNBrn · · Score: 1

    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.

  63. How do home ISPs withhold tablet updates? by tepples · · Score: 1

    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.

  64. Android 8 introduces Treble by tepples · · Score: 1

    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, which begins to refactor Android toward what you expected: a stable driver ABI.

  65. Mario much? by tepples · · Score: 1

    What you are still using SMB1

    People are still buying new NES-clone consoles to enjoy SMB1.

  66. Re: What the fuck is Google going to do about Andr by Chromium_One · · Score: 1

    Expecting updates on a mobile device made ten years ago? What the hell you smokin? Sure, nowadays that's not quite so unreasonable as the pace of hardware improvement slows, but I don't expect manufacturer's to get in line any sooner than they're forced to. Hell, I'd even settle for allowing unlocking of EOL'd devices and pushing 'em to something like Lineage when available.

    --
    When you live in a sick society, just about everything you do is wrong.
  67. Re:MitM are not newsworthy by Anonymous Coward · · Score: 0

    So a flaw that affects every single Wifi network isn't newsworthy?

    No, that wasn't the troll's direct point. The point was to work anti-frump and fscknews into a sentence for search engines to pick up. Note the use of the hashtag there - this is partisan fodder, not commentary on the current story.

    Making an inflammatory comment is just bait to get people to respond to it so that the comment appears to have an air of legitimacy to a content-scanning bot.

  68. It's wrong to call it a WPA security flaw by michielschaeverbeke · · Score: 1

    This is not a WPA2 security flaw, it's a bug in a specific implementation. It's a Linux/Android flaw if anything, but maybe it's not popular to say it when Windows/IOS did something better than Linux/Android?

    1. Re:It's wrong to call it a WPA security flaw by Anonymous Coward · · Score: 1

      Linux/Android implemented it correctly, that's why they are vulnerable. That makes it a WPA2 flaw. The Windows and ios implementations are incorrect.

  69. TP-Link support never heard of it by DOK2 · · Score: 1

    A customer service rep on TP-Link's chat support this morning was completely unaware of the problem. After checking with the engineers, they said they will be working on it. Hmmm, the vulnerability has been known for about six months, and is only now being reported on news sites after presumably waiting to give vendors time to develop fixes. And TP-Link has done, well, nothing? There's no word on the TP-Link.com website about the issue at all. The rep said that I would be contacted when the fix becomes available, but that is not a credible claim since the company has no information about customers. I'm disappointed, guys.

  70. Re: What the fuck is Google going to do about Andr by Chromium_One · · Score: 1

    Great! Now to get manufacturers to provide, if not push, updates on those devices. Best of luck!

    --
    When you live in a sick society, just about everything you do is wrong.
  71. 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
  72. Re: Looks like that CAT 5 is looking better every by Chromium_One · · Score: 1

    Been hibernating a while? 6 and 6A have been ratified, 6e isn't a standard though.

    --
    When you live in a sick society, just about everything you do is wrong.
  73. Re:MitM are not newsworthy by bill_mcgonigle · · Score: 1

    If the network is using TKIP there's a chance of content injection. AES-CCMP is safe from that, for now. More here.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  74. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    It's not like their flagships are any cheaper than Apple's, after all.

  75. Re:MitM are not newsworthy by phantomfive · · Score: 1

    If the network is using TKIP there's a chance of content injection

    No one does that.

    --
    "First they came for the slanderers and i said nothing."
  76. And right on the heals of the Bluetooth exploit... by Anonymous Coward · · Score: 0

    Sadly, any strides made in wireless security to challenge the idea that wireless isn't secure have been undone with the publish of so many attack vectors

  77. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    I'm actually a little surprised at how Google is handling all of this. There's no way in hell they didn't get advance notice. Most of the vendors either had patches ready to go today or snuck them into updates over the past couple of weeks.

    And yet Google say Nov. 6? They're acting like they just found out about this today like most folks. That, or their code is so bad, it's that hard to fix

  78. SSL may not help by nuckfuts · · Score: 1

    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.

    If you watch the video posted by Mathy Vanhoef, you'll see at 1:16 he's also using sslstrip.

  79. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    FWIW, my device was first released in late 2011. It's the only one I've ever owned and likely ever will. It originally came with Android 2.x. Over the years I have upgraded to 4.x, 5.x, 6.x, and as of today 7.2.1. It actually runs faster now and I fully plan on upgrading to 8.x soon.

    I also specifically bought this device because it was manufactured for sale outside of the US, so it is not carrier-locked.

    Additionally, I give myself the ability (through various means over the years - it has become easier) to fully control permissions, which allows the situation to be acceptable for me. I wouldn't settle for anything less and I'll never understand why other technically-inclined people do.

  80. Re:MitM are not newsworthy by Anonymous Coward · · Score: 0

    Every single public hotspot, coffee shop, hotel, whatever, have always been affected by the same issue, even if they're encrypted (if using a shared/known key/password).

  81. Big profits for the telcos! by RhettLivingston · · Score: 1

    I predict that millions are now turning off their WiFi on their mobile devices and may keep it off for some time. Mobile data usage will surge over the next few weeks. The providers couldn't have asked for a better Christmas present.

  82. Re:What the fuck is Google going to do about Andro by thegarbz · · Score: 1

    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!

    And? What's your point? I got an OTA security update for a 5 year old Android 4.4 device in February this year, one which I voluntarily chose not to upgrade to 5 (though that also got a security update at the same time). Just because it isn't the latest OS version doesn't mean that it isn't getting security updates.

    And likewise just because it's a security issue doesn't mean that the fix requires an OTA update. A great many are done by patching up drivers and core components through the Play Store.

    Read up on how security in Android is handled before you get too concerned. Stress is not healthy.

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

  84. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    Apple has done nothing according to the latest report.

    Apple have already fixed the problems in the latest betas.

  85. Re:What the fuck is Google going to do about Andro by thegarbz · · Score: 1

    Maybe in the USA, but in most of the world we regularly still receive updates to older phones.
    My Galaxy Tab 3 got an update earlier this year for Kitkat even though I voluntarily haven't installed Lollipop. My over 3 year old phone now 3 Android versions behind received its latest security update 3 weeks ago.

    Kitkat introduced a security patching framework independent of the core OS. Since then, people quoting Android version install base when discussing security has been completely irrelevant.

  86. Wonderfully Poetic Acronym by Cyphase · · Score: 0

    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

    --
    by Cyphase ( 907627 )
  87. Re: What the fuck is Google going to do about Andr by Brockmire · · Score: 1

    Bullshit, or you would have said what device. The phone is likely 512MB ram, 1GB max. That shit was obsolete years ago.

  88. Kali automated? by Anonymous Coward · · Score: 0

    Has anyone automated this for vulnerability testing with Kali yet?

  89. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    Android is by far not the most popular OS in the world. I believe thats taken by Windows. Unless you want to limit the "Most popular OS" to just phones, in which case, it should be called "The most popular mobile OS in the world"

  90. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    I was stung by this earlier. My Android went from 6 to 7 without me even wanting it, and t-mobile couldn't revert, saying it was coming from samsung and not them. Called Samsung, they said it was coming from Google and not them. Called Google, they said tough shit, your phone is upgraded and there is nothing I can do about it.

    I hate android 7. Its such a shitty OS. 6 was perfect!

  91. Re: What the fuck is Google going to do about And by Anonymous Coward · · Score: 0

    The Nexus 10 is from 2013.

  92. Re: What the fuck is Google going to do about Andr by Anonymous Coward · · Score: 0

    You're a fucking liar.

  93. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    What fucking rock have you been living under?
    Verizon locks the bootloaders on all their smartphones. Google releases a patch, 90 days later HTC releases an update that incorporates that patch, and then it is up to Verizon to decide whether or not to roll it out or not.

    Verizon often refuses to do so because it might mess with their ability to push bloatware (VZ Navigator, VZ Messages, VZ Cloud, etc).

  94. Re:What the fuck is Google going to do about Andro by Darinbob · · Score: 1

    This is a snag for many operating systems. Their "support" model is to always get the latest version, even if it's not the version you like. Ie, would Microsoft backport a fix to Windows 7 when they prefer to force people to upgrade to Ugly Edition? Will Android or phone makers backport to older models that the user wants to keep or force them to get the latest $800 phone if they want the fix? I can seriously see some companies thinking about this as a profit opportunity rather than priority bug.

    Remember, WPA came about as an interim soltuion because the wifi makers wanted to get the products out and for sale quickly rather than wait for WPA2 or 802.11i, and yet it's still in wide use today as an option even in some new products.

  95. MOD DOWN -1, WRONG by Anonymous Coward · · Score: 0

    Entirely incorrect! A patched AP does not prevent an unpatched client from being exploited. The attack is entirely against the client!

    Ugh. Idiot moderators modding up because it "sounds" informative, without knowing themselves. This site sucks.

  96. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    The situation is bad, but not as bad as you make out. It's really not important at all what version of Android you are running as long as the vendor issues security patches. Historically many vendors have released security updates for even old unsupported devices when an issue potentially this destructive arises.

  97. Re: What the fuck is Google going to do about And by Chromium_One · · Score: 1

    What I get for skimming through too quickly. Oops. Still, ~4 yrs is a longer than most manufacturers support anything lately. Which sucks, is sad, condolences, etc.

    --
    When you live in a sick society, just about everything you do is wrong.
  98. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    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!

    It's not like Android users have a choice. I'd love to have a current version on my Nexus 5, but Google basically abandoned us at a truck stop a couple of versions back for no good reason. Same goes with the manufacturers of my tablet and the couple of TV boxes I've bought over the years.

    Not that Apple is a lot better in their own way: you basically get updates forced on you for a few years, gradually bogging your device down because the newer versions expect the latest hardware, then suddenly *pop*, tough luck, Chuck, no more updates.

  99. Re:What the fuck is Google going to do about Andro by Anonymous Coward · · Score: 0

    Google can't do anything about that.

    It's the fucking telcos who are withholding updates from the end users.
    Google absolutely can do something about it with their own --ing devices, but they abandon them after only a couple of years. I've got a perfectly good Nexus 5 that hasn't seen any updates if a few years. I've got friends and family with Nexus 5s and Nexus 4s that continue to work fine, but we've all been abandoned by Google for no good reason.

  100. Why upgrade to the most vulnerable versions? by Anonymous Coward · · Score: 0

    If I remember correctly from my reading earlier today, the component causing the extreme version of the vulnerability was only introduced in Android 6.0, so earlier versions are actually safer than later ones, since Google couldn't be arsed creating a patch in the months they've had since being alerted.

  101. Re: Looks like that CAT 5 is looking better every by Carewolf · · Score: 1

    Been hibernating a while? 6 and 6A have been ratified, 6e isn't a standard though.

    Well, last I looked into it was 10 years ago when I bought a lot of cat6 cables, but had to use reviews as it didn't mean much at the time. Either that or I confused it with 6e ;)

  102. Re: What the fuck is Google going to do about Andr by Anonymous Coward · · Score: 0

    My personal experience with updating android versions in older phones is that they get better and faster. Surprisingly so, I may add. Major updates include VM optimizations that make apps run more efficiently.

  103. CDREIMER RATING: Neutral by Anonymous Coward · · Score: 0

    Your post does nothing, it's not funny, it's not informative. Try to imagine you're reading your posts and how you might feel about it as the reader.

    At least it's not gross, offensive, repetitive, monetized, or off topic so you're making ok progress chris.

  104. Re: Looks like that CAT 5 is looking better every by rthille · · Score: 1

    That must have been a long time ago:
    "The standard for Category 6A is ANSI/TIA-568-C.1, defined by the TIA for enhanced performance standards for twisted pair cable systems. It was defined in 2009.[citation needed] Category 6A is defined at frequencies up to 500 MHz—twice that of Cat 6."

    --
    Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
  105. Creimers wifi password and ssid! by Anonymous Coward · · Score: 0

    C.D. Reimer is a renowned Slashdot collaborator, as he puts it himself; "Because of the quality of my posts and my article submissions, I'm a highly rated commentator and moderator."

    But does anybody ever wondered what "C.D." stands for? Well, it stands for Creimy Dumpty of course!

    Creimy Dumpty sat on the wall,
    Creimy Dumpty had a great fall.
    All the king's horses
    And all the king's men
    Couldn't put Creimy Dumpty
    Together again.

    Creimy's siblings video and theme song, very realistic, especially the pants, just like Creimy's:
    https://www.youtube.com/watch?v=0oKreL1jvkg
    Creimy's real pictures:
    Before the sex change:
    https://ibb.co/cc7Ddw
    After the sex change:
    https://ibb.co/gVad65

    Creimy's "enterprise-level" chair, he talks about it all the time on slashdot:
    http://www.keynamics.com/images/bariatric-chair.jpg
    Creimy's head, while his supervisor was talking to him, not with him, since it is impossible to do with Creimy:
    https://school.discoveryeducation.com/clipart/images/ani-hello.gif
    Creimy acting in educational resource document, he actually confirmed himself on Slashdot that he was handled by Special Education for the Santa Clara County Office of Education! He is really a king Dumpty!:
    http://www.sccoe.org/depts/students/special-education/Documents/Guide%20to%20Adult%20Agencies.pdf

  106. Re:What the fuck is Google going to do about Andro by kaatochacha · · Score: 1

    yeah, but that's the problem. Google pushed out android "oooh, do what you want with it, customize, free!". But when security issues arise, it's all "Ooops, not our fault, talk to the manufacturer". They share some of the blame.
    I may not like apple, but at least they're consistent in updating, fairly long in fact.