Authors: Brian Papile and Jeff Stokes
The GOG Galaxy version 2.0.35 was vulnerable to a DLL Load Order Hijacking vulnerability. The vendor has patched the vulnerability and released version 2.0.37, as of March 30, 2021.
This vulnerability came about when we tried to uninstall the Folding at Home Client, but its folder and some DLLs remained. When trying to manually delete the files, the below warning prompted that they were in use by the GOG Galaxy client application.
To us this was very odd, GOG of course has no relationship with the FAH software. It was even installed on a completely different drive. We suspected there to be a vulnerability here, but were not sure or if it was exploitable.
After reaching out to colleagues, they believed this could be a DLL Load Order Hijacking vulnerability. After doing some research, we came to the conclusion that Process Monitor, with some filters applied, would likely be the best avenue for investigation.
This was returned around 113 events on startup of the GOG client. But most paths were places only administrators had access to. Adding additional filters, we ended up with
Nice, we have a DLL path that a standard user can write to: C:\Users\(username)\AppData\Local\Microsoft\WindowsApps\ZLIB1.dll
Development of POC
From here, we knew we needed a DLL to place in this directory. After doing some searching (mainly on GitHub), we couldn’t find one that fit our needs. We wanted to write out to a file, the process and the account that was running it. Additionally, we wanted a popup, with the same information, for visual confirmation.
Our requirements for this DLL was to make it flexible (for other vulnerability research), but mainly to see if the update mechanism of the GOG Galaxy client would run the code in our DLL. The update service runs as SYSTEM level permissions. This was necessary, because there was no way to manually kick off a check for updates of their software, and we couldn’t find a cadence of when or how it happened. As our coding knowledge only included scripting languages, we reached out to some colleagues (again), and they assisted us with the creation of the DLL.
We dropped the DLL into the above path, and boom! The file C:\temp\whoami.txt was created, with username, process path, and PID. Additionally, the popup displayed the same information:
We dug around, and tried to get the GOG Galaxy client to update and trigger our DLL, but we had no luck. At this time, we could not find a way to elevate, above the current user. But that doesn’t mean that this vulnerability should be ignored, as other processes could exploit this to hide their malicious code and run as the logged on user (we were thinking ransomware primarily as the risk).
Now we needed to report the vulnerability to GOG and submit for a CVE, which we have never done before. This was a learning opportunity for us, but wasn’t as bad as initially thought. See the below timeline.
Jan 24, 2021 – Initial finding
Jan 25, 2021 – Notified vendor
Jan 25, 2021 – Vendor forwarded on to their security team
Jan 26, 2021 – Vendor closed initial support ticket, opens JIRA and recommends we “follow Google Responsible Disclosure rules”
Jan 26, 2021 – Google waiting period begins — 90 days (April 26, 2021 from this date)
Feb 2, 2021 – Notified MITRE/CVE portal
Feb 9, 2021 – CD Projekt Red is hacked and held for ransom (only including this, because GOG might fall under them, or vice versa, so resources could be distracted from this)
Feb 25, 2021 – MITRE issues CVE-2021-26807
Mar 30, 2021 – Vender releases 2.0.37, fixing the vulnerability
Mar 30, 2021 – MITRE notified of fixed version
Apr 6, 2021 – MITRE informed us we could publish
Apr 29, 2021 – Blog published
Thanks to everyone involved (post will be updated with names once we know they are ok being named).
Thanks to Alyssa Miller for guiding us on how the whole CVE process works!
Github for our DLL (TBD)
Leave a Reply