IntroductionOn 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.
SummaryThe 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.
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:
- 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.
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).
SummaryAttack 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.