DROWN abuses SSL v2 to attack TLS

A fascinating new research called DROWN has uncovered a previously-unknown vulnerability in SSL v2, the first ever version of SSL that was released in 1995 and declared dead less than a year later. Even though this old version of SSL is not used much these days, it continues to be supported by many servers. The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does). The researchers estimate that up to 22% of servers could be impacted by this problem.

Disable SSL v2 everywhere now

The attack is not trivial, but can be done cheaply against high-value targets. Before you go on to learn more about it, I recommend that you first ensure your systems are not vulnerable. Fortunately, remediation is straightforward: disable SSL v2 on all servers you have. It’s as simple as that…. but I really do mean all servers. If you’ve been reusing private RSA keys (even with different certificates), disabling SSL v2 on one server is not going to help if there’s some other server (possibly using a different hostname, port, or even a protocol) that continues to support this old and crazy-vulnerable protocol version.

Impact of the generic attack

The attack is an extension of the 1998 Bleichenbacher attack that can be used to decrypt a ciphertext when a padding oracle exists. For more information, I suggest that you read the original DROWN research, which is very interesting indeed. However, the bottom line is that one out of every 1,000 full TLS handshakes can be decrypted, leading to the compromise of the entire TLS session (potentially many connections of data). The cost is modest—only $440 and 8 hours. (The attack can be sped up if you want to spend more money on it. There is also a much better attack against some OpenSSL versions; I describe it later in this text.) The generic attack is entirely passive, but requires that 1) RSA key exchange is used and 2) that there is an SSL v2 server configured with the same private RSA key.

The worst case is when an automated service is attacked, anything that might be carrying connection credentials. Even though you need 1,000 full TLS handshakes, you’ll get those in a matter of hours, and the credentials will be yours to do as you’re pleased.

Attacking browser sessions is going to be more difficult, because HTTPS servers typically rely on TLS session caching as a way of improving handshake performance. A bigger problem is that user sessions rarely carry credentials; in most cases you can compromise session cookies and perform account hijacking. But that’s not bad at all!

Speeding-up the generic attack

I developed a slight improvement to the attack, for the cases when you don’t want to wait a lot of time to collect those 1,000 handshakes and don’t mind carrying out an active attack. It’s possible to speed things up by injecting some JavaScript into the victim’s browser (a-la-BEAST). You’re still up against TLS session caching, though. But TLS has an interesting property, in that it requires TLS sessions to be invalidated whenever an error occurs (e.g., client receives an invalid TLS record). Thus, as a MITM, all you need to do is force an error on established TLS sessions, causing a new full handshake on the subsequent connection. This way you can obtain the required 1,000 TLS handshakes very quickly.

Best attack variant is against vulnerable OpenSSL servers

The best attack variant is against servers that use a vulnerable version of OpenSSL. The recent versions of OpenSSL are not vulnerable because the exploited flaw had been patched (without knowing) in March 2015. But, if the conditions are right, the same SSL v2 flaw can be used for real-time MITM attacks and even against servers that don’t support the RSA key exchange at all.

Obsolete crypto is dangerous

Once again, we realise that obsolete crypto is dangerous. For many years the argument for not disabling SSL v2 was that there was no harm because no browsers used it anyway. We heard the same thing before learning about Logjam, and also before FREAK. This approach is obviously not working. Instead, in the future we must ensure that all obsolete crypto is aggressively removed from all systems. If it’s not, it’s going to come back to bite us, sooner or later.

Tags