• Trend Micro
  • About TrendLabs Security Intelligence Blog
Search:
  • Home
  • Categories
    • Ransomware
    • Vulnerabilities
    • Exploits
    • Targeted Attacks
    • Deep Web
    • Mobile
    • Internet of Things
    • Malware
    • Bad Sites
    • Spam
    • Botnets
    • Social
    • Open source
Home   »   Vulnerabilities   »   Denial of Service Attacks Possible with OpenSSL Vulnerability CVE-2015-1787

Denial of Service Attacks Possible with OpenSSL Vulnerability CVE-2015-1787

  • Posted on:April 15, 2015 at 2:05 pm
  • Posted in:Vulnerabilities
  • Author:
    William Gamazo Sanchez (Vulnerability Research)
0

On March 19 we wrote about how OpenSSL disclosed and fixed 13 vulnerabilities to address several security holes. Among the vulnerabilities addressed was CVE-2015-1787, which can result in a complete denial of service on an application compiled with OpenSSL library. This blog post will tackle how the bug can be exploited, and how Trend Micro can protect against future possible attacks.

CVE-2015-17187 also affects several protocols, including SSL/TLS and DTLS, which we will analyze in this entry.

Vulnerability description

The vulnerability is rooted in the method ssl3_get_client_key_exchange implemented in the file s3_srvr.c. This method processes the SSL/TLS Client Key Exchange Message. When ssl3_get_client_key_exchange is called, it will do a group of decisions and checks based on the length of the Client Key exchange message.

The length of the Client Key exchange message can be controlled by the attacker independent of the content of the message. A portion of ssl3_get_client_key_exchange in Figure 1.

The analysis was performed using the standard OpenSSL commands configuring it as a server and client. At the point of the function call at ssl3_get_client_key_exchange we have the following call graph:

Figure 1. ssl3_get_client_key_exchange call graph.

The following image shows the section where the Client Key exchange message length is calculated and stored in the variable n.

Figure 2. Client Key Exchange Message length in n

Note that if n==0 the method will continue the execution because this can be a valid case according to the TLS specification. This occurs when the client is sending a certificate containing a static DH exponent, and is mentioneded in section 7.4.7 of RFC5246, which we will tackle later on.

The next important critical section of the method is shown in the following image:

Figure 3. ssl3_get_client_key_exchange vulnerable code section

From the previous image we can see the vulnerable section of code inside of ssl3_get_client_key_exchange where the following preconditions are necessary:

  • The algorithm alg_k needs be of type SSL_DHE. When this condition is valid, the variable skey will never be assigned to a valid key.
  • If n == 0 then the DH parameters are taken from the client certificate. However, this is a valid action only if the algorithm is of type SSL_kDHr or SSL_kDHd.
  • The final precondition is that value s-session-peer contains a valid certificate. This is the case when the client certificate authentication is present.

If these preconditions are valid, then the call to EVP_PKEY_cmp_parameters will crash the application because does not check if skey is null before accessing it.

This vulnerability rated with a “moderate” severity because it requires client authentication because the session must have a client certificate before the EVP_PKEY_cmp_parameters is called. The following section shows the real attack scenario.

Attack Delivery Mechanisms

As mentioned earlier, this CVE affects both SSL/TLS and DTLS. While the attack is very similar in both cases, in DTLS it is slightly different as DTLS implements message fragmentation at SSL Level. First, we will explain SSL/TLS and later DTLS.

SSL/TLS Attack Delivery

This vulnerability can be exploited if the attacker has access to a valid authentic certificate or can modify the traffic using a man-in-the-middle (MITM) attack. Only one byte needs to be altered: the client key exchange length. The following traffic capture shows a real attack traffic pattern:

Figure 4. Attack over TLS

In this scenario the attacker established a TLS version 1.2 session with the Client Key Exchange Length equal to 0. The algorithm used during the session was DHE-RSA-DES-CBC-SHA and from pcap we can see the client certificate sent to the server.

DTLS Attack Delivery

The method ssl3_get_client_key_exchange is also called from dtls1_accept. The following image shows the call graph of ssl3_get_client_key_exchange in DTLS.

Figure 5. DTLS ssl3_get_client_key_exchange.

The DTLS implementation uses the same ssl3_get_client_key_exchange but a successful attack requires changes to a different field in the protocol. If we change the client key exchange length (as we did for SSL/TLS), the attacks fails. This is because DTL implements a fragmentation mechanism at the SSL level where one SSL message can be split in several UDP packets (as specified in RFC4347). To be effective, the attack needs to reset to zero. The fragment length is shown as the following:

Figure 6. Attack over DTLS

Conclusion

CVE-2015-1787 has moderate impact and requires a valid client certificate. However, attacks can be implemented using MITM by changing only one byte, and the vulnerability affects both protocols SSL/TLS and DTLS. Patched versions of OpenSSL are now available.

To protect our customers, Deep Security for Web Apps scans and detects vulnerabilities and protects web applications via a single integrated solution. Additionally, we have published the following Deep Security rules, which we urge customers to apply as soon as possible:

  • 1006621 – OpenSSL Client Authentication Handler ClientKeyExchange Message Denial Of Service Vulnerability (CVE-2015-1787)
Learn how to protect Enterprises, Small Businesses, and Home Users from ransomware:
ENTERPRISE »
SMALL BUSINESS»
HOME»
Tags: CVE-2015-1787denial of service attacksOpenSSL

Security Predictions for 2020

  • Cybersecurity in 2020 will be viewed through many lenses — from differing attacker motivations and cybercriminal arsenal to technological developments and global threat intelligence — only so defenders can keep up with the broad range of threats.
    Read our security predictions for 2020.

Business Process Compromise

  • Attackers are starting to invest in long-term operations that target specific processes enterprises rely on. They scout for vulnerable practices, susceptible systems and operational loopholes that they can leverage or abuse. To learn more, read our Security 101: Business Process Compromise.

Recent Posts

  • Our New Blog
  • How Unsecure gRPC Implementations Can Compromise APIs, Applications
  • XCSSET Mac Malware: Infects Xcode Projects, Performs UXSS Attack on Safari, Other Browsers, Leverages Zero-day Exploits
  • August Patch Tuesday Fixes Critical IE, Important Windows Vulnerabilities Exploited in the Wild
  • Water Nue Phishing Campaign Targets C-Suite’s Office 365 Accounts

Popular Posts

Sorry. No data so far.

Stay Updated

  • Home and Home Office
  • |
  • For Business
  • |
  • Security Intelligence
  • |
  • About Trend Micro
  • Asia Pacific Region (APAC): Australia / New Zealand, 中国, 日本, 대한민국, 台灣
  • Latin America Region (LAR): Brasil, México
  • North America Region (NABU): United States, Canada
  • Europe, Middle East, & Africa Region (EMEA): France, Deutschland / Österreich / Schweiz, Italia, Россия, España, United Kingdom / Ireland
  • Privacy Statement
  • Legal Policies
  • Copyright © Trend Micro Incorporated. All rights reserved.