Arise from the Wireless: Breaking the Security Barrier in Wi-Fi

Arise from the Wireless: Breaking the Security Barrier in Wi-Fi

Speakers: Wei-Che Kao, Security Researcher, DEVCORE

Conference: Hexacon

YouTube: https://www.youtube.com/watch?v=qT3YFtGjiUq

Overview

In this comprehensive security study presented at Hexacon, Wei-Che Kao, a security researcher from DEVCORE, delved into the often-overlooked security landscape of MediaTek Wi-Fi chips. The talk, titled "Arise from the Wireless: Breaking the Security Barrier in Wi-Fi," provided an in-depth exploration ranging from the intricate process of reverse engineering Wi-Fi Microcontroller Unit (MCU) firmware to uncovering critical vulnerabilities within the Wi-Fi kernel module. Kao culminated the presentation by demonstrating a sophisticated exploit that achieved remote code execution (RCE) on a Wi-Fi router by leveraging a specific heap buffer overflow vulnerability.

The significance of this research cannot be overstated, given MediaTek's pervasive presence across a vast array of consumer and industrial devices. Its Wi-Fi chips are integral components in popular products such as Sonos speakers, Amazon Echo devices, and Starlink Wi-Fi routers, alongside numerous other widely used devices. Despite this widespread adoption, detailed security studies on MediaTek's Wi-Fi implementations have historically been scarce, with most research tending to concentrate on chips from competitors like Qualcomm and Broadcom. This talk aimed to bridge that knowledge gap, focusing specifically on remote attack surfaces to highlight the critical security implications for millions of deployed devices.

Kao's work not only exposed multiple zero-day vulnerabilities but also shed light on the challenges of reverse engineering custom embedded architectures and the complexities of the vendor-patching ecosystem. By meticulously dissecting MediaTek's Wi-Fi 6 and Wi-Fi 7 chipsets, the research revealed that the majority of the Wi-Fi protocol stack's security-sensitive logic resides within the Linux kernel module, rather than the MCU, a design choice that significantly expands the remote attack surface. The findings underscore the urgent need for enhanced protection mechanisms and more consistent security update practices across the device manufacturing supply chain.

Background

▶ Watch: Introduction to MediaTek Wi-Fi security research (0:00)

MediaTek's footprint in the wireless communication market is substantial, with its Wi-Fi chips powering an extensive range of devices, from smart home gadgets to enterprise networking equipment. Despite this ubiquity, the security of MediaTek's Wi-Fi implementations has received comparatively little attention from the broader security research community. Prior to this research, only a handful of studies touched upon MediaTek Wi-Fi chip security, and most of these offered limited architectural detail or focused on specific product lines rather than the underlying chipset vulnerabilities. Notable mentions include "Bad masher," which discussed issues related to easy mesh, and "Listen Up," which primarily focused on Sonos devices. A more recent study, "Unlock hidden superpowers in MediaTek Wi-Fi chips," presented in September 2023, offered some initial insights into reverse engineering and architecture, but comprehensive security analyses remained largely unexplored. This research by DEVCORE aimed to fill this void, specifically targeting remote attack surfaces.

The talk began by outlining the standard Wi-Fi stack, which comprises several layers: the Physical (PHY) layer responsible for converting bits into signals, the Media Access Control (MAC) layer for controlling physical layer access and frame encapsulation/decapsulation, the MAC Layer Management (MLM) module for handling management frames and state machine logic, and the Logical Link Control (LLC) layer for forwarding data frames to upper layers (e.g., IPv4, IPv6). Authentication and key exchange are handled by subsequent mechanisms like 802.1X and EAP.

MediaTek's Wi-Fi 6 router architecture, exemplified by the MT7981 Wi-Fi System-on-Chip (SOC) and the MT7976 Radio Frequency (RF) chip, was detailed. The MT7981 SOC integrates an Application Processor (AP) and three Wi-Fi MCUs. The research primarily focused on the AP and the Wireless MAC CPU (WMCPU). The WMCPU is crucial for managing the MAC and physical layers, receiving Wi-Fi frames from the RF chip. The AP, running a Linux kernel, hosts the MT_WiFi.ko kernel module. This kernel module is the central orchestrator, interacting with the WMCPU firmware to process received Wi-Fi frames and issue commands for MAC and physical layer management. This architectural division, where significant frame processing occurs in the kernel module, is characteristic of a SoftMAC implementation, which contrasts with FullMAC architectures where most Wi-Fi protocol logic resides on the MCU. This SoftMAC approach, as the research later highlighted, significantly expands the remote attack surface within the Linux kernel module.

