Steam Windows Client Local Privilege Escalation 0day
I’ve been searching for vulnerabilities for several years, and, it would seem, 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 do not understand why vulnerability information needs to 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.
The vulnerability itself is pretty simple. Steam installs the “Steam Client Service” service for its work. Take a look at the SDDL service descriptor :
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 is also found out that the HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam section 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 ?
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):
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 HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver branch - 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 over the HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver branch, we change the path to the executable in the ImagePath key and start the msiserver service. Our executable file 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.
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, really?”
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.
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:
Timeline:
June 15 - Vulnerability Report sent.
June 16th - Rejected, "Attacks that require the ability to drop files in arbitrary locations on the user's filesystem."
June 16 - rediscovered with commentary.
July 2 - confirmed by HackerOne employee, 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 was published.
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 is impossible to establish this exactly, but let's compare the facts:
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.
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 details of the vulnerability after July 30.
August 2 - another h1 employee is reported in a private 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 yesterday (August 6) Steam update was released. No, it didn’t fix anything.
File version: 5.27.59.20 signature dated 08/08/2019.
We continue to update the timeline:
August 7 (after publication) - the report on h1 was rediscovered. I received a letter, the essence of which is difficult to fit in a nutshell, but the most important thing was that some convincing arguments need to be brought to the conclusion that the consequences of the vulnerability are significant. There was "Valve is not going to fix something that they have determined to be N / A." These words once again confirmed my conviction that I am right in that I conducted a public disclosure of details.
August 7 - Matt Nelson writes that the vulnerability he reported is exactly the same as mine. Which confirms my thesis about the ease of finding it. He opens his PoC .
August 9 - Steam Beta receives an update where one of the lines is “Fixed privilege escalation exploit using symbolic links in Windows registry”. There are suspicions that the fix can be circumvented, but for now stock up on popcorn.
August 13 - Steam receives an update where one of the lines is “Fixed privilege escalation exploit using symbolic links in Windows registry”. It seems that the service does not expose rights in the registry, so we can assume that it is fixed.
August 15 - the researcher showed that the patch can be circumvented , the vulnerability is still relevant. Shortcut - you can return the previous (before the patch) version of the service.
August 20 - Valve banned me in their program on H1. The rest of the H1 is available to me.
This article in english.
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 service descriptor :
O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(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 is also found out that the HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam section 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 ?
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 HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver branch - 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 over the HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver branch, we change the path to the executable in the ImagePath key and start the msiserver service. Our executable file 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, really?”
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 believed that reports that do not contain a vulnerability as such, but demonstrate some strange application of the installed software, are excluded from the scope.
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 connected to the servers by waves or wires - physically!
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 connected to the servers by waves or wires - physically!
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 16th - Rejected, "Attacks that require the ability to drop files in arbitrary locations on the user's filesystem."
June 16 - rediscovered with commentary.
July 2 - confirmed by HackerOne employee, 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 was 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 is impossible to establish this exactly, but let's compare the facts:
- There is a vulnerability that is easy to exploit (and, judging by the messages on Twitter , not one).
- It is quite easy to detect - I’m not sure that I was the first to find it, but at least the first one was described publicly.
- Reluctance to accept a report on such vulnerabilities and similar ones (the scope is specially chosen so that privilege escalation falls out of it).
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 details of the vulnerability after July 30.
August 2 - another h1 employee is reported in a private 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 yesterday (August 6) Steam update was released. No, it didn’t fix anything.
File version: 5.27.59.20 signature dated 08/08/2019.
After disclosure
We continue to update the timeline:
August 7 (after publication) - the report on h1 was rediscovered. I received a letter, the essence of which is difficult to fit in a nutshell, but the most important thing was that some convincing arguments need to be brought to the conclusion that the consequences of the vulnerability are significant. There was "Valve is not going to fix something that they have determined to be N / A." These words once again confirmed my conviction that I am right in that I conducted a public disclosure of details.
August 7 - Matt Nelson writes that the vulnerability he reported is exactly the same as mine. Which confirms my thesis about the ease of finding it. He opens his PoC .
August 9 - Steam Beta receives an update where one of the lines is “Fixed privilege escalation exploit using symbolic links in Windows registry”. There are suspicions that the fix can be circumvented, but for now stock up on popcorn.
August 13 - Steam receives an update where one of the lines is “Fixed privilege escalation exploit using symbolic links in Windows registry”. It seems that the service does not expose rights in the registry, so we can assume that it is fixed.
August 15 - the researcher showed that the patch can be circumvented , the vulnerability is still relevant. Shortcut - you can return the previous (before the patch) version of the service.
August 20 - Valve banned me in their program on H1. The rest of the H1 is available to me.
This article in english.
All Articles