TL;DR
This blog post describes a privilege escalation issue in Windows (CVE-2020-16877) I reported to Microsoft back in June, which was patched in October. This issue allows an attacker to exploit Windows via videogames by directly targeting how Windows handles Microsoft Store games. This issue could be exploited to elevate privileges from a standard user account to Local System on Windows 10.
Introduction
Back in June, a certain announcement caught my attention – Microsoft just added support for mods for various games as part of its gaming subsystem. My growing curiosity lead me to explore this new Windows feature and find an implementation flaw that could be abused to conduct privilege escalation attacks.
I have put together this blog post using the many Post-it notes left stuck around my monitors, detailing a long night spent playing around with this new Windows feature.
Before we start playing with this feature, let me provide you with some background on Windows apps and game mods. If you are familiar with these concepts, please feel free to skip over the next section.
Windows Gaming and Mods
If you are not too familiar with videogames, a mod (short for "modification") is an alteration made by players or fans of a videogame, that changes one or more aspects of a videogame, such as how it looks or behaves. Mods range from small changes and tweaks to complete overhauls, which can make a game more interesting to play.
In general, Microsoft Store games are Universal Windows Platform (UWP) apps deployed on Windows as Windows apps.
According to Microsoft's documentation, a UWP app is:
- Secure: UWP apps declare which device resources and data they access. The user must authorize that access. UWP apps use a manifest to specify the capabilities that are needed, such as access to the microphone, location, Webcam, USB devices, files, and so on.
- Able to use a common API on all devices that run Windows 10.
- Available from the Microsoft Store on all devices that run on Windows 10.
- Able to be installed and uninstalled without risk to the machine or incurring "machine rot".
One can think of a UWP app as a sandboxed application, which defines its capabilities (e.g. filesystem access, network access, and so on) in the Manifest part of the application package (Appx).
Appx is the file format used to distribute and install apps on Windows 10, Xbox One, HoloLens, and Windows 10 IoT Core. Unlike legacy desktop apps, Appx is the only installation system allowed for UWP apps.
Windows apps are stored in a special “hidden” directory ("C:\Program Files\WindowsApps") on the system that has strict access rules, preventing any sort of game mods or standard user interaction:
The following images shows the permissions for this directory:
In the past, given the lack of mod support for Microsoft Store games, players have been looking for workarounds to mod their favorite games (i.e. Minecraft – Microsoft Store edition). For example, in order to perform DLL injection on UWP apps, the ALL APPLICATION PACKAGES (S-1-15-2-1) group should have had R+X permissions on the DLL being injected into the Windows app.
Now that we have a basic idea of the Windows apps ecosystem and game mods, we are ready to jump into the fun part.
Game On!
Before installing the game on my system, I took a step back and considered how Microsoft might implement this feature and came up with two possible ways. My two guesses were:
- A new subdirectory within the WindowsApps directory that was accessible to standard users.
- A separate directory placed in a (standard) user-accessible directory.
So, I performed an additional step and did a simple search on my main drive for "*WindowsApps*" and got the following result:
It appears that in order to allow games to support mods, Windows created a new directory "C:\Program Files\ModifiableWindowsApps", which as the name suggests, should host Windows apps that could be modified. Interesting.
I wanted to check the permissions on this directory as well as its contents, but unfortunately, I didn't have any content in it yet. However, I could at least access it without an admin prompt, but couldn't do much in it...
Permissions on C:\Program Files\ModifiableWindowsApps:
I did a quick online search for references to this directory and found the following bits:
- References to the ModifiableWindowsApps directory could be found in the Microsoft documentation for desktop6:MutablePackageDirectory (dated 04/19/2019), which states this directory, "specifies a folder under the %ProgramFiles%\ModifiableWindowsApps path where the contents of your desktop application's install folder are projected so that users can modify the installation files (for example, to install mods)."
- The documentation for desktop6:MutablePackageDirectories (dated 04/19/2019) states this directory, "enables your desktop application to specify one or more folders where users can modify the installation files for your application (for example, to install mods)."
- And most importantly, "this element is currently intended to be used only by certain types of desktop PC games that are published by Microsoft and our partners. It requires the modifiableApp restricted capability".
This tells us that this feature is restricted to only certain games that need to be vetted and approved by Microsoft, in order for the game to be allowed to specify the modifiableApp capability in the manifest, and therefore allow mods.
Recap Time
Let's recap what we know so far:
- Windows is allowing a number of Microsoft Store games to be modifiable.
- This is achieved by allowing certain game developers to publish UWP games on the Store using a restricted capability (modifiableApp).
- Among other things, the modifiableApp capability allows Microsoft Store games to rely on the Windows mod support and a bunch of new APIs.
- These modifiable Windows apps can specify the directories where their modifiable data is stored via MutablePackageDirectory and MutablePackageDirectories.
Back To The Action
At this point, in order to proceed with my exploration, I had to find a list of games with mod support available on the Microsoft Store, and pick a game to play with. Luckily enough, the Microsoft article about mod support for Microsoft Store games had this list ready for me:
- DiRT Rally 2.0
- Farming Simulator 17
- FTL: Faster Than Light
- Into The Breach
- MudRunner
To confirm my understanding of the Windows apps' modding approach, I took a quick peek at the game manifest to check and confirm the presence of the "special" capability (modifiableApp):
And to confirm the location of the game directory where the game data would be deployed, I checked the ModifiableWindowsApps directory after installing the game, and "FTL" would be the MutablePackageDirectory:
With this information, I decided to go ahead and install the game again as a standard user, and monitor the installation process with ProcMon:
ProcMon provided me with the following information about installing games with mod support from the Microsoft Store:
- There were two main processes doing the heavy lifting:
- svchost (running as NT AUTHORITY\SYSTEM), specifically:
- GamingServices (running as S-1-5-18)
- These processes performed interesting file actions without impersonating a low-privileged user.
Houston, We Got A Problem
The ModifiableWindowsApps directory, storing Windows games, does not allow (by default) standard users to fiddle with the installation directory or its contents:
One of the reasons why Microsoft may want to restrict access to the game directory (and its parent directory) is to prevent standard users from hijacking the installation process and placing game data into an unwanted directory. How? For example, by relying on symbolic links.
Specifically, on Windows it is possible to create symbolic links via:
- Hard Links - A hard link is the filesystem representation of a file by which more than one path references a single file in the same volume.
- Junctions - A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer.
- Object Manager Symbolic Links - a filesystem-like structure, which is used to hold named resources, such as devices and events, that also supports symbolic links.
If I were able to gain write access to the ModifiableWindowsApps directory, I could try to redirect the game installation to target an arbitrary directory on the system, including a directory a standard user would not have access to, since the installation process(es) run as a high-privileged user, as shown earlier.
Under the assumption I could create the initial junction (for the ModifiableWindowsApps directory itself), the following workflow shows a possible way to hijack the installer to an arbitrary directory (i.e. into "C:\Windows\ImmersiveControlPanel"), bypassing access restriction:
Permissions for C:\Windows\ImmersiveControlPanel:
Unfortunately, to be able to set up any symbolic link, a standard user would need to have write access to ModifiableWindowsApps or any of its subdirectories.
This was not possible since the ModifiableWindowsApps could not be replaced (as this was already part of the system) and there were strict access rules in place to protect this directory and its content (i.e. the game directory "FTL").
Is it game over? Well not just yet...
And Yet It Moves
All I needed to find was a way to "lift" the ModifiableWindowsApps directory and place it somewhere else on the system where I have access, at least until this relocation has completed.
Interestingly, Windows has a neat feature that lets you define where various data should be stored, which is accessible to standard users. This feature is accessible via Storage Settings.
This feature obviously works for Windows apps, and I wanted to confirm this would also work with modifiable Windows apps. So, I set the destination drive for new apps to a different drive on my system and tried the installation process again. Great news, the ModifiableWindowsApps directory and the game were both placed on the new drive.
Potentially, this could be a way to gain write access to the ModifiableWindowsApps directory when this is deployed on a different drive (rather than C:), and all I had to do was prepare the destination drive (i.e. any other drive on the system, even an empty USB stick) with a combination of junctions and bait the installer via Storage Settings.
Challenge Accepted
It was time for me to put all the pieces together and try to exploit this mechanism and see if the workflow I envisioned earlier, with a minor change (bouncing from one drive to another), would work and reveal an interesting implementation flaw:
First off, I set the junction to hijack the installer using the following commands (assume D: is any other available drive on the system - even a USB stick):
- md "D:\Program Files"
- mklink /J "D:\Program Files\ModifiableWindowsApps" "C:\Windows\ImmersiveControlPanel"
And installed the game:
While monitoring the installation via ProcMon:
To confirm the game data was actually written into my arbitrary directory:
At this point I knew a standard user could write data into any arbitrary directory on the system, but what about deleting files? The first approach that came to mind was trying to uninstall the game.
Unfortunately (or fortunately), the uninstall process only removes game files (stored in the actual game directory) and it didn't appear to touch any unrelated data.
But what if the game directory itself is a junction? What if we use a double junction to trick the installer into thinking that the game installation directory itself is another directory on the system?
This way, when the installer attempts to delete the game data, instead of deleting the content of the game directory (i.e. "FTL"), it will remove the content of an arbitrary directory on the system (i.e. the "Private" directory stored on the admin's desktop):
So, I prepared my attack environment again but with a little twist, I would use a double junction to wipe an arbitrary directory by pivoting the installer towards my target:
- md "D:\Program Files"
- md "D:\pivot"
- mklink /J "D:\Program Files\ModifiableWindowsApps" "D:\pivot"
- mklink /J "D:\pivot\FTL" "C:\Users\dnt-admin\Desktop\private"
And by doing so, all the data in the targeted directory was actually wiped.
As a final comment before we jump to the last section, please note that it is possible to achieve good control over where the game data is written to (or which files to delete) by the installer by using multiple combinations (and levels) of symbolic links.
Elevation Time
People usually say "pics or it didn't happen", so I shall leave a GIF(t) below of a standard user spawning a shell running as nt authority\system by exploiting this vulnerability:
Hope you enjoyed the reading! Game on and play safe!