Key Findings

▶ Watch: WMCPU firmware loading and memory mapping (4:00)

The research uncovered several significant findings across MediaTek's Wi-Fi 6 and Wi-Fi 7 platforms, from fundamental architectural insights to critical zero-day vulnerabilities.

1. Discovery of WMCPU Architectures: The WMCPU in Wi-Fi 6 (MT7981) was identified to use the MDS32 architecture, a less common instruction set. For Wi-Fi 7 (MT7991), the WMCPU was found to use RISC-V, specifically a customized variant by Andes Technology, which included custom instructions and the CodAns extension for firmware compression.
2. Advanced Reverse Engineering Techniques: Faced with encrypted firmware and custom instruction sets, the researchers successfully employed novel techniques, such as using core dumps obtained via MediaTek debug commands, to extract plaintext firmware and runtime state, enabling full disassembly and decompilation in Ghidra. They also developed custom Sleigh language definitions to properly interpret Andes RISC-V custom instructions.
3. SoftMAC Architecture Confirmation: The study confirmed that MediaTek's Wi-Fi implementation largely follows a SoftMAC architecture, where most of the Wi-Fi protocol stack, including critical frame parsing and handling logic, resides within the Linux kernel module (MT_WiFi.ko) rather than being fully offloaded to the Wi-Fi MCU. This design choice proved to be a significant factor in the severity of discovered vulnerabilities.
4. Multiple Zero-Day Vulnerabilities: The research identified several critical vulnerabilities in the MediaTek Wi-Fi kernel module, affecting various Wi-Fi protocol versions and chipsets:

• Unauthenticated Data Frame Injection (Missing Authentication Check): A design flaw allowing unauthenticated attackers to inject arbitrary plaintext data frames into the AP's network by bypassing authentication checks in an accelerated data path. This effectively opened the network to port scanning and direct attacks without a Wi-Fi password. (Discussed in the "Forgotten Frame Injection" chapter, type of vulnerability previously seen in 2021 Fred attacks).
• Action Frame Category Field Missing Range Check (CVE-XXXX-XXXX): An issue in action frame processing where, if the order bit in the MAC header is set, a missing range check on the category field allows an attacker to access internal kernel module state machines. This can cause a remote kernel Denial of Service (DoS) and potentially lead to remote code execution, though difficult.
• FT Action Frame Heap Buffer Overflow (CVE-XXXX-XXXX): A heap buffer overflow in the processing of Fast BSS Transition (FT) confirm action frames. Insufficient size validation during copying of Information Elements (IEs) into a fixed-size buffer could lead to a remote kernel DoS. The overflow could be up to 761 bytes.
• Wi-Fi 7 MLE Fragmentation Heap Buffer Overflow (CVE-XXXX-XXXX): Specific to Wi-Fi 7's Multi-Link Operation (MLO), this vulnerability involves a heap buffer overflow during the defragmentation of Per-Station Profiles within the MLE Information Element. A fixed-size buffer of 576 bytes was vulnerable to overflow if a fragmented profile exceeded this limit, leading to remote kernel DoS.
• Beacon/Probe Response IE Parsing Heap Buffer Overflow with RCE (CVE-XXXX-XXXX): This critical vulnerability occurs in the parsing of Information Elements within Wi-Fi beacon and probe response frames. A specific logic flaw copies a WSC IE (type 221) into a 512-byte buffer, which is then copied into a larger 1024-byte buffer (ibuff) without boundary checks. This leads to a heap buffer overflow that can be exploited for remote code execution. This was the vulnerability chosen for the live demonstration.

1. Pervasive Impact: The discovered vulnerabilities affect a wide range of devices utilizing MediaTek's Wi-Fi SDK, extending beyond the specific chips studied (MT7981, MT7991).
2. Exploitation of Kernel Heap Overflows: The research demonstrated a practical one-shot arbitrary address write primitive leveraging a heap buffer overflow, which was then used to hijack a function pointer in the kernel module and achieve RCE, highlighting the severe consequences of these flaws, especially in systems with minimal kernel protections.

