Code Signing: Can you trust that executable?

In order to vouch for the authenticity of an executable, a company or person can ask a Certificate Authority (CA) to verify their identity and provide them with a Code Signing Certificate.  The private keys for that certificate can then be used to prove something about the origin of an executable.  Properly signing executables and other binary files with code signing certificates using the public key infrastructure (PKI) that supports it, is a key component to establish trust when downloading and executing code.

Some users are more likely to trust a signed file, regardless of who signed it.  This has led to more and more greyware and malware being properly signed by a valid certificate. There is even a black market ecosystem to support the acquisition and sale of authentic code signing certificates. All of this is a problem but may still be okay if you don’t trust the entity that signed the file in these scenarios.

But if a private key for a certificate is lost or stolen then this undermines the chain of trust that underpins this system since an entity that is untrusted can masquerade as a trusted source.  In this situation it is critical that the certificate can be revoked properly.  There is a mechanism to revoke certificates using a Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) which are maintained by the CA and used to invalidate the trust that we might otherwise have in the certificate.

However, there are flaws and misunderstandings about how revocation works.  In a recent paper from Symantec Research Labs, in collaboration with the University of Maryland College Park, we looked at the code signing revocation process and what can go wrong. 

In the paper we analyzed the revocation process from end to end using the largest set of code signing certificates yet collected and actively monitoring the revocation lists for those certificates over a period of time to see how the revoked certificates are handled. Effective revocations rely on three tasks: (1) discovering the abused certificates, (2) revoking the certificates effectively, and (3) disseminating the revocation information for clients to see.

Table 1 highlights some of the key findings from the research, looking at what can go wrong at each stage. 

The paper assessed the challenges related to discovering compromised certificates and the subsequent revocation delays that occur. We showed that erroneously setting revocation dates causes signed malware to remain valid even after the certificate has been revoked. We also found failures in disseminating the revocations, leading clients to continue trusting some revoked certificates. 

Some key takeaways are:

• There appears to be no standard process to move from discovery to revocation, even after files that are properly signed are found to be malicious by multiple AV venders. 
• The delay between discovery and revocation is often long, on average 171 days
• Deciding the correct revocation date is a challenge because it is hard to identify the exact date when the certificate was compromised, and there is a balance between revoking trust in malicious binaries and maintaining trust in binaries that the vendor really did publish.
• Due to timestamping in the signing process, certificate revocation has to be maintained indefinitely, which is not always well understood (read the paper for more information on this topic!)

Code signing and revocation are the most effective way to handle trust in the current ecosystem and are a key component in whitelisting solutions.  However, we discovered flaws in the system that make it possible to undermine that trust.  This is one reason that anti-virus software, supported by a security vendor with robust backend systems for malware analysis, machine learning, and behavioral based detections, is an important component of a defense in depth strategy.