Yet Another Cycling Forum
General Category => The Knowledge => Ctrl-Alt-Del => Topic started by: Afasoas on 16 October, 2017, 08:54:57 pm
-
A WiFi Vulnerability was disclosed today which probably affects everyone - https://www.krackattacks.com/
You will need check whether your WiFi equipment is affected (android, anything running Linux, MacOS, access points, routers, Smart TVs and more) and make sure that the appropriate updates mitigating the risks have been applied to that equipment.
There's a growing list here:
https://www.kb.cert.org/vuls/byvendor…
It's my understanding that both wireless access points and client devices (phones, laptops etc.) need to be patched to mitigate the vulnerability. So be careful with public Wi-Fi hotspots etc.
The vulnerability was disclosed to manufacturers in August so patches should be appearing imminently.
-
It's my understanding that both wireless access points and client devices (phones, laptops etc.) need to be patched to mitigate the vulnerability. So be careful with public Wi-Fi hotspots etc.
AIUI the wireless access points are only a problem if in range extender mode (therefore partly acting as a client). There's not much (that I've read yet) to say that anything except the clients are vulnerable, but I'm willing to be proven wrong on this.
The things that desperately need patching are all of the clients that connect to a WiFi network.
-
The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked. Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent by the client. When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent towards the client.
I believe it's both.
Which can only explain Ubiquity rushing out patches for their Unifi APs which rely on WPA_Supplicant.
-
The Unifi APs have a failover mode where they operate as a client from a nearby AP, as well as the option of being configured for point-to-point operation. (To clairfy: I've no idea whether pure AP mode is safe, but this would explain why they were quick to patch.)
I patched mine earlier. And Debian have an update for wpasupplicant. Not that that helps the various Androids we're using...
-
Windows and iOS are apparently not vulnerable because - as per time-honoured tradition - they don't follow the 802.11 standard properly.
https://doublepulsar.com/regarding-krack-attacks-wpa2-flaw-bf1caa7ec7a0
It's older Androids and all those Internet Of Shit devices that are going to be the main problem, as so many of them don't get updates.
-
Windows and iOS are apparently not vulnerable because - as per time-honoured tradition - they don't follow the 802.11 standard properly.
Not quite...
First of all the exploit has to get the client moved to its own channel (which looks like the target network but runs on a different channel). It does this by spoofing a channel change packet (which isn't encrypted) and the client dutifully follows this. The exploit can then forward the raw packets it receives to the real channel (where there will be replies) and can forward these replies to the hijacked client when they come in. It can do this even though the wifi frames are encrypted as it does not need to decrypt them or re-encrypt them on the way (indeed it can't as it does not know the encryption key).
The vulnerability then replays one of the encrypted wifi frames (the 3rd one in the 4 stage handshake) which tells the client to (re)install the encryption key. (Whether the protocol has protection against a replay attack like this I'm not sure, but since every client is vulnerable to this part I would guess not.)
The reason Linux and Android are subsequently and so easily vulnerable is because they are both based off Linux's wpa_supplicant which had zeroed out the memory holding the key after it first installed it (because the 802.11i spec suggested this as a security precaution so as not to leave the key in memory). The problem comes when it is told to (or rather tricked into) re-install the key it does exactly that - and so the encryption key it reinstalls is all zero bytes. This is how the exploit is able to decrypt subsequent packets straight away because it knows the encryption key that will be reinstalled. The exploit code then proxies the requests and responses so the client continues to receive its data.
Windows, iOS and other clients do reinstall the correct encryption key (because they didn't zero it out in memory) but they also reset the frame counters. This is a bad thing as it leads to nonce reuse which means the underlying ciphers (such as AES-GCM) are vulnerable to a birthday attack. Here the exploit has to gather lots of example encrypted data packets in order to derive the encryption key and start to passively decode the stream or actively inject packets. But the much easier fish to shoot in the barrel are the Linux/Android clients which simply move to a known encryption key when asked.
So the flaws are numerous, not least:-
* Clients can be moved from one channel to another by an unencrypted packet
* There's no encrypted confirmation done that the channel move request was legitimate
* Protocol allows original handshake frames to be replayed
* Clients are not warned to protect against replayed handshake frames
* Reinstalling the key requires keeping it in memory (against security best practices)
* Clients that tried to follow best practice (and zeroed out the key once installed) didn't fail when asked to reinstall the now zeroed key.
It's older Androids and all those Internet Of Shit devices that are going to be the main problem, as so many of them don't get updates.
As the old gag goes: The 'S' in 'IoT' stands for security.
-
Thanks for that clear explanation. What a mess!
-
None of it means anything to me. The important thing, I suspect, is does this mean the Norks are stealing our collective porn stash?
-
None of it means anything to me. The important thing, I suspect, is does this mean the Norks are stealing our collective porn stash?
This is a WiFi vulnerability. You do need to be in WiFi range to exploit it. Although that doesn't preclude pr0n-seeking Norks launching an attack from your neighbour's insufficiently paranoid Android or similar.
Public WiFi networks were always considered dodgy. This is why we have TLS.
-
In a home context could you not just use a fixed, rather than floating, wifi channel?
-
None of it means anything to me. The important thing, I suspect, is does this mean the Norks are stealing our collective porn stash?
This is a WiFi vulnerability. You do need to be in WiFi range to exploit it. Although that doesn't preclude pr0n-seeking Norks launching an attack from your neighbour's insufficiently paranoid Android or similar.
Combine it with a few 0-day vulns (to get onto the underlying devices once you're on to the network) and you make a fantastic worm that would slowly spread through neighbouring wifi networks (sitting at home there are 6 or 7 in range of me) and bigger jumps when people move infected devices around. That'd be fun to watch spread.
The biggest point is that if someone wanted to target a specific person they now have a way into their WPA2 protected WiFi network from just being in range (which could be as simple as walking/driving/cycling past with a suitably set up raspberry pi in a bag) and someone not having patched all clients suitably. If you can compromise the device (or inject malware into what it is doing) then you can get onto the device and from there its local network(s).
Public WiFi networks were always considered dodgy. This is why we have TLS.
The original exploit was combined with Moxie's sslstrip, see the video for an example of match.com. There are quite a few badly setup HTTPS servers (i.e. no certificate stapling) that people simply won't notice aren't being connected to securely any more.
-
In a home context could you not just use a fixed, rather than floating, wifi channel?
I don't think any devices allow you to:
a) ignore channel change requests (maybe wpa_supplicant can be configured thus but I doubt this is exposed inside, say, Android)
b) be warned you when you have been moved to a different channel
-
None of it means anything to me. The important thing, I suspect, is does this mean the Norks are stealing our collective porn stash?
This is a WiFi vulnerability. You do need to be in WiFi range to exploit it. Although that doesn't preclude pr0n-seeking Norks launching an attack from your neighbour's insufficiently paranoid Android or similar.
Public WiFi networks were always considered dodgy. This is why we have TLS.
So, if my neighbour was a porn-obsessed Nork and I was in the habit of streaming HD porn, then I'd be trouble, right? Damn, this is precisely the scenario that keeps me awake at night. That and the dildo clowns in the wardrobe, of course.
-
LineageOS are rolling patches - one became available for my wileyfox swift last night
wpa_supplicant patch is also available for MintBuntu.
Still waiting on updates to Samsung phones.
And thankfully the Samsung telly relies on trusty cat5 as that hasn't had a firmware update in a couple years.
I'm figuring my social media phone will forever be vulnerable.
-
https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability