The hunt for vulnerability: executing arbitrary code on NVIDIA GeForce NOW virtual machines
Against the backdrop of the coronavirus pandemic, the demand for cloud gaming services has noticeably increased. These services provide computing power to launch video games and stream gameplay to user devices in real-time. The most obvious advantage of this gaming type is that gamers do not need to have high-end hardware. An inexpensive computer is enough to run the client, spending time in self-isolation while the remote server carries out all calculations.
NVIDIA GeForce NOW is one of these cloud-based game streaming services. According to Google Trends, worldwide search queries for GeForce NOW peaked in February 2020. This correlates with the beginning of quarantine restrictions in many Asian, European, and North and South American countries, as well as other world regions. At the same time in Russia, where the self-isolation regime began in March, we see a similar picture with a corresponding delay.
Given the high interest in GeForce NOW, we decided to explore this service from an information security standpoint.
Exploring the platform
The menu contains a list of games supported by the service. To play a game, the gamer needs an account from one of the digital distribution services with a particular game linked to it. If the game is paid, it must be purchased in advance. In this study, we examine GeForce NOW in conjunction with the Steam digital store.
Upon clicking “Play”, a remote virtual environment is launched in the main window and real-time streaming from the server to the user's device begins.
If the selected game has already been purchased, it will run in full-screen mode and other features of the virtual environment should not be available to the player. However, if the game settings allow the game to be launched in the windowed mode, it becomes possible to access the Steam library. Another way to access the library is to select a game that is not yet present in the catalog.
It is already clear that one can execute arbitrary code by exploiting a vulnerability in a supported game. The only limitation is that the exploit must be delivered over the network. Several scenarios for further events exist. For example, if an exploit during its operation creates an executable file on the virtual machine’s disk, the service may theoretically prevent the payload from executing by tracking the executable file created by “kiosk” — the standard username in GeForce NOW virtual machines. On the other hand, if exploiting a vulnerability results in shellcode execution, the entire system will become vulnerable.
To perform proper exploration of the virtual machine’s environment, access to cmd.exe or powershell.exe would be useful. But how to get it? A brief browse through the Steam library helped find a way to launch an arbitrary executable file that already exists in the system. To do this we used the “Add a Non-Steam Game...” option.
In regular conditions, it would not be a problem to add cmd.exe to the library as a Non-Steam game. But in the GeForce Now environment this option is blocked and clicking the “Browse” button does not lead to anything. Nevertheless, it is possible to select one of the existing applications (and at the same time see what programs are installed in the virtual machine). The 7-Zip file archiver will be used as an example, but any of the listed programs will work.
After adding 7-Zip to the Steam library, the program settings can be changed. At this stage the path can be altered to point to cmd.exe. Ready. Let’s launch the “Non-Steam game” and get the working shell:
Now it is possible to look around and locate some of the system parameters. Launching winver:
As it turned out, the service’s virtual machine runs on Windows Server 2019.
As a result, we can already do things that GeForce NOW virtual machines are not supposed to do. What else can be done and how dangerous would it be?
According to the FAQ located on the NVIDIA webpage designed to report vulnerabilities, obtaining access to cmd.exe on the GeForce NOW virtual machine is not considered a vulnerability. The default user has minimal permissions in the virtual environment, and there is filtering for running applications. For example, the virtual machine immediately shuts down immediately after launching powershell.exe.
Thus, to make this study topical we need to solve two tasks:
1. Deliver the payload to the virtual machine
2. Launch it by bypassing the application allowlist
We tried popular LOLBins such as regsvr32, bitsadmin and some others to deliver the payload, but in all cases, the virtual machine crashed:
The decision came naturally. GeForce NOW is a service for gaming, including multiplayer online gaming where a client connects to the game server to download sounds, models, maps and other files. Therefore, we should choose a game that allows one to deliver an arbitrary file to the client. At the same time, we do not need to worry about the file extension since we have access to the shell and we can move the downloaded file to a location where we can use it.
But how to deal with the application allowlist? After all, even if we manage to put a third-party application onto a virtual machine, it will crash the moment the application starts. One possible solution is to find an application from the allowlist, perform a DLL hijacking attack and inject the code into that app. The most obvious target is the game’s process.
Counter-Strike: Source game (CS:S) will be used as a working example. The first thing to do is create a custom CS:S game server that will deliver the DLL file disguised as the game model (d.mdl). We then launch CS:S within GeForce NOW and join our server to automatically download the prepared d.mdl onto the virtual machine. Now we minimize the game and launch cmd.exe. Then we move the d.mdl file to “Counter-Strike Source/bin/user32.dl” and restart the game with the console command. We have just run arbitrary code within the context of a trusted process.
And even make a video clip:
Although attacks on the service’s users are potentially possible, they are still questionable. Additionlly, in the event of an attack on a single virtual machine, the risks to other users will be minimal. For each new game session, GeForce NOW launches a clean virtual environment. After the player finishes his session, the virtual machine shuts down and resets. With that, even if the vulnerability is successfully exploited, the malicious code will run only as long as the compromised virtual machine runs. To attack other users, hackers will need to go beyond the virtual environment by utilizing the “virtual machine escape” exploit. These kinds of exploits are rare and difficult to implement. Still, if successful, the attack will threaten not only individual players, but also users who began the game session after the initial infection through one of the GeForce NOW virtual machines.
However, a more straightforward and realistic attack scenario is to use a compromised virtual machine for mining, conducting DDoS attacks, and performing other illegal actions that require computing power.
After our report, NVIDIA confirmed the problem and released a corresponding fix for its service.
Chronology of events:
18.04.2020 — Vulnerability report is sent to NVIDIA.
20.04.2020 — NVIDIA PSIRT confirmed receiving the report and reproduced the bug.
13.05.2020 — NVIDIA PSIRT informed us that developers were working on the problem.
21.08.2020 — NVIDIA PSIRT informed that the fix would be released before 30.08.
02.09.2020 — We requested a clarification about the release date.
03.09.2020 — NVIDIA released the fix.
04.09.2020 — NVIDIA made an announcement about the vulnerability.
07.09.2020 — We published our report.