pwning asus driverhub, msi center, acer control centre and razer synapse 4

At the beginning of this year I spent a week finding several vulnerabilities in various “bloatware” software. This was after I got suspicious of how my ASUS motherboard’s “DriverHub” behaved. In the end I looked at 6 targets from 6 random vendors (apart from ASUS) and found vulnerabilities ranging from Remote Code Execution to Local Privilege Escalation in all of them. Those were: ASUS, Acer, Lenovo, HP, MSI and Razer.

At the beginning of this year I spent a week finding several vulnerabilities in various “bloatware” software. This was after I got suspicious of how my ASUS motherboard’s “DriverHub” behaved. In the end I looked at 6 targets from 6 random vendors (apart from ASUS) and found vulnerabilities ranging from Remote Code Execution to Local Privilege Escalation in all of them. Those were: ASUS, Acer, Lenovo, HP, MSI and Razer.

All of the PoC’s mentioned in this post can be found here https://github.com/sensepost/bloatware-pwn. This blog post contains significantly more detail, but if you want to watch me live you can either watch the DEF CON 33 talk https://www.youtube.com/watch?v=zSBf2CMKlBk, or the RomHack ’25 talk https://www.youtube.com/watch?v=_39UbCePFfw. I also did a live stream that takes you through some of the detailed thinking / process that went into finding the ASUS DriverHub vulnerability on the Off By One Security YouTube channel here https://www.youtube.com/watch?v=sASmrVDMF_A.

In total I found 7 vulnerabilities, netting 6 CVE’s in the end. The tl;dr on the vulnerabilities I found is:

• Razer: Local Privilege Escalation via razer_elevation_service.exe (CVE-2025-27811)

• Acer: Local Privilege Escalation via unprotected Windows Named Pipe (CVE-2025-5491)

• Acer: Remote Code Execution (privileged) via a Misconfigured Windows Named Pipe (bundled with previous CVE)

• MSI: Time-of-create time-of-use (TOCTOU) vulnerability Leading to Privilege Escalation (CVE-2025-27812)

• MSI: Lack of PE Signature Validation leading to Privilege Escalation (CVE-2025-27813)

• ASUS: Insufficient Origin Header Validation (CVE-2025-3462)

• ASUS: Insufficient PE Signature Validation (leading to RCE when coupled with CVE-2025-3462) (CVE-2025-3463)

In this post I’ll detail how I found these vulnerabilities, how they worked along with POCs for all of them.

Asus DriverHub 1-click RCE

It’s summer holiday time, I’ve just wrapped up a gaming session, when I casually react to a popup from Asus DriverHub telling me there is an update.

Alright, I click the thing, a browser opens up. Weird? But ok. Is there some cloud thing at play here? Admittedly I am already sus’ about what’s going on. The browser is definitely not installing things directly so it must have help somehow, right? This is driverhub.asus.com after all… Eventually the installation of my update is complete, and I’m asked to restart my computer. This is a browser modal, asking to reboot.

I click “Restart Now” and immediately Windows restarts.

Hold. The. Phone. How!?

With the computer rebooted, I opened the DriverHub thing again, popped open the inspector and immediately it became clear to me what was happening. Something on my computer exposed a web server on localhost that driverhub.asus.com was talking to, invoking instructions via JavaScript. And so far, two of those instructions (at least) were to install something, and reboot my computer.

That was much more power than I had imagined a browser-based app should have over my computer. What other endpoints exist? Can anyone talk to them? What can ASUS effectively do remotely on my computer? Who else can perform these actions (spoiler alert, until it was fixed, anyone).

These were all questions I had, and truthfully I kind of knew I wasn’t going to like the answer to any of them.

Asus DriverHub: Reconnaissance

ASUS DriverHub is, like the name implies, a utility for ASUS motherboards to easily search for and download relevant drivers for your hardware. While whatever Windows Update will get you from a drivers perspective is usually good enough, having the latest drivers often result in the best performance – a trait gamers and/or performance sensitive users will always love.

I first wanted to know which process was exposing port 53000, and found it using Process Explorer. ADU.exe seemed to be the culprit. It looked like a native binary which was also responsible for spawning a child process which appeared to be the tray icon application. Everything was running as my logged in user.

Ideally I wanted to test stuff in a VM so that I could revert snapshots and what not, so I decided to download ASUS DriverHub from their website and install it in my VM. Fun fact, if the JavaScript on https://driverhub.asus.com/en can’t connect to localhost on port 53000, it will show the download page. :) I ran the downloaded file and was met with a “no can do” message like this.

Looks like ASUS DriverHub was checking if I actually have hardware that they support first. Nice. To investigate how, I chose Binary Ninja, and opened the installer using it.

Right off the bat in the main function I noticed what looked like a logging related configuration function, with a line a little bit lower that seemed to be logging output. This will be a recurring theme in this post, but logging information is insanely useful when reversing for various reasons. First, just knowing the high-level logic flow of your target, but secondly using the log line string references in a binary is a quick way to find the relevant sections of code you may want to inspect.

Anyways, searching my VM for AsusDriverHub\Log paths, I found C:\ProgramData\ASUS\AsusDriverHub\Log that lo-and-behold, had a ASUS-DriverHub-Installer.log. In it was my first hint about why it would not want to install on my Parallels VM.

Neat, contextualised log lines like this made the next part really, really easy to deal with. Taking a close look you’ll see lines stating that my VM is not a supported motherboard (duh) and not an ASUS product (duh). So, with the binary open in Binary Ninja, I searched for the string “Not support” (1), then clicked the string in the linear view (2), and finally followed a cross reference to find the relevant code section (3) that uses that string reference.

In the function that references the string were interested in, we can see a call to sub_14000f9d0() (which if you check, you’ll see what looks like a whole bunch of system enumeration code to check motherboard, BIOS and OS information), that returns a value. That value is checked to determine if the current system is supported.

To get past this is simple. Patch the installer so that this check is either not made, or inverted. The choice is yours. To do that, right click the check before the goto statement -> patch -> never branch.

This should remove the jump that stops the installer. With that done, save your new patched binary by going File -> Save As -> Save File Contents Only and choosing a new file name for your patched binary. Run it again, and this time you should be able to install ASUS DriverHub on a non ASUS computer. We’re ready to start playing with the software \o/.

With the software now installed in my VM, I double checked that the program behaved in a similar way to what I’ve seen before. For the most part it did, however, it complained that it did not support my hardware in the web interface this time. Of course, my VM is not an ASUS product after all.

[...]

Original source