Steam Windows Client Local Privilege Escalation 0day

Steam Windows Client Local Privilege Escalation 0day


I’ve been searching for vulnerabilities for several years, and it would seem that I have seen a lot, but there is such a part of the work that I can’t get used to and I can’t understand. This is an absolute reluctance of vendors to accept information about vulnerabilities and problems. I understand that it’s very unpleasant when they directly show you that you made a mistake and, most likely, not one. It’s unpleasant to confirm publicly in open sources that there were problems, that the employees didn’t work. But I don’t understand why vulnerability information should be rejected.


So, the hero of our story is Steam software from Valve. And the privilege escalation vulnerability in it, which allows any user to execute commands on behalf of NT AUTHORITY \ SYSTEM.

Vulnerability


The vulnerability itself is pretty simple. Steam installs the “Steam Client Service” service for its work. Take a look at the SDDL descriptor of the service:

O: SYG: SYD: (A ;; CCLCSWLOCRRC ;;; IU) (A ;; CCLCSWLOCRRC ;;; SU) (A ;; CCLCSWRPWPDTLOCRRC ;;; SY) (A ;; CCDCLCSWRPWPDTLOCRSDRCWDWO ;;; A ;; RPWP ;;; BU)

Here we are interested in the part (A ;; RPWP ;;; BU). In this case, this entry means that any user from the Users group can start and stop the service.
Let's see what the service does at startup. Not very much interesting, but there are some operations that look unusual - the service lists the contents of the HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps section and sets some rights for all subsections.



I wonder what kind of rights are exhibited? We create a test key, start the service (procmon’s log above) and see what’s right. Here it turns out that even the section HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam has full access rights for all users that are inherited on all subkeys. A hypothesis is born that the same rights will be set for all subsections of HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps through a call to RegSetKeySecurity . But what if there is a symlink in the registry and the branch HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps \ test will point, for example, to HKLM \ SOFTWARE \ test2 ? < br/>
We check and see that the rights in the case of a symlink are registered for the target registry branch.



We check the rights of the target branch and see in the SDDL form (skipping uninteresting):

(A; ID; KA ;;; BU) (A; OICIIOID; GA ;;; BU)

In verbal form, this means full (read and write) access for all users. These are the rights the Steam service prescribed to the branch.

Now that the primitive has been prepared to gain control over almost any registry branch, it’s easy to deploy PoC. I chose the branch HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver - it corresponds to the "Windows Installer" service, which can also be started by the user, but the service will work with NT AUTHORITY \ SYSTEM privileges. After gaining control of the HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver branch, we change the path to the executable file in the ImagePath key and start the msiserver service. Our executable is launched with the highest possible permissions - NT AUTHORITY \ SYSTEM.

We collect everything that is written above in the code and get a simple privilege escalation on any Windows computer where Steam is installed.

Vulnerability Report


I sent a vulnerability report to Valve through Hackerone.

Here the first surprise was waiting for me - before transferring the vulnerability directly to Valve, I had to first convince hackerone staff that I really had a vulnerability report, since Valve used the "Managed by HackerOne" function. I do not mind - I have PoC, which calls the console on behalf of NT AUTHORITY \ SYSTEM - evidence on the face. And I get a denial in the report. The reason indicates that my report is outside the scope of research, because “Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.” (An attack requires the ability to locate files in arbitrary paths of the file system). My reaction: “I don’t even have a single file system operation, but a failure for that reason, seriously?”

I am writing a comment about this and another employee arrives, who nevertheless undertakes to check the vulnerability. Confirms it and passes Valve. Hooray, the goal is achieved. Or not ...?

Time passes and the report is again marked as not applicable. Reasons: “Attacks that require the ability to drop files in arbitrary locations on the user's filesystem” and “Attacks that require physical access to the user’s device” (the attack requires physical access to the user's device). Then I realized that privilege escalation attacks were simply not interesting to Valve.

A short comment about the reasons
Initially, I thought that reports that did not contain the vulnerability as such were excluded from the scope, but they show some kind of weird application of the installed software.

