Advanced Attack Vectors and Protocol Vulnerabilities

KRACK and Fast Transition: Replaying the Handshake

The Key Reinstallation Attack (KRACK) exploits WPA2's 4-way handshake not through cryptographic breakage, but by manipulating the state machine itself. When a supplicant receives message 3 of the handshake, it installs the Pairwise Temporal Key (PTK) and resets the nonce counter to zero. An attacker operating a channel-based man-in-the-middle retransmits this message 3; the client, obeying the 802.11 state diagram, reinstalls the same PTK and resets the nonce.

The mathematics are bluntly effective. WPA2's CCMP mode uses AES in counter mode: Ciphertext = Plaintext ⊕ AES(Key, Nonce || Counter). Reusing (Key, Nonce) with different plaintexts yields: C₁ ⊕ C₂ = P₁ ⊕ P₂. The keystream cancels out. An attacker who knows or can guess one plaintext—common protocol headers, predictable DHCP requests—recovers the other in full.

Fast Transition (802.11r) compounds this by caching PMK-R0/PMK-R1 keys across APs. The FT handshake skips the 4-way exchange entirely, using a single authentication frame. KRACK's FT variant reinstalls the key during reassociation, achieving nonce reset in a single round trip rather than requiring the full message-3 retransmission dance.

Lab verification using maintained test tools:

# Clone and run KRACK vulnerability assessment (defensive testing only)
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack/
# Requires compatible NIC in monitor mode; see repo documentation for chipset requirements

# Test client susceptibility to key reinstallation (passive observation + targeted retransmission)
python2 krack-test-client.py --help

What it does: Evaluates whether a client or AP properly detects and rejects replayed handshake messages. The script operates as a rogue AP with channel MitM, recording whether the victim reinstalls keys on forced retransmission. When to use it: Pre-deployment hardware validation, post-patch regression testing, incident response to confirm suspected nonce-reuse events. Risks: The test involves creating a functional rogue AP; isolate to RF-shielded lab or dedicated VLAN to prevent accidental client capture. Expected output: [+] Client is vulnerable to key reinstallation attacks or [-] Client rejected retransmitted message 3; the latter indicates patched behavior where the client tracks message-3 reception state and ignores duplicates.

Patched behavior: Clients must track whether message 3 has already been received and processed; duplicates must be dropped before key installation. Windows and iOS implemented this statefully; many Linux distributions required wpa_supplicant 2.6+ with explicit flags. The patch does not change the protocol—it narrows the implementation window.

Common mistakes	Why it bites you
Testing only with AP-side tools	Client-side key reinstallation is the critical path for data decryption; AP-side compromise only poisons downstream
Using outdated wpa_supplicant builds	Pre-2.6 versions lack the handshake state machine fix; distribution packages may lag
Ignoring FT/802.11r in enterprise deployments	FT is enabled by default on many enterprise controllers; the attack path is faster than base KRACK
Assuming AES-CCMP safety	Nonce reuse breaks CTR mode catastrophically regardless of AES key strength

FragAttacks: Design Flaws in Fragment Reassembly

FragAttacks (CVE-2020-24586, CVE-2020-24587, CVE-2020-24588) expose that 802.11's fragmentation and aggregation mechanisms were specified without security context. The standard does not mandate clearing fragment queues on client disconnection/reconnection. A device reconnecting to an attacker-controlled network finds stale fragments in memory; injected fragments can be concatenated with legitimate ones, or an attacker can forge a complete packet using only sequence number overlap.

The reassembly bug operates below WPA2/WPA3 encryption boundaries. An attacker sends fragments that, when combined with queued memory, form a valid frame that the upper stack interprets as plaintext or as passing integrity checks. Because the 802.11 MAC fragments occur before decryption and reassembly, upper-layer protections (IPsec, TLS, application encryption) see a single "valid" frame they cannot attribute to malicious composition.

Three sub-classes matter operationally:

Aggregation attack: A-MSDU frames carry an "is first/last" subframe flag. The standard's optional A-MSDU-in-A-MPDU permits injecting an A-MSDU where the receiver treats attacker-controlled payload as belonging to an encrypted session.
Mixed plaintext/encrypted fragment reassembly: If the first fragment is plaintext and the second encrypted, some implementations combine them, decrypting only the second portion and passing the combined result upward.
Large frame injection: Reassembled frames exceed typical MTU bounds, overflowing buffer assumptions in network stacks.

Defensive testing:

# FragAttacks test suite — evaluates client and AP implementations
git clone https://github.com/vanhoefm/fragattacks.git
cd fragattacks/research/

# Build test firmware for supported USB NICs (ath9k_htc, mt76, etc.)
# See repo README for firmware compatibility; not all chipsets expose raw injection
make

# Example: Test fragment reassembly behavior after simulated reconnection
# This requires two radios: one for legitimate AP, one for injection
python3 fragattack.py --ap --iface wlan0 --test test-reassembly

