Improper Following of a Certificate's Chain of Trust

Draft Base
Structure: Simple
Description

This vulnerability occurs when software fails to properly validate the entire certificate chain back to a trusted root authority. This mistake can cause the system to incorrectly trust a certificate and the resource it represents, creating a security gap.

Extended Description

A certificate's trustworthiness isn't inherent; it's derived from a verifiable chain linking it back to a root certificate you already trust. If your code only checks the first link—or skips any intermediate certificates—you haven't actually verified the chain. This is like trusting an ID card because it looks official, without checking if the issuing authority is legitimate and properly authorized the person who issued it. The chain can break in several common ways. These include accepting a self-signed certificate (unless it's the designated root), failing to validate every intermediate certificate's constraints and signatures, or relying on a root certificate that has been compromised. Each skipped check creates an opportunity for an attacker to present a fraudulent certificate that your software will incorrectly accept as valid.

Common Consequences 2
Scope: Non-Repudiation

Impact: Hide Activities

Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.

Scope: IntegrityConfidentialityAvailabilityAccess Control

Impact: Gain Privileges or Assume IdentityExecute Unauthorized Code or Commands

Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity.

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 3
Phase: Architecture and Design
Ensure that proper certificate checking is included in the system design.
Phase: Implementation
Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.
Phase: Implementation
If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the full chain of trust.
Demonstrative Examples 1

ID : DX-121

This code checks the certificate of a connected peer.

Code Example:

Bad
C
c

// certificate looks good, host can be trusted*

In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or using an Adversary-in-the-Middle (AITM) attack to modify the traffic from server to client.
Observed Examples 8
CVE-2016-2402Server allows bypass of certificate pinning by sending a chain of trust that includes a trusted CA that is not pinned.
CVE-2008-4989Verification function trusts certificate chains in which the last certificate is self-signed.
CVE-2012-5821Chain: Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA).
CVE-2009-3046Web browser does not check if any intermediate certificates are revoked.
CVE-2009-0265chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
CVE-2009-0124chain: incorrect check of return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
CVE-2002-0970File-transfer software does not validate Basic Constraints of an intermediate CA-signed certificate.
CVE-2002-0862Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
References 3
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software
Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov
25-10-2012
ID: REF-245
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
Likelihood of Exploit

Low

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Implementation
Taxonomy Mapping
  • CLASP