For example, for the reason “Attacks that require the ability to drop files in arbitrary locations on the user's filesystem” I highlighted key words, in my opinion. It seemed to me that such a reason Valve wanted to exclude speculation on the topic “Let me install the game in a folder accessible to all users, then I will run it with admin rights, without checking if anyone replaced the files”, but for them this is apparently a reason to exclude in general, everything about local attacks.

The same goes for physical access. For me, physical access is the ability to use a screwdriver to unscrew the screws on the hard drive, boot from external media and other interesting things directly with the PC hardware. It is quite logical to assume that with such access you can do almost anything. As well as overcoming two-factor authentication with physical access to the phone. Valve, apparently, considers any action on the user's computer as physics. And RCE can not be prohibited for long: the computer is physically connected to the servers by waves or wires!

Since 45 days have passed since the report, I decided to publicly disclose the details of the vulnerability, although I'm not sure if this will encourage Steam developers to make changes.

Small statistics: the vulnerability was tested on Windows 8 x64, Windows 8.1 x64 and Windows 10 x64. I don’t know the features of Steam software version numbering, so I’ll fix the version of the service components:

  • SteamService.dll (5.16.86.11, signed by Valve 06/14/2019)
  • SteamService.exe (5.16.86.11, signed by Valve 06/14/2019)

Timeline:

June 15 - Vulnerability report sent.
June 16 - Rejected, "Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.".
June 16 - rediscovered with commentary.
July 2 - verified by HackerOne, transferred to Valve.
July 20 - Rejected, "Attacks that require the ability to drop files in arbitrary locations on the user's filesystem.", "Attacks that require physical access to the user’s device.".
August 7 - this article has been published.

A bit of speculation


I'm very disappointed.A serious company that writes pompous words that security is important opens your computer for maximum access to any programs that you run.

It's pretty ironic to find that a launcher, which is actually designed to run third-party programs on your computer, allows them to quietly get maximum privileges. Are you sure that a free game made on the knee by an unknown developer will behave honestly? Believe that for a 90% discount you won’t get a hidden miner? Of course, some threats will remain while working without administrator rights, but the high rights of malicious programs can significantly spoil the nerves - disabling the antivirus, fixing it to system startups, changing almost any files, any users.

Due to the popularity of Steam, the number of potential victims is very large. In 2015, the number of active Steam accounts was estimated at 125 million. Yes, not all Steam users have Windows OS, but most definitely, and some users have several “live” accounts on the same machine. But the magnitude of the problem is still impressive.
Or maybe all this is left on purpose? Maybe Steam is a kind of legal backdoor? It’s impossible to establish exactly, but let's compare the facts:

  1. There is a vulnerability that is easy to exploit (and, judging by the Twitter messages , not one).
  2. It’s pretty easy to spot - I’m not sure that I was the first to find it, but at least the first I described it publicly.
  3. Reluctance to accept a report on such vulnerabilities and similar ones (the scope is specially chosen so that privilege escaping from it falls out.

I really don't like all this. I will not urge you to remove Steam, but I propose to be very careful with what it does. Your safety is at stake.

Bonus


The fact is that in the process of preparing this article a rather interesting event occurred, in connection with which I decided to supplement the timeline.

July 20 - after rejecting the report, I warned h1 that I would publicly disclose the details of the vulnerability after July 30.
August 2 - another h1 employee is featured in a closed report and says that they do not allow me to disclose.

This article was prepared for publication by July 30 (this date was chosen at the rate of 45 days after sending the report), but was delayed. And so, two weeks later from my message on July 20, a man appears who says to me: “we do not give permission to disclose the vulnerability”. In fact, it turns out: we marked your report as inappropriate, we closed the discussion, we did not consider it necessary to explain anything to you and we just do not want you to publish. There is not a single word from Valve. No guys, that won't work. You did not respect my work, I will not respect yours - I see no reason not to publish this report for everyone. Most likely I will be banned on h1 because of this, but I won’t be upset.

UPD. It turns out that Steam was released yesterday. No, it didn’t fix anything.
File version: 5.27.59.20 signature dated 08/08/2019.

This article in english.

Source text: Steam Windows Client Local Privilege Escalation 0day