Razer CoInstaller Privilege Escalation
I'm an opportunistic hacker, what this really means is that I just need decent motivation and an interesting problem and suddenly my weekend is gone in the blink of an eye and maybe I broke something along the way. It was saturday and I just sat down to play some video games for a few hours so I fired up my windows virtual machine, upon logging in I was greeted with a familiar annoyance. The Razer software installer.
I like to keep a relatively clean system so I usually avoid installing additional management software and the software for my mouse was no exception. One thing that makes this software particularly annoying is that it LOVES to automatically launch via the windows driver install process. This means that whenever windows decides that the same razer mouse, which has been plugged in for over two years, is somehow new it will automatically launch the razer software installer and bother me to install their bloat.
The very idea of it bothers me.
SO I decided to dig into the software to figure out what exactly it's doing and how I can potentially neuter it.
Enter: procmon
Okay, so my first thought is to fire up procmon and listen to the process activity whenever the CoInstaller process kicks off. After I got procmon running I went into the windows device manager and removed the USB controller driver then re-scanned for devices. This effectively cleared out the device history for said controller and caused windows to recognize the mouse as a new device.
Once I plugged in the Razer mouse I watched procmon fill up with events (tbh it was already filling up) and captured the process chain for the Razer software install, filtering in procmon for ProcessName contains 'Razer' did well to narrow down to a few binaries that are responsible for this annoyance.
Reviewing the execution chain revealed an interesting snag that the software was running into. During the CoInstaller process the RzS3WizardPkgS3.exe binary performs some file queries for a C:\Program Files (x86)\Razer\RzS3WizardS3\RazerSynapseInstaller_ProdDiscoveryEndpoint.exe executable. This is perfectly fine however procmon illuminated that the binary was not performing this file search with a quoted path, indicated by the multiple queries leading up the search order tree until the final file path is determined, in addition to the 'NAME NOT FOUND' result for a Program.exe.
These were a good enough indicator to me that a file path somewhere in the RzS3WizardPkgS3.exe binary was not properly quoted making this a potential search order hijack vulnerability. My next step was to verify my hypothesis with a simple calc-test. I copied calc.exe to the root of the C:\ drive and named it Program.exe, I then repeated the steps required for windows to re-learn my device. Once the CoInstaller process kicked off the RzS3WizardPkgS3.exe binary I checked the task manager and sure enough our calc.exe was running in the background and as SYSTEM to boot!
Nice.. So we've potentially got a privilege escalation available to us, lets make a quick exploit with msfvenom and see if we can pop a reverse shell.
Metasploit goodness
For this one I used the windows/meterpreter/reverse_tcp payload, configured the LHOST param for my attacker box and copied it over to my victim host using updog.
Since I'm not trying to evade EDR and AV tools I turned off Windows Defender so it would stop gobbling it up and let me test. I moved the payload to our C:\ drive as Program.exe, something to note is that with our default configuration windows requires administrator privileges to place this executable at the root of the C:\ drive, so unfortunately we're not going straight from USER permissions to SYSTEM but Administrator to SYSTEM is still fun and useful.
Once the payload was in place I fired up msfconsole and used the multi/handler exploit and configured it for my payload settings then hit run.
Again we followed the earlier steps to mind-wipe our USB controller and reinitialize the new device process chain, within a few moments of plugging in the mouse we can see the msfconsole light up with our new reverse shell connection! Just for good measure we'll run whoami to check if we're actually running as SYSTEM
Final thoughts
Well, I kinda forgot why I was doing this in the first place, oh yeah! To disable this software from starting up... Well, I guess I can just delete the RzS3WizardPkgS3.exe file and that should do the trick. Anyway, I was honestly surprised how simple this one was, goes to show that not every vulnerability takes a ton of work and research I guess! Also a big shoutout to the teams at Razer for their prompt handling of this vulnerability in their software.
Resources
MSFConsole reverse shell
Path interception by Search Order Hijack
Disclosure timeline
2022-05-21. Vulnerability was submitted through Razer's partner bug bounty platform
2022-06-13. Razer states that the bug has been validated and the severity is being assessed
2022-06-16. Razer assesses the bug as medium severity and a bug bounty reward was paid