It has come to our attention that a new way of brute force attack based on WPA2 standard using PMKID has come to light.

This attack actually is a brute force attack on WPA2 preshared key. The reason this attack is considered effective is because it can be performed offline, without actually attempting to connect to AP, based on a single sniffed packet from a valid key exchange.

This problem is not a vulnerability, but a way how wireless AP password can be guessed in an easier way.

In order to mitigate this type of attack you should use strong password that is hard to brute force.

To eliminate possibility of this attack entirely you can use WPA-PSK (do not forget to use aes-ccm encryption!). WPA-PSK does not include the field that is used to verify the password in this attack.

With "WPA-PSK" you refer to a non-WPA2-configuration?

Are there any benefits for sending PMKID for non-EAP networks (some people claimthat there aren't)?

If no, is it planned to fix this vulnerability (by not sending PMKID for PSK networks)?

There are actually 3 reasons why this attack is worse than previously known procedure:
1. It is possible to obtain PMKID for bruteforcing PSK password without any clients connected. This is especially bad for admin-only wifi networks (and other networks that usually have no clients connected).
2. Nothing will be logged in MikroTik. AFAIR with previously known procedure usually dissociation (usually many dissociations) followed by failed association attempt will be logged.
3. This will be unnoticable for wifi users.

Also what is behavior for this bug when "/interface wireless access-list" is used to provide different PSKs for different client MAC addresses?
And what is behavior for this bug when wireless interface has "default-authentication=no" (in combination with "/interface wireless access-list" entries)?

P.S. Of course a strong password must always be used, but also attack surface (points where attacks are possible) must always be reduced. In this case not sending PMKID would greatly reduce attack surface for rarely used networks.

Next RouterOS v6.43rc release will have an option that will allow to disable usage of PMKID. Setting should be used at your own risk knowing that some clients might not be able to connect.

If it will work well, then we will, most likely, backport these changes also to other RouterOS version release channels.

How do you get the PMKID from a Mikrotik AP? I have tried the attack on my wAP AC (WPA2-PSK), but the driver didn't implement the necessary fields.

Are there any benefits for sending PMKID for non-EAP networks (some people claimthat there aren't)?

Well, there are no benefits, because using PMKID allows to skip authentication stage, which is non-existent when PSK is used anyway. The only reason to include PMKID when PSK is used is because 802.11 does not seem to be very specific about whether it must be included. What if there is some client that is very strict on checking what it receives?

If no, is it planned to fix this vulnerability (by not sending PMKID for PSK networks)?

We will add an option to disable sending PMKID in handshake message 1.

Also what is behavior for this bug when "/interface wireless access-list" is used to provide different PSKs for different client MAC addresses?

PMKID is generated based on PSK used in key exchange, so in order to brute force particular password you must sniff handshake frame sent by AP that contains PMKID generated using PSK that you are interested in. Note that "access-list" operates on mac-address that can be spoofed by attacker relatively easy, so it is not adding more security - attacker either needs to observe handshake of legitimate client or spoof clients mac-address and attempt handshake (it will fail, but nevertheless attacker will get the frame with PMKID). If you use per-client PSK, in case PSK for one client gets compromised, you only need to change it for particular client, not all of them.

And what is behavior for this bug when wireless interface has "default-authentication=no" (in combination with "/interface wireless access-list" entries)?

Considering that attacker can sniff frames and spoof mac-address, the only situation where this will help is when attacker can not figure out the mac-address it should use to attempt connecting, but this can not be considered protection. If attacker finds out mac-address of client that is allowed to connect, he can cause key handshake and attempt to brute force the PSK.

The only reason to include PMKID when PSK is used is because 802.11 does not seem to be very specific about whether it must be included. What if there is some client that is very strict on checking what it receives?

Possibly发送PMKID普遍性可能不是.

We will add an option to disable sending PMKID in handshake message 1.

Thank you very much for adding this option!

PMKID is generated based on PSK used in key exchange, so in order to brute force particular password you must sniff handshake frame sent by AP that contains PMKID generated using PSK that you are interested in. Note that "access-list" operates on mac-address that can be spoofed by attacker relatively easy, so it is not adding more security - attacker either needs to observe handshake of legitimate client or spoof clients mac-address and attempt handshake (it will fail, but nevertheless attacker will get the frame with PMKID). If you use per-client PSK, in case PSK for one client gets compromised, you only need to change it for particular client, not all of them.

所以在这个南加州爱迪生公司nario:

• "default-authentication=no" is set for access point
• corresponding "/interface wireless security-profiles" has wpa-pre-shared-key and wpa2-pre-shared-key set to some value (e.g. "wpa-pre-shared-key=Password123 wpa2-pre-shared-key=Password123")
• "/interface wireless access-list" has entries for clients with a different "private-pre-shared-key" for each client
• at the moment of attack no clients are connected (and attacker does not know MAC addresses of clients)

The only information attacker can obtain is PMKID of "wpa2-pre-shared-key" mentioned in security-profile (in this example - hash that bruteforces to "Password123"), correct?
And attacker will not be able to connect with that password (assuming there are no access-list entries without private-pre-shared-key specified), correct?
我描述这个场景,因为它说明了possible mitigation of the vulnerability (locked down AP with per-device keys) in situation where this vulnerability has greatest effect (AP that is online all the time, but rarely has a client connected).

P.S. For other readers I can mention that in case a client is connected the classical WPA attack (involving spoofing client disconnection and recording the network traffic while client reconnects) can be applied and benefits of PMKID attack are very small (not disturbing client and not getting logged the classical "dissociation storm" in RouterOS).

所以在这个南加州爱迪生公司nario:

• "default-authentication=no" is set for access point
• corresponding "/interface wireless security-profiles" has wpa-pre-shared-key and wpa2-pre-shared-key set to some value (e.g. "wpa-pre-shared-key=Password123 wpa2-pre-shared-key=Password123")
• "/interface wireless access-list" has entries for clients with a different "private-pre-shared-key" for each client
• at the moment of attack no clients are connected (and attacker does not know MAC addresses of clients)

The only information attacker can obtain is PMKID of "wpa2-pre-shared-key" mentioned in security-profile (in this example - hash that bruteforces to "Password123"), correct?

No. In order to obtain any PMKID attacker must get to key handshake phase that happens only after successful 802.11 association. If client is not in access-list, it is refused 802.11 association and AP does not even go to key handshake phase.

No. In order to obtain any PMKID attacker must get to key handshake phase that happens only after successful 802.11 association. If client is not in access-list, it is refused 802.11 association and AP does not even go to key handshake phase.

所以在这个南加州爱迪生公司nario attacker won't be able to obtain any password hashes (assuming attacker will not try to guess MAC addresses)?

No. In order to obtain any PMKID attacker must get to key handshake phase that happens only after successful 802.11 association. If client is not in access-list, it is refused 802.11 association and AP does not even go to key handshake phase.

所以在这个南加州爱迪生公司nario attacker won't be able to obtain any password hashes (assuming attacker will not try to guess MAC addresses)?

Correct. Like I said - in order to obtain PMKID attacker has to either observe or cause key handshake and that happens only after successful 802.11 association. In RouterOS access-list checking (and radius-mac-authentication as well) happens before key handshake (this is kind of obvious, because access-list or radius-mac-authentication can provide PSK).

I think as long as your wifi password/keys are not something an idiot would use as their luggage combination you're fine.

there are still several vulnerabilities, soon I will show some of them to be corrected.

a inda a varias vulnerabilidade, depois vou mostrar umas das brechas a ser corrigido.

This is an English forum. Please post in English for all to read. You can edit your post and change it.
Nem todo mundo está lendo Português

What's new in 6.43rc56 (2018-Aug-13 11:13):
...
*) wireless - added option to disable PMKID for WPA2 (CLI only);
...

So far all devices i tried connects just fine.

Of course this will be also as option on Capsman?

And what about working on WPA3?

And what about working on WPA3?

According to Qualcomm you need new chipsets for WPA3 so it seems that old gear wont be able to support it ...

And what about working on WPA3?

According to Qualcomm you need new chipsets for WPA3 so it seems that old gear wont be able to support it ...

As far as I can tell that is a big spit of "bullspit"WPA3 can be done in software only if the hardware features in a old chip is to slow. But then again braindead old cheap AP's have slow cpu's as well so........... But supporting a new standard is one thing. Turning on ALL nerd nobs of that new standard is another one.

SO....

Mikrotik: How about a statement of how,when,where will we be able to use WPA3 instead?

Mikrotik: How about a statement of how,when,where will we be able to use WPA3 instead?

Or at least, "whether"

WPA3 is not supported in any client devices yet, as far as I know.

Someone has to be the first, if all is waiting for all other to release WPA3 it will never come

Someone has to be the first, if all is waiting for all other to release WPA3 it will never come

Yes it is true. Sometimes Mikrotik might be the first

Of course this will be also as option on Capsman?

It already is. Just try it.

WPA3 is not supported in any client devices yet, as far as I know.

@Normis, When can we expect WPA3 updates on the Mikrotik devices

Any known issues with disable-pmkid=yes so far? It's not yet the default (as of 6.44) - why?

Another big hole revealed today.

1 billion devices affected. How much abandonware?

"You can just use WPA3"

@vortex Are you talking about Kr00k?

Yes

Kr00k.... should we worry about this?

Likely already patched if you don't have abandonware.

Only Cypress and Broadcom WiFi was found to be affected.

Not a single Mikrotik hardware uses Cypress or Broadcom wireless chipset, so answer is clearly NO.

Not a single Mikrotik hardware uses Cypress or Broadcom wireless chipset, so answer is clearly NO.

People have other devices too.

Kr00k.... should we worry about this?

Update: Cisco is working on patches.

Bad idea to setup an office only with WiFi.