Whitelisting is an exercise in building and maintaining trust-based relationships. Digital certificates provide a standardized way for an organization to implement whitelisting. However, there are many pitfalls and gotchas when those policies start being deployed in a production environment.
Throughout this series of blogs, we will examine the details of certificate processing including: the creation of secure whitelists, trust-based relationship models, certificate tampering, forgery, impersonation and more.
To start, let's discuss what exactly digital certificates are and how they can be used to create a whitelist.
Digital certificates are cryptographic documents that contain public identity information of the certificate owner. They are used to verify the origin and integrity of the message, package, application or document they are signing. Since public key cryptography is used to protect the content, we can be sure that the information within cannot be modified without breaking the encryption envelope.
Because of this, we rely on certificates to keep network communication private, and software installations trustworthy. It is therefore imperative that they are incorporated correctly into security workflows.
The simplest certificates are self-signed ones. For them, the signer vouches for the information stored in the certificate. While this is sufficient for a limited set of use cases, most real-world scenarios rely on a trusted third party to guarantee the identity of the signer. We call those third parties certificate authorities and entrust them with the task of certificate issuing based on identity validation. This way, at least in theory, we can guarantee that the person or the organization signing the content is the one with the legal right to do so.
As a result, we have the chain of trust signing the content with multiple certificates. This chain of trust starts with a certificate authority and ends with the signer.
Things only get more complex from this point, as concepts such as cross-signing and dual signing are introduced. We’ll touch upon them briefly in a bit since they are as important as the solution to the certificate time-stamping problem.
ReversingLabs solutions make use of digital certificates to enhance core file classification capabilities. Because of properties certificate have, they can be used for file whitelisting or blacklisting. Using them for classification purposes also requires maintaining a large list of trustworthy parties (which are included on the whitelist), and untrustworthy parties (which are blocked on sight).
Example of a counter-signed certificate chain visualized in ReversingLabs A1000
The list itself is extendable, with partners and customers able to customize the certificate lists based on their specific needs. Transparency is key to trust-based models, and it is crucial that our certificate policies can be reviewed by the organization that will rely on them.
Before we explain how to extend ReversingLabs certificate lists, we should cover the details of our code signing verification process. The following table lists all possible validation states that a digital certificate can have.
DESCRIPTION
Any digital certificate with a correct digital certificate chain confirming the integrity of the file it is signing. Since code signing certificates include a hash of the file they are signing, ReversingLabs validates it, and only if there is a match, it is declared that the file is validly signed.
DESCRIPTION
Any digital certificate with a correct digital certificate chain that fails validation due to the code signing hash mismatch.
DESCRIPTION
Any valid digital certificate issued by a certificate authority not present in the ReversingLabs certificate store. To be explicit about which certificates can be trusted and used for whitelisting, we embed the list of trusted certificate authorities within our products. Only those certificate authorities are trusted to implement identity validation correctly, which is why our whitelisting requirements are strict and can be relied upon. If necessary, any of our partners and customers can view and modify the certificate store based on their needs.
DESCRIPTION
Any digital certificate with an incomplete or damaged digital certificate chain. These are generally caused by incomplete file transfers when the file is truncated before the whole certificate has been copied from source to destination.
DESCRIPTION
Any valid digital certificate signed by the same entity whose identity it certifies. The information within these kinds of certificates cannot be trusted, as no one has verified its accuracy.
DESCRIPTION
Digital certificates are issued with expiration in mind. They have hardcoded limits to reduce any possible negative exposure due to certificate misuse or loss. Since code signing takes place outside of the certificate authority domain, every certificate authority offers a special timestamping service which only guarantees that the signing has taken place while the certificate was valid and non-expired.
DESCRIPTION
Any valid and trusted digital certificate that has been explicitly revoked by the certificate authority which has issued it. Revocation usually happens due to certificate misuse or loss. Most certificates include an address of a remote server that is used to check if the certificate is still valid or if it has been revoked by the issuer.
DESCRIPTION
Any valid and trusted digital certificate that has been added to the internal certificate whitelist.
DESCRIPTION
Any valid digital certificate that has been added to the internal certificate blacklist.
Trust is an inherent property of a relationship between two or more different parties. An organization can opt to trust another organization, and use this trust to make policies that correspond to rules for running software or opening documents signed by the trusted party. In this type of trust model, identity validation is the most important factor. ReversingLabs enables its partners and customers to define such relationships with certificate whitelisting.
There are two types of certificate whitelisting procedures supported today: loose and strict. The difference between loose and strict is determined by the type of information used to guarantee the certificate is the one intended to be whitelisted. While both are equally valid, it is strongly recommended that certificate whitelisting is performed via strict whitelisting. All certificates included in ReversingLabs solutions are exclusively using the strict whitelisting method.
What information is used to whitelist certificates? Moreover, what is a strict whitelisting method? The following table lists the requirements.
| OPTION | DESCRIPTION |
| Certificate common name | This is the most basic information about the signer. It is commonly used to declare the name of the organization or a subject who is signing the file. For loose whitelisting purposes, this can be the only information provided. This way the user can whitelist all certificates a trusted party has issued without worrying about the other certificate property specifics. The certificate still needs to be issued by a certificate authority in the certificate store. This reduces the risk that an untrusted authority can issue the certificate with the same common name. |
| Certificate serial number | Serial numbers are pseudo-random generated numbers with a length of at least 64 bits. Because of this, they can be used in one of two ways: 1) as a complement to the common name (to better define the certificate to whitelist); or 2) as a single piece of information (to specify the certificate to whitelist). Both options still represent the loose way of whitelisting. Adding the serial number with the common name enables the whitelisting process for more targeted loose whitelisting. |
| Thumbprint | Strict whitelisting is enforced by whitelisting with a certificate thumbprint. This is a SHA256 hash (digest) of the digital certificate. The digest includes the whole digital certificate, thus covering both the certificate common name and its serial number. Both are still listed in the whitelist as a reference for the list maintainer. This is the most secure way to whitelist certificates. By specifying the certificate thumbprint, it is ensured that no parameter of the certificate can be changed, with the intent to whitelist that single certificate with all of its intended uses. |
| Certificate timestamping | Certificates can be misused or stolen at any point in time. This makes for an unpleasant situation where it must be decided if the whole certificate is not to be trusted, or if the old files that were signed before the incident can still be safely used. Users are enabled to do just that - limit the scope and still consider the certificate to be trusted. This information is called the last valid timestamp, and everything signed before that time can still be whitelisted. There is, however, a caveat in this case. Since ReversingLabs limits the trustworthiness of the certificate by time, assurance that the time is correct is a must. Therefore, an additional requirement is that the file must be counter-signed by the certificate authority’s timestamping service. Picking the right time to limit whitelisting is crucial for this process. It is common to use the certificate revocation date as the last valid timestamp, but that is not the best way to limit the certificate trust. Revocation does occur after the breach, and it is possible that the certificate has already been misused. Because of that, whenever possible, the last valid timestamp should be the one that refers to a date when the first misused certificate has been seen in the wild. ReversingLabs uses the last valid timestamp only when a big software vendor experiences a breach, and the old signed files are proven to be clean. |
| Trust factor | A measure of how trusted the certificate signer is within the organization. This is a discrete scale which is implemented in the following ranges: [0, 1] - Highly trusted parties. Biggest software vendor companies. [2] - Common shareware parties with proof of an SDLC process and AV scans. [3, 4] - Individual software developers with good or decent release record. [5] - Supported value, but unused because it signifies the worst possible trust. The lower the trust factor value, the more reputable the certificate issuer is considered to be. |
Blacklisting uses the same set of parameters as described above. The only difference is the assigned factor. For blacklisting, ReversingLabs uses the threat factor, which describes the severity of the threat posed by the signed content. The higher the threat factor value, the bigger impact the threat can have on the organization.
Blacklisting can also be loose or strict. However, when trying to blacklist the offending party, loose blacklisting can be relied on to cover as many files as possible. Any certificate, including the self-signed ones, can be blacklisted. It is, however, impractical to blacklist self-signed certificates, as the signer can simply generate new ones. The only exception to this would be self-signed certificates found in online stores that guarantee the certificates won’t be changed frequently.
Maintaining the list of whitelisted and blacklisted certificates can be a very daunting task. ReversingLabs sees over 500,000 new and unique valid signed files every single day, most of which are signed with an already known certificate. The ones that are not known need to be analyzed and put on the appropriate list, if any.
However, this process can be automated. ReversingLabs has built a highly effective solution that hunts for anomalies and alerts our analysts when a certificate is an impersonation attempt, a complete certificate forgery, or a supply chain attack. Throughout this series of blogs on the topic of certificates, we will explore different certificate attack vectors, the details of our certificate hunting system and the results it delivers.
This article is the 1st part of our Digital Certificates series of blogs. Read other blogs in this certificate series:
- Blog 2: Trust-based models in the age of supply chain attacks
- Blog 3: Tampering with signed objects without breaking the integrity seal
- Blog 4: You are you, but so am I - certificate impersonation
- Blog 5: Subverting trust with digital counterfeits
- Blog 6: A new kind of certificate fraud: Executive impersonation
