Exploring CWE-296: Improper Following of a Certificate’s Chain of Trust￼
Digital certificates enable secure, trusted communications between systems – relying on a chain of trust back to a trusted root certification – and are the primary functions of public key infrastructure (PKI). They enable us to do everyday things like browse websites or use our credit cards safely and securely.
PKI makes it possible to validate the authenticity and integrity of data being sent over the Internet. It ties public keys to real-world identities, and these public keys can be used to validate digital signatures.
PKI infrastructure ties public keys to identities via digital certificates, but this doesn’t always work out. CWE 296 describes how validation of a digital certificate’s chain of trust can go wrong, undermining the security of PKI and digital signatures.
The Digital Certificate Chain of Trust
Digital certificates are built on a hierarchy. At the top of the stack is a root certificate authority (CA) that is entrusted with the authority to generate trusted digital certificates. This authority is delegated through a chain of intermediate CAs to create the digital certificates that are used to prove the validity of a website or sign an email.
The Chain of Trust
Many digital certificates are not directly created and validated by a root CA. Instead, they contain a chain of trust that starts with the certificate in question and ends at a root CA.
Digital signatures are created with a private key and validated with the corresponding public key. Each link in this chain of trust validates the authenticity of the public key of the entity below it.
This is accomplished via digital signatures. The root CA digitally signs data containing the public key of the intermediate CA below it. Since the root CA’s public key is known and trusted, this signature can be validated, providing proof that this intermediate CA’s public key is legitimate.
This public key is used to validate a digital signature authenticating the public key of the certificate below it, a process that repeats until the end-user certificate is reached. The purpose of this chain of trust is to validate that an end-user certificate is valid if:
- All digital signatures in the chain of trust are valid
- The root CA is authentic and trusted
Root Certificate Validity
The problem with a chain of trust like the ones used in PKI is that the chain has to have an end. While each link can validate the authenticity of the entity below it, there is no one to verify the identity of the entity at the top of the chain: the root CA.
In PKI systems, root CAs are trusted by default. Each computer has a list of trusted root CAs and their public keys. If the root CA at the end of a certificate chain is in this list and has the right public key, then they’re trusted along with any intermediate CAs and end-user certificates that they validate directly or indirectly.
Where Certificate Validation Goes Wrong
Certificate validation is essential to PKI and the validation of digital signatures. However, it can go wrong in a few different ways, including:
- Failing to Check the Chain: A certificate chain is only valid if every digital signature in the chain is valid. A single forged signature could enable an attacker to create a chain that looks good but is actually illegitimate. A failure to validate every signature in a digital certificate chain undermines the security of the entire system.
- Failing to Check Revocation Lists: Digital certificates may be revoked if they are compromised or misused. If an attacker has compromised a CA’s private key, they can generate malicious certificates using it. A failure to check certificate revocation lists for all certificates in the chain leaves an application vulnerable to this threat.
- Accepting Self-Signed Certificates: Root CAs have self-signed certificates because there is no one to validate their public keys; however, anyone can generate a self-signed certificate. Accepting a self-signed certificate from an entity not in a system’s list of trusted root CAs makes spoofed certificates possible.
Case Study: Avast and AVG AntiTrack
Avast and AVG AntiTrack are anti-tracking tools. Their purpose is to prevent websites from fingerprinting a user’s browser and computer to protect against targeted advertising. This is accomplished by proxying HTTPS traffic between the user’s computer and the server, so the proxy requests a webpage from the server on the user’s behalf.
CVE-2020-8987 addresses certificate validation issues in Avast AntiTrack before 126.96.36.199 and AVG AntiTrack before 188.8.131.52. These vulnerable versions of the software did not perform certificate validation of HTTPS sites, making it possible for an attacker to use a self-signed certificate and perform a man-in-the-middle attack to deliver phishing content to a user.
Properly Validating Digital Certificates
The goal of a digital certificate is to prove that a public key belongs to a particular entity, making it possible to validate their digital signatures. Modern PKI accomplishes this by linking an end-user certificate back to a trusted root CA via a chain of trust.
When developing an application that relies on PKI and digital signatures for security, it is vitally important to properly validate this chain of trust. This includes:
- Testing each digital signature in the chain for validity
- Checking revocation lists for each certificate in the chain
- Validating that the root CA is in a computer’s list of trusted root CAs
- Only accepting self-signed certificates from root CAs
To help build understanding of how cryptography can go wrong and how to fix it, we’ll continue to dive deep into prevention measures and most of the 29 CWEs related to OWASP’s A02:2021 – Cryptographic Failures vulnerability in a series of blogs. Each blog will describe the weakness, why it happens, a real-world case study, and recommended mitigations.
We’re very committed to improving the state of cryptography and data security by sharing knowledge and helping to correct common misconceptions about how cryptography works and how to use it properly. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog in the page footer below.
Setup is quick and easy
Ready to get started?
Create a FREE account instantly and start encrypting data or get in touch to discuss a custom package for your organization.