SecureBlackbox 16: Security Advisory: On the version fallback vulnerability in SSL/TLS implementations (Moeller/Duong/Kotowicz POODLE attack)

Introduction

In late September 2014, a new attack on the SSL/TLS protocol was recognized and described by security researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz. The report of the attack gained high popularity in the news and raised concerns about its applicability to various network environments.

Background

The authors' description of the POODLE attack brings attention back to the last year’s sensational BEAST attack, essentially binding the discovered vulnerability with the latter. Yet, even though the new attack looks fairly serious and might produce really bad results for the affected parties, it would not be correct to collate POODLE and BEAST, as both attacks have different targets, use different methods, and exploit different vulnerabilities. What we can say for sure about the relations between those two is that POODLE can be used to prepare the environment to conduct BEAST.

The history of the SSL/TLS protocol is comprised of five versions: SSL 2.0 (the oldest and least secure), SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2 (the most recent and secure). TLS 1.1 and TLS 1.2 are the only versions that are considered secure today. Yet, due to the internet’s heterogeneous nature, a certain proportion of servers are still running older versions of SSL/TLS. Even though that proportion is negligible and primarily specific to close corporate environments, its presence pulls a prank on those client implementations that put compatibility as their priority.

The problem is that a lot of older servers did not implement a well-defined mechanism of reporting version incompatibility to newer clients. Many SSL 3.0 servers went as far as silently closing the connection upon receiving a client hello message (a special TLS message sent by the client, essentially meaning an invitation to set up a secure connection) offering an unrecognized protocol version.

Due to the above specifics, a majority of newer clients implement the following SSL/TLS negotiation scheme (the "downgrade dance"). First, they try to connect with the most secure version they support (e.g., TLS 1.2). If their connection request is accepted and then immediately rejected by the server without any apparent reason, they consider the server to be one of those medieval sentinels that don’t handle TLS 1.2 correctly. These clients then go ahead and try their chances with a lower version (TLS 1.1). In the case of a further failure with TLS 1.1, they keep on trying, eventually ending up with SSL 3.0 or even SSL 2.0.

What would an attacker do if he or she could intrude into the client-server SSL/TLS communications? Listen on the pipe for the SSL/TLS client hellos, terminating connections on encountering a TLS 1.2 or TLS 1.1 hello. Insecure SSL 3.0 connections would be given a green light.

As you can see, this attacker's behavior, from the client's point of view, is fairly consistent with that of older SSL servers. As a result, after failing to connect with TLS 1.2 and TLS 1.1, the client will probably make another try with a lower protocol version -- the attacker can then use a different attack to exploit some vulnerability in that lower protocol version. Again, this might be a BEAST attack, or might as well not be.

So, POODLE itself does not actually exploit a protocol vulnerability. Instead, it exploits a common practice in the SSL/TLS protocol version negotiation approach, reasoned by the need to achieve maximal compatibility with older implementations. After successful enforcement of the negotiation of an older, insecure, protocol version, BEAST, or any other attack, is conducted.

Who is affected

You are affected if your application uses the above method (trying versions in descending order one after another) for negotiating secure connections with older servers. You may also be vulnerable to BEAST if you use SSL 3.0, or if you use TLS 1.x with CBC cipher suites, and if your application supports the uncontrolled establishment of user-initiated HTTPS requests.

What to do

The most straightforward way to deal with POODLE is to disable anything below TLS 1.0 and do not even attempt to negotiate SSL 2.0 and SSL 3.0 versions. For those implementations that have reasons to use SSL 3.0, a special protocol mechanism (Fallback Signaling Cipher Suite Value) was introduced and is currently being integrated into SSL/TLS software around the globe.

Please also read our BEAST advisory on how to deal with BEAST.

Summary

This summary concerns the POODLE approach only and does not cover the ‘associated’ BEAST attack.

Attack type: man-in-the-middle attack exploiting vulnerabilities in application protocol use practices

Attack application point: SSL/TLS client

Attack goal: protocol version fallback

Attack criticality: medium

Attack techniques: sniffer