{"id":15129,"date":"2016-03-11T19:14:02","date_gmt":"2016-03-11T19:14:02","guid":{"rendered":"https:\/\/kasperskydaily.com\/b2b\/?p=5271"},"modified":"2019-11-15T22:54:34","modified_gmt":"2019-11-15T11:54:34","slug":"drawn-flaw","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.au\/blog\/drawn-flaw\/15129\/","title":{"rendered":"A sinkhole flaw: 33% of HTTPS connections at risk to DROWN"},"content":{"rendered":"

A massive flaw in transport layer security (TLS) protocol was\u00a0discovered<\/a>\u00a0on 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 \u2018personal\u2019 name \u2013 DROWN.<\/p>\n

Drowning the protocol<\/strong><\/p>\n

According to Threatpost<\/a>, the vulnerability was unveiled by a group of international researchers (PDF) who are calling it \u201cDecrypting RSA with Obsolete and Weakened eNcryption\u201d 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.<\/p>\n

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.<\/p>\n

Researchers said that as a consequence of \u201ca series of dumb mistakes on the part of a vast number of people\u201d, this vulnerability effectively makes TLS connections \u201cto a depressingly huge slice of the web\u201d, as well as mail servers and VPNs, open to attack by \u201cfairly modest adversaries\u201d.<\/p>\n

What is affected<\/strong><\/p>\n

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 \u2013 TLS. Both of these protocols support RSA encryption, but while TLS properly defends against certain well known attacks on this encryption, with SSlV2\u2019s \u201cexport suites\u201d it is not the case.<\/p>\n

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.<\/p>\n

The scope of the vulnerability is magnified by two outdated versions of the OpenSSL implementation that are still running on many web servers.<\/p>\n

Counteraction and downplaying<\/strong><\/p>\n

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.<\/p>\n

While stakeholders, such as Red Hat, released statements downplaying the threat of DROWN (and offering patches), OpenSSL representatives aren\u2019t that positive about the problem.<\/p>\n

\u201cThis 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,\u201d Threatpost\u2019s Steve Marquess said of OpenSSL. Marquess said people shouldn\u2019t be using SSLv2, but \u201ca huge number of websites still are.\u201d<\/p>\n

\u2018Don\u2019t make encryption too strong\u2019<\/strong><\/p>\n

The primary reason behind this faulty encryption is the two decades-old demand from US government to impose restriction on the \u2018export-grade cryptography\u2019<\/a>. In the 1990s, anyone who implemented SSLv2 was forced to build in a series of \u201cexport-grade ciphersuites\u201d that offered 40-bit session keys.<\/p>\n

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

While the U.S. government no longer requires these export restrictions, the crippled cryptography is still widely used.<\/p>\n

Other vulnerabilities such as Logjam and FREAK also rely on that weak crypto code.<\/p>\n

And again about old junk<\/strong><\/p>\n

Last year we ran\u00a0a story<\/a> on a long-deprecated RIPv1 network protocol which was used to launch a potent DDoS-attack.<\/p>\n

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.<\/p>\n

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 \u2018antique\u2019 queries. Some of those technologies can\u2019t 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.<\/p>\n

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.<\/p>\n

On March 9, Threatpost reported<\/a> DROWN to still be a sensitive\u00a0threat, as \u00a0literally \u201chundreds\u201d (well over 600, in fact) of cloud services are still at risk because of the incredibly slow pace of updating. According to some reports,\u00a098.9 percent of enterprises use at least one DROWN-vulnerable cloud service.<\/p>\n","protected":false},"excerpt":{"rendered":"

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.<\/p>\n","protected":false},"author":209,"featured_media":15313,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,2994],"tags":[816,2398,682,640],"class_list":{"0":"post-15129","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-cloud","10":"tag-drown","11":"tag-https","12":"tag-vulnerability"},"hreflang":[{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/drawn-flaw\/15129\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/drawn-flaw\/15034\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/drawn-flaw\/15129\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/drawn-flaw\/15129\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.au\/blog\/tag\/cloud\/","name":"cloud"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/15129","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/users\/209"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/comments?post=15129"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/15129\/revisions"}],"predecessor-version":[{"id":24597,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/15129\/revisions\/24597"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/media\/15313"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/media?parent=15129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/categories?post=15129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/tags?post=15129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}