
The DROWN Attack - jsnell
https://www.drownattack.com/
======
tptacek
The vulnerability here is tricky to exploit but actually simple to describe.

There's a padding oracle in the form of RSA used by both TLS and SSLv2; by
repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you
can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures
for this attack.

But SSLv2's countermeasures are sabotaged by the crappy ciphers it also
supports. In both TLS and SSLv2, the anti- padding- oracle trick is that the
server detects bad messages and then generates a fake message to continue
running the protocol with, instead of aborting (which would reveal to the
attacker that the message was corrupt, thus enabling the padding oracle). But
when SSLv2 does that, the attacker can detect that it did, because the cipher
key lengths in SSLv2 are so short that they can be brute forced. The attacker
knows when the SSLv2 server replaced its message with a fake one, and thus has
a working padding oracle.

The big problem here is that people run old SSLv2 servers with the same RSA
keypairs as their TLS servers. So you can take messages you captured from the
TLS servers, and, with some very clever message manipulation owing to an older
Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding
oracle to decrypt them.

It's a great, great paper. The Bardou "trimmer" stuff was news to me too!
:mind-blown-emoji:

The top line takeaway on DROWN for most people seems to be "export ciphers are
evil". I think: (a) boring! (b) misses the more important point.

To me, the real problem here is RSA. Virtually every system on the Internet
that does RSA uses PKCS1v15 padding (DNSSEC, which is only now being rolled
out after nearly two decades of standards work, _uses PKCS1v15 padding!_ ).
Moreover, RSA directly exposes an encryption primitive, unlike DH+signature
forward-secure protocols, and RSA ciphertexts are surprisingly malleable.

To me, the real takeaway: RSA is obsolete. Stop using it.

