Authenticode Certificate Chain Verification

Introduction

Microsoft introduced digitally signing PE object files (authenticode) in Windows 98. Hardware drivers eligible for the Windows Logo Program are required to contain a valid authenticode signature. Since then, Microsoft has expanded the program to executable object files (EXEs) and DLLs.

Microsoft has its own public key infrastructure (PKI). There are four trusted root certificate authorities: two by Microsoft, Thawte, and Verisign. Microsoft's own executables for Windows are signed.

Authenticode At Work

The Problem

It's becoming more common for malware authors to sign their executables. Malware authors are known to steal existing certificates or forge certificates (the certificate forging link talks about SSL certificates; though you can't use certificates used for web browsing with authenticode, the concept still applies). Stealing and forging existing certificates can trick unsuspecting users into trusting the malware.

The Solution

ClamAV 0.98 now parses and validates the authenticode certificates. ClamAV now ships a database of trusted and revoked certificates. If the PE file being scanned is flagged as a virus, ClamAV follows this logic in validating the certificate chain contained inside the PE file:

1. Load the chain in full
2. Validate each certificate in the chain:
1. If no certificate matches one of the four trusted roots, the whole chain is considered invalid and is subsequently ignored. Further chain processing is stopped.
2. If one certificate matches a revoked entry in the database, the whole chain is considered invalid. Report PE file being scanned is a virus.
3. If no certificates match a revoked entry in the database, the PE file is marked as clean. No virus is reported for the PE file being scanned.

Generating A Certificate Revocation Entry

Since the authenticode chain is verified only after a file has been flagged as virus by the ClamAV engine, you have to first create a signature for the file if one doesn't already exist. If a signature exists, yet the file is reported as clean, chances are that the file is being whitelisted due to having a valid authenticode signature. You can verify that the file is being whitelisted by passing --debug --verbose to clamscan and looking for the word authenicode (yes, that is indeed misspelled, but that works out to our advantage). If you see that word, then the file is being whitelisted and a certificate revocation entry needs to be created.

First, we need to dump the certificate chain so that we can find the certificate to revoke. You can tell ClamAV to dump the certificate chain to stderr by passing --dumpcerts to clamscan. You will then match the certificate that is dumped with the public key of the lowest certificate in the chain that Windows shows. Windows shows a few bytes before the public key actually starts. Don't worry, if that confuses you, I have screenshots:

Windows Certificate Information

Validating and Dumping Authenticode Certificate Information via ClamAV

Certificate revocation entries go into a .crtdb file in your ClamAV database directory. Its format is as follows: name;trusted;subject;serial;pubkey;exponent;codesign;timesign;certsign;notbefore;comment[;minFL[;maxFL]]

Where:

1. Name: a descriptive name for the certificate entry
2. Trusted: a bit field (0 or 1) whether this entry is trusted or revoked
3. Subject: the subject reported by ClamAV
4. Serial: the serial reported by ClamAV
5. Pubkey: the public key reported by ClamAV
6. Exponent: The exponent of the certificate. Set this to 010001.
7. Codesign: A bit field (0 or 1) whether this certificate can sign code
8. Timesign: A bit field (0 or 1) whether this certificate can generate a timestamp signature
9. Certsign: A bit field (0 or 1) whether this certificate can sign other certificates
10. Notbefore: The notbefore field of the certificate. Defaults to 0 if empty.
11. Comment: any comments about this entry
12. MinFL: The minimum ClamAV feature level needed for this entry. Required only if MaxFL is set.
13. MaxFL: The maximum ClamAV feature level supported by this entry

Let's return back to the example. We now have enough information to create the certificate revocation entry. It would look like: 

Descriptive name here;0;fe72355be4b6893d8e5b628d1a9ae8863d202b6f;a58d94ce010afa9865e732870971428768c92d64;ba0532ff862861cfaf8c22601fe479e3697b6ab94ff01c3254d105018c93bdb47f4c3fc1fb1d20172c46a727fb589f310cf6b081517ee472d145dfd4939c7d4652aad06c3ee6722f15703e88bbd8bc4d56fe7030b21f105fa9817b625103273caf46072628207e81bc13ac6ba18cdd3e93b97c9761730eb14ce36464cc997075;010001;1;0;0;0;

After adding that revocation entry to our certs database, ClamAV now flags the sample as a virus:

clamscan Reporting Virus