Don't Do KRACK - Breaking WPA2 WiFi Protocol

FrgMstr

Just Plain Mean
Staff member
Joined
May 18, 1997
Messages
55,634
Just when you thought that WPA2 was safe, think again. This new hack, called KRACK, Key Reinstallation Attack, is really really bad to put it in laymen's terms. Changing passwords does not make a difference. We will have to update firmware to fix this, and the IoT is likely going to make this a huge mess at the consumer level. This attack affects Android, Linux, iOS, macOS, Windows, OpenBSD, and embedded and IoT devices. BleepingComputer has a full summary published. Thanks SCHTASK.

Check out the video.

"Any device that uses Wi-Fi is likely vulnerable," Vanhoef said. "Luckily implementations can be patched in a backwards-compatible manner." A list of available products and updates will be available in this US-CERT advisory page that will go live in the following hours. No updates are available at the time of publishing.

While updates are expected for desktops and smartphones as soon as possible, experts believe routers and IoT devices will be affected the most and will see a delay in receiving firmware updates.
 
giphy.gif


Welp that's hilarious.
 
Let's face it. Most WiFi devices will never be patched and consumers will be told to just buy the latest and greatest to be secure.

I will give Belkin/Linksys credit for something: they patched the remote administration pnp bug on routers that have been out of production for years. Admittingly it took them two years but they did it.

I would say 95% of their product line networking code is likely based on the same code with tweaks for features. So patching a vulnerability for one will likely fix it for a very large number of products. They just need to put out the new binary.
 
I will give Belkin/Linksys credit for something: they patched the remote administration pnp bug on routers that have been out of production for years. Admitting it took them two years but they did it.

I'm interested to see what happens on the older high end stuff like the Netgear Nighthawks, etc. I'd guess most of the work is going to be on the enterprise end for a while and consumer stuff is coming later.
 
I'm interested to see what happens on the older high end stuff like the Netgear Nighthawks, etc. I'd guess most of the work is going to be on the enterprise end for a while and consumer stuff is coming later.

Well there's two parts:

1. The networking stack. These protocols are usually written by third parties and used by everyone with custom tweaks

2. The low level hardware drivers that allow the networking stack to communicate with the hardware.

I'm guessing this is a fix to #1. So a fix for one will usually fix a large number of products.
 
Ah, the never ending game of catch your tail in IT Security.
 
I'm interested to see what happens on the older high end stuff like the Netgear Nighthawks, etc. I'd guess most of the work is going to be on the enterprise end for a while and consumer stuff is coming later.

My netgear nighthawk received a patch for it already.
 
So hiding your SSID help this? They have to know your network name right?
 
I have an R7000 and the only thing the latest firmware says it does is "Fix Security Issues" without a further explanation.

They never say exactly what in the notes. Cert reports Netgear started patching in Aug. I have a 7800 and it got patched 9/21 and it looks like the 7000 patch came out a few days ago.
 
So hiding your SSID help this? They have to know your network name right?

If the person really want to get in, that will not help at all. All they have to use is a sniffer in order to find out the SSID.
 
Sadly, the real issue is that the problem is not the router side. It is a client side vulnerability. Thus the real problem is the tons of Android devices which will never get the patch.
 
Sadly, the real issue is that the problem is not the router side. It is a client side vulnerability. Thus the real problem is the tons of Android devices which will never get the patch.

You're right.
 
My router vendor has everything patched. Tomorrow is network day for me.
https://forum.mikrotik.com/viewtopic.php?t=126695

Unless you use your router as a client of another WiFi network, then that update is irrelevant. KRACK is about another device inpersonating your wifi router in a MITM manner. Fix needs to be on the WiFi client device side, there is no fix needed on WiFi router side.
 
So, does this affect enterprise type WPA as well as WPA2 Personal? Could setting up an authentication server for WPA Enterprise be a solution until a replacement standard comes out?
 
Lets hope in 6 months we dont have a large breach at a company because they "forgot" to update their security patches.
 
So, lets see if I have understood this correctly. Please correct my statements below if wrong:

1.) This is not an Access Point problem. I don't have to worry about unauthorized access of my network via my WiFi access points. It affects the traffic between the access point and devices, making it unprotected.

2.) Using VPN tunneling whenever on WiFi would seem it would protect against this for now.

Does this sound right?
 
Lets hope in 6 months we dont have a large breach at a company because they "forgot" to update their security patches.


Well, right now, I'm not sure how patching will help. This affects everything WPA2 based on the handshake process. We'd need a brand new protocol to replace WPA2, and that won't appear overnight. This could be a significant problem for a long time.
 
