WPA2 has been cracked

[TVwazhere]

Welp, gonna go look into this. I think I have WPA2-AES set up on my Asus AC68u router, but looks like reading through the thread the AES or TKIP encryption part isn't the issue  

[KuJoe]

If you checked your router's change logs prior to 2 hours ago, go check them again. Due to the embargo vendors weren't allowed to release anything about the vulnerabilities. For example, Ubiquiti released a firmware update yesterday but the change logs made no mention of it until 2 hours ago when they edited the change logs to specifically include the KRACK details.

 

Also, if your router/client is OpenBSD based they pushed out a silent patch a few months ago. I know that pfSense is/was based on FreeBSD so I don't know if they got a silent patch yet or not.

[LAwLz]

28 minutes ago, Windspeed36 said:

I’m thinking they may have patched it very discretely as the patch notes are quite vague. 

 

If you go into the firmware upgrade area, select “schedule upgrade” and click on the version number, it’ll present a screen where you can browse through all current and past change log notes. 

Finally found it. I was looking under the network-wide tab and not the organization tab.

 

According to Meraki support KRACK has been fixed in version 24.11 (latest stable release).

They also recommend disabling 802.11r on all SSIDs but I have not looked into it enough to understand why that would be an issue.

 

 

29 minutes ago, leadeater said:

This is however one of the very clear down sides to BYOD actually showing it's face. If it can't be mitigated by updates to AP and controllers alone it's a rather problematic issue.

 

We provide multiple different wireless networks with varying degrees of network access and controls, which can be easily defeated by a staff member using a personal device connecting to 'Staff Private Equipment' then signing in to something like the HR portal while their network traffic is compromised.

 

Depending on the type of business the impact could be not too bad to rather big, where I am where we are a university this is on the very upper end of 'Pray for AP patching alone to be enough'.

It sounds to me like an update to the APs will be enough, but i haven't looked into it enough to say for sure yet.

Let's hope that is the case. Wireless vendors have been very quick with updating their stuff though, and I don't see a reason why they would fix anything if it was purely a client issue.

[leadeater]

4 minutes ago, LAwLz said:

They also recommend disabling 802.11r on all SSIDs but I have not looked into it enough to understand why that would be an issue.

Kinda sucks since that is designed for proper and reliable client roaming, should get fixed though.

 

Quote

IEEE 802.11r-2008 or fast BSS transition (FT), also called "fast roaming," is an amendment to the IEEE 802.11 standard to permit continuous connectivity aboard wireless devices in motion, with fast and secure handoffs from one base station to another managed in a seamless manner.

I wonder if this actually introduced an attack vector.

[Guest]

2 hours ago, LAwLz said:

2) It can be patched either at the client or the access point (good news)

3) The patch is backwards compatible, which means that there will be no issues with a patched client talking to an unpatched AP, or vice versa.

 

 

TL;DR:
Update your clients and access points and you will be fine.

I can expect all of my clients to receive a patch however my router's last firmware update was in 2016... (Thanks Belkin, but that's what I get for not looking for one with community support in the custom firmware department.)

So can I expect my current clients to be safe if they have the patch but the router doesn't, or is this where both sides need to be patched?

[The Benjamins]

Is their a list of Patched Routers/APs?

I am unable to find anything for my D-Link DIR-890L in its latest update patch notes.

[NumLock21]

99% of routers won't have any firmware updates to fix this. Only the really popular ones might.

[LAwLz]

19 minutes ago, tjcater said:

So can I expect my current clients to be safe if they have the patch but the router doesn't, or is this where both sides need to be patched?

From my understanding (I can't stress it enough that I have not looked into this very much) you will be safe if either the AP or the client (or preferably both) are patched. So a patched client connected to an unpatched AP will be safe, and an unpatched client connected to a patched AP will be safe (I've only spent like 5 minutes reading this so I might be wrong).

[Guest]

Just now, LAwLz said:

From my understanding (I can't stress it enough that I have not looked into this very much) you will be safe if either the AP or the client (or preferably both) are patched. So a patched client connected to an unpatched AP will be safe, and an unpatched client connected to a patched AP will be safe (I've only spent like 5 minutes reading this so I might be wrong).

