Full Report
Have you ever wanted to participate in Pwn2Own!? The author of this post took the jump into competing at this hacking event. They were part of a team with 2 other players trying in the routers, printers and phones event. They picked a consumer NETGEAR router since they thought it was the path of least resistance. First, they started by opening up the box and getting a shell on the target. This was done by soldering some pins onto the device and interacting with a UART console. Luckily for them, it outputs a root shell with no further troubles. Next, they started looking for juicy attack surfaces. In particular, they wanted to look into something that had never been popped before; this was to ensure their wouldn't be duplicates. Initially, they looked into uhttpd, which was able to invoke and run Lua extensions. The router had scrambled the opcodes, causing decompilation issues. While looking at the netstat output, two open sockets on 0.0.0.0 were not associated with any process. It turned out that this was a network USB stack that was running in the kernel. Although this had been popped in the past, they found an integer overflow vulnerability they could be made into a smaller write than the size of the overflow! A user controlled value, without bounds checks, was passed into a call to malloc with additional values being added and multiplied. Pretty neat! The exploit code to trigger this is less than a hundred lines of Python code. The buddy alloactor is used for allocating this chunk. This means that it's allocated in groups of 2**N pages, limiting the allocation sizes that can be used for the exploit. The kernel driver was missing ASLR, NX and sent addresses (for debugging) over the network on a different port. Although they had a bug, they wanted to emulate NetUSB using QEMU to develop their exploit. After spending hours compiling and using other kernel, they learned about some compilation flags that must have been set on the build of this driver that weren't set on their builds. Eventually, they got everything to build! They looked at the Linux source code and played around with different objects. Eventually, they learned that a small pause after the allocation of the buffer but before overflowing it, an interesting structure would be magically allocated fairly close to the buffer. Inside the wait_queue_entry object is a function pointer, which they choose to overwrite. Getting code execution was as simple as overwriting the function pointer and jumping to existing code. Since ASLR and others things were turned off, they could even hardcode addresses! Porting this to the real router was pretty easy and had a success rate of about 3 out of 5 times. Entering the contest was rough though... Netgear put a patch out the day before the event and they were unable to get their exploit to drop live. Overall, an awesome post on an end-to-end Pwn2Own experience with a good amount of diversity on the content.
Analysis Summary
# Vulnerability: NetUSB Kernel Integer Overflow Remote Code Execution
## CVE Details
- **CVE ID:** CVE-2021-45608
- **CVSS Score:** 9.8 (Critical)
- **CWE:** CWE-190 (Integer Overflow or Wraparound)
## Affected Systems
- **Products:** Various consumer routers (specifically NETGEAR and TP-Link models).
- **Versions:** Multiple models utilizing the NetUSB (KCodes) kernel module.
- **Configurations:** Devices with the "ReadyShare" or USB network sharing feature enabled, typically listening on 0.0.0.0 (all interfaces).
## Vulnerability Description
The flaw exists within the NetUSB kernel driver, which handles USB-over-IP functionality. A user-controlled value is received from the network and passed into a `malloc` (kmalloc) call without sufficient bounds checking. Before the allocation, additional values are added and multiplied to the user input. An attacker can provide a specific value that triggers an integer overflow, resulting in a memory allocation significantly smaller than the size of the data subsequently written into it. This leads to a kernel heap buffer overflow.
## Exploitation
- **Status:** PoC available (developed for Pwn2Own 2021). Noted as patched by the vendor just prior to the competition.
- **Complexity:** Medium to High (requires heap grooming/feng shui in the Linux kernel buddy allocator).
- **Attack Vector:** Network (Remote).
## Impact
- **Confidentiality:** High (Full kernel-level access)
- **Integrity:** High (Ability to modify kernel memory and execute arbitrary code)
- **Availability:** High (Potential for system crashes or complete takeover)
## Remediation
### Patches
- **NETGEAR:** High-priority firmware updates were released in late 2021 (e.g., just before Pwn2Own Austin). Users should update to the latest available firmware for their specific model.
- **TP-Link:** Released firmware updates for affected models using the NetUSB stack.
### Workarounds
- Disable USB sharing features (e.g., NETGEAR ReadyShare) in the router's web interface.
- Block access to the NetUSB port (typically TCP 20005) using firewall rules if the device supports it.
## Detection
- **Indicators of Compromise:** Unusual network traffic on port 20005. System instability or unexpected reboots.
- **Detection Methods:** Vulnerability scanners can identify the presence of the NetUSB service. The blog author noted that `netstat` shows open sockets on `0.0.0.0` not associated with a named process, as the service runs entirely within the kernel.
## References
- **Vendor Advisories:** [https://www.netgear.com/about/security/](https://www.netgear.com/about/security/)
- **Technical Analysis:** [https://doar-e.github.io/blog/2022/03/26/competing-in-pwn2own-2021-austin-icarus-at-the-zenith/](https://doar-e.github.io/blog/2022/03/26/competing-in-pwn2own-2021-austin-icarus-at-the-zenith/)
- **PoC Repository:** [https://github.com/0vercl0k/zenith](https://github.com/0vercl0k/zenith)
- **SentinelOne Labs Report:** [https://www.sentinelone.com/labs/cve-2021-45608-netusb-rce-flaw-in-millions-of-end-user-routers/](https://www.sentinelone.com/labs/cve-2021-45608-netusb-rce-flaw-in-millions-of-end-user-routers/)