Exploiting SteelSeries' Subapplication Mechanism for Privilege Escalation
Executive summary
Akamai security researcher Tomer Peled recently discovered two vulnerabilities in SteelSeries’ application.
SteelSeries is a hardware company that manufactures computer peripherals and has more than 9 million customers worldwide.
The vulnerabilities were assigned the CVE numbers CVE-2023-31461 and CVE-2023-31462. SteelSeries acted expeditiously to patch these vulnerabilities in May 2023.
These vulnerabilities allow an attacker to execute code with higher privileges than initially obtained, and possibly with ADMIN privileges. To exploit these vulnerabilities, the attacker needs to send two local packets to a listening IPC server. The server will then execute the attacker’s payload with elevated privileges.
The root cause of these vulnerabilities lies in insecure permission handling in the service’s IPC listener and in a lack of protection against path traversal.
The Akamai Security Intelligence Group (SIG) responsibly disclosed the vulnerabilities to the SteelSeries support and engineering teams and submitted them to MITRE for the assigned CVEs.
The SIG found the vulnerable service in several data centers we monitor and informed customers of the risk and how to mitigate it.
- We provide a proof-of-concept (PoC) exploit as well as an osquery for detecting machines with the vulnerable service.
Introduction
SteelSeries is a hardware company that specializes in computer peripheral devices, such as keyboards, mice, headphones, etc. To customize these devices, SteelSeries offers its users an application – SteelSeries GG – that can be downloaded from its website.
This application, composed of the main SteelSeries GG module and several subapplications, is a mechanism that SteelSeries uses to enhance user experience.
In our research, we found two ways to register our own subapplication and specify what code to run through it, possibly leading to code execution with higher permissions. In this blog post, we provide the technical details of the vulnerabilities, as well as an exploitation PoC.
Technical details
SteelSeries GG is executed at medium integrity level by default, and usually in the administrator context. Consequently, it may be executed in a high-integrity context under certain circumstances. This detail, combined with the fact that SteelSeries GG is a listening process (Figure 1), makes it a good target for vulnerability research.
Fig. 1: Process Hacker and netstat show the listening SteelSeries GG application
The subapplication mechanism and the interprocess communication API
The subapplication mechanism is used to manage SteelSeries’ optional features and enhance user experience. One example of such a subapplication is Sonar, “an advanced suite of audio software tools for gaming that gives anyone the ability to tweak the in-game sound, team chat, and microphone separately,” as defined by SteelSeries. Subapplications run in the background, and they communicate with the application’s main module via an interprocess communication (IPC) API.
The SteelSeries GG IPC API exposes several types of operations that a user can request, including configuration changes, administrative actions, user-profile edits, etc. More interesting: The API exposes an interface to manage subapplications – from creation and deletion to enabling and disabling.
The API routing functionality (namely, how to handle each API request) is implemented using the gorilla/mux open source library. Knowing this, we can more easily explore the attack surface. The routing function itself is very large, but it’s essentially just a collection of if statements for each of the available API options (Figure 2).
Fig. 2: The implementation of HTTP routing in SteelSeries GG
These API calls are available to anyone who initiates a connection with the listening server ("SteelSeriesGG.exe") and require no authentication.
I chose to focus on the subapplication event handlers since they had the most potential for impact. After reorganizing the disassembled code in IDA, we found that the routing handlers for subapplications have the prototype seen in Figure 3.
Fig. 3: Handler function prototype in gorilla/mux code
Exploiting the subapplication mechanism
One of the API calls we can make is to create a new subapplication. This process is done by sending a POST request to the /subApps route with a JSON payload that contains several parameters, four of which are of interest to us: "name", "executableName" , "isEnabled", and "shouldAutoStart".
Using these fields, we can practically create a new subapplication as a nonprivileged user, point it at an executable in a nonprivileged location, and possibly schedule it with every application startup.
SteelSeries GG builds the full path to the subapplication executable file as follows:
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
Since the “name” and “executableName” fields are concatenated this way, we figured we could try a path traversal attack. As it appears, SteelSeries GG is nonresistant to path traversals, and preceding the path with “../../../../” was accepted, as seen in Figure 4.
Fig. 4: Path traversal is accepted while creating a new subapplication
When a subapplication is created, the information about it is stored in SteelSeries GG’s database. Is there perhaps another way to control subapplications through this database? Indeed, the database is located in an insecure location. This means that even without access to the subapplication API, we may be able to add a subapplication directly to the database. However, attackers will have to find a vulnerability to abuse this design flaw, which by itself is not exploitable and thus does not pose an immediate risk.
You might think creating a subapplication in a controlled location means that we have achieved privilege escalation (once we execute a binary from that path), but trying that, we found that there is another restriction — certificate validation. SteelSeries rightfully makes sure that subapplication executable files are signed and approved. To run our own payload, we’ll have to bypass the verification process.
The verification function calls the WinVerifyTrust function and then calls a chain of WinAPI functions to compare certain fields in the certificate with hardcoded strings in the application.
This validation is a little tricky to bypass, but can still be achieved in two ways:
DLL hijacking
TOCTOU (time-of-check to time-of-use)
The DLL hijacking vector
With the DLL hijacking technique, we can rely on the fact that SteelSeries trusts several existing binaries; one of them is SteelSeriesEngine.exe, which loads the library SSEDEVICE.dll. We will compile our own library with the same name so that our library is loaded instead of the original SSEDEVICE DLL. Our own DLL’s exported functions will call the genuine DLL’s functions.
However, the function called upon the loading of our DLL will implement our malicious logic (Figure 5). The technique is further explained in itm4n’s DLL proxying blog post.
Fig. 5: DLL hijacking of SSEDEVICE
The animation in Figure 6 shows the process of sending the initial packet to running the attacker payload (in our case, opening a cmd instance) with elevated privileges.
Fig. 6: The process of sending the initial packet to running the attacker payload with elevated privileges
The TOCTOU vector
In this case, we take advantage of the time gap between certificate verification and actual execution of the binary (Figure 7). In other words, we try to win a race condition by quickly switching the legitimate file with a malicious one using James Forshaw’s BaitAndSwitch tool. We want to replace this immediately after the certificate verification. That way, verification happens on a legitimate file, but then a malicious unverified file is executed.
By design, race conditions are not guaranteed to work. To stabilize this exploit, we can try to gain more time for the replacement to expand our window of opportunity.
Fig. 7: TOCTOU vector illustration
Recall that the certificate verification relies on two tests: a call to WinVerifyTrust and a check between several fields in the certificate and hardcoded string in the application. We can implant a certificate with these exact values in our executable. This enhancement enables the attacker to win the race condition even if the switch occurs between the two tests, as our malicious binary meets all the criteria for the second test.
The animation in Figure 8 shows the process from waiting for the start of the verification process with BaitAndSwitch to the execution of the attacker binary (in this case, cmd.exe).
Fig. 8: The process from waiting for the start of the verification process with BaitAndSwitch to the execution of the attacker binary
Detection and mitigation
To aid with detection of vulnerable assets in the network, we provide an osquery to find instances of SteelSeries GG and its currently installed version:
SELECT name,version from programs where name LIKE '%SteelSeries%' |
Akamai Guardicore Segmentation customers can use this query with Insight to locate applications that require patching.
SteelSeries updates its application with each new patch. This may lower the chances of your devices being affected by these vulnerabilities, but we advise defenders to upgrade their version of SteelSeries to one higher than 39.
Conclusion
SteelSeries is a large company with a massive user base of more than 9 million customers worldwide. Any vulnerability in its products is inherently impactful. The consequences are compounded when we consider the ease of exploitation of these vulnerabilities and their effect on the machine; i.e., potentially gaining execution of binaries under ADMIN context.
The scope of impact is not limited to the machine belonging to the user; enterprises might be affected as well. An employee’s laptop that connects to a vulnerable device or runs a vulnerable application can later be connected to the enterprise network and “import” risks into the organization. For this reason, it is important for enterprises to consider implementing a bring your own device (BYOD) policy and educating employees on the dangers of using such devices.
We have scanned the networks of Akamai customers to search for instances of the vulnerable application and informed the relevant customers.
As part of our ongoing efforts to protect our customers and the community, we will continue to analyze patches and other systems for vulnerabilities. To keep up with the latest security research from Akamai, follow us on Twitter.
Disclosure timeline
4/27/2023 — CVE request submitted to MITRE
5/1/2023 — Email sent to SteelSeries customer support
5/2/2023 — CVEs assigned by MITRE
5/3/2023 – 6/4/2023 — Conversations with SteelSeries engineering team
5/31/2023 — Fixes published
7/17/2023 — Blog draft reviewed by SteelSeries
7/18/2023 — Blog post published