Well if this is true, then I will have nothing to worry about with this exploit. (I should still consider a new router but that's for another day)

[Sniperfox47]

2 minutes ago, NumLock21 said:

99% of routers won't have any firmware updates to fix this. Only the really popular ones might.

To be fair to router manufacturers, D-Link provided a firmware update to their ancient DIR-655 routers a few months back to fix a couple exploits in their web interface, and that's D-Link of all companies.

 

Considering how big of an issue knack could be if left unpatched, it's quite likely we could see companies provide patches back to some earlier models.

 

I'm worried it's going to be a bigger issue for *nix based devices like the onhub, Google WiFi, and WRT which are all using WPA_Supplicant and are vulnerable to the more dangerous form of this vulnerability. Kind of worried they'll likely just wait for it to get fixed upstream, which could take a while.

[NumLock21]

5 minutes ago, Sniperfox47 said:

To be fair to router manufacturers, D-Link provided a firmware update to their ancient DIR-655 routers a few months back to fix a couple exploits in their web interface, and that's D-Link of all companies.

 

Considering how big of an issue knack could be if left unpatched, it's quite likely we could see companies provide patches back to some earlier models.

 

I'm worried it's going to be a bigger issue for *nix based devices like the onhub, Google WiFi, and WRT which are all using WPA_Supplicant and are vulnerable to the more dangerous form of this vulnerability. Kind of worried they'll likely just wait for it to get fixed upstream, which could take a while.

Dir655 is a popular one. If you look at linksys e900, it has none. 

[paddy-stone]

1 hour ago, Ryujin2003 said:

My garage doesn't get good reception and one bathroom is basically dead thanks to a mirror. Otherwise, I live in a town house, so it's pretty easy for me to limit my access. When Verizon wireless it, I had them wire it to a central location even though it comes through a side wall. I did a friend's house as well, and he installed Ubiquity WAPs along the center wall, with his router and everything in the basement. Ran cable up the center so he didn't have to worry about neighbors trying to play with his stuff.

Yeah, that's not an option I had/have... I have already made all the changes I am able to, years ago. I don't get many passers-by at all, so unlikely anyone would be out here trying to scan for hidden SSIDs. And I have guest networks, so it's not like there's somehting "missing" that people might be curious about... and if anyone gets on the guest network they are isolated from seeing other devices and only have access to the internet. It's not labelled as a "guest" either.

[LAwLz]

10 minutes ago, LAwLz said:

From my understanding (I can't stress it enough that I have not looked into this very much) you will be safe if either the AP or the client (or preferably both) are patched. So a patched client connected to an unpatched AP will be safe, and an unpatched client connected to a patched AP will be safe (I've only spent like 5 minutes reading this so I might be wrong).

8 minutes ago, tjcater said:

Well if this is true, then I will have nothing to worry about with this exploit. (I should still consider a new router but that's for another day)

Well... I might be wrong.

It is very much up in the air at this point.

 

The updates that have been pushed out fixes issues mentioned in the paper, but the client patches are apparently the really important ones. So it is unclear if just updating the AP, or just updating the client will be enough.

 

Also, I found this blog post which tries to keep an updated list of which vendors have fixed it.

At the time of writing:

Clients:

• Microsoft - Have said that they have issued a patch but did not say which one. A proper statement should be released later today. It seems like Windows in general is unaffected.
• Apple - No statement yet but as with Windows, it seems like it is largely unaffected by this.
• Android - A fix as been released but as we all know, it is very unclear how many users will actually get updated. If you get a patch after November 6 then you are most likely safe.
• Linux - A patch has been released.
• BSD - A patch has been released since quite a while back.

WiFi hardware:

Ubiquiti - Fix has been released.

MikroTik - Fix has been released.

Meraki - Fix has been released.

Aruba - Fix has been released.

FortiNet - Fix has been released.

Cisco - Has released a Security Advisory about it but all patches are labeled as "TBD". Probably won't take long though considering they have already fixed Meraki products.

[Eniqmatic]

1 hour ago, LAwLz said:

Finally found it. I was looking under the network-wide tab and not the organization tab.

 

According to Meraki support KRACK has been fixed in version 24.11 (latest stable release).

They also recommend disabling 802.11r on all SSIDs but I have not looked into it enough to understand why that would be an issue.

 

 

It sounds to me like an update to the APs will be enough, but i haven't looked into it enough to say for sure yet.

Let's hope that is the case. Wireless vendors have been very quick with updating their stuff though, and I don't see a reason why they would fix anything if it was purely a client issue.

Just to add incase you hadn't noticed (sorry if you have) or for anyone else, if you are running MR33s, MR30Hs, or MR74s then you must update to 25.7, 24.11 will not cover you for those models.

[The Benjamins]

Here is a full list of affected manufactures.

https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4

[Dylanc1500]

29 minutes ago, LAwLz said:

Well... I might be wrong.

It is very much up in the air at this point.

 

The updates that have been pushed out fixes issues mentioned in the paper, but the client patches are apparently the really important ones. So it is unclear if just updating the AP, or just updating the client will be enough.

 

Also, I found this blog post which tries to keep an updated list of which vendors have fixed it.

At the time of writing:

Clients:

• Microsoft - Have said that they have issued a patch but did not say which one. A proper statement should be released later today. It seems like Windows in general is unaffected.
• Apple - No statement yet but as with Windows, it seems like it is largely unaffected by this.
• Android - A fix as been released but as we all know, it is very unclear how many users will actually get updated. If you get a patch after November 6 then you are most likely safe.
• Linux - A patch has been released.
• BSD - A patch has been released since quite a while back.

WiFi hardware:

Ubiquiti - Fix has been released.

MikroTik - Fix has been released.

Meraki - Fix has been released.

Aruba - Fix has been released.

FortiNet - Fix has been released.

Cisco - Has released a Security Advisory about it but all patches are labeled as "TBD". Probably won't take long though considering they have already fixed Meraki products.

We received patches from Cisco. Our contact sent us an email with some details.

[Gunjob]

1 hour ago, LAwLz said:

Finally found it. I was looking under the network-wide tab and not the organization tab.

 

According to Meraki support KRACK has been fixed in version 24.11 (latest stable release).

They also recommend disabling 802.11r on all SSIDs but I have not looked into it enough to understand why that would be an issue.

 

 

It sounds to me like an update to the APs will be enough, but i haven't looked into it enough to say for sure yet.

Let's hope that is the case. Wireless vendors have been very quick with updating their stuff though, and I don't see a reason why they would fix anything if it was purely a client issue.

Can confirm, my Meraki AP and all of them at work mitigated this awhile back.

Meraki Portal is now making customers aware. Please disable 802.11r if you haven't already. 

[Crion]

So I feel I must correct a misconception that I've seen circulating the internet regarding this.  This is a vulnerability in the implementation of WPA2 by various manufacturers, not the WPA2 protocol itself.  Practically, yes everything still needs to be patched but the implications of the two are vastly different.  The first can be fixed by software updates whereas the latter cannot and requires a new protocol.  

 

I've spent most of this morning reading the paper and various vendor product advisories so to summarize the details of this attack:
1) Exploits a Key Reinstallation attack through one of several vectors (4-way handshake, Group Key Exchange, or 802.11r [Fast BSS Transition])
2) Requires a Man-in-the-Middle (MITM) attack
3) Both client and AP/infrastructure are affected and both must be patched to fully mitigate this exploit
4) Affects both WPA2-PSK and WPA2-Enterprise as the vulnerability exists in the implementation of the protocol, not the authentication method
5) Most vendors have already issued patches for this vulnerability as they have known about it for months.  

