COMMON WEAKNESS ENUMERATIONDraft

CWE-296

Improper Following of a Certificate's Chain of Trust

The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate.

Abstraction

Base

Structure

Simple

Likelihood of Exploit

Low

Understand the problem

What is the problem?

The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate.

Extended description

There are several ways in which the chain of trust might be broken, including but not limited to: - Any certificate in the chain is self-signed, unless it is the root. - Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate. - An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions. - The root certificate has been compromised or authorized to the wrong party.

Root cause

How and when does the problem arise?

Lifecycle phase

Implementation

When the product uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.

Lifecycle phase

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.
The trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate. In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the product receives a certificate at the end of one of these trust chains and then proceeds to check only the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.

Risk

What does successful exploitation lead to?

Hide Activities

Affected security scopes: Non-Repudiation

Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.
Gain Privileges or Assume IdentityExecute Unauthorized Code or Commands

Affected security scopes: Integrity, Confidentiality, Availability, Access Control

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

Defence

How is it prevented and fixed?

Architecture and Design

Architecture and design approach

Detail
Ensure that proper certificate checking is included in the system design.

Implementation

Implementation-phase defence

Detail
Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.

Implementation

Implementation-phase defence

Detail
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.

Verification

How is it detected?

Automated Static Analysis

High
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.)

MITRE diagram

Weakness relationships and flow

CWE-296 MITRE diagramı