nexus/sreweekly/markdown/13/04-drown-attack.md

# DROWN Attack

- **期号**: SRE Weekly Issue #13（2016-03-06）
- **作者**: —
- **链接**: https://drownattack.com/

## 简介

Everyone’s favorite OpenSSL vulnerability of the year.  I hope you all had a relatively easy patch day.

## 正文

DROWN is a serious vulnerability that affects HTTPS and other services that rely on SSL and TLS, some of the essential cryptographic protocols for Internet security. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication.

DROWN allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data. At the time of public disclosure on March 2016, our measurements indicated 33% of all HTTPS servers were vulnerable to the attack. Fortunately, the vulnerability is much less prevalent now. As of 2019, SSL Labs estimates that 1.2% of HTTPS servers are vulnerable.

Any communication between users and the server. This typically includes, but is not limited to, usernames and passwords, credit card numbers, emails, instant messages, and sensitive documents. Under some common scenarios, an attacker can also impersonate a secure website and intercept or change the content the user sees.

Websites, mail servers, and other TLS-dependent services
        are at risk for the DROWN attack.
        At the time of public disclosure,
	[many popular sites](https://drownattack.com/top-sites.html) were
        affected.  We used Internet-wide scanning to measure how many
        sites are vulnerable:

|  | Vulnerable at Disclosure (March 2016) | 
| **HTTPS — Top one million domains** | 25% | 
| **HTTPS — All browser-trusted sites** | 22% | 
| **HTTPS — All sites** | 33% | 

Operators of vulnerable servers need to take action. There is nothing practical that browsers or end-users can do on their own to protect against this attack.

Modern servers and clients use the TLS encryption protocol. However, due to misconfigurations, many servers also still support SSLv2, a 1990s-era predecessor to TLS. This support did not matter in practice, since no up-to-date clients actually use SSLv2. Therefore, even though SSLv2 is known to be badly insecure, until now, merely supporting SSLv2 was not considered a security problem, because clients never used it.

DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.

A server is vulnerable to DROWN if:

- It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings.

- Its private key is used on *any other server* that
          allows SSLv2 connections, even for another protocol.  Many
          companies reuse the same certificate and key on their web
          and email servers, for instance.  In this case, if the email
          server supports SSLv2 and the web server does not, an
          attacker can take advantage of the email server to break TLS
          connections to the web server.

[To protect against DROWN, server
        operators need to ensure that their private keys are not used
        anywhere with server software that allows SSLv2 connections.
        This includes web servers, SMTP servers, IMAP and POP servers,
        and any other software that supports SSL/TLS.]

Disabling SSLv2 can be complicated and depends on the specific server software. We provide instructions here for several common products:

**OpenSSL:** OpenSSL is a cryptographic library used in
        many server products.  For users of OpenSSL, the easiest and
        recommended solution is to upgrade to a recent OpenSSL
        version.  OpenSSL 1.0.2 users should upgrade to 1.0.2g.
        OpenSSL 1.0.1 users should upgrade to 1.0.1s.  Users of older
        OpenSSL versions should upgrade to either one of these
        versions.  More details can be found
        in [this
        OpenSSL blog post](https://www.openssl.org/blog/blog/2016/03/01/an-openssl-users-guide-to-drown/).

**(Updated March 13th, 16:00 UTC)
	Microsoft IIS (Windows Server):**
	Support for SSLv2 on the server side is enabled by default
	only on the OS versions that correspond to IIS 7.0 and IIS 7.5,
	namely Windows Vista, Windows Server 2008, Windows 7 and Windows
	Server 2008R2. This support can be disabled in the appropriate
	SSLv2 subkey for 'Server', as outlined in
	[KB245030](https://support.microsoft.com/kb/245030/EN-US).
	Even if users have not taken the steps to disable SSLv2,
	the export-grade and 56-bit ciphers that make DROWN feasible
	are not supported by default.
	

**Network Security Services (NSS):** NSS is a common
        cryptographic library built into many server products. NSS
        versions 3.13 (released back in 2012) and above should have SSLv2 disabled by
        default. (A small number of users may have enabled SSLv2
        manually and will need to take steps to disable it.) Users of
        older versions should upgrade to a more recent version. We
        still recommend checking whether your private key is exposed
        elsewhere

**Other affected software and operating systems:**

          Instructions and information for:
          [Apache](https://drownattack.com/apache.html),
          [Postfix](https://drownattack.com/postfix.html),
          [Nginx](https://www.nginx.com/blog/drown-vulnerability-cve-2016-0800-in-openssl-misses-most-nginx-users/),
          [Debian](https://security-tracker.debian.org/tracker/CVE-2016-0800),
          [Red Hat](https://access.redhat.com/security/vulnerabilities/drown)
        

**Browsers and other clients:** There is nothing
        practical that web browsers or other client software can do to
        prevent DROWN. Only server operators are able to take action
        to protect against the attack.

[**DROWN: Breaking TLS
        using SSLv2**](https://drownattack.com/drown-attack-paper.pdf) [PDF]

        Nimrod Aviram, Sebastian Schinzel,
        Juraj Somorovsky, Nadia Heninger, Maik Dankel,
        Jens Steube, Luke Valenta, David Adrian,
        J. Alex Halderman, Viktor Dukhovni,
        Emilia Käsper, Shaanan Cohney,
        Susanne Engels, Christof Paar, and
        Yuval Shavitt

        *25th USENIX Security Symposium*, Austin, TX, August 2016

More: [Conference paper](https://drownattack.com/drown-attack-paper.pdf) | [Bibtex](https://drownattack.com/drown.bib.html) | [Original tech report](https://drownattack.com/drown-attack-original-report.pdf)

The team can be contacted at [**mail@drownattack.com**](mailto:mail@drownattack.com).

DROWN stands for **D**ecrypting **R**SA with **O**bsolete and **W**eakened e**N**cryption.

For the complete details, see
        our [full technical
        paper](https://drownattack.com/drown-attack-paper.pdf).  We also provide a brief technical summary
        below:

In technical terms, DROWN is a new form of cross-protocol
        [Bleichenbacher
        padding oracle attack](http://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5).  It allows an attacker to decrypt
        intercepted TLS connections by making specially crafted
        connections to an SSLv2 server that uses the same private
        key.

The attacker begins by observing roughly several hundred connections between the victim client and server. The attacker will eventually be able to decrypt one of them. Collecting this many connections might involve intercepting traffic for a long time or tricking the user into visiting a website that quickly makes many connections to another site in the background. The connections can use any version of the SSL/TLS protocol, including TLS 1.2, so long as they employ the commonly used RSA key exchange method. In an RSA key exchange, the client picks a random session key and sends it to the server, encrypted using RSA and the server’s public key.

Next, the attacker repeatedly connects to the SSLv2 server
        and sends specially crafted handshake messages with
        modifications to the RSA ciphertext from the victim’s
        connections. (This is possible because
        [unpadded
        RSA is *malleable*](https://en.wikipedia.org/wiki/Homomorphic_encryption#Unpadded_RSA).) The way the server responds to
        each of these probes depends on whether the modified
        ciphertext decrypts to a plaintext message with the right
        form. Since the attacker doesn’t know the server’s private
        key, he doesn’t know exactly what the plaintext will be, but
        the way that the server responds ends up leaking information
        to the attacker about the secret keys used for the victim’s
        TLS connections.

The way this information is leaked can take two forms:

- In the most general variant of DROWN, the attack exploits a fundamental weakness in the SSLv2 protocol that relates to export-grade cryptography that was introduced to comply with 1990s-era U.S. government restrictions. The attacker’s probes use a cipher that involves only 40 bits of RSA encrypted secret key material. The attacker can tell whether his modified ciphertext was validly formed by comparing the server’s response to all 2 <sup>40</sup> possibilities—a moderately large computation, but one
          that we show can be inexpensively performed with
          GPUs. Overall, roughly 40,000 probe connections and
          2<sup>50</sup> computation is needed to decrypt one out of 900 TLS
          connections from the victim.
          Running the computations for the full attack
          on Amazon EC2 costs about $440.
- A majority of servers vulnerable to DROWN are also affected by an OpenSSL bug that results in a significantly cheaper version of the attack. In this special case, the attacker can craft his probe messages so that he immediately learns whether they had the right form without any large computation. In this case, the attacker needs about 17,000 probe connections in total to obtain the key for one out of 260 TLS connections from the victim, and the computation takes under a minute on a fast PC.

This special case stems from the complexity introduced by export-grade cryptography. The OpenSSL bug allows the attacker to mix export-grade and non-export-grade crypto parameters in order to exploit unexpected paths in the code.

This form of the attack is fast enough to allow an online man-in-the-middle (MitM) style of attack, where the attacker can impersonate a vulnerable server to the victim client. Among other advantages, such an attacker can force the client and server to use RSA key exchange (and can then decrypt the connection) even if they would normally prefer a different cipher. This lets the attacker target and break connections between modern browsers and servers that prefer perfect-forward-secret key exchange methods, such as DHE and ECDH.

We were able to execute this form of the attack in under a minute on a single PC.

DROWN was developed by researchers at Tel Aviv University,
        Münster University of Applied Sciences, Ruhr University
        Bochum, the University of Pennsylvania, the Hashcat project,
        the University of Michigan, Two Sigma, Google, and the OpenSSL
        project:
          [Nimrod Aviram],
          [Sebastian Schinzel](https://www.fh-muenster.de/hochschule/aktuelles/news/index.php?newsId=91),
          [Juraj Somorovsky](https://www.nds.rub.de/chair/people/jsomorovsky/),
          [Nadia Heninger](https://www.cis.upenn.edu/~nadiah/),
          [Maik Dankel],
          [Jens Steube](https://hashcat.net/),
          [Luke Valenta](https://www.seas.upenn.edu/~lukev/),
          [David Adrian](https://davidadrian.org/),
          [J. Alex Halderman](https://jhalderm.com/),
          [Viktor Dukhovni],
          [Emilia Käsper](http://research.google.com/pubs/author58129.html),
          [Shaanan Cohney](https://cohney.info/),
          [Susanne Engels],
          [Christof Paar](https://www.emsec.rub.de/chair/_staff/christof-paar/), and
          [Yuval Shavitt](https://www.eng.tau.ac.il/~shavitt/)
        

Yes.  The DROWN attack itself was
        assigned [CVE-2016-0800](https://www.openssl.org/news/secadv/20160301.txt).

DROWN is made worse by two additional OpenSSL
        implementation vulnerabilities. [CVE-2015-3197](https://www.openssl.org/news/secadv/20160128.txt),
        which affected OpenSSL versions prior to 1.0.2f and 1.0.1r,
        allows a DROWN attacker to connect to the server with disabled
        SSLv2 ciphersuites, provided that support for SSLv2 itself is
        enabled. [CVE-2016-0703](https://www.openssl.org/news/secadv/20160301.txt), which affected OpenSSL
        versions prior to 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf, greatly
        reduces the time and cost of carrying out the DROWN
        attack.

Yes. We’ve been able to execute the attack against OpenSSL versions that are vulnerable to CVE-2016-0703 in under a minute using a single PC. Even for servers that don’t have these particular bugs, the general variant of the attack, which works against any SSLv2 server, can be conducted in under 8 hours at a total cost of $440.

We have no reason to believe that DROWN has been exploited
        in the wild prior to this disclosure. Since the details of the
        vulnerability are now public, attackers may start exploiting
        it at any time, and we recommend taking the
        countermeasures [explained above](https://drownattack.com#mitigation) as
        soon as possible.

Indeed, SSLv2 has long known to be weak when clients and
        servers use it to communicate, and so nearly every modern
        client uses a more recent protocol.  DROWN shows
        that *merely allowing SSLv2*, even if no legitimate
        clients ever use it, is a threat to modern servers and
        clients.  It allows an attacker to *decrypt modern TLS
        connections* between up-to-date clients and servers by
        sending probes to any server that supports SSLv2 using the
        same private key.

No. DROWN allows an attacker to decrypt one connection at a time. The attacker does not learn the server’s private key.

Yes. Some variants of the attack can be used to perform
        MitM attacks against TLS or QUIC. More details can be found in
        sections 5.3 and 7 of
        the [technical paper](https://drownattack.com/drown-attack-paper.pdf).

Surprisingly, no. The active MitM form of the attack allows an
        attacker to target servers and clients that prefer non-RSA key
        exchange methods. See sections 5.3 and 7 of
        the [technical paper](https://drownattack.com/drown-attack-paper.pdf).

Probably not. As the attacker does not learn the server’s
        private key, there’s no need to obtain new certificates. The
        only action required is disabling SSLv2 as per
        the [countermeasures explained
        above](https://drownattack.com#mitigation). If you cannot confidently determine that SSLv2 is
        disabled on every device or server that uses your server’s
        private key, you should generate a fresh key for the server
        and obtain a new certificate.

No. There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack.

Yes, that’s a reasonable precaution, although it will also
        prevent our scanners from being able to
        help you identify vulnerable servers. You might consider first
        running the test suite to identify vulnerable servers and only
        then filtering SSLv2 traffic. You should also use
        the [countermeasures explained
        above](https://drownattack.com#mitigation).

Possibly. If you run a server and can be certain no one made a large number of SSLv2 connections to any of your servers (for example, by examining IDS or server logs), then you weren’t attacked. Your logs may contain a small number of SSLv2 connections from the Internet-wide scans that we conducted over the past few months to measure the prevalence of the vulnerability.

Yes. Even if you’re certain that you have SSLv2 disabled on your HTTPS server, you may be reusing your private key on another server (such as an email server) that does support SSLv2. We recommend manually inspecting all servers that use your private key.

Security against DROWN is not possible for that embedded device. If you must keep that device running, make sure it uses a different RSA private key than any other servers and devices. You can also limit the scope of attack by using a firewall to filter SSLv2 traffic from outside your organization. In all circumstances, maintaining support for SSLv2 should be a last resort.

Unfortunately, no. Although [SSLLabs](https://www.ssllabs.com/ssltest/)
        provides an invaluable suite of security tests, right now it
        only checks whether your HTTPS server directly allows SSLv2.
        You’re just as much at risk if your site’s certificate or key
        is used anywhere else on a server that does support SSLv2.
        Common examples include SMTP, IMAP, and POP mail servers, and
        secondary HTTPS servers used for specific web
        applications.

[You can also download and run our]
        [scanner utility](https://github.com/nimia/public_drown_scanner).
        This utility only detects SSLv2
        support *on a single port*. It *cannot detect the common
        scenario*, explained above, where a web server that doesn't
        support SSLv2 is vulnerable because it shares its public key with
        an email server that does.
        

[Due to CVE-2015-3197, OpenSSL may still accept
        SSLv2 connections even if all SSLv2 ciphers are disabled.]

Not in the immediate future. There are still too many servers vulnerable to the attack.

For the third time in a year, a major Internet security
        vulnerability has resulted from
         
        [the way cryptography](https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States)
         [was weakened](http://privacyink.org/pdf/export_control.pdf)
        by U.S. government policies that
        restricted exporting strong cryptography until the late
        1990s. Although these restrictions, evidently designed to make
        it easier for NSA to decrypt the communication of people
        abroad, were relaxed nearly 20 years ago, the weakened
        cryptography remains in the protocol specifications and
        continues to be supported by many servers today, adding
        complexity—and the potential for catastrophic
        failure—to some of the Internet’s most important
        security features.

The U.S. government deliberately weakened three kinds of
        cryptographic primitives: RSA encryption, Diffie-Hellman key
        exchange, and symmetric
        ciphers. [FREAK](https://mitls.org/pages/attacks/SMACK#freak)
        exploited export-grade RSA,
        and [Logjam](https://weakdh.org) exploited
        export-grade Diffie-Hellman. Now, DROWN exploits export-grade
        symmetric ciphers, demonstrating that all three kinds of
        deliberately weakened crypto have come to put the security of
        the Internet at risk decades later.

Today, some policy makers are calling for new
        [restrictions on the design of cryptography](http://hdl.handle.net/1721.1/97690)
        in order to
        prevent law enforcement from “going dark.” While
        we believe that advocates of such backdoors are acting out of
        a good faith desire to protect their countries, history’s
        technical lesson is clear: weakening cryptography carries
        enormous risk to all of our security.