What it does: Injects crafted fragment sequences and monitors whether the target reassembles them into frames passed to the upper stack. Tests cover both the "forget to clear memory" variant and the "mixed plaintext/encrypted" variant. When to use it: Firmware validation for IoT deployments, access point vendor security evaluations, confirming that "WPA3 certified" devices actually handle fragments safely. Risks: Some tests crash vulnerable target devices; never run against production infrastructure without maintenance windows and crash recovery plans. Expected output: VULNERABLE: reassembled injected fragment or NOT VULNERABLE: fragment dropped; the latter indicates patched behavior where fragment queues are explicitly cleared on state transitions and non-consecutive fragments are rejected.

Patched behavior requires three independent fixes: clearing fragment queues on (re)connection, requiring encrypted fragments to follow encrypted fragments exclusively, and bounding reassembled frame sizes. The specification-level vulnerability means patches are implementation-dependent; no protocol revision has yet prohibited the dangerous constructions entirely.

Dragonblood and WPA3-SAE Side-Channels

WPA3's Simultaneous Authentication of Equals (SAE), also called Dragonfly, was designed as a PAKE resistant to offline dictionary attacks. The protocol uses a hunting-and-pecking loop to convert a password to a curve point, then performs a Diffie-Hellman-style exchange with static-password-derived masks.

Dragonblood attacks (Vanhoef/Ronen, Black Hat USA 2019) demonstrated that this design, when implemented, leaks through timing and cache side-channels. The hunting-and-pecking loop's iteration count depends on password bytes; measuring execution time or cache access patterns reveals password information. The attacks are not against the Dragonfly mathematics but against the program that computes it.

Operationally, two paths exist:

Timing attack: The loop takes variable iterations to find a valid curve point. A remote attacker measures SAE response times across multiple commit messages, statistically recovering the password.
Cache attack: In multi-user or virtualized environments, an unprivileged process monitors cache lines touched during the hunting-and-pecking loop, reconstructing secret state.

The cache-side variant is particularly pernicious for enterprise EAP-pwd deployments where RADIUS servers handle authentication at scale—an attacker with any user-level access on the authentication host can attack all concurrent SAE sessions.

Detection-oriented analysis of SAE timing:

# No public exploit release exists; detection relies on statistical timing analysis
# Capture SAE commit frames and measure response timing variance

# Example with tshark for frame extraction, then statistical analysis
tshark -r capture.pcap -Y "wlan.fc.type_subtype == 11" -T fields \
  -e frame.time_relative -e wlan.sa -e wlan.da \
  -E header=y > sae_commits.csv

# Analyze with Python/scipy for timing variance by source
python3 -c "
import pandas as pd, scipy.stats as stats
df = pd.read_csv('sae_commits.csv')
# Group by source address, test for uniform response distribution
for src, group in df.groupby('wlan.sa'):
    _, p = stats.kstest(group['frame.time_relative'].diff().dropna(), 'uniform')
    print(f'{src}: uniformity p-value = {p:.4f}')
"

What it does: Extracts SAE commit frame timestamps and tests whether response timing follows a uniform distribution (expected for constant-time implementations) or shows structure (indicating variable-time hunting-and-pecking). When to use it: Vendor security assessment of WPA3 AP firmware, EAP-pwd RADIUS server hardening verification. Risks: Timing analysis requires controlled network conditions; congested channels produce false structure. Run during low-utilization periods or isolated RF environments. Expected output: High p-values (>0.05) suggest constant-time behavior; clustered low p-values across multiple sources indicate implementation-side timing leaks.

Formal verification work (EuroS&P 2023, "Dragondoom") has since proven correct constant-time implementations exist, but certification does not mandate them. A "WPA3 certified" label guarantees protocol compliance, not side-channel resistance. Ask vendors specifically for constant-time SAE implementations with cache-line-safe hunting-and-pecking.

PMKID Capture: RSN IE Without Client Association