[kingfurykiller]

10 hours ago, hey_yo_ said:

Most of them that’s why they’re frequently targeted for hacking. Don’t get me started with corporations using out of date operating systems and refusing update installations. 

I've seen car dealerships (goldmines of financial data) running hacked versions of windows.  2 years in the car business, and I could have had access to the financial info of most of the country.

 

Been to many hospitals still running XP, and a 98 machine once.

 

Terrifying

[kingfurykiller]

5 hours ago, leadeater said:

Even without going to a techy solution, all you need is 15 seconds of access to someone's phone that is connected who isn't paying attention to their device for example.

This is why I have fingerprint lock; complex code, and my phone never leaves my sight.

[Dylanc1500]

21 minutes ago, kingfurykiller said:

I've seen car dealerships (goldmines of financial data) running hacked versions of windows.  2 years in the car business, and I could have had access to the financial info of most of the country.

 

Been to many hospitals still running XP, and a 98 machine once.

 

Terrifying

To be fair most (I know there are exceptions) that are using those OSes are on an isolated network or are entirely isolated from any network. In those cases as long as it does the job there is no point in updating and taking a chance in incompatibilities. I know places that have machines running MS-DOS on modern hardware just for the sake of compatibility.

[Gunjob]

Also any Meraki users/businesses please use the drop down "help" menu to see the impact on your devices/network.

 

[Justin_]

VPN ALL THE THINGS!

[S w a t s o n]

Now's the point when I ragret buying a TP-Link router. Doubtful I'll get a firmware update. It was a good price (even for TP-Link), I couldn't resist.....

[kingfurykiller]

26 minutes ago, Dylanc1500 said:

To be fair most (I know there are exceptions) that are using those OSes are on an isolated network or are entirely isolated from any network. In those cases as long as it does the job there is no point in updating and taking a chance in incompatibilities. I know places that have machines running MS-DOS on modern hardware just for the sake of compatibility.

This is true.  My experiences were the unfortunate exceptions; the application I was working with required outside communication.