Powered by ACTIVECYBER, LLC
Powered by ACTIVECYBER, LLC
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 firstname.lastname@example.org if you have any questions. Also, see the link here for a complete list of ACTIVELabs advisories.
ACTIVELabs was created in 2018 to hunt and research undiscovered vulnerabilities, report them to vendors via responsible disclosure programs, publish advisories, develop and validate new patches, and to share this information for the advancement of the cybersecurity community. ACTIVELabs was established with the mission of securing our ever-growing client base, partnerships, and the technology community as a whole.
We are actively providing the community with verified findings and research that leads to the creation of new Common Vulnerabilities and Exposures (CVEs) and updates to the National Vulnerability Database (NVD). For a full listing of all of our Advisories, visit our GitHub page here.