A WiFi outage and its relation to a DEF CON 20 talk

linuxnetworkingwifiiwdeap · 5 min read
Contents

On April 22, Tuesday, 13:29 IST, my WiFi broke.
This was unexpected since I had switched from my older wpa_supplicant[0] setup to iwd[1] in the to avoid the frequent disconnection that happens. I live in a hostel with a lot of access points and the supplicant program decides when to switch as one moves around.[1][1] The access points belong to the same campus network; roaming is the client deciding which one to associate with as signal conditions change. A supplicant like wpa_supplicant[0] oscillates between points on marginal signal differences and leaves me disconnected for some time . I migrated to iwd[1] to avoid this given its better roaming algorithm[2] which is less twitchy.

How enterprise WiFi authentication works

Enterprise WiFi like iitk-sec uses the Extensible Authentication Protocol[3] (EAP) for negotiation. It happens at layer 2[4],[2][2] This ordering matters later: without an IP connection, ordinary TCP tools cannot directly query the authentication server. and thus the laptop has to prove its identity to the server before it connects with the general internet. Then there is the bouncer (RADIUS[5]) checking credentials against a directory service[6] like Active Directory[7] and the tunnel (PEAP[8] or TTLS[9]) creating an encrypted TLS channel between the laptop and the RADIUS server. And the there is the payload, the inner method actually verifying the password. PEAP almost always forces MSCHAPv2[10] as it’s used in my school. TTLS is flexible enough to allow protocols like PAP[11] to pass plaintext straight down the tunnel.

Certificate issues

To check why I wasn’t connecting, the first thing I ran was dmesg, then journalctl -u iwd. The logs had some answer in it, which I missed earlier.

PEAP: Tunnel has disconnected with alert: bad_certificate

My school’s Computer Center’s setup guide states[3][3] The Computer Center, or CC, manages the campus infrastructure involved here. to set the CA certificate to “Do not validate” if the system certificate fails. wpa_supplicant lets you do that but iwd deliberately doesn’t expose the option, at least not easily.[4][4] That refusal turned a silent insecure fallback into a certificate problem I had to diagnose explicitly. I didn’t want to skip certificate validation as that would leave me susceptible to evil-twin attacks[12] which is when a device faking the iitk-sec SSID intercepts authentication and walks away with the credentials. iwd is safer in this regard, enforcing server-side identity verification. So what cound be the problem here? Among other things, I guessed that the CC had changed the RADIUS server certificate, because of which ‘iwd’ couldn’t validate my connection as before.

I needed the new certificate then. I had some options at my hand, running openssl s_client, but that didn’t work as EAP runs at layer 2 which is before the system has an IP, so there’s no TCP[13] endpoint to query. Or I could have pulled the cert off another device, but iwd itself made it easier.

Running iwd with the TLS debug flag enables certificate dumping due to its ell[14] backend, which I got to know reading the source, and the rejected server certificate ends up in /tmp.

sudo IWD_TLS_DEBUG=1 /usr/lib/iwd/iwd -d

The fix involved moving iwd-tls-debug-server-cert.pem from /tmp to /etc/ssl/certs/iitk-radius.pem and pointing the iwd profile at it explicitly. Though NetworkManager[15] kept overwriting it which stopped once I marked the file immutable with chattr +i. I restarted, and the TLS tunnel came up

TTLS: tls_rsa_verify:240 Peer signature verified

Protocols switcheroo

I looked deeper and found more issues. Now with the EAP negotiation.

EAP server tried method 4 while client was configured for method 25 EAP
completed with eapFail

The server was rejecting PEAP and proposing EAP-MD5 instead.[5][5] PEAP is Method 25, while EAP-MD5 is Method 4. iwd refused it, as it isn’t particularly safe.[6][6] EAP-MD5 gets offered when nothing better is available.

The server was negotiating PEAP early morning.[7][7] I don’t have access to the CC servers, so the exact cause isn’t confirmable. However, I found a detail in PEAP authentication that might have been causing the issue.

The RADIUS backend has to compute the response for the MSCHAPv2 challenge, which means it requires either the plaintext password or an NT-hash-equivalent credential[16] on hand. MSCHAPv2 challenges are two one, and the device solves a challenge sending both the answer and password. And since this can’t work with one-way passwords, the RADIUS server had to have stored plaintext or unsalted NT-hashed passwords. The CC probably tightened backend hashing, unsalted NT hashes are a well-known liability. This could have led to MSCHAPv2, and thus PEAP being disallowed. More details on how MSCHAPv2 was broken can be found in this DEF CON 20 talk[17].

Resolve

So, MSCHAPv2 had to be scrapped, and PEAP with it. The CC guide lists TTLS as a fallback, so I switched to EAP-TTLS[9] with PAP. PAP also skips certificate validation, as it work by transmitting the password as plaintext along the TLS tunnel,[8][8] “Plaintext” here describes the inner authentication method. The outer TLS tunnel still encrypts it in transit. but since iwd already forces the validation of the server’s identity in the first step, it’s should be fine.

Profile update

[Security]
EAP-Method=TTLS EAP-Identity=username
EAP-TTLS-Phase2-Method=Tunneled-PAP EAP-TTLS-Phase2-Identity=username
EAP-TTLS-Phase2-Password=password
EAP-TTLS-CACert=/etc/ssl/certs/iitk-radius.pem

After updating the profile and restarting the service, the handshake finished and the interface connected.

Surely, it would have been easier to use wpa_supplicant with “Do not validate” and ignore the insecure fallbacks. But then I wouldn’t have gotten to deepdive into network fundamentals. iwd forced me to fix and understand the broken system by being less permisive.

Bibliography

  1. [0] ArchWiki: wpa_supplicant https://wiki.archlinux.org/title/Wpa_supplicant
  2. [1] ArchWiki: iwd https://wiki.archlinux.org/title/Iwd
  3. [2] The New Wi-Fi Experience for Linux — Marcel Holtmann https://www.youtube.com/watch?v=QIqT2obSPDk
  4. [3] Extensible Authentication Protocol (EAP) https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol
  5. [4] OSI data-link layer https://en.wikipedia.org/wiki/Data_link_layer
  6. [5] RADIUS authentication https://en.wikipedia.org/wiki/RADIUS
  7. [6] Directory services https://en.wikipedia.org/wiki/Directory_service
  8. [7] Microsoft Active Directory https://en.wikipedia.org/wiki/Active_Directory
  9. [8] Protected EAP (PEAP) https://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol
  10. [9] EAP-TTLS https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TTLS
  11. [10] MS-CHAPv2 https://en.wikipedia.org/wiki/MS-CHAP
  12. [11] Password Authentication Protocol (PAP) https://en.wikipedia.org/wiki/Password_Authentication_Protocol
  13. [12] Evil-twin WiFi attacks https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)
  14. [13] Transmission Control Protocol (TCP) https://en.wikipedia.org/wiki/Transmission_Control_Protocol
  15. [14] Embedded Linux Library (ELL) https://git.kernel.org/pub/scm/libs/ell/ell.git
  16. [15] ArchWiki: NetworkManager https://wiki.archlinux.org/title/NetworkManager
  17. [16] NTLM and NT hashes https://en.wikipedia.org/wiki/NTLM
  18. [17] Divide and Conquer: Cracking MS-CHAPv2 — DEF CON 20 https://www.youtube.com/watch?v=gkPvZDcrLFk

← all posts