LiveActive security incident?Get immediate response
CWE Reference

CWE-295: Improper Certificate Validation | Glexia

CWE-295 (Improper Certificate Validation) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.

Release 4.20weaknessDraft
Search CWECWE Dictionary

Glexia's Take · Automated analysis

CWE-295: Improper Certificate Validation

Improper Certificate Validation represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.

Executive Impact

  • Integrity Authentication: Bypass Protection Mechanism Gain Privileges or Assume Identity: When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. The product might connect to a malicious host while believing it is a trusted host, or the product might be deceived into accepting spoofed data that appears to originate from a trusted host.

Developer Pattern

CWE-295 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.

Automation confidence

high confidence from CWE-295, 4.20.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official CWE Definition

CWE-295: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

Type
weakness
Abstraction
Base
Status
Draft
Source
MITRE CWE definition

Developer And Remediation Guidance

How teams prevent and detect this weakness

Causes

  • This code checks the certificate of a connected peer. 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.
  • The following OpenSSL code obtains a certificate and verifies it. Even though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.
  • The following OpenSSL code ensures that there is a certificate and allows the use of expired certificates. If the call to SSL_get_verify_result() returns X509_V_ERR_CERT_HAS_EXPIRED, this means that the certificate has expired. As time goes on, there is an increasing chance for attackers to compromise the certificate.
  • The following OpenSSL code ensures that there is a certificate before continuing execution. Because this code does not use SSL_get_verify_results() to check the certificate, it could accept certificates that have been revoked (X509_V_ERR_CERT_REVOKED). The software could be communicating with a malicious host.
  • The following OpenSSL code ensures that the host has a certificate. Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.

Remediation

  • Architecture and Design Implementation: Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • 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 hostname.

Detection

  • Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
  • Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
  • Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner
  • Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Man-in-the-middle attack tool
  • Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections)
  • Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
  • Architecture or Design Review: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Mappings

Related CVEs, CWEs, and ATT&CK context

Related CWEs

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

Open CWE CVE mapping

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.