Technical Deep Dive

▶ Watch: Discovering WMCPU uses MDS32 architecture with Ghidra (6:00)

The technical deep dive commenced with the arduous process of reverse engineering MediaTek's Wi-Fi MCU firmware. For the Wi-Fi 6 (MT7981) platform, the process began by understanding how the firmware is loaded. The Wi-Fi kernel module first parses and loads a ROM patch based on its header, which specifies load address and size (e.g., region zero at 0x90000 with size 0x2580). Subsequently, the RAM firmware header is parsed (located at the end of the file), and its 11 regions are loaded into WMCPU memory, with region zero's load address also serving as the firmware's entry point.

A critical step was identifying the Instruction Set Architecture (ISA) of the WMCPU. Initial string analysis of the firmware revealed paths containing "MDS32," strongly suggesting the use of the MDS32 architecture. This was validated by using a Ghidra processor patch for MDS32, loading the firmware, setting the base address, and observing coherent disassembly. A significant hurdle in Ghidra was the unresolvable Global Pointer (GP) register, which prevented correct interpretation of global data accesses. To overcome this, the researchers leveraged MediaTek's debug commands to obtain a core dump of the WMCPU's runtime state. Loading this core dump into Ghidra finally revealed the GP register's value, enabling complete and human-readable decompilation. This allowed for vulnerability hunting, leading to the discovery of an N-day stack overflow vulnerability due to the absence of stack canaries, Data Execution Prevention (DEP), and fixed memory mapping, a flaw that had been patched in October 2022 but persisted in older firmware versions on newer devices. This highlighted a critical issue: device vendors sometimes lag in adopting chipset vendor patches, leading to prolonged vulnerability windows.

The research then moved to Wi-Fi 7 (MT7991), which presented new challenges. The RAM firmware for Wi-Fi 7 indicated that all regions were encrypted. Without a clear decryption algorithm in the kernel module or Wi-Fi 6 firmware, hardware-level decryption was suspected. Again, core dumps proved invaluable, providing access to the plaintext firmware. String analysis of this core dump revealed source code paths indicating the WMCPU used RISC-V. However, initial Ghidra analysis of the RISC-V firmware was "a disaster," with many custom instructions undecipherable. Recognizing that the Wi-Fi 6 MCU was from Andes Technology, the researchers investigated Andes's RISC-V ISA specification. They then converted approximately 24 custom Andes instructions into Sleigh language for Ghidra, significantly improving disassembly and decompilation. Further, they encountered RISC-V compressed instructions and identified the CodAns extension, specifically the exec.it instruction, which fetches and executes instructions from a table to reduce firmware size. An undocumented CodAns instruction remained, whose behavior was inferred by comparing functionality between Wi-Fi 6 and Wi-Fi 7 firmware. Despite these efforts, no zero-day vulnerabilities were found in the MCU firmware for either Wi-Fi 6 or 7, leading to the conclusion that MediaTek's architecture leans towards SoftMAC, with most critical logic in the kernel module.

This led to the focus on the MediaTek Wi-Fi kernel module (MT_WiFi.ko), which presented a much larger remote attack surface. The first major finding was a Forgotten Frame Injection vulnerability (unauthenticated data frame injection). Wi-Fi networks typically require authentication (e.g., WPA2) to send data frames, allowing only management frames (like authentication/association requests) from unauthenticated users. The vulnerability stemmed from an accelerated data path where the MCU converts a received Wi-Fi frame into an Ethernet frame before forwarding it to the kernel module. Crucially, the kernel module's processing of this Ethernet frame lacked an authentication check. This meant an unauthenticated attacker could inject arbitrary plaintext data frames into the AP's network, enabling port scanning and direct attacks on connected devices without knowing the Wi-Fi password. This type of vulnerability, previously discussed in "Fred attacks" (2021), showed a concerning persistence.

The "One Frame to Break Them All" chapter detailed several kernel-level vulnerabilities:

