CWE-295: Improper Certificate Validation

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

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based, Mobile
Parent weaknesses: CWE-287, CWE-287

Consequences:
  - Integrity: Bypass Protection Mechanism

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           

Mitigations:
  - [Architecture and Design] 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.

Demonstrative examples:
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.
if ((cert = SSL_get_peer_certificate(ssl)) && host) foo=SSL_get_verify_result(ssl); 
                      if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo)) 
                         
                            
                            // certificate looks good, host can be trusted

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.
cert = SSL_get_peer_certificate(ssl); if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) { 
                         
                            
                            // do secret things 
                            
                         
                      }

Real-world examples:
  - CVE-2019-12496: A Go framework for robotics, drones, and IoT devices skips verification of root CA certificates by default.
  - CVE-2014-1266: Chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-56
  - CVE-2021-22909: Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firm
  - CVE-2008-4989: Verification function trusts certificate chains in which the last certificate is self-signed.
  - CVE-2012-5821: 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)