CVE-2024-33218 - Elevating Privileges Using a Flaw in ASUS USB 3. Boost Storage Driver (AsUpIO64.sys) – An Explainer and Guide
In May 2024, researchers identified a serious vulnerability (CVE-2024-33218) in the ASUS USB 3. Boost Storage Driver (AsUpIO64.sys), version 5.30.20., published by ASUSTeK Computer Inc. This vulnerability is a classic “local privilege escalation” (LPE) issue, meaning a regular Windows user could run code as SYSTEM simply by sending a crafted IOCTL (Input/Output Control) request to the ASUS driver. Once exploited, attackers could take control of an affected machine. In this post, we break down what happened, how the vulnerability works, and how exploitation unfolds, using clear language and example code.
Background: About AsUpIO64.sys
ASUS’s USB 3. Boost package includes a driver named AsUpIO64.sys. This driver helps with speeding up file transfers between USB storage devices and ASUS PCs, but like many device drivers, it interacts closely with the Windows kernel and accepts special requests (“IOCTLs”) from software running in user mode.
The Bug: Insufficient Privilege Checks in IOCTL Handler
The main problem in CVE-2024-33218 lies in the way AsUpIO64.sys handles IOCTL requests. It exposes a device object accessible by regular users and fails to properly check whether the caller is authorized to use privileged operations. Specifically, attackers can send a malicious IOCTL request to the driver, which then performs some sensitive file or memory operations in the context of the SYSTEM account.
Step-by-step Breakdown
1. Accessing the device: By default, ASUS’s driver creates a device object (e.g., \\.\AsUpIO64) with permissions that allow any Windows user to open and send IOCTLs.
2. Sending Crafted IOCTL: The driver exposes one or more privileged IOCTL codes (the exact code may vary; often x222004 or similar) that allow untrusted input to control kernel operations.
3. Abusing the IOCTL: By sending specific data, attackers can gain kernel privileges – writing to arbitrary memory, manipulating the system, or running code as SYSTEM.
Quick Proof-of-Concept (POC) Code
WARNING: This code snippet is for educational purposes only! Do not run it on production systems.
#include <windows.h>
#include <stdio.h>
#define DEVICE_NAME "\\\\.\\AsUpIO64"
#define IOCTL_ASUS_BOOST x222004 // Example, may change in real driver
int main(void) {
HANDLE hDevice = CreateFileA(DEVICE_NAME, GENERIC_READ | GENERIC_WRITE,
, NULL, OPEN_EXISTING, , NULL);
if (hDevice == INVALID_HANDLE_VALUE) {
printf("[-] Could not open device\n");
return 1;
}
char inBuffer[x10] = {}; // Fill with exploit data as needed
DWORD bytesReturned;
if (!DeviceIoControl(hDevice, IOCTL_ASUS_BOOST,
inBuffer, sizeof(inBuffer),
NULL, ,
&bytesReturned, NULL)) {
printf("[-] DeviceIoControl failed: %d\n", GetLastError());
CloseHandle(hDevice);
return 1;
}
printf("[+] IOCTL sent, check for elevation!\n");
CloseHandle(hDevice);
return ;
}
Bypass endpoint security tools
All from a regular Windows user account if the ASUS driver is installed and loaded.
References
- NIST National Vulnerability Database – CVE-2024-33218
- ASUSTeK Computer Inc Support
- Original disclosure by security researchers (if available) *(replace with actual report if/when published)*
- Windows DeviceIoControl documentation (Microsoft)
If you use any ASUS software that relies on USB 3. Boost
1. Update: Check ASUS support for a driver update. If an update is not yet available, contact ASUS support directly.
2. Restrict device access: Temporarily remove or rename AsUpIO64.sys (may break USB 3. Boost features).
Conclusion
CVE-2024-33218 demonstrates how even trusted software from big names like ASUS can harbor critical bugs if device drivers don’t lock down what unprivileged users can do. Unchecked IOCTL calls are a common bug class in Windows drivers – attackers look for these to get instant SYSTEM access.
Recommendation: If you are running ASUS devices or the USB 3. Boost driver, patch as soon as updates are released!
*This post is an original breakdown based on public CVE info, driver analysis, and standard Windows driver exploitation techniques. Always report vulnerabilities to vendors and do not use information here for unauthorized activity.*
Timeline
Published on: 05/22/2024 15:15:28 UTC
Last modified on: 08/01/2024 13:51:46 UTC