Summary

A vulnerability that has been present in Windows for the past ten years is actively exploited in the wild by cybercriminals to make executables appear legitimately signed. The issue stems from a 2013 flaw known as the "WinVerifyTrust Signature Validation Vulnerability," which Microsoft made an optional fix for due to the potential for it to invalidate legitimately signed files that stored data in an executable's signature block. As a result, the vulnerability still exists and can only be fixed by manually editing the Windows Registry. Even worse, the fix is removed after upgrading to Windows 11, making devices vulnerable once again. The vulnerability has been exploited in last week’s attacks, including the 3CX supply chain attack, and a Zloader malware distribution campaign in January. While enabling the fix may cause issues with certain installers, the added protection is worth the inconvenience. Microsoft has not yet responded to inquiries about this continued abuse of the flaw and the opt-in nature of the fix.

How to leverage CODA Footprint's capabilities to disarm attack kill chains before they become public

CODA Footprint’s unique Real-Life Exploit Validation engine, fueled by Cortex ® was able to accurately score the vulnerability’s real exploitation risk based on the actual registry settings as presented below, before it was even exploited in the wild. Once this was exploited in the wild, Cortex® picked it up and automatically upgraded its CRSS attributes to reflect its weaponization and utilization within the 3CX active threat campaign. Please be aware that an upgrade to Windows 11 is going to reset the registry keys, and make the vulnerability exploitable again, even if the system has been fully patched. Therefore, continuous monitoring and real-time alerting is highly encouraged for all customer environments.

Full Attack Story

10-year-old Windows vulnerability exploited in the wild

A 10-year-old Windows vulnerability is being exploited in attacks to make it appear that executables are legitimately signed, with the fix from Microsoft still "opt-in" after all these years. Even worse, the fix is removed after upgrading to Windows 11.

On Wednesday night (the 29th of March 2023), news broke that VoIP communications company 3CX was compromised to distribute trojanized versions of its Windows desktop application in a large-scale supply chain attack.

As part of this supply chain attack, two DLLs used by the Windows desktop application were replaced with malicious versions that download additional malware to computers, such as an information-stealing trojan.

One of the malicious DLLs used in the attack is usually a legitimate DLL signed by Microsoft named d3dcompiler_47.dll. However, the threat actors modified the DLL to include an encrypted malicious payload at the end of the file.

Even though the file was modified, Windows still showed it as correctly signed by Microsoft.

Modified DLL seen as having a valid signature
Source: BleepingComputer

Code signing an executable, such as a DLL or EXE file, is meant to assure Windows users that the file is authentic and has not been modified to include malicious code.

When a signed executable is modified, Windows will display a message stating that the "digital signature of the object did not verify." However, even though we know that the d3dcompiler_47.dll DLL was modified, it still showed as signed in Windows. The DLL is exploiting the CVE-2013-3900 flaw, a "WinVerifyTrust Signature Validation Vulnerability."

Microsoft first disclosed this vulnerability on December 10th, 2013, and explained that adding content to an EXE's authenticode signature section (WIN_CERTIFICATE structure) in a signed executable is possible without invalidating the signature.

For example, researcher Will Dormann explained in a couple of tweets that the Google Chrome installer adds data to the Authenticode structure to determine if you opted into "sending usage statistics and crash reports to Google." When Google Chrome is installed, it will check the authenticode signature for this data to determine if diagnostic reports should be enabled.

Microsoft ultimately decided to make the fix optional, likely because it would invalidate legitimate, signed executables that stored data in the signature block of an executable.

"On December 10, 2013, Microsoft released an update for all supported releases of Microsoft Windows that changes how signatures are verified for binaries signed with the Windows Authenticode signature format," explains Microsoft's disclosure for the CVE-2013-3900.

"This change can be enabled on an opt-in basis."

"When enabled, the new behavior for Windows Authenticode signature verification will no longer allow extraneous information in the WIN_CERTIFICATE structure, and Windows will no longer recognize non-compliant binaries as signed."

It is now close to ten years later, with the vulnerability known to be exploited by numerous threat actors. Yet, it remains an opt-in fix that can only be enabled by manually editing the Windows Registry.

To enable the fix, Windows users on 64-bit systems can make the following Registry changes:

Windows Registry Editor Version 5.00  
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config]   
"EnableCertPaddingCheck"="1"

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] 
"EnableCertPaddingCheck"="1"

Once these Registry keys are enabled, you can see how differently Microsoft validates the signature in the malicious d3dcompiler_47.dll DLL used in the 3CX supply chain attack.

To make matters worse, even if you add the Registry keys to apply the fix, they will be removed once you upgrade to Windows 11, making your device vulnerable again.

As the vulnerability has been used in recent attacks, such as the 3CX supply chain and a Zloader malware distribution campaign in January, it has become clear that it should be fixed, even if that inconveniences developers.

Unfortunately, most don't know about this flaw and will look at a malicious file and assume it's trustworthy as Windows reports it as being so.

"But when a fix is optional, the masses aren't going to be protected," warned Dormann.

I enabled the optional fix, used the computer as usual throughout the day, and did not run into any issues that made me regret my decision.

While this may cause an issue with some installers, like Google Chrome, not showing as signed, the added protection is worth the inconvenience.