Windows code-signing attacks explained (and how to defend against them)

Learn how code-signing attacks work and how to defend against them. It starts with patching.

A hacker attacks from within a Windows system.
AlphaSpirit / Getty Images

Code signing is a mechanism by which software manufacturers assure their consumers that they are running legitimate software, signed by its manufacturer via cryptography. This ensures that the software release wasn’t tampered with while making its way from the manufacturer to the end-user and is especially relevant when downloading software from third-party websites rather than the manufacturers themselves.

You need to be sure you’re downloading the official release of a software package as shipped by the manufacturer and not an executable that was, say, injected with malware by an attacker.

How code signing works

Digital signatures in this context work by cryptographically signing a file to assure the user that the integrity of this file is intact. To do this, a manufacturer, with a public and private key pair, calculates the hash of the finalized software package and encrypts this hash with their private key.

This encrypted hash bundled with the shipped file enables signature validation utilities installed on the client’s end to check the authenticity of the signature via the corresponding public key. The end result on Windows systems looks like the dialog box below. The .exe file has an embedded digital signature that certifies the file was signed by Microsoft Corporation.

sharma code sign 1 Ax Sharma

Running signed executables in Windows shows the publisher name


What are code-signing attacks?

In an ideal world, cryptography would work as designed and private keys remain heavily guarded. However, this isn’t always the case.

Code signing attacks occur when attackers are able to fraudulently sign bootleg or outright malicious applications using legitimate certificates of a reputable organization. This gives the impression the user is running a trustworthy software program when that might not be true. This can typically happen for one of two reasons:

  • The attacker was able to steal the secret (private) key used to sign certificates and files. This would compromise the trust of the entire key pair and anything signed by the manufacturer using this key should now be considered invalid when it comes to trust.
  • A flaw exists in either the signing algorithm or the signature validator’s implementation. In these cases, the weakest link becomes the tool verifying the digital signatures. By failing to properly check the particulars of a file and any signatures it carries, these flaws let adversaries pass off invalid signatures or improperly signed files as legitimate. 

Microsoft Windows code signing/signature validation vulnerabilities

Recently, Microsoft patched a vulnerability it had known about for at least two years and had been actively exploited. VirusTotal founder, Bernardo Quintero discovered and reported this flaw in 2019 from a malware sample submitted to the site. At that time, Microsoft chose not to patch the flaw after acknowledging its existence, according to Quintero’s blog post.

The cryptic “spoofing vulnerability” CVE-2020-1464 is nothing but a code signing flaw in Windows OS versions, including latest Windows 10 builds, that would let an attacker craft a malicious Java Archive (JAR) file that passes the digital signature validation.

According to Microsoft’s official explanation, “[a] spoofing vulnerability exists when Windows incorrectly validates file signatures. An attacker who successfully exploited this vulnerability could bypass security features and load improperly signed files. In an attack scenario, an attacker could bypass security features intended to prevent improperly signed files from being loaded.”

Exploiting this vulnerability is simple and made possible by how Microsoft Windows checks digitally signed MSI installers (*.msi files). When it comes to MSI files, the Windows signature validation utility reads only the first few bytes of an MSI file to check if it’s valid, and then looks at the signature appended at its end to confirm it’s authentic. Any data bundled with the file between these points is ignored.

This may not initially seem problematic as the digital signature authentication is working in the context of the MSI archive. Issues arise when this file is present in an archive. For example, if a ZIP file contains an MSI file (first) followed by another file, Windows signature validation reading the first few bytes of the ZIP sees the MSI, checks its signature, and ignores the rest. Consequently, the entire ZIP will appear to be digitally signed by the same organization regardless of how many other files it contains.

JAR files are archives, too, with a structure similar to the ZIP format. These JARs contain Java class files and resources (images, texts, etc.) that can be run by a bytecode interpreter, such as the Java runtime virtual machine (JVM).

Interestingly, while Windows signature validation of MSIs takes places from top to bottom and ignores anything appended to the MSI, JVM runs JAR files reading them from bottom to top. In other words, if a JAR archive contains a legitimately signed MSI followed by a nested malicious JAR file at the end, the JVM will run the malicious JAR first, whereas the Windows operating systems will see the digital signature of the MSI and nothing afterwards.

CSO   >   Signature spoofing vulnerability exploit in Windows 10 [infographic / diagram] CSO / IDG

By exploiting this technique, an attacker has passed off malicious code as authentic. Right-clicking on the combined JAR that contains a valid MSI signed by Google, Inc., for example, and a malicious (nested) JAR would display the MSI’s (Google’s) digital signature in Windows.

How to defend against code-signing attacks

Code-signing attacks come in multiple types and classes, each requiring their own detection and remediation methods. “With certificate cloning attacks, for instance, you can detect this class of attack with Sigcheck and prevent non-admins from installing root certificates by setting the HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots\Flags registry value,” explains Matt Graeber, director of threat research at Red Canary.

Regularly monitoring registry key changes can also highlight cases of code signing. “Another class of attack, subject interface package and trust provider hijacking, is detected by monitoring for registry modifications an attacker would have to be running elevated to carry out this attack. These are just two examples of code-signing attacks,” adds Graeber.

The Microsoft Windows code-signing flaws exploited in the wild are similar to another issue (CVE-2019-1163) around how CAB files are validated, Graeber says. “The way to prevent this attack is to apply the patch. After patching, Windows will no longer validate these files as having valid signatures. VirusTotal will also report invalid signatures for these files. For example, here’s an MSI that was found in the wild that VirusTotal now marks as invalid. After applying the patch, Windows also indicates that there is a hash mismatch which can be validated with Sigcheck or Get-AuthenticodeSignature in PowerShell.”

The conventional advice to install and stay up to date with the latest Windows updates remains. Security updates released by Microsoft for CVE-2020-1464 went into multiple Windows 10 builds. Users should install these latest updates to safeguard their systems against these spoofing vulnerabilities.

Because code-signing vulnerabilities keep evolving, future iterations of these flaws should also be considered when drafting detection strategies. Validation rules can be put in place to not only check digital signatures but particulars of a portable executable (PE) file.

“As for detection of future attempts, one could rely upon detecting PE abnormalities. For example, you can calculate the expected size of a signed file by parsing the PE header signature info in the optional header. If it was determined that overlay data existed beyond the expected file size, then that file could be considered suspicious,” says Graeber.

Copyright © 2020 IDG Communications, Inc.

Subscribe today! Get the best in cybersecurity, delivered to your inbox.