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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