† _We walk you through this vulnerability in our challenges
here:[http://cryptopals.com/sets/6/](http://cryptopals.com/sets/6/) \--- start
with #46_

~~~
drdaeman
> RSA is obsolete. Stop using it.

The problem is, the ONLY curves that are supported in practice are NIST P-256
(prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess,
many are reluctant to switch (because we're non-experts and don't know real
implications, but we heard that there's something not right there - and
shouldn't one be wary?).

Neither Curve25519 nor Curve448 - which are said to be safe - are usable with
X.509 and TLS, yet. Still waiting for that RFC to get past the draft status.

So, what should we do?

~~~
microcolonel
Frankly I don't do security critical things on TLS anymore. I'm tired of
having to wait in limbo for months to fix known vulnerabilities.

~~~
wolf550e
What do you use instead? SSH? IPSec?

~~~
sandworm101
Go to datacenter. Open cage. Plug in keyboard. Oldschool.

~~~
Someone1234
Are you shielding the keyboard from EM leakage? I don't open a cage, I get in
one and do my work in there... No more EM eavesdropping.

~~~
sandworm101
Unless there is an enemy antenna with you inside the cage. A real security pro
uses a pneumatic keyboard.

~~~
IgorPartola
No magnetized needle and a steady hand?

------
jvehent
From a pool of 11 million scans of HTTPS sites, I could only find ~265k
targets with SSLv2 enabled [1]. That's 2.4%, not 25%.

A breakdown of the type of target that have SSLv2 enabled would be useful to
understand how they reached that number. It's possible that they scanned much
much more than HTTPS on port 443, and found a lot of embedded devices with
poor SSL configurations.

At any rate, you should verify the configuration of your websites. There are
many tools to do that, and we publish configuration sample to make it easy:
[https://mozilla.github.io/server-side-tls/ssl-config-
generat...](https://mozilla.github.io/server-side-tls/ssl-config-generator/)

[1]
[https://twitter.com/jvehent/status/704657734810148864](https://twitter.com/jvehent/status/704657734810148864)

[edit] the page [https://drownattack.com/top-
sites](https://drownattack.com/top-sites) shows that sites like yahoo.com are
vulnerable, but there are no details as to why it is listed vulnerable.
yahoo.com does not allows connections with SSLv2, but some of its subdomains
do, so maybe the top-level domain is listed because some of its subdomains are
vulnerable?

[edit 2] according to one of the researcher, the scanner "check if pubkey (not
cert) runs on SSLv2. Then mark all others with that pubkey vuln" (src:
[https://twitter.com/seecurity/status/704665265712308224](https://twitter.com/seecurity/status/704665265712308224))

~~~
dadrian
Due to CVE-2015-3197, many servers using OpenSSL reported they supported no
SSLv2 ciphers, which causes OpenSSL-based SSLv2 clients to hang up. However,
if you aggressively choose a cipher and continue the handshake, the server
will still negotiate the connection. As a result, most existing scanning tools
vastly underestimate SSLv2 support.

~~~
yeukhon
Wait, what? Is there a PoC script?

------
ColinDabritz
From the article: "For the third time in a year, a major Internet security
vulnerability has resulted from the way cryptography was weakened by U.S.
government policies that restricted exporting strong cryptography until the
late 1990s."

The bearing of this on the ongoing "backdoor" and "just one device"
discussions is critical. This is direct evidence of real harm done by
weakening encryption.

~~~
tptacek
The attack is viable without export ciphers. The real issue here is the
continued and unabated prevalence of PKCS#1 v1.5 padding (really, of RSA in
general).

~~~
ColinDabritz
Oh, I agree. I don't mean that the weakness created the vulnerability
entirely, thank you for clarifying. I appreciate the excellent research and
security investigation done here. It was excellently articulated and
presented, and we need to keep improving our publicly available tools and
finding these issues.

What I mean is that, today, many many years since the creation of the suite,
the single-target cost has dropped to 'only' $440 per target for non-weakened
ciphers. I love the money-to-execute-attack metric.

That's still high enough to slow down the viability of broad attacks for most
attackers. What about in the past? How much was that back when the suite was
created? Much higher. How much sooner did the weakened version make the attack
efficient?

I don't mean that the government is the source of all crypto flaws, I mean
that we have a specific example of a government mandated crypto 'back door'
weakness causing a specific harm, making exploitation of a security flaw
substantially easier. This is direct evidence of the harm caused by
undermining security, which the government is currently adamant can be done
"safely". The security and hacker communities know that this is not true, and
this is a timely counter-factual example.

This is direct evidence that weakening cryptography, including back-doors, and
special "one time" access fundamentally cause harm by undermining the security
of cryptography for everyone.

------
mrThe
[https://test.drownattack.com/?site=localhost](https://test.drownattack.com/?site=localhost)
nice one

~~~
draugadrotten
[https://test.drownattack.com/?site=mail](https://test.drownattack.com/?site=mail)
ouch

~~~
fgtx
[https://test.drownattack.com/?site=ftp](https://test.drownattack.com/?site=ftp)

------
jqueryin
If you want to check your servers for various other attacks with a shell
script:

[https://testssl.sh/](https://testssl.sh/)

Also, I'm not seeing any guides on fixes for Dovecot yet. If you built from
source or the defaults aren't working, you can use the following:

    
    
        ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
    

Something more secure (blocks other vulnerabilities):

    
    
        ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:!RC4:+HIGH:+MEDIUM
    

The second one also covers SSlv3. You can read more on why to disable this at:
[http://disablessl3.com/](http://disablessl3.com/)

Also, you may need to update your Exim configs as well:

    
    
        tls_require_ciphers = AES128+EECDH:AES128+EDH
        openssl_options = +no_sslv2 +no_sslv3
    

If there's anything else I'm missing, let me know.

~~~
pfg

      ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
    

Does this just disable all SSLv2 ciphers, or disable SSLv2 via
SSL_OP_NO_SSLv2? The former might not be enough, unless your OpenSSL version
includes fixes from 1.0.2f and g.

~~~
capnrefsmmat
Dovecot also supports disabling SSLv2 directly:

    
    
        ssl_protocols = !SSLv2 !SSLv3

------
metafex
From the FAQ:

"In technical terms, DROWN is a new form of cross-protocol Bleichenbacher
padding oracle attack. It allows an attacker to decrypt intercepted TLS
connections by making specially crafted connections to an SSLv2 server that
uses the same private key."

------
nateberkopec
> Disabling SSLv2 can be complicated [...]

If users are accidentally enabling a feature that's been insecure for 20
years, the vulnerability is that your configuration mechanism is too
complicated to understand.

------
skywhopper
So, disable SSLv2. That is not new information. I like how the FAQ insists you
are still at risk if you've disabled SSLv2 because you still might be using it
somewhere else!!! In other words, if you've not disabled SSLv2 everywhere,
then there are still places where SSLv2 is enabled. Thank you.

~~~
Steuard
I expect you already understand this, but to be clear: the risk appears to be
that even one forgotten old server (or service) running SSLv2 can put your up
to date, highly secure servers at risk (if you've shared keys between them).

To my eye, the way you've phrased it here could be read to imply "any server
with SSLv2 disabled is safe". The linked report says this is incorrect, and
its inaccuracy is responsible for roughly half of the vulnerabilities that
they have observed.

~~~
skykooler
So, disable SSLv2 and get a new key, and only share it between servers with
SSLv2 disabled.

~~~
pfg
Note that the private key isn't actually leaked (as opposed to Heartbleed), so
it wouldn't be necessary to revoke the old certificate and use a new key.
Rather, DROWN uses an existing SSLv2 service with the same key as an Oracle to
decrypt (usually secure) TLS connections.

It's still a good idea to not share keys to limit the exposure for future
attacks.

------
fulafel
Quote from paper: "Unfortunately, during our experiments we discovered that
OpenSSL servers do not respect the cipher suites advertised in the ServerHello
message. That is, the client can select an arbitrary cipher suite in the
ClientMasterKey message and force the use of export cipher suites even if they
are explicitly disabled in the server configuration. The SSLv2 protocol itself
was still enabled by default in the OpenSSL standalone server for the most
recent OpenSSL versions prior to our disclosure."

Hopefully OpenSSL still honored a configuration setting to disable SSLv2?

~~~
pfg
It would depend on exactly _how_ the code disables SSLv2 - if it just disables
all SSLv2 ciphers, you're SOL, see my other comment:
[https://news.ycombinator.com/item?id=11202785](https://news.ycombinator.com/item?id=11202785)

------
jaxr
I don't know that much about encryption at all. But I was wondering if the
fact that the private key for a certain web server could be uncovered using
this attack implies that all the encrypted data that could have been gathered
by, say, NSA's PRISM, while the site was using that certificate is now
available to them in 'plain text'?

~~~
pfg
Unlike Heartbleed, the actual private key is not leaked to the attacker.
Rather, a SSLv2-enabled server allows you to build an oracle with which you
can decrypt a TLS connection (modern crypto, secure, etc.) to a server that
uses the same key.

With Perfect Forward Secrecy, any DROWN compromise is limited to the period
where an attacker is actively running the attack against you. Previous PFS
sessions cannot be decrypted. Without PFS, I'm not sure, but my gut feeling is
that previous traffic could be decrypted if someone actively attacks you on an
unpatched system now.

------
api
This is why complexity is so terribly evil in secure protocols. All these
features, feature flags, upgrades, downgrades, _state transitions_... it's all
surface area for bugs. A complete state diagram for a modern SSL/TLS stack
would be huge and contains edge cases that are probably undocumented and
poorly understood.

Do boring crypto: [https://cr.yp.to/talks/2015.10.05/slides-
djb-20151005-a4.pdf](https://cr.yp.to/talks/2015.10.05/slides-
djb-20151005-a4.pdf)

Boring crypto means minimal state, minimal code (and therefore easy to audit),
a minimal set of algorithms with new algorithms and encodings and such being
added _only when absolutely necessary_ , etc. Crypto "flexibility" means edge
case bugs and lots of code where bugs can hide.

There is in general an exponential relationship between LOC and complexity and
bugs. In crypto and security code this is really bad.

------
dbalan
Better explanation: [http://blog.cryptographyengineering.com/2016/03/attack-
of-we...](http://blog.cryptographyengineering.com/2016/03/attack-of-week-
drown.html)

------
Mojah
Oh come on, it targets SSLv2. You better have a _damn_ good reason for still
having SSLv2 enabled on your systems.

If you didn't, you had this one coming.

~~~
cjbprime
> Oh come on, it targets SSLv2. You better have a _damn_ good reason for still
> having SSLv2 enabled on your systems.

"Unfortunately, during our experiments we discovered that OpenSSL servers do
not respect the cipher suites advertised in the ServerHello message. That is,
the client can select an arbitrary cipher suite in the ClientMasterKey message
and force the use of ex- port cipher suites even if they are explicitly
disabled in the server configuration. The SSLv2 protocol itself was still
enabled by default in the OpenSSL standalone server for the most recent
OpenSSL versions prior to our disclosure."

~~~
pfg
I think it's a little bit more complicated than that, and depends on how SSLv2
was disabled.

From the OpenSSL 1.0.2f release notes:

    
    
      SSLv2 doesn't block disabled ciphers
    
      A malicious client can negotiate SSLv2 ciphers that have been disabled on
      the server and complete SSLv2 handshakes even if all SSLv2 ciphers have
      been disabled, provided that the SSLv2 protocol was not also disabled via
      SSL_OP_NO_SSLv2.
    

So if you disabled all SSLv2 ciphers, but didn't actually disable SSLv2
itself, you could still complete a SSLv2 handshake. If your server software
disables SSLv2 via SSL_OP_NO_SSLv2, then you're fine. This seems to be the
case for (at least) nginx, based on how I read the code.

------
pmcao
Is there anyone developing an exploit for this attack? You'll need a
vulnerable openssl version to test. After major Linux distros releasing the
path, it'll be difficult to obtain the vulnerable openssl.

Timemachine (debian) is a tool that constructs a Docker image of a Debian base
system. You can choose a Debian distribution and a date in the past. Then
install any (vulnerable) package of your choice for experiment.
[https://github.com/CSLDepend/timemachine](https://github.com/CSLDepend/timemachine)

This tool is a part of a security testbed that we are developing. We have
created container images of recent attacks in our repo, e.g.,
[https://github.com/CSLDepend/itestbed/tree/master/repo/mitm/...](https://github.com/CSLDepend/itestbed/tree/master/repo/mitm/CVE-2015-7547)

If anyone is interested in developing such testbed for reproducible security
experiments, let me know @pmcao

~~~
joeyh
Are you familiar with version control systems?

------
level
The site appears to be getting hit pretty hard, here's Google's cached page:
[https://webcache.googleusercontent.com/search?q=cache:Hi1cki...](https://webcache.googleusercontent.com/search?q=cache:Hi1ckiKBQyAJ:https://drownattack.com/+&cd=1&hl=en&ct=clnk&gl=ca)

------
developer2
For those using nginx:

All nginx versions >= 0.8.19 (Oct 2009), and backported to >= 0.7.65 (Feb
2010), have SSLv2 disabled in default configuration[1][2]. Versions >= 1.9.1
(May 2015) also disable SSLv3 by default, which is not affected by this
particular attack but suffers from the POODLE attack.

If you are on a version of nginx covered above, just ensure your nginx
configuration does not have an "ssl_protocols" directive explicitly enabling
SSLv2 (and SSLv3 for POODLE).

If you are on an older affected version of nginx, check your configuration to
make sure you exclude SSLv2 (and typically SSLv3) with something like:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

It is not necessary to worry whether your nginx is built against openssl
1.0.2g, as this release simply disables SSLv2 support by default. If you've
covered your bases with your nginx configuration, the openssl update is not
strictly required.

[1]
[http://nginx.org/en/docs/http/configuring_https_servers.html](http://nginx.org/en/docs/http/configuring_https_servers.html)
(versions listed at very bottom of page)

[2] [https://drownattack.com/nginx](https://drownattack.com/nginx)

------
devit
From the paper: "In order to decrypt one TLS session, the attacker must
passively capture about 1,000 TLS sessions using RSA key exchange, make 40,000
SSLv2 connections to the victim server and perform 2^50 symmetric encryption
operations"

In other words, while this compromises TLS when SSLv2 is enabled, it seems to
be only maybe practical for targeted use by state actors, and even then easily
detectable by network capture.

~~~
tptacek
If by "state actors" you mean "people who can afford $500 of AWS compute",
then yes.

------
jwcrux
Basically, it looks like this affects servers that still support SSLv2. From
the mitigation notes:

> To protect against DROWN, server operators need to ensure that their private
> keys are not used anywhere with server software that allows SSLv2
> connections.

Also, I like this snippet:

> Disabling SSLv2 can be complicated and depends on the specific server
> software.

------
PythonicAlpha
According to the info page, SSLv2 can only be disabled on OpenSSL by having
the right (newer) version of OpenSSL installed.

I just checked Debian versions.

Wheezy (oldstable): Much to old OpenSSL versions, according to the info site

Jessy (stable): Still to old OpenSSL version.

Stretch (testing): _Still_ to old OpenSSL version.

Sid (unstable): The same version of OpenSSL as Stretch -- Still to old.

What to do?

~~~
pferde
From the recent Debian security advisory (DSA-3500-1) about this:

"Additionally the EXPORT and LOW ciphers were disabled since thay could be
used as part of the DROWN (CVE-2016-0800) and SLOTH (CVE-2015-7575) attacks,
but note that the oldstable (wheezye)[sic!] and stable (jessie) distributions
are not affected by those attacks since the SSLv2 protocol has already been
dropped in the openssl package version 1.0.0c-2."

So it seems that neither Jessie nor Wheezy are affected by this.

~~~
PythonicAlpha
Thank you very much!

------
chinathrow
SSLLabs is the go to place for checks regarding your SSL/TLS setup.

[https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/)

DROWN is not yet marked there but you can look for "SSL 2" within the
protocols section of the report.

~~~
kardos
Mostly. See the DROWN FAQ [1] regarding the SSLLabs test.

[1] [https://www.drownattack.com/#faq-
ssllabs](https://www.drownattack.com/#faq-ssllabs)

------
jcoffland
> 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.

Thanks again US government.

------
geertj
For those using ManageIQ / CloudForms, here's a blog post and a policy to
check your Red Hat systems for compliance.

[http://cloudformsblog.redhat.com/2016/03/01/drown-openssl-
vu...](http://cloudformsblog.redhat.com/2016/03/01/drown-openssl-
vulnerability/)

------
fosco
Additional write-up on this. -->
[https://blog.qualys.com/securitylabs/2016/03/01/drown-
abuses...](https://blog.qualys.com/securitylabs/2016/03/01/drown-abuses-
ssl-v2-to-attack-rsa-keys-and-tls)

more technical detail

------
chejazi
I checked out the services I use and most of them are OK. I was surprised to
find Namecheap [0] did not pass, however. Kind of ironic given they sell SSL
certs...

[0]
[https://test.drownattack.com/?site=namecheap.com](https://test.drownattack.com/?site=namecheap.com)

------
Mojah
Here's OpenSSL's announcement on disabling SSlv2:
[https://marc.ttias.be/openssl-
announce/2016-03/msg00002.php](https://marc.ttias.be/openssl-
announce/2016-03/msg00002.php)

------
pekk
It would be fine if this were just a public service announcement, but then
there is the huge political rant at the bottom. The use of a vulnerability as
a megaphone for personal opinions is very annoying.

------
chmike
How can I test if my servers are vulnerable ?

------
eggie5
does cloudflare block this?

~~~
pfg
I didn't find any affected CloudFlare sites on their test site, so I assume
they don't allow SSLv2 connections.

You should probably patch your origin servers anyway.

------
bencollier49
These marketed attacks with special logos drive me up the wall. If I ever
discover one I'll <edit!> give it a rude name and force everyone to look at a
silly picture to go with it.

~~~
rmc
But Heartbleed was the first one, and it's marketing made it get everywhere.
Regular newspapers, etc.

Instead of hating people marketing vulnerbilities, tackle why people-in-power
don't care about vuln when communicated the old way.

~~~
laumars
> _But Heartbleed was the first one_

Perhaps with a logo - I never really pay much attention to logos - but it
wasn't the first to have an accessible name. Just off the top of my head I can
name 3 SSL vulnerabilities that predated Heartbleed: BEAST, CRIME, BREACH.

Personally I can't see how having a logo changes much in terms of press
coverage since radio and printed newspapers tend not to publish the logos,
online publications have a large resource of stock images they can use (eg
Getty) and the TV would likely want video footage anyway.

I think the nature of the bug with Heartbleed also played an important factor
in it's coverage. It was quite a simple exploit to explain to the lay-person
(albeit imprecisely) when compared to BEAST, CRIME, BREACH, POODLE, etc which
require a much greater understanding of SSL/TLS. We do see other unbranded
exploits are reported by the mainstream media, such as websites being hacked,
DDoS attacks, etc, and in all of those instances the content is easily
communicated in a 30 second soundbite.

~~~
manarth
And if we step outside SSL vulnerabilities:

\- ILOVEYOU \- Melissa \- Slammer

We've been naming attacks for a long time. Perhaps one difference is that
these days, a vulnerability is named if it's deemed high-risk/high-impact. In
the past, vulnerabilities became well-known names once they'd been seen to do
serious damage.

~~~
laumars
Let's not forget the Millennium bug. That thing also had a logo:
[http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_...](http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_79938728_squarebug.jpg)

------
outworlder
What's with this trend of vulnerabilities getting a catchy name, domain and
even a logo?

Is that because people don't pay attention when there's just a CVE number?

------
tamana
Why does everyone bug need its own domain name?

~~~
pekk
If you look at the bottom of the page, you will see that some of the
underlying motivation for the site is to shill for a particular political
stance.

~~~
cantrevealname
> shill for a particular political stance

Government agencies lobby for what they want (restrictions on speech, limits
on privacy, back doors into crypto), but we technical people should stick to
technical discussion only?

A technical report should never discuss what government policy caused the bug,
political decisions that could have avoided it, and their effect on society?

By the way (to save a click), the political stance is this (quoted from the
article):

" _Today, some policy makers are calling for new restrictions on the design of
cryptography 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._ "

------
andygambles
I guess DROWN has a better ring to it than DROWE

------
neoeldex
Is this new? Since I would say it's already widely known as a ssl Downgrade
attack.

[https://en.wikipedia.org/wiki/Downgrade_attack](https://en.wikipedia.org/wiki/Downgrade_attack)

~~~
CJefferson
Nope, this is different.

Your machine can not support SSLv2 at all (so you couldn't be downgraded), but
the existence of SSLv2 on the server (or a different server running SSLv2, say
an e-mail server) allows the attack.

