Overwolf Symbolic Link Privilege Escalation (CVE-2020-15932)
Overwolf is a software platform designed to help developers create extensions for video games, which are then offered to users through Overwolf's App Store. The extensions are often focused on providing in-game services that would normally require a user to exit the game, such as the use of a web browser or an IM client. Other extensions provide game-specific features that can remind users about certain in-game events, easing the game experience. The platform has gained traction in competitive video games, such as eSports and MMORPGs, where native extensions are often forbidden due to concerns about cheating. Overwolf extensions sidestep this concern since they do not interact with the game engine; they operate exclusively on the overlay created by the main Overwolf program.
When examining the latest version of the software, that is v0.142.0.22 we found that the update mechanism is susceptible to file redirection attacks which could lead to elevation of privileges from standard users to NT AUTHORITY\SYSTEM. Now, keep in mind this vulnerability was discovered in early March, and the reason we mention that will become apparent later in this blog post. Let’s start by running the update service which can be triggered by standard users via the software itself or the services console.
Once the update service was done running, we noticed the following in the OverwolfUpdater.log file under C:\ProgramData\Overwolf\Log folder.
As we can see above the update service performs a handful of operations including checking and setting the permissions of several folders when needed, but more importantly, it’s setting the permissions for two files under the ProgramData folder which historically has overly permissive DACL for standard users. Let’s confirm our assumptions before we continue any further.
Now the reason setting the file permissions for appstore.json has failed is due to the non-existing folder housing the file, which is the Store folder. The error was very helpful because it allowed us to identify the calling function within the software which if you haven’t already figured out by now is .NET application. Let’s open OverwolfUpdater.exe in dnSpy and take a look at the EnsureFileHasEveryonePermission function.
The code is fairly simple to interpret, the function accepts filePath as a string argument and then logs the filePath to the OverwolfUpdater.log file. The function then creates a new FileInfo class for the filePath provided and then fetches the FileSecurity object that encapsulates the access control list (ACL) entries for the specified file via File.GetAccessControl method. Next, WorldSid which is part of the WellKnownSidType enum is added to the list of access control list (ACL) entries for the specified file’s FileSecurity object via FileSystemSecurity.AddAccessRule method. Lastly, File.SetAccessControl method is used to update the target file permissions, granting the everyone group full control. Additionally, if for whatever reason, an exception is raised the function will catch said excerption and then logs it to the OverwolfUpdater.log file. Now if we highlight the function and then press Ctrl+Shift+R, we should get a list of functions that are used by the highlighted function.
Looking at the FixPermissionsIfNeeded function, it confirms what we saw earlier in the OverwolfUpdater.log file.
The function first calls RemoveFolderEveryonePermissionIfExists function which as the name suggests, removes the everyone group if found from a set of folders. In essence, the function performs most of the steps discussed in the EnsureFileHasEveryonePermission function, for the most part, only this time it removes the S-1-1-0 SID (everyone group) from the specified folders when found.
And then calls the EnsureFileHasEveryonePermission function twice to make sure the files we’re after are having the everyone group added with full control. Again, if we highlight the FixPermissionsIfNeeded function and then press Ctrl+Shift+R, we will see where this function is being called.
And ultimately confirm that the Updating function is indeed the originating/caller function.
Now what we haven’t mentioned up to this point, is the fact that the OverwolfUpdater.exe process will run under the context of NT AUTHORITY\SYSTEM when performing all of the above operations without impersonating the user even when running check for updates in the software. Let’s run Process Monitor and set a few filters to show details about the SetSecurityFile operation.
At this point, we decided to develop a proof of concept exploit targeting SetupInfo.ini file under the C:\ProgramData\Overwolf\Setup folder using Hard Links because there are other files and folders within the directory that standard users don’t have enough control over to perform other redirection attacks such as Symbolic Links.
The below demo shows how this vulnerability can be utilized to change the permissions of system files. In this instance, we chose C:\Windows\System32\license.rtf.
Whilst requesting security contact from Overwolf to send the report, Microsoft added Hard Links mitigation to Windows 10 in the March cumulative update. After installing this update, Windows will require write access on the target file; otherwise, the Hard Link will fail.
As a result, we had to rewrite the proof of concept exploit to target appstore.json file under the C:\ProgramData\Overwolf\Store folder using Symbolic Links. The exploit was tested against the latest version of Overwolf at the time, which is version 0.143.0.24.
A report detailing the vulnerability along with the demo was sent to the vendor and patch was shared in version 0.145.0.19. Analyzing the patch via Process Monitor we noticed that OverwolfUpdater.exe process first reads the content of appstore.json to see whether it’s a valid JSON file presumably and close the handle to it and then open another handle to the same file to perform a handful of operations and ultimately set the security permissions of the file.
Opening the patched OverwolfUpdater.exe in dnSpy and analyzing the EnsureFileHasEveryonePermission function we see now it’s being used by ExcludePermissionToSpicalFiles function as opposed to FixPermissionsIfNeeded function before the patch.
The function does exactly what we saw earlier in Process Monitor, it first checks whether the file exists, if true the function will then open handle for reading. Next, the function will deserialize the JSON string using the DeserializeObject method provided by JsonConvert Class. If the result is not equal to null the EnsureFileHasEveryonePermission function will be called on the appstore.json file and change its permissions, otherwise, the function will catch the error and log it.
We were able to bypass the patch by abusing race condition between the time the file was checked and the time the file permissions were modified (TOCTOU) using BaitAndSwitch.exe from symbolic link testing tools. The executable makes use of Symbolic Links and Opportunistic Locks to win the race.
We did communicate the bypass details to the vendor and suggested a few alternative fixes that can be incorporated to mitigate the issue. A few weeks later, we received another patch and we were able to bypass it using the same TOCTOU method to achieve arbitrary file overwrite and arbitrary file creation leading to local denial of service and/or privilege escalation. Following further discussions, the vendor released a patch which has nullified the reported vulnerability. Feel free to reach out to labs@activecyber.us if you have any questions. Also, see the link here for a complete list of ACTIVELabs advisories.
Affected Products
Overwolf prior to version 0.149.2.30
Disclosure Timeline
03-06-20: ACTIVELabs contacted Overwolf support requesting security contact and PGP key
03-08-20: Overwolf support responded that we can send it over to support and they will be forwarded it to the relevant department
03-15-20: Overwolf support sent PGP key
03-17-20: ACTIVELabs sent security vulnerability report and requested timeline for patch
03-17-20: Overwolf support responded there might be some delay in response to the issue due to COVID-19
03-17-20: Overwolf security team responded that they will fix as soon as possible
03-19-20: Overwolf security team sent number of possible fixes and requested feedback
03-20-20: ACTIVELabs provided feedback on suggested fixes
03-24-20: Overwolf security team responded that new version will be released to QA as soon as possible
04-13-20: ACTIVELabs requested an update
04-21-20: Overwolf security team responded that fix will should released by 04/29/2020
04-28-20: ACTIVELabs sent a report detailing the new patch bypass
04-29-20: Overwolf security team responded that they will work on implementing new fix and requested feedback
04-30-20: ACTIVELabs provided feedback on suggested fixes
05-15-20: ACTIVELabs requested an update
05-17-20: Overwolf security team responded a fix will be released in 2-3 weeks
06-04-20: ACTIVELabs requested an update
06-04-20: Overwolf security team stated that few more protections will be incorporated, and the fix will be pushed out in another 2-3 weeks
06-19-20: ACTIVELabs requested an update
06-24-20: Overwolf security team shared patch and requested to test it
06-25-20: ACTIVELabs sent a report detailing the new patch bypass and suggested a fix
06-29-20: Overwolf security team stated they are currently working on few fixes to eliminate the issue and plan on phasing it out starting on 7/12/2020
07-07-20: Overwolf security team shared patch and requested to test it
07-07-20: ACTIVELabs confirmed the patch has nullified the reported vulnerability
07-16-20: Version 0.149.2.30 released
07-20-20: ACTIVELabs publishes an advisory
07-20-20: ACTIVELabs request CVE from MITRE
07-23-20: CVE-2020-15932 assigned
