CVE-2019-13142: Razer Surround 1.1.63.0 EoP

Version: Razer Surround 1.1.63.0
Operating System tested on: Windows 10 1803 (x64)
Vulnerability: Razer Surround Elevation of Privilege through Insecure folder/file permissions

Purpose
I hope that this post serves as a motivator for folks who see vulnerability research as an intimidating area to get started in. While this bug can be considered simple, the primary purpose of this post is to outline the methodology behind how to get started and what to look for. Additionally, I’d like it to serve as a reminder to not discount the low hanging fruit, no matter how large the organization.

Brief Description:
Razer Surround installs a service named “RzSurroundVADStreamingService” that runs as SYSTEM. This service runs “RzSurroundVADStreamingService.exe” out of “C:ProgramDataRazerSynapseDevicesRazer SurroundDriver”. The permissions on  RzSurroundVADStreamingService.exe and “C:ProgramDataRazerSynapseDevicesRazer SurroundDriver” allow for overwriting the service binary with a malicious one, resulting in elevation of privilege to SYSTEM.

Identification and Exploitation
When doing vulnerability research, picking a target to go after can be challenging. Hunting for bugs in large software platforms can be intimidating as there is an assumption that all vulnerabilities are complex and take a special skill set to identify. I’d like to use this vulnerability as an example as to why the act of hunting for vulnerabilities isn’t as hard as it sounds.

You may ask, why Razer? How do you identify a piece of software to begin hunting for vulnerabilities in? The answer is simple: Investigate what interests you. In this case, I own various Razer products. It is hard to ignore the urge to look when you use a product and the software associated with it every day.

When looking for vulnerabilities, there is often a common workflow that I follow once the software of interest is installed. This stage involves analyzing the potential attack surface that the target software has exposed. I typically start with the basics and then resort to dynamic/static analysis if needed. The things I typically look for initially are:

1. Installed services (both the service permissions and the service executable/path permission)
2. Named pipes (and their ACLs)
3. Log file permissions in folders like C:ProgramData
4. Network sockets
5. DCOM servers and hosted interfaces

As far as tooling goes, I mostly stick to Process Monitor and James Forshaw’s NTObjectManager project.

In the instance of Razer Surround, I began by checking what privileged processes the software uses by looking at the process list. This revealed that “RzSurroundVADStreamingService.exe” was running as “NT AUTHORITYSYSTEM”. The next step was to figure out how that process was being started. Given the name of the process has “service” in it, that is a good starting point. To verify, it was easy enough to do “Get-Service *Rz*” in Powershell, which returned all of the services with “Rz” in the name. This led me to the “RzSurroundVadStreamingService” system service with the ImagePath set to the executable of interest. After dumping the ImagePath, the location of the service executable stood out as it was running out of “C:ProgramDataRazerSynapseDevicesRazer SurroundDriver”

Why is this interesting? By default, “BUILTINUsers” have “GenericWrite” access to C:ProgramData:

A very common error that software developers make is not properly locking down the permissions of any created subfolders in C:ProgramData. If an installer simply creates a folder in C:ProgramData, that folder and any subfolders will have inherited permissions of C:ProgramData, which include the “GenericWrite” access right for “BUILTINUsers”.

Improper file and folder permissions were the culprit in this case as “Everyone” was eventually granted “FullControl” over any files in “C:ProgramDataRazerSynapseDevicesRazer SurroundDriver”

As previously noted, this path is where the “RzSurroundVADStreamingService” ImagePath for the service executable was pointing to. Given a low privileged user has “FullControl” over the folder and included files, it is possible to just replace the service executable for the “RzSurroundVADStreamingService” system service:

Once the payload is copied, rebooting the host will cause the service to start the new executable as SYSTEM. In this instance, the new service executable will start cmd.exe as SYSTEM:

Razer fixed this vulnerability by moving “RzSurroundVADStreamingService.exe” and the associated dependencies to a secured location in “C:Program Files (x86)Razer”.

Disclosure Timeline
As committed as SpecterOps is to transparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publicization of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.

• March 20th, 2019 — Initial report sent to Razer
• March 21st, 2019  — Report acknowledgement received from Razer
• April 30th, 2019 —  30 days after initial report
• May 2nd, 2019  —  Razer provided a fixed build to test
• May 2nd, 2019 —  Fix was verified
• May 20th, 2019 —  60 days after initial report
• June 6th, 2019 —  Reached out to Razer for a timeframe regarding a public fix
• June 6th, 2019 —  Razer informed me a fix should be live, but verification from the development team was needed
• June 7th, 2019 —  Informed Razer that a fix wasn’t available on the site or via Surround’s update mechanism
• June 10th, 2019 —  Razer informed me that there had been some internal confusion and that a fix was going live the end of June
• June 11th, 2019 —  Informed Razer I would hold off on disclosure until the fix is live
• June 20th, 2019 —  90 days after initial report, extension granted
• July 1st, 2019 —  Razer informed me that a note is out to the development team regarding when the fix would be pushed live
• July 5th, 2019 —  Fix published

-Matt N.

Comments are closed.