1. Action Frame Category Field Missing Range Check: This vulnerability affects action frames. When the order bit in the MAC header is set, a missing range check on the category field (which determines the internal state machine to execute) allows an attacker to direct the frame to internal state machines not intended for external access. This causes internal kernel structures to be treated as pointers. While the duration field is fully controllable, the frame control field is only partially controllable, making arbitrary code execution difficult but enabling a remote kernel DoS.
2. FT Action Frame Heap Buffer Overflow: During Fast BSS Transition (FT), FT Confirm Action Frames are used for key exchange. The kernel module validates specific Information Elements (IEs) within these frames. The vulnerability occurs because the copy_ie_to_fixed_buffer function copies IEs into a fixed-size buffer without proper length validation. An IE exceeding 761 bytes could cause a heap buffer overflow, leading to a remote kernel DoS.
3. Wi-Fi 7 MLE Fragmentation Heap Buffer Overflow: In Wi-Fi 7's Multi-Link Operation (MLO), the Multi-Link Element (MLE) and its sub-element, the Per-Station Profile, can be fragmented. While MLE defragmentation includes checks, the defragmentation of the Per-Station Profile copies data into a fixed-size buffer (576 bytes) without size validation. An attacker could craft an oversized fragmented Per-Station Profile to trigger a heap buffer overflow, resulting in a remote kernel DoS.
4. Beacon/Probe Response IE Parsing Heap Buffer Overflow (RCE): This critical flaw affects the parsing of IEs in beacon and probe response frames. A pseudo-code analysis revealed a loop that checks if IEs fit into ibuff (1024 bytes). IEs of type 244 are copied directly into ibuff. Crucially, WSC IEs (type 221) are copied into a WSC buffer (512 bytes). After the loop, the content of WSC buffer is copied into ibuff without any boundary checks. This allows an attacker to craft a malicious beacon or probe response that overflows ibuff from the WSC buffer, leading to a heap buffer overflow. This vulnerability was identified as capable of causing remote kernel DoS and, in the worst case, remote code execution, affecting any device using the MediaTek Wi-Fi SDK.

Demo / Proof of Concept

▶ Watch: Discovery of a stack overflow vulnerability (9:00)

The demonstration focused on exploiting the Beacon/Probe Response IE parsing heap buffer overflow (the last vulnerability discussed in the technical deep dive) to achieve remote code execution. The specific device model used for the demonstration was not disclosed due to MediaTek's bug bounty program policies. The overflow allowed overwriting up to 58 bytes on the kernel heap.

A key challenge for exploitation was the lack of standard kernel protection mechanisms commonly found in enterprise-grade systems. Many IoT devices, including the target, often operate with no stack canary, no Data Execution Prevention (DEP), and crucial for some devices, Kernel Address Space Layout Randomization (KASLR) disabled. This significantly simplifies exploitation. Debugging was also difficult, as attaching a debugger like GDB to the kernel was not possible; researchers relied solely on crash logs and stack traces for analysis.

The exploitation strategy involved a one-shot arbitrary address write primitive achieved through heap manipulation:

1. Free List Hijacking (First Beacon): An attacker first broadcasts a malicious beacon frame crafted to hijack the kernel's heap free list. This manipulates the free list to point to a controlled address (Address A).
2. Payload Delivery (Second Beacon): Subsequently, another kernel allocation (triggered by a second beacon or other network activity) would acquire Address A from the hijacked free list. The attacker's malicious payload, embedded in the second beacon, would then be written to this controlled location. If Address A was an invalid or critical memory region, it would lead to a crash with a specific stack trace that the researchers had identified.

To achieve RCE, the arbitrary write primitive was used to modify a function pointer within the Wi-Fi kernel module. The controlled execution flow then utilized three carefully selected gadgets after a stack pivot. These gadgets were responsible for making the attacker's shellcode executable and then finally jumping to the shellcode.

The exploit was not perfectly reliable due to partial kernel module load address randomization and non-deterministic heap allocation order. It could take "several hours" to succeed, often resulting in device crashes before successful RCE. However, after a crash, the device would reboot, allowing the attacker to retry. The speaker humorously suggested that an attacker could launch such an attack at night when users are less likely to notice, providing ample time for the exploit to complete. The demo showed that after roughly two hours of attempts, the exploit successfully executed the attacker's shellcode, which printed a message from the kernel, confirming remote code execution.

Defensive Implications

▶ Watch: The 'N-day' revelation: vulnerability already patched (10:00)

The research provides crucial insights for various stakeholders in the Wi-Fi ecosystem to enhance security:

