Introduction

On September 23, 2011, two security researchers, Thai Duong and Juliano Rizzo, 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 as far back 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, were developed and standardized. Still, as no real-world exploit utilizing the attacks had ever been developed, those new versions never gained popularity among vendors of SSL/TLS engines, who claimed there was "no demand" for them. 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 several 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 other SSL/TLS-secured application-layer protocols, such as SMTP or POP3.

The vulnerable part of this multilayer 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 the attacker. 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 the low popularity of these protocols and the instability of the agents that might lead to various compatibility issues. Still, some precautions can be taken. One possible solution would be disabling or decreasing the priority of all the CBC cipher suites (thus only leaving RC4 enabled / prioritized). However, care should be taken here, as the strength of RC4 is much less than that of the 3DES and AES cipher suites. 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 the 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:

• The application allows external parties to initiate SSL/TLS connections on its behalf with the use of its SecureBlackbox-driven engine.
• 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 a mail agent or FTP client)

Protocol versions that are vulnerable: SSL 3.0, TLS 1.0

Attack goal: Application-layer secret transferred within the SSL/TLS connection (e.g., cookies)

Attack criticality: Low to medium

Attack techniques: Sniffers, automated SSL/TLS request invocation environment, HTTP code injection

Links

You can read more about the attack at 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.