CWE-297 Detail

The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.

Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the product is interacting with. If the certificate's host-specific data is not properly checked - such as the Common Name (CN) in the Subject or the Subject Alternative Name (SAN) extension of an X.509 certificate - it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host. In order to ensure data integrity, the certificate must be valid and it must pertain to the site that is being accessed.

Even if the product attempts to check the hostname, it is still possible to incorrectly check the hostname. For example, attackers could create a certificate with a name that begins with a trusted name followed by a NUL byte, which could cause some string-based comparisons to only examine the portion that contains the trusted name.

This weakness can occur even when the product uses Certificate Pinning, if the product does not verify the hostname at the time a certificate is pinned.

Modes Of Introduction

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.
Implementation : REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Technologies

Class: Mobile (Undetermined)
Class: Not Technology-Specific (Undetermined)

Common Consequences

Observed Examples

Potential Mitigations

Phases : Architecture and Design
Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed.
Phases : 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 Methods

Automated Static Analysis

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

Dynamic Analysis with Manual Results Interpretation

Set up an untrusted endpoint (e.g. a server) with which the product will connect. Create a test certificate that uses an invalid hostname but is signed by a trusted CA and provide this certificate from the untrusted endpoint. If the product performs any operations instead of disconnecting and reporting an error, then this indicates that the hostname is not being checked and the test certificate has been accepted.

Black Box

When Certificate Pinning is being used in a mobile application, consider using a tool such as Spinner [REF-955]. This methodology might be extensible to other technologies.

Vulnerability Mapping Notes

Justification : This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

REF-18

The CLASP Application Security Process
Secure Software, Inc..
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf

REF-245

The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software
Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, Vitaly Shmatikov.
http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

REF-243

Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith, Lars Baumgärtner, Bernd Freisleben.
http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf

REF-249

Secure programming with the OpenSSL API, Part 2: Secure handshake
Kenneth Ballard.
https://developer.ibm.com/tutorials/l-openssl/?mhsrc=ibmsearch_a&mhq=secure%20programming%20with%20the%20openssl%20API

REF-250

An Introduction to OpenSSL Programming (Part I)
Eric Rescorla.
https://www.linuxjournal.com/article/4822

REF-44

24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, John Viega.

REF-955

Spinner: Semi-Automatic Detection of Pinning without Hostname Verification
Chris McMahon Stone, Tom Chothia, Flavio D. Garcia.
http://www.cs.bham.ac.uk/~garciaf/publications/spinner.pdf

Submission

Modifications