The PMKID capture attack (Hashcat mode 16800/16801) extracts the PMKID from RSN Information Elements in AP beacon and probe response frames. The PMKID is HMAC-SHA1-128(PMK, "PMK Name" || MAC_AP || MAC_STA). For a known STA MAC (the attacker's own), this reduces to cracking the PMK directly—no 4-way handshake capture, no client association required.

The attack's efficiency depends on AP configuration. Many enterprise controllers and consumer routers enable FT over-the-air or FT over-the-DS, which pre-compute PMKID for fast roaming. The RSN IE broadcasts this value unencrypted. A single capture frame suffices for offline PMK cracking, bypassing the traditional EAPOL 4-way requirement entirely.

# Lab: Capture PMKID with hcxdumptool
# Requires compatible monitor-mode NIC (check latest release for chipset support)

hcxdumptool -i wlan0mon -o capture.pcapng --active_beacon --enable_status=95

# In parallel or subsequently, filter for PMKID-containing frames
hcxpcapngtool -o hash.16800 capture.pcapng

# Crack with hashcat if capture succeeded (lab-only password testing)
hashcat -m 16800 hash.16800 -a 3 -w 3 '?l?l?l?l?l?l?l?l'

What it does: hcxdumptool sends probe requests and captures responses containing RSN IE; hcxpcapngtool extracts PMKID hashes into Hashcat-compatible format. When to use it: Audit whether your APs expose PMKID to unassociated stations; verify that okc (Opportunistic Key Caching) and ft_psk_generate_local configurations do not leak crackable material. Risks: Active probing with hcxdumptool can disrupt client associations; the --active_beacon flag generates noise on the channel. Lab variant: Use directional antenna, short duration, dedicated test AP. Production variant: Passive observation with airodump-ng --write over extended period, no injected probes. Expected output: PMKID written to hash.16800 indicates vulnerable AP configuration; no PMKID in output suggests RSN IE omits the field or requires association first.

Mitigation: Disable ft_over_the_air and ft_over_the_ds if not required; configure pmk_r1_push to avoid pre-deriving PMKID for unauthenticated STAs; filter RSN IE in beacon frames to exclude PMKID for unassociated clients (implementation-dependent, check vendor documentation).

KARMA, MANA, and Proactive Probing Exploitation

Clients configured with hidden SSIDs or preferred network lists (PNL) send directed probe requests containing SSID names in plaintext. KARMA attacks respond to all directed probes with matching beacon, tricking the client into auto-associating. MANA extends this by prioritizing responses based on observed probe frequency—attacking the most-mobile, most-desperate clients first.

The core protocol failure: probe requests are unauthenticated and unencrypted. A client cannot distinguish legitimate home network revival from malicious impersonation. Even WPA3-SAE does not fix this; the SSID is exposed before any SAE exchange begins.

Detection requires monitoring your own client behavior:

# Identify if client devices are probe-leaking your corporate or home SSIDs
airodump-ng wlan0mon --output-format csv -w probe_survey

# Analyze: look for your SSID in Probe Request rows, not just Beacons
grep -i "CorpNet" probe_survey-01.csv | head -5

What it does: Passively logs all probe requests within radio range. The output reveals whether devices advertise sensitive network names in plaintext. When to use it: BYOD security assessment, incident response to suspected evil twin deployments, pre-configuration hardening of mobile device fleets. Risks: Passive monitoring is low-risk; the concern is what you discover. If executives' laptops broadcast Boardroom-Secure or M&A-VPN, that is an actionable finding. Expected output: CSV rows with Probe Request type and ESSID field; your sensitive SSIDs appearing here indicate clients that will associate with any matching responder.

Hardening: Disable automatic connection to non-broadcast networks (netsh wlan set profileparameter name=CorpNet connectionMode=manual on Windows; remove PNL entries on macOS/iOS; NetworkManager auto_connect=FALSE on Linux). For enterprise: deploy 802.11u/Hotspot 2.0 with certificate-based network selection, eliminating SSID-based probing entirely.

Distance-Bounding, Relay, and NIC Firmware Considerations

Wi-Fi Time-of-Flight (ToF) and Fine Timing Measurement (FTM) protocols, specified in 802.11mc/az, enable ranging for indoor positioning. Relay attacks against these protocols are conceptually simple: a man-in-the-middle extends the RF path without adding detectable delay, making a distant attacker appear local. Distance-bounding protocols should prevent this by requiring rapid challenge-response exchanges where speed-of-light delays bound the maximum distance.

The protocol-specified countermeasure is cryptographically sound, but NIC firmware implementations rarely achieve the nanosecond-precision timing required. Firmware bugs in Qualcomm, Broadcom, and Intel chipsets have permitted relay extension beyond theoretical maximums by manipulating FTM request timestamps in driver-controlled fields before hardware processing.

Firmware and driver-level vulnerabilities extend beyond ranging. Fragment reassembly bugs in specific A-MPDU implementations (patched in Linux mac80211 over multiple cycles) allowed memory corruption because the hardware DMA descriptor ring and software SKB queue desynchronized. These are not protocol vulnerabilities but implementation vulnerabilities in the protocol path—unpatchable by standards revision, only by vendor action.

Verification checklist for firmware posture:

Check	Method	Failure indicator
FTM timestamp monotonicity	`iw phy0 measurement ftm_request` with local responder, compare reported ToF against physical distance	Reported distance varies >20% with fixed geometry
Fragment reassembly under load	`fragattacks` `test-reassembly-stress` with 1000+ fragment injections per second	Kernel oops or NIC reset in `dmesg`
Driver version against CVE database	`ethtool -i wlan0` or `modinfo mac80211`, cross-reference with Linux wireless mailing list	Driver predates known fix commit without backport notation
SAE timing variance	Statistical test above, or `hostapd` build with `-DWPA_TRACE` for internal timing logs	Standard deviation >10% of mean response time

⚠️ Authorized, defensive use only. FTM manipulation and fragment stress testing can crash target devices or corrupt their wireless state. Execute only in isolated lab environments with serial console recovery access, or in explicitly authorized detection-validation exercises with documented scope.

The practical insight: protocol certification and CVE patching operate on different clocks. A device may be "WPA3 certified" and "KRACK patched" while remaining vulnerable to fragment reassembly crashes in firmware never audited by the certification program. The only reliable validation is direct testing of your specific hardware revision with maintained tools—trusting labels is a complacency that adversaries do not share.