Question Possible to abuse the sections in which are excluded from signature check in a signed executable?

[Hormoz]

Microsoft allows you to sign an executable, and has a list of certificates to validate those signatures.

However it is possible to change the data on a file, while still passing the signature check, allowing you to add or change data in certain parts of it.

Does this pose any security risk?

Quoting from an old blog post (which is still relevant):

However three areas of a PE executable are excluded from the hash computation:

the Checksum in the optional Windows specific header: 4 bytes.

the Certificate Table entry in the optional Windows specific header: 8 bytes.

the Digital Certificate section at the end of the file: variable length.

You should be able to change those area without breaking the signature. I have discovered by accident that it is possible to append an arbitrary amount of data at the end of the Digital Certificate. The data are ignored by both the signature parsing and hash computation algorithms. It works on all version of Windows I tested (2000, XP, Vista), as long as the length of the Certificate Table is correctly increased. The length is stored in two different location: the PE header and the beginning of the certificate table.

 

[Andy Ful]

Microsoft allows you to sign an executable, and has a list of certificates to validate those signatures.

However it is possible to change the data on a file, while still passing the signature check, allowing you to add or change data in certain parts of it.

Does this pose any security risk?

Quoting from an old blog post (which is still relevant):

It is possible. There is also a tool somewhere on GitHub, that can do it. But, it does not mean that the malicious code can be executed by the abused executable. The attacker can only hide the malicious code in the abused executable, similarly to hiding the code in a picture, plain txt file, etc. Something else must be used to decode/read/execute the malicious code.

 

[struppigel]

Microsoft allows you to sign an executable, and has a list of certificates to validate those signatures.

However it is possible to change the data on a file, while still passing the signature check, allowing you to add or change data in certain parts of it.

Does this pose any security risk?

Quoting from an old blog post (which is still relevant):

Yes, it is a security risk. Sadly, many legitimate installers abuse this to add tracking info, settings or other things into certificate structures, so they do not have to sign every single file.
We had a case here in this thread: Need Advice - Glasswire's SHA-256 hash doesn't match the one listed on their website

Some software vendors put download URLs into the certificate structure. That is the worst case because malware authors can change this download URL into a malicious one and the file will still be valid and happily download malware.

Validly signed executables are often excluded from antivirus detection signatures if they are assumed to be from a trusted source. E.g. if the publisher is Microsoft, it is seen as a trusted source.

Another abuse case happened in the 3CX SmoothOperator supply chain attack. That one uses the tool from github and embedds encrypted malware code into the legitimate file. The file here works as a carrier for the malware, similar to a smuggler. It needs a second component to decrypt and execute the data. But it has the advantage that the actual malicious code is never on disk and the decryption code itself is small and not that suspicious.
Explained in detail in this video:


A good technical blog post about this topic is here: Caveats for Authenticode Code Signing - IEInternals - Site Home - MSDN Blogs

 

[Andy Ful]

It would be possible (I think) to find benign executables that use URLs embedded into the certificate structure (without breaking it) to download/execute benign applications. The most probable candidate would be an online installer. In this way, one can sign one executable and modify the URL to obtain many online installers (no need to sign them again).
By abusing the URL, the attacker could make the benign online installer into a signed trojan downloader.
Anyway, I did not see such an attack technique in the wild (for a couple of years).
Here is some info from the year 2013:

Today, with MS13-098, as described above, the Windows team has added additional hardening and mitigation in order to detect this kind of bad practices and report an invalid Authenticode signature. When enabled, these hardening measures will detect cases where additional unverified data has been placed after the PKCS #7 blob in the certificate directory of a PE image. The check validates that there is no non-zero data beyond the PKCS #7 structure. Although this change prevents one form of this unsafe practice, it is not capable of preventing all such forms; for example, an application developer can place unverified data within the PKCS #7 blob itself which will not be taken into account when verifying the Authenticode signature. However, as this blog post illustrates, developers are strongly discouraged from doing this as it can lead to unsafe application behavior and could potentially put the reputation of the signing company at risk if their application makes use of the unverified data in an unsafe way.

- Ali Rahbar, MSRC engineering team

Archived MSDN and TechNet Blogs

blogs.technet.com

 

[Andy Ful]

The Authenticode signature validation was exploited in the past, for example:

Beware of a new Windows security vulnerability (MS12-024)

Beware of a new Windows security vulnerability (MS12-024)

blog.avast.com

https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Frecon.cx%2F2012%2Fschedule%2Fattachments%2F54_Signed_executables.pps&wdOrigin=BROWSELINK

Uncovering and Disclosing a Signature Spoofing Vulnerability in Windows Installer: CVE-2021-26413

Okta Security has discovered and disclosed a new bypass in Windows Installer (MSI) Authenticode signature validation that could allow an attacker to disguise an altered package as legitimate software.

sec.okta.com

Some exploits were patched only after two years.

 

[Andy Ful]

Does this pose any security risk?

The sources presented in this thread show that Authenticode signature validation is not perfect (by design), so it can pose a security risk:

1. It was exploited in the past and probably still can be exploited in the future. The exploit could run the malicious code embedded in the signed executable.
2. In some cases, it can be abused to make a trojan downloader.
3. In some cases, it can be abused to download the malware.
4. It can be easily abused to hide the malicious code.

The potential security risk can be high (especially via point 1), but such attacks are very rare.
The scenarios via points 2-3 are probably uncommon, because I did not see such attacks for several years.
The scenario from point 4 was well explained by @struppigel, but it makes sense only in the targeted attacks.

For home users, the real security risk of abusing Authenticode signature validation is rather low, compared to the risk of malware legally signed by the attacker, malware with a stolen certificate, or DLL hijacking via a vulnerable digitally signed program.

 

[Trident]

For home users, the real security risk of abusing Authenticode signature validation is rather low, compared to the risk of malware legally signed by the attacker, malware with a stolen certificate, or DLL hijacking via a vulnerable digitally signed program.

I am not sure also to what extent signed malware is a problem. Although for performance reasons signed malware may be almost invisible (for example excluded from antivirus scanning after one verification, whitelisted from behavioural blocking or under reduced monitoring). These are some of the ways it can bypass defences. But it is normally short-lived. It won’t take extremely long before vendors update their certificate revocation list.

The biggest problem now (although not a novel tactic) seems to be Mitre T1027 signed + inflated (padded) or just padded and placed in a password protected archive — this bypasses static analysis, emulation and many other layers effectively and prevents transmission to vendors (both from the product and from crawlers). Technologies such as CrowdStrike Falcon Sandbox, Symantec Cynic, Check Point threat emulation and Defender cloud ML are extremely effective and well researched but can’t handle files above certain size (usually 50MB).
Only once the payload is extracted in memory, certain technologies may react.
For example CozyBear have been using this tactic at least a few years now + other tactics like creating fake PirateBay dupes (pushing “movies” that were a year ago 700 mb executable), using CEO poisoning, AI-Generated YT tutorials on how to download illegal software, using certificates obtained from breaches and others. It all ends with crypto-extortion and other theft.

In the case of installers, this might be used in a highly-fragmented attack (some behavioural blockers are not great against these). But there are many other ways code can be smuggled as well.