Posted
by
msmash
on Monday October 16, 2017 @10:10AM
from the security-woes dept.

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

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

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

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

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

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

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

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

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.

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.

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

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-G930USM-G930VSM-G930VLSM-G930AZSM-G930ASM-G930T1SM-G930R6SM-G930R7SM-G930PSM-G930TSM-G930R4

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.

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.

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.

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.

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

I had hoped that it would be google, not the carrier or handset manufacturer providing updates. The manufacturer would provide drivers for the hardware, but Google would take care of the rest, similar to how MS rather than a PC manufacturer handles Windows updates.

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

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.

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

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

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

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

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.

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.

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

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.

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.

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.

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.

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.

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 DSSRequirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such asAES 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-endcryptographic 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...

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.

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), becau

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

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.

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.

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.

Having run aircrack, several variants such as aircrack-ng, airsnort, and other WEP cracking tools, I call bullshit. They are terrible tools and rarely work as "advertised". Yes, I've been able to occasionally crack a WEP key on an AP. So, it's not like they are completely garbage. However, if you actually use these tools you'll find that they don't work "in a few minutes" in all but the very best scenarios. In many cases, when the AP attacks that force clients to re-init their keys (and thus give you a chan

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:

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

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

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

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

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

It appears that it is "worse" for pre-shared keys (attacker can do more nasty), but there are still problems for the non-pre-shared-key cases. Thanks for the links. Funny that it was actually already fixed in more recent versions of wpa_supplicant, it just wasn't known that it was security-critical.

I wonder about an almost off-hand remark in section 6.2."6.2 Example Attack ScenariosAmong 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

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

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

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

The reason this is big news is because 'security' auditors love wifi: it's an easy way to attack the system, and even if they're too incompetent to find any other vulnerabilities, they can still 'prove' to the CxO team that they've found a vulnerability and made the

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

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

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 con

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

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.