A sinkhole flaw: 33% of HTTPS connections at risk to DROWN

A massive flaw in transport layer security (TLS) protocol was discovered and it leaves millions vulnerable to an attack that could expose financial data and more.

A massive flaw in transport layer security (TLS) protocol was discovered on March 1st, which leaves millions of Internet users vulnerable to an attack that could expose passwords, credit card numbers, and other financial data. Due to the dramatic scale, the attack received its own ‘personal’ name – DROWN.

Drowning the protocol

According to Threatpost, the vulnerability was unveiled by a group of international researchers (PDF) who are calling it “Decrypting RSA with Obsolete and Weakened eNcryption” or DROWN. The attack exploits a flaw in SSLv2 that relates to so-called export-grade cryptography, a decades-old issue that continues show up.

The vulnerability can be exploited to use SSLv2 handshakes to decrypt TLS sessions. DROWN attackers can decrypt current sessions and those recorded in the past.

Researchers said that as a consequence of “a series of dumb mistakes on the part of a vast number of people”, this vulnerability effectively makes TLS connections “to a depressingly huge slice of the web”, as well as mail servers and VPNs, open to attack by “fairly modest adversaries”.

What is affected

DROWN is a cross protocol attack which makes use of bugs in one protocol implementation (SSLv2) to attack the security of connections made under a different protocol – TLS. Both of these protocols support RSA encryption, but while TLS properly defends against certain well known attacks on this encryption, with SSlV2’s “export suites” it is not the case.

And the figure behind all of this wording is quite scary: about 33% of all HTTPS servers are vulnerable to attackers who have the ability to break web browser to web server encryption and eavesdrop on data passed between the two. This amounts to ~11 million HTTPS websites.

The scope of the vulnerability is magnified by two outdated versions of the OpenSSL implementation that are still running on many web servers.

Counteraction and downplaying

On Monday, the OpenSSL released two patches that disable the SSLv2 protocol by default, as well as remove SSLv2 EXPORT ciphers. The patches include version 1.0.2g of its open source toolkit for SSL/TLS and version 1.0.1s of its open source toolkit for SSL/TLS.

While stakeholders, such as Red Hat, released statements downplaying the threat of DROWN (and offering patches), OpenSSL representatives aren’t that positive about the problem.

“This is a vulnerability that has been known for a long time in the older versions of the SSL protocol, but that combined with the backdoor vulnerability caused by export crippled cryptography,” Threatpost’s Steve Marquess said of OpenSSL. Marquess said people shouldn’t be using SSLv2, but “a huge number of websites still are.”

‘Don’t make encryption too strong’

The primary reason behind this faulty encryption is the two decades-old demand from US government to impose restriction on the ‘export-grade cryptography’. In the 1990s, anyone who implemented SSLv2 was forced to build in a series of “export-grade ciphersuites” that offered 40-bit session keys.

This effectively means that such encryption can be broken (brute-forced) over reasonable time, from under a minute to a few hours, using generally accessible computational power ranging from a modern PC to Amazon’s EC2 cloud compute service. In contrast, 128-bit session keys aren’t easily breakable.

While the U.S. government no longer requires these export restrictions, the crippled cryptography is still widely used.

Other vulnerabilities such as Logjam and FREAK also rely on that weak crypto code.

And again about old junk

Last year we ran a story on a long-deprecated RIPv1 network protocol which was used to launch a potent DDoS-attack.

Although it is deprecated for the last twenty years, more than enough devices are still responding to RIPv1 queries, which was aptly exploited by the cybercriminals.

We still use a lot of decades-old technologies on the Web, and a multitude of long-obsolete devices with profoundly flawed cybersecurity are online, responding to ‘antique’ queries. Some of those technologies can’t be dropped at once, of course, but there also totally obsolete and replaceable protocols, software, and equipment still in use. Sometimes they are a borderline cyberthreat on their own.

With DROWN we have seen the problem of deliberately degraded security (for reasons too obvious to elaborate on them), which backfired for years. But what the DROWN story clearly shows is that costs of having old, vulnerable protocols on the Internet is potentially too high.

On March 9, Threatpost reported DROWN to still be a sensitive threat, as  literally “hundreds” (well over 600, in fact) of cloud services are still at risk because of the incredibly slow pace of updating. According to some reports, 98.9 percent of enterprises use at least one DROWN-vulnerable cloud service.

Tips