A 10-year-old Windows vulnerability is still 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, 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.
As first noted yesterday, even though the file was modified, Windows still showed it as correctly signed by Microsoft.
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.
After contacting Will Dormann, a senior vulnerability analyst at ANALYGENCE, about this behavior and sharing the DLL, we were told that 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, Dormann explained in 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.
Update 4/4/22: Microsoft shared the following statement with BleepingComputer about the CVE-2013-3900 vulnerability:
“The technique described requires an attacker to have already compromised the code via a third-party. As a best practice, we encourage customers to apply all the latest security updates for better protection. In addition, Defender for Endpoint and Microsoft Defender antivirus can detect and block the domains and files involved with this threat. We will continue to investigate and will take additional action as needed to help keep customers protected,” Microsoft told BleepingComputer.
Comments
fromFirefoxToVivaldi - 1 year ago
What a ridiculous situation. It should be 100% on the devs to adapt to the fix and not up to the user to decide whether to apply security measures related to certificate validity or not. At the very least it should be an opt-out measure instead.
NoneRain - 1 year ago
Totally agree. If the cert validation passes after the file has being modified, what's the point?
Winston2021 - 1 year ago
For the sake of backwards compatibility they do not fix a serious and what must be a well-known to threat actors serious back door known since 2013 (excuse me, "disclosed" in 2013), require one to manually edit the registry to fix it, eliminate it again if Win 11 is installed, and yet they require for security reasons relatively new hardware to meet the "minimum system requirements" for a Win11 installation. Right... That doesn't sound at all suspicious.
NoneRain - 1 year ago
I think they're different things.
The use of virtualized features indeed harden low level stuff. MS has being hitting this have some time, and claims Win11 changes protect the system against malware, which I believe is true if you look specifically at firmware persistent malware.
unwrap_unchecked - 1 year ago
I actually think it's overblown.
Everything described in attack can be accomplished without using the append-data-to-signature.
Bomgard puts the identifier as part of the filename. So 3CX will do that in the future too.
New campaign gets sent out, user still executes random file from the web and presses 'yes' when prompted for admin permission.
And you're done. It's over. At this moment you ARE on the other side of the airtight hatchway. You have admin privileges. Anything done AFTER after that is purely done to remain hidden for longer.
That said, let's fix the loophole, security is done in layers and this does make things harder.
fromFirefoxToVivaldi - 1 year ago
It's not as easy. Every company network I've seen with a semi-competent sysadmins had a policy completely blocking execution of unsigned executable (with a list of exemptions, because... MS is too lazy to sign all executable files which come with Windows). Having new unsigned executable is a huge red flag that immediately should send and alert the admins.
Everythingisfine - 1 year ago
I'm trying to figure out if this would have had an impact on this specific attack where it was the DLL that would have been unsigned since it's not an executable? Would the AV have treated it any differently since it's a DLL file?
Pkshadow - 1 year ago
Interestingly I do not have either of those paths in my Registry : \Wintrust\Config] notta there.
So what does that mean/// ???
Edition Windows 10 Pro Version 22H2
Installed on 2023-02-01
OS build 19045.2788
Experience Windows Feature Experience Pack 120.2212.4190.0
Tulatin - 1 year ago
That's kind of normal. With it being an opt in fix (and not having a matching group policy entry for some reason????)
Nothing would have ever created the key. Now you get to do it manually!
Please document this somewhere for people to do
cakruege - 1 year ago
Hi,
this registry key is not usefull.
osslsigncode.exe add -addUnauthenticatedBlob
https://github.com/mtrojnar/osslsigncode
shows a perfectly valid signture even if that registry key is set
greetings
Carsten
PS: Detailed description of the problem:
https://vcsjones.dev/authenticode-stuffing-tricks/