• For Device Vendors:
• Enable Robust Protection Mechanisms: It is imperative to enable modern kernel protection mechanisms such as Stack Canaries, Data Execution Prevention (DEP), and Kernel Address Space Layout Randomization (KASLR). The absence of these protections, particularly in IoT devices, significantly lowers the bar for exploitation.
• Consistent Security Updates: Device vendors must establish a rigorous process to continuously track and integrate security updates from their chipset vendors (like MediaTek) into their product firmware. The discovery of N-day vulnerabilities on "latest" device firmware highlights a severe disconnect in the update supply chain.
• Secure Coding Practices: Implement thorough input validation, boundary checks, and robust error handling in all firmware and kernel module code, especially when processing external input like Wi-Fi frames and Information Elements.

• For Chipset Vendors (MediaTek):
• Improve Collaboration with Researchers: Chipset vendors should actively engage with security researchers. Providing researchers with the latest testing builds and SDKs under Non-Disclosure Agreements (NDAs) can significantly accelerate vulnerability discovery and validation, leading to more robust patches before public release.
• Transparent Vulnerability Handling: Continue to follow clear processes for vulnerability handling and communicate fixes through security bulletins, as MediaTek has done for the issues presented in this talk.
• Security-First Design: Prioritize security in architectural design, particularly in SoftMAC implementations where critical protocol logic resides in the kernel module, which is a prime target for remote attacks.

• For Security Researchers:
• Focus on Under-Researched Areas: There remains a vast, under-explored attack surface in Wi-Fi kernel modules and vendor-specific Wi-Fi protocols. MediaTek's ubiquitous presence and historical lack of deep scrutiny make it a fertile ground for further research.
• Leverage Available Resources: The availability of Wi-Fi SDKs on platforms like GitHub can significantly speed up the reverse engineering process by providing insights into the codebase and protocol implementations.
• Advanced RE Techniques: Continue to develop and apply sophisticated reverse engineering techniques for embedded systems, such as core dump analysis for encrypted firmware and custom ISA definition languages (like Sleigh), to overcome common obfuscation and protection mechanisms.

• For End Users:
• Strong Passwords: Always use strong, unique passwords for Wi-Fi networks to mitigate basic unauthorized access.
• Limit Signal Leakage: Take measures to limit Wi-Fi signal leakage beyond the intended coverage area, making it harder for remote attackers to initiate attacks from outside the premises.
• Update Device Firmware: Regularly check for and apply firmware updates for Wi-Fi routers and other connected devices. While vendor patching can be inconsistent, applying available updates is still the best defense against known vulnerabilities.

In conclusion, all issues presented in the talk have been fixed by MediaTek, with details available in their security bulletins. However, the broader implications regarding architectural design, patching inconsistencies, and the need for enhanced kernel protections remain critical for the security of the entire Wi-Fi ecosystem.

Key Takeaways

• MediaTek Wi-Fi chips, widely deployed in devices from smart speakers to routers, represent a significant and historically under-researched remote attack surface.
• Advanced reverse engineering techniques, including core dump analysis for encrypted firmware and custom Ghidra Sleigh definitions for unique ISAs like Andes RISC-V with CodAns, are essential for dissecting deeply embedded Wi-Fi systems.
• MediaTek's SoftMAC architecture design, which places extensive Wi-Fi protocol logic in the Linux kernel module, significantly expands the attack surface for kernel-level vulnerabilities.
• Multiple critical zero-day vulnerabilities were discovered in the MediaTek Wi-Fi kernel module, including an unauthenticated data frame injection flaw and several heap buffer overflows leading to remote kernel DoS and demonstrated remote code execution.
• The absence of standard kernel protection mechanisms (e.g., KASLR, stack canary, DEP) in many IoT devices makes the exploitation of these vulnerabilities significantly easier and more impactful.
• Inconsistent firmware update practices by device vendors can result in "N-day" vulnerabilities persisting on devices even after chipset vendors have released patches, creating prolonged exposure windows for users.

About the Speaker(s)

Wei-Che Kao, also known as Wika or Shiaai, is a Security Researcher at DEVCORE. His research focuses on uncovering vulnerabilities in complex embedded systems, particularly within the realm of Wi-Fi chipsets and related kernel modules. His work on MediaTek Wi-Fi security at Hexacon highlights his expertise in reverse engineering diverse architectures, analyzing kernel-level flaws, and developing practical exploitation techniques for remote code execution.