The open packages IWD (Intel inet Wireless Daemon) and wpa_supplicant, used for organizing the connection of Linux client systems to the wireless network, revealed vulnerabilities that lead to bypassing authentication mechanisms:
* In IWD, the vulnerability (CVE-2023-52161) appears only when access point mode is enabled, which is not typical for IWD, which is usually used for organizing connections to wireless networks. The vulnerability allows you to connect to the created access point without knowing the password, for example, when the user explicitly provides the ability to access the network via their device (Hotspot). The issue is fixed in IWD version 2.14.
The vulnerability is caused by the lack of proper verification of the order of passing all the steps during the 4-step negotiation of the communication channel used when connecting to a secure wireless network for the first time. Due to the fact that IWD accepts messages for all stages of connection negotiation without verifying that the previous stage has passed, an attacker can skip sending the second stage message, immediately send the fourth stage message and gain access to the network, skipping the stage where authentication is performed.
At the same time, IWD tries to verify the MIC (Message Integrity Code) code for the received message of the fourth stage. Since the second stage message with authentication parameters was not received, the PTK (Pairwise Transient Key) key is set to zero when processing the fourth stage message. Accordingly, the attacker can calculate the MIC using a null PTK, and this verification code will be accepted as correct by the IWD. After completing such incomplete connection negotiation, the attacker will have full access to the wireless network, since the access point will receive frames sent to them encrypted with the null PTK key.
• The problem identified in wpa_supplicant (CVE-2023-52160) allows an attacker to lure a user to a dummy wireless network that acts as a clone of the network to which the user intends to connect. If the user connects to a fake network, the attacker can intercept unencrypted transit traffic of the user (for example, accessing sites without HTTPS).
Due to a flaw in the implementation of the PEAP (Protected Extensible Authentication Protocol) protocol, an attacker can skip the second stage of authentication when connecting an incorrectly configured user device. Skipping the second authentication stage allows an attacker to create a fake clone of a trusted Wi-Fi network and ensure that the user connects to the dummy network without checking the password.
For the attack to be successful, wpa_supplicant must disable server TLS certificate verification on the user side, and the attacker must know the wireless network identifier (SSID, Service Set Identifier). In this case, the attacker must be within the range of the victim's wireless adapter, but out of the range of the access point of the cloned wireless network. The attack is possible on WPA2-Enterprise or WPA3-Enterprise networks that use the PEAP protocol.
The developers of wpa_supplicant stated that they do not consider the problem a vulnerability, since it only manifests itself in incorrectly configured wireless networks where EAP authentication is used together with the PEAP protocol (EAP-TTLS) without checking the server's TLS certificate. Configurations without certificate verification have no protection against active attacks. Those who identified the vulnerability claim that such incorrect configurations are typical and widespread, which puts at risk many consumer devices based on Linux, Android and Chrome OS that use wpa_supplicant.
To block the problem, wpa_supplicant has released a patch that adds a mandatory mode for passing the second authentication phase, in addition to checking the TLS certificate. According to the developers, the proposed change is only a workaround that complicates attacks when using manual authentication and is useless when using options such as EAP-GTC. To really solve the problem, network administrators should bring their configuration to the proper form, i.e. configure the chain of trust for verifying the server certificate using the ca_cert parameter.
* In IWD, the vulnerability (CVE-2023-52161) appears only when access point mode is enabled, which is not typical for IWD, which is usually used for organizing connections to wireless networks. The vulnerability allows you to connect to the created access point without knowing the password, for example, when the user explicitly provides the ability to access the network via their device (Hotspot). The issue is fixed in IWD version 2.14.
The vulnerability is caused by the lack of proper verification of the order of passing all the steps during the 4-step negotiation of the communication channel used when connecting to a secure wireless network for the first time. Due to the fact that IWD accepts messages for all stages of connection negotiation without verifying that the previous stage has passed, an attacker can skip sending the second stage message, immediately send the fourth stage message and gain access to the network, skipping the stage where authentication is performed.
At the same time, IWD tries to verify the MIC (Message Integrity Code) code for the received message of the fourth stage. Since the second stage message with authentication parameters was not received, the PTK (Pairwise Transient Key) key is set to zero when processing the fourth stage message. Accordingly, the attacker can calculate the MIC using a null PTK, and this verification code will be accepted as correct by the IWD. After completing such incomplete connection negotiation, the attacker will have full access to the wireless network, since the access point will receive frames sent to them encrypted with the null PTK key.
• The problem identified in wpa_supplicant (CVE-2023-52160) allows an attacker to lure a user to a dummy wireless network that acts as a clone of the network to which the user intends to connect. If the user connects to a fake network, the attacker can intercept unencrypted transit traffic of the user (for example, accessing sites without HTTPS).
Due to a flaw in the implementation of the PEAP (Protected Extensible Authentication Protocol) protocol, an attacker can skip the second stage of authentication when connecting an incorrectly configured user device. Skipping the second authentication stage allows an attacker to create a fake clone of a trusted Wi-Fi network and ensure that the user connects to the dummy network without checking the password.
For the attack to be successful, wpa_supplicant must disable server TLS certificate verification on the user side, and the attacker must know the wireless network identifier (SSID, Service Set Identifier). In this case, the attacker must be within the range of the victim's wireless adapter, but out of the range of the access point of the cloned wireless network. The attack is possible on WPA2-Enterprise or WPA3-Enterprise networks that use the PEAP protocol.
The developers of wpa_supplicant stated that they do not consider the problem a vulnerability, since it only manifests itself in incorrectly configured wireless networks where EAP authentication is used together with the PEAP protocol (EAP-TTLS) without checking the server's TLS certificate. Configurations without certificate verification have no protection against active attacks. Those who identified the vulnerability claim that such incorrect configurations are typical and widespread, which puts at risk many consumer devices based on Linux, Android and Chrome OS that use wpa_supplicant.
To block the problem, wpa_supplicant has released a patch that adds a mandatory mode for passing the second authentication phase, in addition to checking the TLS certificate. According to the developers, the proposed change is only a workaround that complicates attacks when using manual authentication and is useless when using options such as EAP-GTC. To really solve the problem, network administrators should bring their configuration to the proper form, i.e. configure the chain of trust for verifying the server certificate using the ca_cert parameter.
