WPA2 KRACK attack smacks Wi-Fi security: Fundamental crypto crapto Users are urged to continue using WPA2 pending the availability of a fix, experts have said, after security researchers went public with more information about a serious flaw in the wireless encryption protocol. So-called Key Reinstallation Attacks, aka KRACK, potentially work against all modern protected Wi-Fi networks. …
We don't have to care up here in our facilities.
As we are VERY aware of this type of over-the-air attack.
We use our OWN nested IP-3000 packet protocol which
stuffs our custom Internet Protocol Version 3000 data
which we designed ourselves into an upper-level packet
such as IPV6 or IPV4 (i.e. nested packeting) and since
we change our communication encryption keys every
few seconds based upon NATIVELY calculated hardware
keys, our servers will REJECT any comms coming from
outside (even over VPN and SSL!) that does NOT have
the properly formatted nested IP3000 encrypted packets
scrambled with the PROPER session validation keys.
Intruders are simply locked out of the system
as they need DIRECT HARDWARE access
to ALL our smartphones, laptops, desktops, etc.
in order to get the ALWAYS-CHANGING session keys
algorithms and "Secret Keys"
And since we use VARIABLE 3x AES-256 and 3x CAST-256 data
encryption ON EVERY Custom IP3000 packet, they are
hooped!
Good Luck NSA ---- Our security is 1000x yours!
WE take security EXTREEEEEEEEEEEEMELY SERIOUSLY!
Even our smartphones use CUSTOM encrypted drive and memory technology!
REEAAAALLY GOOD LUCK on your tries!
This post has been deleted by its author
Unless your ubiquiti hardware is a client you did nothing.
This is a client side vulnerability not AP side, and there's little that can be done on the AP to detect it (and unifi have said they currently aren't tackling that.
Too many people are installing AP updates and thing they've fixed it. Nope. You need to update every wireless client.
If I read the kracken website correctly, both clients and APs must be patched - patching only one end of the connection is not enough, so with the updates from Ubiquiti and Microsoft, the most critical parts of the network are now patched.
I have some hopes of the various Apple and Samsung/Huawei clients, but suspect the Withings scale, Netgem set top box and Squeezebox Radio will have to be relegated to the guest network...
Re:Google
A quick check of my Nexus 7 shows an Android security patch level of 5th August 2016 - looks like nothing's happening here then.......
I wouldn't mind but I bought it 4th October 2016. Maybe an upgrade to Lineage is in order
If you'd been reading The Register, you'd have known when you bought it that it was already 2 months out of support. https://www.theregister.co.uk/2017/05/01/google_eol_for_nexus_phones/
That said, I wouldn't worry about the Nexus 7. I'm sure all the router manufacturers will be quickly rolling out updates to protect wireless sessions.
This post has been deleted by its author
Isn't the whole point that this loophole is built in to the standard?
How else would it be in everything? Did everyone make the same mistake? Or is there some reference code that everyone copied, and nobody noticed was broken?
We know outfits like the RIAA can go after trivial cases to "make an example". How long before we have the RIAA War-driving Enforcement Teams?
Isn't the whole point that this loophole is built in to the standard?
From reading around, the root of the issue appears to be the lack of specifics in the standard (unless you pay lots and lots of money for the reference code).
And the reason that the impact varies across platforms is that the spec is sufficiently loose that it can be interpreted in several ways - which is why wpa_supplicant has such a problem - the spec could be read to have requred the zeroing.
So, get the standards agencies to stop hiding soo much detail behind paywalls and you'll get better products.
Could someone who understands these things better than I do explain the details behind the attack? The article mentions getting a 'mark' to reinstall a cryptographic key. Is this something a human needs to do or is it automatically carried out by the OS? Does the miscreant have to install software on the target device or can this take place as a drive by attack?
In a nutshell:
When connecting to a wireless access point, a "handshake" (a procedure to establish the connection) is performed. This is part of the standard.
The problem lies in part of this handshake. Part of the procedure involves generating a Number used ONCE (a NONCE) as part of the session key exchange (read up on Diffie-Hellman Key Exchange for the gist of the procedure). This is built into whatever software/firmware makes the connections.
The problem lies in that the nonce isn't guaranteed to be a nonce. An attacker can glean a nonce and trick the victim into reusing it. Since it's not a number used once, the attacker has calcualted enough information from this to decode and thus hijack the session.
Bad news: This CAN be done with wardriving, without requiring a previous intrusion into either client or access point. They would need some good RF gear to both sniff and transmit, but this is considered standard wardriving equipment. The only solution is to update software/firmware to be more thorough about checking if a nonce has been used. Depending on the nature of the device, this can be easy or hard as all getup.
This is also fundamentally broken and a problem for IoT and low power devices.
You will be forced to have a database of NONCEs associated to SSIDs, so you need permanent storage and a lookup table.
Microcontrollers with wifi capabilities are going to be seriously affected.
"This is also fundamentally broken and a problem for IoT and low power devices."
Meh...
It's like saying you can force a euro lock on a door when you've left the windows open, the key under the mat, a note for the milkman saying you're away for a week, put a post on social media saying don't break into my house at 11 Acacia avenue as we forgot to arm the alarm and please no one will pop round as we don't want you turning the lights on at night.
If following the standard it should be automatic, as your client device trsusts a forged message, that is the fundamental problem.. from there, you are just screwed.
It is essentially a MIM attack, and it can potentially be used to get you user/password to several services.
Thanks everyone for the replies. Icon for each of you ------->
So if I understand correctly a device is authenticated against a router. Some communication is intercepted between the router and client, giving the client the NONCE details again which the client inappropriately responds to, providing enough detail to determine the logon details etc being used. Because cleints do this automatically there is no defense at the moment for unpatchd routers etc.
For the attack to work, access is needed to the physical wi-fi signal so this attack can't be delivered via software, webpages etc.
"For the attack to work, access is needed to the physical wi-fi signal so this attack can't be delivered via software, webpages etc."
Correct. Don't worry about drive-by attacks so much as wardriver attacks. Someone has to be physically in the vicinity of the WiFi point to pull it off, but they can be hidden away or use more-sensitive radio equipment to work from outside the normal range since they don't need to physically touch any of the devices.
BT have decided to approach the problem in a very different way, by making WiFi so frickin' unreliable in their Home Hubs that the chance of a connection staying up long enough to hack is approximately zero.
Vodafone NZ are trying to beat them in those stakes. Keeping their crippleware routers from crashing just about takes a top ICU team - and then some.
El Reg has managed to split the comments on this by having two articles on the same topic (viz. https://www.theregister.co.uk/2017/10/16/wpa2_inscure_krackattack/) so pardon me if I briefly repeat my query to the assembled commentariat.
Assuming that updates are not going to fix this problem—which seems a fair assumption, given the nature of the flaw, the overall uselessness of manufacturers, the cluelessness of Joe Average Householder and the heroic incompetence of corporate IT security teams—what do we see as reasonably practical mitigation? The much-ballyhooed fact that the attacker has to be within wireless range (well, duh) does not make much of a defence: others have already mentioned the prospect of wardriving/drive-by hacking. And in many neighbourhoods you can see at least half a dozen WiFi networks from your own living room.
It seems the exploit can be parlayed into access to one's LAN, which surely ought to fill a few hearts with dread, if correct. I was considering restricting ALL WiFi access to "Guest" status, i.e. allowing internet use only, which isn't perfect if my neighbours want to leech on my connection, but at least offers some protection for files. Thoughts, anyone?
"Routers just have to check that the NONCE from a client hasn't been used recently, that's all."
Nope. The router isn't involved because the attacker pretends to be the router, as such the router is taken out of the equation. The client will authenticate with the spoof router. Or at least that's how I read it.
As such it's the client side that needs to be updated to protect against re-use of NONCES. Or rather to ensure that the NONCE is indeed a NONCE.
"Nope. The router isn't involved because the attacker pretends to be the router, as such the router is taken out of the equation."
Sorry, but I think the router IS, in fact, fundamentally involved. If not then why are (responsible) router manufacturers frantically issuing patches for their devices?
Routers capable of being clients, like wireless bridges, are vulnerable in their own right. (Bigger can of worms here as some mfgs. still use WEP in this mode.) Another possibility is that the AP may be capable of detecting the attack, assuming the attacker is in range of the AP as well as the client. A patched AP may be able to drop the connection if it detects the rogue handshake packets.
I replaced a couple of very powerful Wi-Fi BTS turned up to 11 (~thousands of milliwatts), with a whole drum of CAT-5e shoved through house walls in the TV-coax ducting, (some previous owner had helpfully wired the house for a TV in every bathroom, sort-of)
Now on each floor I can get away with an airport express type Wi-Fi BTS on ~1 milliwatt, hence limiting the decode/packet-3 replay inject range of any evil neighbours.
As quite a few Wi-Fi BTS have the "Wi-Fi isolate from LAN" function as a simple click so you could continue not using open/guest until whatever WPA2.1 patch hopefully turns up. In meantime turn off Wi-Fi as you walk/drive around.
Would the expensive 'Slurp' Mesh $$$routers have any better KRACK-resist ability?
Assuming that updates are not going to fix this problem—which seems a fair assumption,
Updates already installed on this computer.
From my reading of the article (happy to be corrected), this attack lets you listen to traffic between one computer and the router (I've not read the other article yet), and doesn't necessarily actually get the wifi password (though if it's listening to traffic I guess that may be passed at some stage - but that may be before this attack is available, I have little knowledge of these matters :) ). The article talks of VPN use to mitigate it, so that would further indicate that it's traffic on that session only rather than the whole network being compromised (of course, if you do a non SSL etc login to any site, said login can be pilfered - thankfully El Reg got their site to HTTPS before this became public knowledge! The horror if someone gets my El Reg credentials! :) )
I'd love to say "you have little to worry about" but I know that with these things, while there may be plenty to mitigate against this attack, there's the possibility that someone will now find further flaws or further ways to exploit it.
But the fix is in. If you like penguins at least...
It's a reasonable bet that this has been exploited for some time - I guess most devices will be patched to fix this within a year ... and then we'll all have to find another crack. Yes, you can use this to intercept Wi-Fi but don't panic, there are much easier ways to read the data most of the time.
Noooo... Most manufacturers will use this as an excuse to push a new model out within the month!
The cynic in me points out that if that's what they do, they'd be having to repeat it after the standard finally gets fixed (for that is where the problem sits). And if I know anything, it's that standards don't get changed very quickly at all.
There seems to be a lot of talk about "devices" here. What's actually needed is patches for client OS's.
Now when people talk about "new devices" rather than patching existing ones I get the feeling they are talking about access points and routers, rather than the likes of laptops, phones, tablets and the like. Patching your access point or router, or indeed buying a new one, isn't going to fix things if your client devices are vulnerable.
This post has been deleted by its author
for the pairwise transient key. That's established in Handshake 2. Replaying 3 would allow you to mess around with the group temporal key, which is for multicast and broadcast packets. So apart from the Android bug which sets the encryption key to all zeroes, this is of limited value, surely. And in the video the guy talks about not wanting the Android to connect to the genuine network, but he needs that to happen in order to capture the packet for the replay attack. The MAIC proves that both parties know the PSK, so you need that. You also need to do a bit of MAC cloning too.
Or am I missing something?
Having reviewed the article and the video a couple of times, I think the following is the explanation, but not being an expert, I'm open to corrections :)
The key (pun intended) is that the router vulnerability seems to allow wardriving kit to inject Handshake 3 into the network traffic to acquire the ability to decrypt traffic on a read-only basis. The hijacking of client devices is stage 2 of the process. The video does not deal with the injection of the packets necessary to get the decryption key, only the creation of a MITM attack on an Android device - the MAC address suggests a Samsung phone.
The capability to eavesdrop on a router is backed up by the following from the article:-
"Despite this, however, the ability to decrypt Wi-Fi traffic could still reveal unique device identifiers (MAC addresses) and massive amounts of metadata (websites visited, traffic timing, patterns, amount of data exchanged etc.) which may well violate the privacy of the users on the network and provide valuable intelligence to whoever's sitting in the black van.”
Ultimately, if there was no eavesdrop capability, there would be no MITM attack capability as the ability to inject encrypted packets to set up the "rogue channel" would not exist. Hence the statement at the end of the video that patching of routers is the fix.
It seems to me that the video involved tricking the client (station) into communicating with the fake AP on a different radio channel then, and this is another thing I'm not clear about, either relaying the packets to the internet via another connection or relaying the packets to the genuine AP. But it's still not clear to me what can be achieved against a non-android 6+ client. You can harvest MAC addresses without MITMing, they broadcast the things, and you can gather timing and packet size data just by listening too. This attack seems to purely trick a client into trusting spurious multicast packets.
Put simply, the attack causes the client (supplicant) to re-install the PTK and GTK (or the GTK alone in the case of their group key attack) , which in turn means it will re-use the same PTK and nonce (replay counter) in the next frame it transmits. Result is 2 frames can be sniffed which have been RC4 stream encrypted with the same keystream. XOR them togther and (maybe) you can retrieve some plain text, or, if the frames happen to have known content, (probably, with some effort) you can retrieve at least parts of the PTK (the 128 bit encryption key and client to AP MIC key).
In their words: "In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted). In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted."
Ah, well, yes. After reading the actual paper several times through it becomes clear that resetting the Nonce does so for both PTK and GTK, which is bad, very bad. The MIC then becomes trivial to reverse engineer and turns a rogue AP into a trusted AP. So it is as serious as they make out, even if it's tricky to pull off due to the need to hijack the airwaves. It could be mitigated further by including the radio channel characteristics in the KEK, but time division multiplexing would still allow a window for hijacking. Hmm... well, updates all round, I think!
"silently due to embargo"
I think that is actually "silently despite the embargo" since publishing a patch to FOSS cannot be done without implicitly disclosing that a particular area of code is considered buggy. Therefore, more than one person reckons that OpenBSD kinda broke the embargo and they will therefore be placed on the naughty step for next time.
Several commentards have mentioned that the attack is against the client rather than the AP. Aruba claim in their update that they've implemented a mitigation in their APs against this type of attack.
Also, some APs can act as clients as well as APs (e.g. Mesh or repeater APs)
Do my devices have to be updated to handle the change in the handshake behaviour?
Depends on the fix. A proper supplier will make sure that older clients still work (and, preferrably, have a configuration setting so that can be turned off if needed) by still supporting the old method.
Then, as updated clients roll out, you can shut off support for the broken method.
Some Netgear rep got an email from me detailing an exploit that new firmware was making on old units.
They tested inhouse and found that the routers were indeed left open (on WAN SIDE) to anyone visiting a crafted URL and fetching the router Login details Name, Password. It was possible to fully hijack the router via the WAN side without issue.
Netgear said that it's nothing to worry about as people buying NEW hardware would not suffer the same problem, thus as people upgrade the exploit will disappear.
This "Problem" will be exactly the same, If the hardware is more than 2-3 years old then a fix will never come via the manufactures.
The exploit for these old routers still exist to this day - even after multiple firmware updates on some units.
"thus as people upgrade the exploit will disappear."
Such naivety disappeared from the desktop about two decades ago. Yes, the automatic update mechanisms on the average OS do not have a 100% record, but for the average user who can't manage much beyond plugging it in and turning it on, they are almost certainly the only way to ensure that patches are deployed in the field.
It is scandalous that people sell network-connected devices without any automatic update mechanism. With society's increasing dependence on such things, such omissions are almost in the league of "not fit for purpose" under consumer legislation. It wouldn't even be hard, since these devices are all based on stripped-down Linux distros and those all have the facility. Yes, have an off-switch for the power users if you must, but don't just leave it out.
Hmm, I reported an issue I discovered to Netgear quite some years ago regarding their DG834 range (G,GT,N..) firmware when they were still current routers, that I don't believe was ever fixed.
It was possible to bypass the login details and gain root access, due to no password protection on a sub-directory within the router's Httpd web server directory, plus various shell exploit vulnerabilities in the web interface, which would allow a hacker full root access to the router, including accessing all setting stored on the router, downloading and running binary code from the internet on the router and flashing custom firmware.
It was remotely exploitable as a reflective attack, by getting a victim's browser to request a specially crafted URL by, for example, posting it as an image link in a forum post.
I did consider publicly releasing a temporary fix which used the same exploits to clone the router's web directory to the ram based temp directory, omitting the unprotected setup directory, and set the router's httpd server to use that instead.
I subsequently also discovered that it was possible to inject scripts into the router's NVRAM settings so that they'd survive a reboot and run automatically, so a hacker could fully own the router without even needing to replace the firmware.
All the password vulnerability needed was a link to the password file added to the setup directory to make it password protected. The various shell exploits needed a lot more work to fix, but without the password bypass they wouldn't have been quite so serious.
As far as I know, I believe the only router to be fixed was the Sky supplied dg834gt, and that was only because Sky replaced the standard firmware with a sky customised version which since it didn't require it, had omitted the setup web sub-directory, removing the password bypass vulnerability.
Hopefully most will have been thrown out, or died and gone to landfill by now.
"Netgear said that it's nothing to worry about as people buying NEW hardware would not suffer the same problem, thus as people upgrade the exploit will disappear."
Nice to know that's their attitude. I will keep it in mind if I ever need to replace my eight year old Netgear router (wireless N dual band; still a decent little AP that is far better than anything my ISP offers). You can grok from that what my attitude may be on only patching new gear might be.
Fortunately, DD-WRT.
cloud accounts, banking accounts, password sites like lastpass, all easily redirected by your next door neighbor.
Everyone now has to have a VPN on their device to encrypt the encrypted.
A lot of ISP's block VPN's, what is this now going to do to for the video streaming sites or even Government surveillance, everyone will have to use VPN for fear of getting hacked.
Did this just break the internet?
"Everyone now has to have a VPN on their device to encrypt the encrypted."
Any HTTPS connection will continue to be secure (or at least as secure as HTTPS itself is). As far as the web goes, more and more sites (like this one) are going HTTPS for everything, and certainly any login prompts or other places where sensitive data is meant to be sent are already encrypted on nearly every legitimate site. That's not to say VPNs are not a bad idea, but it's not so bad that wifi is now useless without one.
FWIW, my laptop's Intel wifi card has already had a patched driver released, and my Android tablet that ( hardly ever use is so old that it was never vulnerable to this in the first place (according to the articles that say it's Android 6+). I am sure my Linux installations will have a fix as soon as I boot them also. Router uses DD-WRT, which has had the fix checked-in; just waiting for the build now.
I don't know about that. The fault lies in the standard, which is why literally everything on the planet is vulnerable.
If the manufacturers have "fixed" the standard and updated their code, they've done so (AFAIK) whilst keeping updates to the standard completely secret, whilst disseminating that to lots and lots of engineers, without any one of them spilling the beans, or being curious about why a "change" is needed in the first place and asking unfortunate questions on bulletin boards trying to find out.
Seems unlikely!
There aren't very many manufacturers, and all of them are well-versed in keeping things secret until release.
For example, the Linux wpa component team leads can be contacted about the issue, and they can then prepare a patch in a small group - all of whom know it's important to keep secret until release - and have it tested and ready to push to the public on the day of publication.
They can even let the major distros know that something is coming without giving details.
Oh yes, looks like they did.
"My router is wide open to all comers. Who cares?"
Whoever pays your broadband bill, I would guess. (Unless they are made of money.) Starbucks are betting that the profit on the coffee far exceeds the cost of the bandwidth you can consume on their connection.
Those with the foil hats on, do you never use Starbuck's or any other public wifi?
Correct. I don't think I've ever even seen a SB except on TV. None around here that I'm aware of.
But for those very few times I might actually want to use someone else's wifi while I am out, there's OpenVPN.
"My router is wide open to all comers. Who cares? Those with the foil hats on, do you never use Starbuck's or any other public wifi?"
Well. When you're in Starbuck, you should be drinking coffee. When you're in the public, you should be walking or doing whatever activities in the public. You shouldn't need their wifi at all. Not to mention those wifi are super slow unsecured unreliable hacker welcoming internet connection.
Even if you do, public wifi should never be on your convenient reliable internet access list. It should only be your last resort in a life emergency.
As El Reg user, you should have at least (+/-)1MB phone data for emergency, so you don't really need that public wifi anyway, right?
"As El Reg user, you should have at least (+/-)1MB phone data for emergency, so you don't really need that public wifi anyway, right?"
Aw crap, they're not going to revoke my silver badge when they find out I don't have a phone with data, are they? I never knew this was a requirement!
"I don't have a phone with data"
wait then how are you going to read El Reg on the go? Don't tell me you're going to white hat hack other wifi routers on the go. Especially in an emergency, in the middle of nowhere, dying of desktop-less, it is essential to access El Reg newest articles at all cost.
/icon
Do you care if someone prints to your printer? Or starts sniffing about to see what might be protected by some ancient long broken Windows authentication scheme? Some of us live on oppressive regimes like Australia and the UK that collect "metadata" from every website you visit because, you know, terrorists. The sort of people who would want to exploit this are no doubt going to be doing things I don't want to go through my connection. Do you really want your media centre indexing the folders of media that they might have on their public share? Didn't think so.
And on your other question, if had need to buy dirty sugar water and use their internet, my VPN is definitely ON with local traffic denied.
WEP is broken, but I fear that it might now be better than WPA2! So far as I know it takes a little bit of effort to break WEP.
This flaw in WPA2 seems to be trivial (at least from the point of view of computational complexity) to exploit.
Oh the irony if the short term fix is to turn on WEP...
@TRT
The session key (PTK) is still secure under KRACKing, the "decryption" involves sniffing 2 frames using the same nonce (variable part is frame sequence number; KRACK causes it to be reset), then XORing them and using known plaintext to recover the keystream used for the 2 frames. This is different from actually finding the key used to generate the keystream (which is 128 bits from the session key PTK). This may be possible in the case of keystreams generated under TKIP (which uses weaker RC4 stream cipher) but highly unlikely for CCMP or GCMP (using AES in counter mode).
In the case of TKIP and in GCMP it is possible to reconstruct the (MIC and GHASH respectively) authentication keys used to authenticate the ciphertext. This enables, along with the known keystream, forging of new frames, injecting arbitrary data.In the case of GCMP, it can be done in both directions (client to AP only with TKIP).
Quick check of the update manager while reading the article - oh, there's a fix already there for Linux Mint (and therefore Ubuntu and Debian).
Getting the routers fixed is another matter of course. And the older Android devices.
Still, at least I don't have to wait till a Tuesday that's what, 3 weeks away?
My has no Wi-Fi Mint Linux Box just asked to do some fucking Wi-Fi update stuff. The other tosser has Wi-Fi on his Wank-Top and a Fire-Stick. I guess I can switch off the Wi-Fi on the router or leave him be fucked. Then again this might be the ideal opportunity for Amber and GCHQ to download consensual Horse Pron on my behalf and blame someone else. Just Gotta Lurve Those Back Doors. Cough.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