So, lets see if I have understood this correctly. Please correct my statements below if wrong:

1.) This is not an Access Point problem. I don't have to worry about unauthorized access of my network via my WiFi access points. It affects the traffic between the access point and devices, making it unprotected.

2.) Using VPN tunneling whenever on WiFi would seem it would protect against this for now.

Does this sound right?

From the looks of it this is how it works:

1. Get the MAC address of the legit router.
2. Hook into legit router channel and issue a channel reset command (forces all wireless clients to go looking for a new channel with the same MAC)
3. Hacker imitates MAC on his own router and intercepts your wifi devices reset/reconnect request. Your client takes it as legit as the MAC matches
4. Apply other well known hacks to reset the WPA on the client so that the router uses a key it controls to descrypt traffic.

So yes, purely client side issue as the legitimate router is just taken out of the picture.
 
Well, right now, I'm not sure how patching will help. This affects everything WPA2 based on the handshake process. We'd need a brand new protocol to replace WPA2, and that won't appear overnight. This could be a significant problem for a long time.

Well the quick fix would be to ignore & disable the channel reset command on the client side. This is a minor inconvenience if you switch channels on a regular basis. Or possibly re-scan the entire channel spectrum to see if the original MAC is on the original channel. (Provided the hacker isn't using the same channel) You could issue various broadcast low level network/wireless commands on the client and see if you get more than 1 reply for the given router MAC given the same channel.

Apparently windows doesn't suffer from the same problem as it's authentication protocol is different than linux.
 
From the looks of it this is how it works:

1. Get the MAC address of the legit router.
2. Hook into legit router channel and issue a channel reset command (forces all wireless clients to go looking for a new channel with the same MAC)
3. Hacker imitates MAC on his own router and intercepts your wifi devices reset/reconnect request. Your client takes it as legit as the MAC matches
4. Apply other well known hacks to reset the WPA on the client so that the router uses a key it controls to descrypt traffic.

So yes, purely client side issue as the legitimate router is just taken out of the picture.

The mac address is of the client you want to hijack not the router.

Unless I am wrong I believe it is actually

1. Get mac address of single client you want to hijack traffic of
2. set your device up to repeat the network said target is connecting to and watch for their attempt at connecting to network
3. steal said packet and return a request to change channel that the single device is using
4. have yourself register on behalf of the target on the real channel to the real AP.


While I can see this being an issue, it also requires a good amount of data and physically being by the target so this isn't something that the average person would probably need to worry about as much as a company.
 
If this is a simple case of masquerading, then once the hacker gets the security key from the client, wouldn't the hacker have what it needs to compromise the network security? Or despite this exploit, is the key still secure and only (client) data compromised?
 
I am curious how this affects DD-WRT devices, and if this will be patched via the newest versions of DD-WRT soon. One thing I am slightly worried about is that apparently Linux based devices are more vulnerable than other devices. DD-WRT is linux based.
 
So, lets see if I have understood this correctly. Please correct my statements below if wrong:

1.) This is not an Access Point problem. I don't have to worry about unauthorized access of my network via my WiFi access points. It affects the traffic between the access point and devices, making it unprotected.

2.) Using VPN tunneling whenever on WiFi would seem it would protect against this for now.

Does this sound right?

2) not really, you can still do the hack and get the password because the VPN runs on top of the wifi connection. The best analogy is that you have a bulletproof OS running in a VM, but the host OS is fully compromised, which means the VM OS doesn't matter.
 
I am curious how this affects DD-WRT devices, and if this will be patched via the newest versions of DD-WRT soon. One thing I am slightly worried about is that apparently Linux based devices are more vulnerable than other devices. DD-WRT is linux based.

This is primarily a client side issue. Any unpatched clients running on the network will negate the network security atm.
 
The only thing hiding an SSID ever accomplishes is reducing WiFi network browsing clutter for nearby clients. Hiding the SSID just puts your network in the "I do not advertise" bucket, and that bucket's contents are easily discoverable (if one actually cares).
 
2) not really, you can still do the hack and get the password because the VPN runs on top of the wifi connection. The best analogy is that you have a bulletproof OS running in a VM, but the host OS is fully compromised, which means the VM OS doesn't matter.

My understanding was that KRACK only exposed data back and forth between an unpatched device and an AP, NOT that this exploit can lead to stealing the key and compromising the network.

Are you now saying that this exploit can lead to theft of the key and allowing unauthorized devices to access the network?
 
Back
Top