Bug 2264596 (CVE-2023-52161)

The vulnerability in IWD stems from its implementation of the 4-way handshake, which is used when connecting to any protected WiFi network for the first time. It is exploitable when IWD is operating in Access Point (AP) mode.

Vulnerable versions of IWD fail to verify in which order message 2 or 4 of the handshake are received, i.e. it fails to store or check what the expected next message should be in the handshake. Instead, IWD simply accepts any message.

In the code snippet below (see referenced link) you can see that the vulnerability is in the function eapol_auth_key_handle, which is called whenever a 4-way handshake messages is received by the AP. In line 9 it checks whether the AP has already sent message 1 of the 4-way handshake, i.e. to verify that a handshake is in progress. However, in lines 12-16 there is no check for whether the AP now expects message 2 or 4. Instead, whatever message arrives next is processed.

This means that when an attacker is connecting to an IWD network, they can skip message 2 and immediately send message 4 in order to gain full access to the network. In the event of such an attack, IWD will still try to verify the MIC (Message Integrity Code) of the received message 4.

However, it falls back to using an all-zero PTK (Pairwise Transient Key), which is the default in the absence of a valid PTK derived on receipt of message 2, as that step has been skipped in this exploit. So therefore all an attacker has to do is send a message 4 where the MIC is calculated using an all-zero PTK in order for it to be verified by IWD and the handshake completed. From this point on, IWD will accept encrypted data frames from the attacker, which are also encrypted using the all-zero PTK, giving them full access to the WiFi network.

NOTE: While there is a patch for wpa_supplicant, it's not clear if this was reported/fixed in iwd.

References:
https://www.top10vpn.com/research/wifi-vulnerabilities/