GlueBall: The story of CVE-2020–1464
Digitally signed files are more trusted by the Operating System. This higher trust allows such files to execute in sensitive contexts or excluded from Antivirus scans. Consequently, attackers are trying to spoof these digital certificates to gain these extended privileges for their malicious code.
Earlier this year, Peleg Hadar and I worked together on some aspects of the CurveBall attack, a “spoofing bug” which allowed attackers to abuse a cryptographic flaw in Microsoft Windows implementation to pass their malicious network traffic and files as validly signed.
Therefore, when Peleg started to analyze last week’s “Windows’ patch Tuesday”’s CVE-2020–1464 , described by Brian Krebs as:
a “spoofing” bug in virtually all supported versions of Windows
he had asked me to look into the cryptographic aspects of this new vulnerability. We soon realized that this vulnerability is not only not cryptographic, but also not new!
In this article, we try to sew the fragmented pieces of information about this vulnerability, we internally call GlueBall, into a cohesive story.
GlueBall Timeline
- August 2018: A GlueBall sample was first uploaded to VirusTotal. According to author, Bernardo Quintero, he immediately reported the issue to Microsoft
- January 2019: VirusTotal published an analysis of GlueBall core issue, after Microsoft understood the issue, added some support to it on external tools, but said they “WONT FIX” for the operating system.
- January 2019: Following the VirusTotal blog, Multiple blog posts on using GlueBall to hide malicious content were published.
- June 2020: Following some in the wild exploitation with popular malware, GlueBall was “re-discovered” and highlighted by social media
- August 2020: Microsoft patched GlueBall, 2 years after it was first discovered in the wild.
GlueBall explained
Windows trust architecture is quite cumbersome and not well documented. SpecterOps’ Matt Graeber had explored it in the detail in his epic “Subverting Trust in Windows” paper. Specifically, it details the functions that allow Windows to treat different kinds of files in a different manner.
The problematic function in GlueBall’s case was MsiSIPVerifyIndirectData, used to verify the contents of Microsoft Installer (MSI) files.
As described in the VirusTotal original blog, the MSI verification function only checks that the beginning of the file is a valid MSI file and verifies its signature. If there is data beyond that, it is ignored.
As a result, attackers could append any data they want to the end of a signed MSI, and still have this file considered as verified by Windows. This trust bypass was made exploitable by appending a Java JAR executable to the end of the MSI. JAR files are evaluated from their end, thus creating a perfect malicious tandem:
- JAR execution is evaluated from file end, ignoring a possible prefix.
- MSI signatures verification is from file start, ignoring a possible suffix.
Consequently a malicious GlueBall file is both verified and executable!
As expected, the solution is quite simple. The patched MsiSIPVerifyIndirectData function checks for the size of the MSI and fails if it contains an unexpected suffix
In the GIF below, the same GlueBall file, comprised of an MSI and JAR is shown to be considered as validly signed on unpatched systems and invalid on patched systems.
Parting thoughts
While the technical details are pretty obvious, the way Microsoft had handled the vulnerability report seems rather strange. It was very clear to everyone involved, Microsoft included, that GlueBall is indeed a valid vulnerability exploited in the wild. Therefore, it is not clear why it was only patched now and not two years ago.
Update August 17, 2020: timeline updated.
