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 uploaded to VirusTotal
  • 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

The VerifyIndirectData function is used to verify the integrity of a specific file format (source: SpecterOps)

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

Patched MsiSIPVerifyIndirectData() verifies the file’s size too (source: Peleg’s twitter)

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.

Same GlueBall file: digital signature valid on an unpatched computer, but invalid on a patched computer

Parting thoughts

Update August 17, 2020: timeline updated.

All things CyberSecurity. Security Research Manager. Co-Founder @ZenGo (KZen). Formerly, VP of Research @ Aorato acquired by @Microsoft ( MicrosoftATA)