Third Steam Windows Client vulnerability, but not 0day

In previous series

Not so long ago, I talked about two vulnerabilities of Steam: CVE-2019-14743 and CVE-2019-15316 . There was a whole story about how I tried to register them, I didn’t succeed, I was banned, and only after public disclosure and the help of the community I managed to achieve results. Valve pretended to apologize and unban me on HackerOne, so I decided to transfer the next vulnerability through this service. The third time ( there should be an obvious joke about Half-Life 3 ), everything went more or less successfully.

Vulnerability Description

The vulnerability allows the creation of files with partially controlled content (or the addition of partially controlled content to existing files). The version of the vulnerable service is 5.31.28.21 (data from the SteamService.exe file). First, I will describe how to exploit the vulnerability, and then I will describe the possible consequences.

Step 1. Environment

You must complete the Steam application and stop the Steam Client Service if they are running. Most often, users without administrator rights cannot start and stop any services. But specifically for this service, Valve set rights that allow all users to stop and start it.



Create a folder in any place accessible to the user (for example, “C: \ test”). In this folder, you need to copy the Steam.exe and steamclient.dll files from the Steam source folder (by default, this is “C: \ Program Files (x86) \ Steam”). Create an empty logs subfolder ("C: \ test \ logs").



Now let's fix the registry: in the “HKLM \ Software \ wow6432node \ valve \ steam" branch, change the value of the "InstallPath" parameter to "C: \ test \ 1 \ ..". Usually, for non-administrator users, registry branches inside HKLM are not writable, but not in this case. When installing Valve, they set such rights to their branch inside HKLM that in it all actions are available to all users (“Full control” for the “Users” group).

Step 2. Let's do a little test

Launch the Steam Client Service. After it stops (this will happen automatically after a few seconds), check the contents of the folder “C: \ test \ logs” - we find the file “service_log.txt” there. The contents of the log will be something like this:

08/27/19 13:45:01 : ERROR: SteamService: Invalid file signature C:\test\1\..\bin\SteamService.dll
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Note that the path "C: \ test \ 1 \ .." is equivalent to the path "C: \ test", so Windows used the second one to work, and the first one got into the message. Delete the file “service_log.txt” and continue.

Step 3. Add more text.

An interesting fact: when Windows works with paths containing "\ ..", it automatically simplifies such paths. Doing no checks for staging folders.



For example, the path “C: \ 1 \ <test> \ ..” will be converted to “C: \ 1” despite the fact that angle brackets cannot be used in the folder name.



At the first step, we registered the path in the registry, now we will add line breaks to it. This can be done by writing simple code, but it can be done from the regedit interface as well. It is enough to open the registry branch "HKLM \ Software \ wow6432node \ valve \ steam" and select "Modify binary data .." in the context menu of the "InstallPath" parameter. Something like a hex editor will appear where you can make the necessary edits.







We will carry out another test launch of the service and check the result of our actions.







After the test, you must again delete the file "service_log.txt".

Step 4. Redirect the created file

Users without administrator rights cannot create symbolic links from one file to another. But there is a focus - you can combine other types of links that are available to users without administrator rights to get an effect that is close to a symlink from file to file.



First, create an NTFS reparse point (another name for NTFS mount point) from the folder "C: \ test \ logs" to "\ RPC Control \". "\ RPC Control \" is not an ordinary folder in the usual sense, it cannot be viewed, for example, in the explorer. This is a system object directory, inside of which are, for example, named mutexes, events, and other similar objects. Why redirection via NTFS reparse point works for her is not clear, most likely, the point is to use the same abstractions for folders in the file system and object directories. From the object directory, you can create a symlink to a file without administrator rights. Create a symlink of the form "\ RPC Control \ service_log.txt" <-> "C: \ Path \ to \ file".



As a result, any calls to "C: \ test \ logs \ service_log.txt" will be redirected to the file "C: \ Path \ to \ file". To create such a redirection there are two main requirements - the folder from which the NTFS reparse point is created must be empty, and it must also be writable to the user. To fulfill the first condition, after each test we deleted the file “service_logs.txt”, the second condition is ensured by the fact that we created the source folder in a user-controlled place.



There is a special utility that creates such pairs of symlinks - CreateSymlink and is available for download on GitHub . Utility Usage:

 CreateSymlink.exe <> <>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

In our case, it will be:

 CreateSymlink.exe "C:\test\logs\service_log.txt" "C:\\\"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Putting it all together, we get that at the start of the Steam Client Service, a file will be created along the path that was specified when creating the symlink, and this file will contain content that we can control (well, except for the first and last line). If we specify the path to an existing file, the contents will be appended to the end of the file. All of this will be done on behalf of the Steam Client Service with NT AUTHORITY \ SYSTEM privileges.

Impact

Now I will list the possible effects of the least important and ascending.

1. Dos
   
   
   
   If the goal of the symlink is to set “C: \ Windows \ System32 \ config \ SAM” or “C: \ Windows \ System32 \ config \ SECURITY”, then it is unlikely that the OS will be able to boot after a reboot.
2. User redirection on the Internet
   
   
   
   Set the goal of the symlink “C: \ Windows \ system32 \ drivers \ etc \ hosts” and add a line like “127.0.0.1 google.com” there.
   
   
   
   Result:
   
   
   
   
3. Horizontal EoP
   
   A horizontal increase in privileges is a change in rights in which we gain access not to higher rights, but to rights of the same level, but relative to other objects, for example, to the rights of other users.
   
   
   
   Set the goal of the symlink “C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp \ run.bat” and add a line like “start C: \ test \ 1.exe” there.
   
   All files from the C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp folder are executed by users when they log in. Thus, one user can force another user to run code. From the bat file, all lines will be executed in turn. The first and last simply will not do anything, but the implemented command "start C: \ test \ 1.exe" will work.
   
   
   
   With the introduction of such a command, there is one subtlety - the characters "\" will be taken into account during the normalization of the path, so for correct operation it will be necessary to add a few more "\ .." to the path in the registry.
4. Vertical EoP
   
   Vertical privilege escalation is a usual escalation, for example, from a user without administrator rights to NT AUTHORITY \ SYSTEM.
   
   
   
   Quite often you can find software that executes high-resolution text scripts. We can add commands to such scripts and execute our code with high permissions. I did not find such scripts in a clean OS, so you can’t just demonstrate such an exploit. But as an example, I can specify bat files that are created by NVIDIA and VmWare or logon scripts for the OS in the domain.

Additionally, to enhance, you can check the ability to create xml-files, ini-files with a broken format. Unfortunately, there are too many options - creating tasks for TaskSheduler, working with .manifest and other library downloads, and many others. It seems to me that the results described above are already enough to understand the results of the vulnerability.

Timeline

To complete the picture, I’ll give a boring timeline on this vulnerability.

08/26 - Found a vulnerability.

August 27 - unban on h1, published a report.

12.09 - a correction has been released .

findings

This is where I finish the Steam research posts - 3 vulnerabilities that were found with a fairly superficial analysis, this is not enough. To go deeper you need more time and desire. Unfortunately, Valve’s attitude and the incompetence of HackerOne employees are very strong barriers.



I want to once again thank all the readers who helped make Steam safer. I thank Valve for fixing the vulnerabilities and refuting my conspiracy theories. I thank HackerOne for providing the platform, despite the fact that they basically prevented me from communicating the vulnerabilities to Valve.



This article in english.