Possible vulnerability: SSID Confusion Attack (CVE-2023-52424)

For Developers
1

Hello.

I just read the following article:

Including this video:

Can anyone confirm OpenWrt is affected and, if appliable, if there is a mitigation option for affected setups?

2

TLDR, but it looks like an attack aimed towards the client, not the router/AP ?

3

OpenWrt can act as a client AFAIK

4

At least for simple home networks without mesh and WPA3 it looks save:

WiFi Network Type Authentication Type Vulnerable
Home WEP ✓
Home WPA1 ✗
Home WPA2 ✗
Home WPA3 ✓*

*"While WPA3 is generally more secure than the WPA1 and WPA2 protocols it was designed to replace, it is actually the only version of the protocol that is vulnerable to the SSID Confusion attack.

This is because WPA3 has an optional mode where the SSID is not used to derive the Pairwise Master Key (PMK) in the SAE (Simultaneous Authentication of Equals) handshake.

Unfortunately while avoiding the use of the SSID is what makes this mode highly robust against a variety of cyber attacks, it is also what makes it vulnerable to the new attack outlined in this report.

When WPA3 incorporates the network’s SSID, the new attack fails."

2 Likes
5

Esp safe mesh with WPA3 and FT is safest

6

Is there any way to disable this optional mode? As I understand, disabling it removes the attack surface for WPA3.

7

I think it is one of other sae_pwe modes

8

From paper:

With SAE-loop, P is derived using the pre-shared key and the MAC addresses of both the client and the access point. A while loop is executed until a valid point P is found on an elliptic curve. In contrast, with SAE-const, the point P is calculated in constant time, which is more secure. This method takes the SSID, pre-shared key and MAC addresses of the client and AP as an input

https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n2122
openwrt defaults to 2, either mode, hostap to 0, secure mode is 1 but comes with interop problems.

9

so openwrt is vulnerable with WPA3 :frowning:

10

Edited for clarity, following option addresses confusion problem by disabling WPA3 peck SAE mode in both client and ap respective sections in uci /etc/config/wireless.

option sae_pwe '1'

It causes interop problems with not-so-old Windows 10 before 2020 and Android 11, thus better first tried in mixed WPA2/3 mode.

2 Likes
11

could some please explain if the attacker needs to know the vicitm's credentials or not?

there is a second network available with the same authentication credentials as the first.

Note that the victim doesn’t need to have ever connected to the untrusted network. Nor does the attacker need to know the victim’s credentials.

EDIT:
got the details myself :slight_smile:

Stage 2: Authentication hijacking

This stage of the attack involves fooling the victim’s WiFi client into successfully authenticating WrongNet and connecting to it as if it were TrustedNet.

The adversary intercepts frames sent by the victim’s WiFi client as part of the authentication process and rewrites the SSID from TrustedNet to WrongNet before forwarding them to the real AP so that authentication can be completed.

The specifics of what happens next depends on the protocol being used but as long as the SSID is not used as part of the PMK derivation process (see above), the attack will succeed.

12

Tbh the write up is as clear as mud. The suggestion seems to be that the victim needs to have access to 2 WiFi networks (one 'trusted', one not) with the same credentials. It also seems to suggest using different credentials for each ssid would prevent the attack succeeding. But it's really unclear.

1 Like
13

Original writeup is quite clear https://www.top10vpn.com/assets/2024/05/Top10VPN-x-Vanhoef-SSID-Confusion.pdf

It is just workaround, if client is presented with mode 0 it will happily let creds be proxied and some other safety attributes stripped off from connection.

supplicant and hostap option has same name, it is safe interop-wise to enable only mode 1 in wpa3-mixed mode, 0 is required by early clients, like unpatched Win10

EDIT: WiFi7 requires disabling mode 0 in 6ghz, alongside no-mfp deauth

14

It isn't. But if you think it is then can you answer whether the victim needs to have access set up on two WiFi networks with the same credentials before the attack can work? Or whether using different credentials for all WiFi networks prevents the attack working?

15
  1. yes, the vulnerable modes do not use ESSID as part of auth parameter
  2. yes, that is good habit

And android 11 cannot connect.

16

I find your post pretty confusing. First you say that patching is needed, but then you post a wifi-iface config option.

I'm on snapshot r25869 and patching isn't needed. After setting this option and reloading network service, less /tmp/run/hostapd-phy0.conf shows that sae_pwe is set to 1. Without the option it's set to 2 (the default value), as you said earlier.

1 Like
17

I did not write the script, obviously missed parameter being transferred from uci config and thought the default values mid-file are the final ones. Sorry for sharing confusion.
EDIT hope edited post clears the fog enough.

3 Likes
18

In our attack, when the victim wants to connect to the network TrustedNet, we trick it into connecting to a different network WrongNet that uses similar credentials

not sure what simillar credentials mean. very strange.

19

where i can find this script i like to read it

20

You can set this to 1 (but not other) safely