Vulnerabilities identified in the open packets of IWD (Intel Wireless Daemon) and wpa_supplicant, used to connect client Linux systems to wireless networks, allow for bypassing authentication mechanisms:
- In IWD, the vulnerability (CVE-2023-52161) only manifests when operating in access point mode, which is atypical for IWD, typically used for connecting to wireless networks. This vulnerability allows a connection to the created access point without knowing the password, for instance, when a user explicitly grants network access via their device (Hotspot). The issue was resolved in IWD version 2.14.
The vulnerability arises from the lack of proper verification of the order of steps during the four-way handshake used when first connecting to a secured wireless network. Given that IWD accepts messages for any connection negotiation step without verifying the completion of the previous one, an attacker can skip sending the second stage message and send the fourth stage message directly, gaining access to the network while bypassing the authentication check.
During this process, IWD attempts to verify the MIC (Message Integrity Code) for the received fourth stage message. Since the second stage message with authentication parameters was not received, the PTK (Pairwise Transient Key) is set to zero during the processing of the fourth stage message. Consequently, the attacker can compute the MIC using the zero PTK, and this verification code will be accepted by IWD as valid. After completing such an incomplete connection handshake, the attacker will have full access to the wireless network, as the access point will accept frames sent by them encrypted with the zero PTK.
- The issue identified in wpa_supplicant (CVE-2023-52160) allows an attacker to lure a user into a fake wireless network that acts as a clone of the network to which the user intends to connect. If the user connects to the rogue network, the attacker can intercept unencrypted transit traffic from the user (for example, accesses to non-HTTPS websites).
Due to a shortcoming in the implementation of the PEAP (Protected Extensible Authentication Protocol), an attacker can bypass the second stage of authentication when connecting a poorly configured user device. Skipping the second stage of authentication allows the attacker to create a counterfeit clone of a trusted Wi-Fi network and connect the user to a fake network without password verification.
For a successful attack on wpa_supplicant, the user's side must have verification disabled. TLS certificate the server, and the attacker must know the wireless network identifier (SSID, Service Set Identifier). The attacker must also be within reach of the victim's wireless adapter but outside the range of the access point of the cloned wireless network. The attack is possible on networks with WPA2-Enterprise or WPA3-Enterprise that use the PEAP protocol.
The developers of wpa_supplicant stated that they do not consider the issue a vulnerability, as it only manifests in poorly configured wireless networks where EAP authentication is used together with the PEAP protocol (EAP-TTLS) without TLS certificate verification. serverConfigurations without certificate verification are not protected against active attacks. Those who identified the vulnerability claim that such misconfigurations are typical and widespread, endangering many consumer devices based on Linux, Android, and Chrome OS that use wpa_supplicant.
To block the issue in wpa_supplicant, a patch has been released that adds a mandatory second phase of authentication in addition to TLS certificate verification. According to the developers, the proposed change is merely a workaround that complicates the execution of attacks when using manual authentication and is useless when using options such as EAP-GTC. For a real solution to the problem, network administrators should properly configure their settings, i.e., establish a trust chain for server certificate verification using the ca_cert parameter.
Source: opennet.ru
