EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SECURITY ADVISORY: On the information disclosure vulnerability in SSL 3.0 and TLS 1.0 protocols (Rizzo/Duong “BEAST” attack)

Introduction

On 23rd of September 2011 two security researchers, Thai Duong and Juliano Rizzo, have presented their web browser exploit aimed at the disclosure of information transmitted over secure HTTP sessions. Authentication cookies, which are widely used to identify the user to various e-commerce platforms, were named among potential attack goals.

Summary

The exploited protocol vulnerability is not brand new and has been pointed out far in 2004 by Bodo Möller, and later investigated further by several other researchers. Eventually, two new revisions of the protocol, TLS 1.1 and 1.2, which particularly address the vulnerability, have been developed and standardized. Still, as no real-world exploit utilizing the attacks had been ever developed, those new versions gained low popularity among vendors of SSL/TLS engines, who claimed there were “no demand” for them. For today, TLS 1.1 and 1.2 remain quite exotic; some TLS implementations even chance to misbehave and crash when the remote side offers to use TLS 1.1 or 1.2.

The attack discovered by Duong and Rizzo appears to be the first practical implementation aimed at exploiting the mentioned protocol vulnerability. The attack utilizes a bunch of smart techniques and relies on modern Web 2.0 technologies and specifics of the HTTP protocol. Still, HTTP is not the only protocol that could be affected; theoretically, similar exploits can be created for the other SSL/TLS-secured application-layer protocols, such as SMTP or POP3.

The vulnerable part of this multi-layer protocol is the confidentiality (data encryption) layer. Due to the way the CBC block cipher mode is used in SSL 3.0 and TLS 1.0, the attacker is capable of “guessing” certain pieces of data sent from the client to the server. Even though such a “guess” requires the attacker to intercept hundreds of individual SSL/TLS connections carrying fairly the same data, technologies used in modern web browsers - namely WebSockets, Java applets, Javascript/Ajax and others - can be quite helpful for them. The attacker can use one of the mentioned technologies (Duong and Rizzo used Java in their PoC) to send as many requests to the attacked service as needed to pick up the entire secret.

Suggested actions

General suggestions

Unfortunately, the only correct solution (upgrading the implementations to TLS 1.1/1.2) is hardly achievable due to low popularity of these protocols and instability of the agents that might lead to various compatibility issues. Still, some precautions can be taken. One of possible solutions would be disabling or decreasing the priority of all the CBC ciphersuites (thus only leaving RC4 enabled / prioritized). However, certain care should be taken here, as the strength of RC4 is much less than that of 3DES and AES ciphersuites. The other solution would be restricting active content (Javascript, Java applets, Silverlight, ActiveX elements) in a browser.

Suggestions for SecureBlackbox users

The vulnerability in the protocol does not affect SecureBlackbox components directly. Instead, it’s SecureBlackbox-driven applications that should be checked for their vulnerability to the attack. Your application might be vulnerable if it is a subject for all the criteria listed below:

  1. the application allows external parties to initiate SSL/TLS connections on its behalf with the use of its SecureBlackbox-driven engine,
  2. the application repeatedly inserts the same sensitive information to externally-originating requests.

Example

Assume you develop a web browser that supports Java applets. Then your application has a high risk of being vulnerable, as it allows an external party (Java applets) to initiate SSL/TLS connections to remote servers (criterion 1), and repeatedly inserts sensitive data (authentication cookies) to these requests (criterion 2).

Summary

Attack type: man-in-the-middle attack exploiting protocol and application vulnerabilities. Attack location: SSL/TLS client (mainly a browser; other options are mail agent, FTP client). Protocol versions that are vulnerable: SSL 3.0, TLS 1.0. Attack goal: application-layer secret transferred within SSL/TLS connection (e.g. cookies). Attack criticality: low to medium. Attack techniques: sniffer, automated SSL/TLS request invocation environment, HTTP code injection.

Links

You can read more about the attack by the links below:
  1. BEAST’s author blog post describing the attack.
  2. BEAST description from Eric Rescorla, the author of TLS 1.1 and 1.2.
  3. Some low-level details of the vulnerability.

Return to the list

|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!