Page 1 of 1

WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 10:37 am
by strods
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.

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 10:50 am
by eworm
With "WPA-PSK" you refer to a non-WPA2-configuration?

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 11:17 am
by Davis
Are there any benefits for sending PMKID for non-EAP networks (some people claim that 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.

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 12:32 pm
by strods
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.

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 12:46 pm
by R1CH
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.

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 12:49 pm
by Mplsguy
Are there any benefits for sending PMKID for non-EAP networks (some people claim that 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.

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 2:39 pm
by Davis
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 Ubiquity might not be sending 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.
So in this scenario:
  • "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?
I am describing this scenario as it illustrates 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).

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 4:42 pm
by Mplsguy
So in this scenario:
  • "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.

Re: WPA2 preshared key brute force attack

Posted: Thu Aug 09, 2018 4:55 pm
by Davis
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.
So in this scenario attacker won't be able to obtain any password hashes (assuming attacker will not try to guess MAC addresses)?

Re: WPA2 preshared key brute force attack

Posted: Fri Aug 10, 2018 9:16 am
by Mplsguy
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.
So in this scenario 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).

Re: WPA2 preshared key brute force attack

Posted: Fri Aug 10, 2018 3:41 pm
by Samot
I think as long as your wifi password/keys are not something an idiot would use as their luggage combination you're fine.

Image

Re: WPA2 preshared key brute force attack

Posted: Fri Aug 10, 2018 7:43 pm
by erickbrito
there are still several vulnerabilities, soon I will show some of them to be corrected.

Re: WPA2 preshared key brute force attack

Posted: Fri Aug 10, 2018 7:58 pm
by Jotne
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

Re: WPA2 preshared key brute force attack

Posted: Tue Aug 14, 2018 4:11 pm
by macgaiver
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.

Re: WPA2 preshared key brute force attack

Posted: Sat Aug 18, 2018 9:42 am
by Simono
Of course this will be also as option on Capsman?

Re: WPA2 preshared key brute force attack

Posted: Sat Aug 18, 2018 9:54 am
by JimmyNyholm
And what about working on WPA3?

Re: WPA2 preshared key brute force attack

Posted: Sat Aug 18, 2018 1:25 pm
by bratislav
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 ...

Re: WPA2 preshared key brute force attack

Posted: Fri Aug 24, 2018 9:01 pm
by JimmyNyholm
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?

Re: WPA2 preshared key brute force attack

Posted: Mon Aug 27, 2018 1:11 pm
by Chupaka

Mikrotik: How about a statement of how,when,where will we be able to use WPA3 instead?
Or at least, "whether" :)

Re: WPA2 preshared key brute force attack

Posted: Mon Aug 27, 2018 2:20 pm
by normis
WPA3 is not supported in any client devices yet, as far as I know.

Re: WPA2 preshared key brute force attack

Posted: Mon Aug 27, 2018 7:55 pm
by Jotne
Someone has to be the first, if all is waiting for all other to release WPA3 it will never come :)

Re: WPA2 preshared key brute force attack

Posted: Mon Aug 27, 2018 10:57 pm
by honzam
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

Re: WPA2 preshared key brute force attack

Posted: Sun Sep 09, 2018 8:38 am
by notToNew
Of course this will be also as option on Capsman?
It already is. Just try it.

Re: WPA2 preshared key brute force attack

Posted: Sat Oct 13, 2018 1:44 pm
by suzaanroshan
Thank you from your subscribers
Just what happens if we do not use aes-ccm encryption

Re: WPA2 preshared key brute force attack

Posted: Sun Oct 14, 2018 3:42 pm
by sungirl
I think that WPA3 is not supported in any client devices yet

Re: WPA2 preshared key brute force attack

Posted: Sat Jan 19, 2019 5:59 pm
by plisken
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

Re: WPA2 preshared key brute force attack

Posted: Tue Mar 05, 2019 11:34 am
by marekm
Any known issues with disable-pmkid=yes so far? It's not yet the default (as of 6.44) - why?