OpenSSL CVE-2015-1793: Separating Fact from Hype

A vulnerability that allows attackers to create their malicious certificates without depending on any external and trustworthy CAs was fixed in the newest version of the open-source software OpenSSL released July 9.

Identified as CVE-2015-1793 (Alternative Chains certificate forgery) and rated with “high severity”, the vulnerability allows attackers to use certificates to produce other valid Certificates even if the signing certificate is not recognized by a Certificate Authority (CA).

Using the proof of concept (POC) provided by the OpenSSL team, along with examples tested using the OpenSSL SSL/TLS server and client applications, we decided to look further into this vulnerability.

Alternative certificate chains

Before we get into the vulnerability itself, let’s first look at how certificates work in a SSL environment. To validate a certificate a complete chain or hierarchy of certificates must be validated. If in that process some certificate in the hierarchy is missing or wrong then it is possible to initiate an alternative validation finding other certificates with the same Issuer Name. If the certificate to be validated is correctly verified using the Alternative Chain then it is trusted.

When using OpenSSL applications, clients, and server, the certificate validation process uses two main sources of certificates. One is the certificates provided by server to the client or by the client to the server in case of client authentication, the other one is the configured certificate store. OpenSSL validates the certificate chain using both sources from which a certificate chain is built.

Figure 1. Certificate validation process

The diagram above shows the scenario where the client is establishing a SSL/TLS channel with the server and server sends one of the following certificate chains in the SSL/TLS response ( A, B, and C, where A is the main SSL/TLS certificate). The client is able to create two possible certificate chains based on the server response and the Trust Storage certificates: Chain 1 and Alternative Chain. If the server cannot validate Chain 1 then the Alternative Chain is validated. Note that it is possible to build the Alternative Chain because the Issuer Name B matches with J.

That is the process to implement Alternative Chain validation. One important aspect to note is that the client must have the J certificate inside the Trust Storage, otherwise the Alternative Chain Validation process never will start.

The alternative chains certificate forgery vulnerability

The vulnerability exists in the last implementation of the Alternative Chain validation in OpenSSL, which allows the creation of a rogue certificate chain that can be successfully validated. The OpenSSL team has released a POC of the said chain, which can show how validation can be bypassed.

The POC contains six certificates and one storage labeled Roots.

Figure 2. POC setup

There are several important details to note about this chain:

The certificate Leaf is signed by the subinterCA, but there is another certificate, subinterCA-ss, which contains the same Issuer Name as subinterCA and is self-signed.
Leaf is not a certificate authorized to sign or validate other certificates. It is simply a client certificate.

Based on this premise, the attack can be implemented as the diagram below shows.

Figure 3. Exploiting the vulnerability

We can see the server sending three certificates to the client and the client will accept them as a valid certificate chains, even if the chain is broken because the Leaf certificate is a rogue one. With that configuration, the client is able to build two certificate chains as the image below shows.

Figure 4. Two certificate chains

The client side attempts to validate Chain 1 but fails and moves on to the Alternative Chain. The client builds the Alternative Chain because the certificate subinterCA-ss, in the client Trusted Storage, matches with the Issuer Name of the Leaf certificate. However, in the process of building the new chain, the client ends up tracking as if the final chain to be validated contains only one certificate.

In the image below, we can see the vulnerable code section (x509_vfy.c : X509_verify_cert()).

Figure 5. Snippet of the vulnerable code

The counter last_untrusted is reduced in the wrong place and the final value for this case will be 1. This error is critical because once the Alternative Chain is built, the validation of the chain extensions relies on the last_untrusted counter value. The actual validation happens in the section below:

Figure 6. Code snippet

Inside the method check_chain_extension(), we can see that because last_untrusted = 1, the method check_chain_extension() returns as true, with all the extensions in the completed chain as correctly validated.

Figure 7. Certificates are accepted as valid

Attacks Scenarios

The vulnerability affects how the certificate chain is validated, which attackers can exploit to use any kind of certificate to sign other certificates. In theory, two types of attack can be implemented:

The first is the man-in-the-middle (MITM) attack, wherein an attacker sends a malicious chain to the client. Note the same can be applicable to attack a client or impersonate it when using SSL/TLS client authentication.

Figure 8. Diagram of a MITM attack

The second type of attack involves using a rogue SSL/TLS server to implement phishing attacks. This can be done with the attacker controlling the SSL/TLS server.

Figure 9. Phishing attack by way of controlled server

Conclusion

The vulnerability allows the creation of a certificate hierarchy can be validated successfully, even when some of the intermediate certificates are not vouched by any CA. This can be exploited, which can lead to attacks, including MITM attacks.

While the vulnerability is rated as severe, the attack surface is very limited due to the following conditions:

The server and client Trust Storage must contain a certificate that must match to trigger the Alternative Chain processing.
The certification validation process can be implemented outside of OpenSSL, even when some applications use OpenSSL.
Commonly used browsers–Internet Explorer, Firefox, Safari and Chrome—do not use OpenSSL, which reduces the chances of being affected by this bug.

While popular browsers may not use OpenSSL, there are other products that do so. Developers of open source products and commercial software that rely on OpenSSL need to assess if their products are affected and apply the patch if needed.

Vulnerability protection in Trend Micro Deep Security protects systems from threats that may leverage this issue with the following DPI rules:

1006855 – OpenSSL Alternative Chains Certificate Forgery Security Bypass Vulnerability (CVE-2015-1793)
1006856 – OpenSSL Client Alternative Chains Certificate Forgery Security Bypass Vulnerability (CVE-2015-1793)

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

OpenSSL CVE-2015-1793: Separating Fact from Hype