In some shocking news it has been discovered that the 3cx attack occurred due to a 10 year old Windows vulnerability which is still actively exploited in attacks which make it seem like executable’s are legitimately signed. Microsoft’s fix is still one that a user has to opt in for after all this time. What is worse when one upgrades to windows 11 this fix gets removed.
When 3cx was compromised at the end of march, the attack vector was the distribution of Trojan infected version of the 3cx desktop application in a massive scale supply chain attack. The windows version of the 3cx app was not the only version affected, also the mac version.
As part of the attack two weaponized DLLs used by the Windows desktop application were replaced with malicious versions that would in turn download further malware to computers such as an information stealing Trojan.
The first compromised DLL is actually a legitimate DLL signed by Microsoft d3dcompiler_47.dll. This was modified by threat actors to also include a malicious encrypted payload at the end of the file.
Even though the file was modified, it was still shown to be signed legitimately by Microsoft.
Modified DLL showing valid signature from Microsoft
Code signing of DLL’s or executables is designed in such a way to ensure Windows users that the file is an authentic one and no modifications have taken place to include malicious code.
If a signed executable is modified Windows will show a message which states, and I quote “digital signature of the object did not verify.” Even though the d3dcompiler_47.dll was modified this messages was not show, as the DLL was still showing as legitimately signed.
After speaking to Will Dormann who is a senior vulnerability analyst at ANALYGENCE, he explained that this is exploiting CVE-2013-3900 which is a flaw in “WinVerifyTrust Signature Validation Vulnerability.”
This vulnerability was disclosed by Microsoft on December 10th 2013. They explained that adding content to the executable’s authenticode signature section, the WIN_CERTIFICATE structure, in a signed executable one can do this without invalidating the signature.
Dormann in a number of tweets on his Twitter gave an example of the Google Chrome installer. This installer adds data to the Authenticode structure to determine if you opted into sending usage and crash reports to Google. When the browser is installed it checks the Authenticode signature for this info and determines if diagnostic reports should be enabled or not.
The ultimate decision that Microsoft took was to make this an optional fix. This is due to the invalidation of legitimate signed executable’s that stored data in the signature block of the executable.
Microsoft released a statement regarding this issue and it is quoted as follows:
“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.”
10 years on, the vulnerability is known to be exploited by various threat actors. Yet Microsoft still has not changed it stance on the fix as they have left it as an opt-in fix that is only enabled by editing the registry.
Set the keys as follows:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config]
“EnableCertPaddingCheck”=”1”
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config]
“EnableCertPaddingCheck”=”1”
Once the registry keys mentioned above are enabled, you notice how differently Microsoft validates the signatures of the malicious DLL used in the 3cx supply chain attack.
Malicious DLL Shown as Signed Before the Fix
Malicious DLL showing unsigned post fix
What makes this even worse is that if you apply the above registry keys to fix this critical vulnerability, once you upgrade to Windows 11 this fix is removed making ones machine vulnerable all over again.
Given that this vulnerability has been used in recent attacks such as the 3cx supply chain attack as well as the Zloader malware distribution campaign back in January 2023. This is essential that this gets fixed even though it inconveniences developers.
What is more shocking is that most developers are not aware of this flaw and they would look at a file that is malicious and think its a trustworthy file given that windows reports it as such.
Dormann warns that even with an option fix the masses are not going to be protected.
He enabled this fix and he used the computer throughout the day without any issues in turn not regretting implementing the fix.
While this can cause issues with certain installers like Google Chrome not showing as signed, the added protection is worth the inconvenience.
On 4th April 2022 Microsoft shared the following statement with BleepingComputer about CVE:
“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,”
Reference:
Leave a Reply