15 ms·

The DROWN Attack

791 points by jsnell 11y ago

mrThe 11y ago
https://test.drownattack.com/?site=localhost https://test.drownattack.com/?site=localhost nice one
- draugadrotten 11y ago
  https://test.drownattack.com/?site=mail https://test.drownattack.com/?site=mail ouch
  - fgtx 11y ago
    https://test.drownattack.com/?site=ftp https://test.drownattack.com/?site=ftp
metafex 11y ago
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."
bencollier49 11y ago
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 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - PakG1 11y ago
    Honestly, I think that would require a generation or two of a modified education system to bring about the desired result. You gotta deal with the here and now sometimes.
  - laumars 11y ago
    > 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 11y ago
      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 11y ago
        Let's not forget the Millennium bug. That thing also had a logo: http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_79938728_squarebug.jpg http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_...
- danielbln 11y ago
  It gets worse, some people produce a whole video around it: https://www.youtube.com/watch?v=3NL2lEomB_Y https://www.youtube.com/watch?v=3NL2lEomB_Y
  - bencollier49 11y ago
    I guess we just rebrand some minor edge case of a well-known attack, give it a stupid name and use it to promote our security consultancy, is that it? EDIT: Sorry, for consultancy read "peer-reviewed paper".
  - taf2 11y ago
    That video is fun to watch though and does a pretty good job of explaining how that attack works.
    - wingerlang 11y ago
      I agree, but it also felt like one of those TV Shop videos where you just know that you're being sold to.
- matthewmacleod 11y ago
  I'd be interested to know why this is the case. It's a hunch, but I reckon that this sort of 'branding' makes a serious problem more obvious and memorable. I mean, I remember 'Heartbleed' and 'GHOST', but I don't really remember the details of say CVE-2014-2523.
  - bencollier49 11y ago
    I guess it depends whether Heartbleed and GHOST are actually more serious than the ones without names.
- themartorana 11y ago
  Seems a bit harsh and unnecessary. This is so much clearer than a security bulletin on a mailing list I'll never see. I'm pretty sure our sites are safe but now I'll remember to check. Rebels without a cause...
- camillomiller 11y ago
  Would be wonderful, you could also develop a fix and call it COCKBLOCK Edit: dear Ben, you let us down :(
  - justinjlynn 11y ago
    Then develop a workaround for the fix and call it COCKKNOCKER. Edit: Well, OP edited their comment and now mine makes no sense... time to take a break.
    - bencollier49 11y ago
      Sorry! I need a more pseudonymous HN account.
      - justinjlynn 11y ago
        No worries mate... I really do need a break heh
  - GirlProgrammer 11y ago
    Careful! Adria Richards will take your photo and tweet it, then blow her USB whistle! (BTW: Did Adria Richards realize that "Python" as in "Monty Python" is one big Penis Joke?)
- jamescun 11y ago
  I'm on the fence over the "marketing". On one hand it is easier to communicate terms like DROWN, GHOST and Heartbleed than say CVE-2016-0800; meaning knowledge of the vulnerability gets spreads quicker and sites are patched more readily. Alternatively it could be a distraction from good security management practices, where only the "marketed" vulnerabilities get patched instead of general tracking the security of critical pieces of your infrastructure.
  - karlkatzke 11y ago
    Yep; at this point, non-technical management is trained that "it's serious if it's got a cool name."
- shiftoutbox 11y ago
  Well how long before the novelty names run out of meaning ? For starters there are probably more issues out there then there are catchy American English anachronisms. I vote for using the names of Mezzo-American gods . Like Hachäk'yum or Xbalanque!
  - fdej 11y ago
    I think GitHub should starting doing something this for issues and pull requests. Instead of the nondescript - Issue #2654: misplaced comma on page 3 of documentation - Issue #2653: open() should accept relative file path it should be - Quetzalcoatl's Rage: misplaced comma on page 3 of documentation - The Dying Curse of Buluc Chabtan: open() should accept relative file path
    - krylon 11y ago
      That would make issue trackers / change logs more interesting to read. ;-) A lot!
- carsonreinke 11y ago
  Marketing helps market the awareness of these problems, even non-tech folk have heard of Heartbleed. More awareness probably means software is likely to be updated.
- _yosefk 11y ago
  I think JSFuck beat you to it: http://arstechnica.com/security/2016/02/ebay-has-no-plans-to-fix-severe-bug-that-allows-malware-distribution/ http://arstechnica.com/security/2016/02/ebay-has-no-plans-to... ('Clever "JSFxxK" technique allows hackers to bypass eBay block of JavaScript.')
- tptacek 11y ago
  I know you didn't mean to do it, but because it's easier for people to snark about attack names, or react to snark, than it is to discuss a complicated crypto attack, this tangent about attack names takes up a pretty big chunk of the thread and really cruds the discussion up. Whatever you might think of the name, this is bona fide important crypto work; it's one of the more interesting TLS attacks ever discovered. Please try to be careful about distracting from the important stuff with silly stuff like naming.
  - lawnchair_larry 11y ago
    Then maybe next time they won't distract people with silly marketing, forcing the conversation to be about substance.
- draw_down 11y ago
  I dunno, bencollier49. Seems like a strange hill to die upon.
- r1ch 11y ago
  I don't like it because it puts too much useful information on one domain. Will the researchers still be paying for the domain in 5-10 years?
neoeldex 11y ago
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 11y ago
  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.
jwcrux 11y ago
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.
jvehent 11y ago
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-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... [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)
- deleted 11y ago
  [deleted]
- pfg 11y ago
  > [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) That seems to make sense, given that any SSLv2 service using a pubkey that's used on a non-SSLv2 service can be used in an attack against the latter. The main takeaway from this is probably that it's a good idea to separate your SSL keys by service (or, more specifically, by DISTINCT($attack_surface), where $attack_surface is your software stack, OpSec, etc.). This would limit the impact of a number of vulnerabilities (think: Heartbleed) and should generally become a best-practice.
- dadrian 11y ago
  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.
Mojah 11y ago
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.
- PythonicAlpha 11y ago
  One reason: Using a distribution that uses old OpenSSL versions (see my own post).
- cjbprime 11y ago
  > 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 11y ago
    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.
- deleted 11y ago
  [deleted]
skywhopper 11y ago
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 11y ago
  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 11y ago
    So, disable SSLv2 and get a new key, and only share it between servers with SSLv2 disabled.
    - pfg 11y ago
      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.
- deleted 11y ago
  [deleted]
- syncsynchalt 11y ago
  Also, disabling SSLv2 in versions of openssl up til January did not actually disable SSLv2.
dbalan 11y ago
Better explanation: http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html http://blog.cryptographyengineering.com/2016/03/attack-of-we...
jqueryin 11y ago
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 11y ago
  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 11y ago
    Dovecot also supports disabling SSLv2 directly: ssl_protocols = !SSLv2 !SSLv3
- yuhong 11y ago
  Please don't put !SSLv3 in the cipher list. I had to help out Pinboard who did this: https://twitter.com/yuhong2/status/602545883775836161 https://twitter.com/yuhong2/status/602545883775836161
deleted 11y ago
[deleted]
PythonicAlpha 11y ago
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?
- anc84 11y ago
  Disable SSLv2 everywhere.
  - PythonicAlpha 11y ago
    To make it more clear: According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found). (I also updated my original post)
    - r1ch 11y ago
      SSLv2 and SSLv3 are dropped at compile time in Jessie.
    - drewcrawford 11y ago
      You misunderstand how Debian works. Debian practically never updates to new versions of software (until you upgrade Debian). Instead they "backport" security fixes into the older software versions, preserving the old version numbers but adding some stuff on the end to reflect Debian's changes. The intent is that you get "only" security fixes, never features or improvements. So when you see "OpenSSL-1.0.c-stuffgoeshere" you are not looking at "OpenSSL" openssl anymore, but a version that Debian customized, probably to add security fixes. I say "Debian" here, but really most distros do it (RHEL, Ubuntu, CentOS, etc.) I'm just not familiar enough with their processes to comment specifically. Debian has disabled SSLv2 in its OpenSSL packages since 2010 [0], and if you are running a Debian OpenSSL version later than 1.0.0c-2 your OpenSSL version is not vulnerable. The current version of OpenSSL in stable is 1.0.1k-3+deb8u2, so unless your server has been under a rock for 5 years you should be fine. And if it's been under a rock for 5 years you have a lot of security vulnerabilities to be worried about. Of course you may have installed OpenSSL from somewhere else, or you may be using some other software for SSLv2 that doesn't involve OpenSSL at all. So merely upgrading your OpenSSL version is not a silver bullet, you need to think about every TLS deployment you have and how it might be used. More broadly, use this vulnerability as a wakeup call to learn about "where your software comes from", because everybody has a role to play in staying secure, including users. Debian is maintained by volunteers; you might be happier with a commercial vendor who guarantees response times. Debian backports security fixes; you might be happier with a distribution that upgrades to new vendor versions which may have avoided the confusion here. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706
chinathrow 11y ago
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 11y ago
  Mostly. See the DROWN FAQ [1] regarding the SSLLabs test. [1] https://www.drownattack.com/#faq-ssllabs https://www.drownattack.com/#faq-ssllabs
fulafel 11y ago
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?
- cjbprime 11y ago
  Yes, seems that way.
- pfg 11y ago
  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
andygambles 11y ago
I guess DROWN has a better ring to it than DROWE
ColinDabritz 11y ago
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 11y ago
  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 11y ago
    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.
  - dadrian 11y ago
    The MITM attack is only viable due to a bug introduced by handling of export ciphers, even though it affects non-export ciphers. So export ciphers are the real issue here.
Mojah 11y ago
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
devit 11y ago
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 11y ago
  If by "state actors" you mean "people who can afford $500 of AWS compute", then yes.
tptacek 11y ago
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
- CiPHPerCoder 11y ago
  As JP Aumasson said https://twitter.com/veorq/status/683360050199552001 https://twitter.com/veorq/status/683360050199552001 1998: Bleichenbacher's padding oracle attack on RSA 2016: still vulnerable systems http://framework.zend.com/security/advisory/ZF2015-10 I second "stop using RSA".
- drdaeman 11y ago
nateberkopec 11y ago
> 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.
geertj 11y ago
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-vulnerability/ http://cloudformsblog.redhat.com/2016/03/01/drown-openssl-vu...
level 11y ago
The site appears to be getting hit pretty hard, here's Google's cached page: https://webcache.googleusercontent.com/search?q=cache:Hi1ckiKBQyAJ:https://drownattack.com/+&cd=1&hl=en&ct=clnk&gl=ca https://webcache.googleusercontent.com/search?q=cache:Hi1cki...
tamana 11y ago
Why does everyone bug need its own domain name?
- thrillgore 11y ago
  It's a lot easier to convince the CTO to do something if there's marketing behind it.
- pekk 11y ago
  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 11y ago
    > 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."
outworlder 11y ago
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?
chejazi 11y ago
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
api 11y ago
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.
eggie5 11y ago
does cloudflare block this?
- pfg 11y ago
  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.
jcoffland 11y ago
> 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.
jaxr 11y ago
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 11y ago
  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.
deleted 11y ago
[deleted]
chmike 11y ago
How can I test if my servers are vulnerable ?
pekk 11y ago
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.
pmcao 11y ago
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/CVE-2015-7547 https://github.com/CSLDepend/itestbed/tree/master/repo/mitm/... If anyone is interested in developing such testbed for reproducible security experiments, let me know @pmcao
- joeyh 11y ago
  Are you familiar with version control systems?
developer2 11y ago
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
fosco 11y ago
Additional write-up on this. --> https://blog.qualys.com/securitylabs/2016/03/01/drown-abuses-ssl-v2-to-attack-rsa-keys-and-tls https://blog.qualys.com/securitylabs/2016/03/01/drown-abuses... more technical detail

The DROWN Attack

791 points by jsnell 11y ago

mrThe 11y ago

https://test.drownattack.com/?site=localhost https://test.drownattack.com/?site=localhost nice one

draugadrotten 11y ago
https://test.drownattack.com/?site=mail https://test.drownattack.com/?site=mail ouch
- fgtx 11y ago
  https://test.drownattack.com/?site=ftp https://test.drownattack.com/?site=ftp

metafex 11y ago

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

bencollier49 11y ago

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 11y ago
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.
- deleted 11y ago
  [deleted]
- PakG1 11y ago
  Honestly, I think that would require a generation or two of a modified education system to bring about the desired result. You gotta deal with the here and now sometimes.
- laumars 11y ago
  > 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 11y ago
    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 11y ago
      Let's not forget the Millennium bug. That thing also had a logo: http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_79938728_squarebug.jpg http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_...
danielbln 11y ago
It gets worse, some people produce a whole video around it: https://www.youtube.com/watch?v=3NL2lEomB_Y https://www.youtube.com/watch?v=3NL2lEomB_Y
- bencollier49 11y ago
  I guess we just rebrand some minor edge case of a well-known attack, give it a stupid name and use it to promote our security consultancy, is that it? EDIT: Sorry, for consultancy read "peer-reviewed paper".
- taf2 11y ago
  That video is fun to watch though and does a pretty good job of explaining how that attack works.
  - wingerlang 11y ago
    I agree, but it also felt like one of those TV Shop videos where you just know that you're being sold to.
matthewmacleod 11y ago
I'd be interested to know why this is the case. It's a hunch, but I reckon that this sort of 'branding' makes a serious problem more obvious and memorable. I mean, I remember 'Heartbleed' and 'GHOST', but I don't really remember the details of say CVE-2014-2523.
- bencollier49 11y ago
  I guess it depends whether Heartbleed and GHOST are actually more serious than the ones without names.
themartorana 11y ago
Seems a bit harsh and unnecessary. This is so much clearer than a security bulletin on a mailing list I'll never see. I'm pretty sure our sites are safe but now I'll remember to check. Rebels without a cause...
camillomiller 11y ago
Would be wonderful, you could also develop a fix and call it COCKBLOCK Edit: dear Ben, you let us down :(
- justinjlynn 11y ago
  Then develop a workaround for the fix and call it COCKKNOCKER. Edit: Well, OP edited their comment and now mine makes no sense... time to take a break.
  - bencollier49 11y ago
    Sorry! I need a more pseudonymous HN account.
    - justinjlynn 11y ago
      No worries mate... I really do need a break heh
- GirlProgrammer 11y ago
  Careful! Adria Richards will take your photo and tweet it, then blow her USB whistle! (BTW: Did Adria Richards realize that "Python" as in "Monty Python" is one big Penis Joke?)
jamescun 11y ago
I'm on the fence over the "marketing". On one hand it is easier to communicate terms like DROWN, GHOST and Heartbleed than say CVE-2016-0800; meaning knowledge of the vulnerability gets spreads quicker and sites are patched more readily. Alternatively it could be a distraction from good security management practices, where only the "marketed" vulnerabilities get patched instead of general tracking the security of critical pieces of your infrastructure.
- karlkatzke 11y ago
  Yep; at this point, non-technical management is trained that "it's serious if it's got a cool name."
shiftoutbox 11y ago
Well how long before the novelty names run out of meaning ? For starters there are probably more issues out there then there are catchy American English anachronisms. I vote for using the names of Mezzo-American gods . Like Hachäk'yum or Xbalanque!
- fdej 11y ago
  I think GitHub should starting doing something this for issues and pull requests. Instead of the nondescript - Issue #2654: misplaced comma on page 3 of documentation - Issue #2653: open() should accept relative file path it should be - Quetzalcoatl's Rage: misplaced comma on page 3 of documentation - The Dying Curse of Buluc Chabtan: open() should accept relative file path
  - krylon 11y ago
    That would make issue trackers / change logs more interesting to read. ;-) A lot!
carsonreinke 11y ago
Marketing helps market the awareness of these problems, even non-tech folk have heard of Heartbleed. More awareness probably means software is likely to be updated.
_yosefk 11y ago
I think JSFuck beat you to it: http://arstechnica.com/security/2016/02/ebay-has-no-plans-to-fix-severe-bug-that-allows-malware-distribution/ http://arstechnica.com/security/2016/02/ebay-has-no-plans-to... ('Clever "JSFxxK" technique allows hackers to bypass eBay block of JavaScript.')
tptacek 11y ago
I know you didn't mean to do it, but because it's easier for people to snark about attack names, or react to snark, than it is to discuss a complicated crypto attack, this tangent about attack names takes up a pretty big chunk of the thread and really cruds the discussion up. Whatever you might think of the name, this is bona fide important crypto work; it's one of the more interesting TLS attacks ever discovered. Please try to be careful about distracting from the important stuff with silly stuff like naming.
- lawnchair_larry 11y ago
  Then maybe next time they won't distract people with silly marketing, forcing the conversation to be about substance.
draw_down 11y ago
I dunno, bencollier49. Seems like a strange hill to die upon.
r1ch 11y ago
I don't like it because it puts too much useful information on one domain. Will the researchers still be paying for the domain in 5-10 years?

neoeldex 11y ago

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 11y ago
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.

jwcrux 11y ago

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.

jvehent 11y ago

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-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... [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)

deleted 11y ago
[deleted]
pfg 11y ago
> [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) That seems to make sense, given that any SSLv2 service using a pubkey that's used on a non-SSLv2 service can be used in an attack against the latter. The main takeaway from this is probably that it's a good idea to separate your SSL keys by service (or, more specifically, by DISTINCT($attack_surface), where $attack_surface is your software stack, OpSec, etc.). This would limit the impact of a number of vulnerabilities (think: Heartbleed) and should generally become a best-practice.
dadrian 11y ago
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.

Mojah 11y ago

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.

PythonicAlpha 11y ago
One reason: Using a distribution that uses old OpenSSL versions (see my own post).
cjbprime 11y ago
> 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 11y ago
  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.
deleted 11y ago
[deleted]

skywhopper 11y ago

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 11y ago
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 11y ago
  So, disable SSLv2 and get a new key, and only share it between servers with SSLv2 disabled.
  - pfg 11y ago
    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.
deleted 11y ago
[deleted]
syncsynchalt 11y ago
Also, disabling SSLv2 in versions of openssl up til January did not actually disable SSLv2.

dbalan 11y ago

Better explanation: http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html http://blog.cryptographyengineering.com/2016/03/attack-of-we...

jqueryin 11y ago

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 11y ago
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 11y ago
  Dovecot also supports disabling SSLv2 directly: ssl_protocols = !SSLv2 !SSLv3
yuhong 11y ago
Please don't put !SSLv3 in the cipher list. I had to help out Pinboard who did this: https://twitter.com/yuhong2/status/602545883775836161 https://twitter.com/yuhong2/status/602545883775836161

deleted 11y ago

[deleted]

PythonicAlpha 11y ago

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?

anc84 11y ago
Disable SSLv2 everywhere.
- PythonicAlpha 11y ago
  To make it more clear: According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found). (I also updated my original post)
  - r1ch 11y ago
    SSLv2 and SSLv3 are dropped at compile time in Jessie.
  - drewcrawford 11y ago
    You misunderstand how Debian works. Debian practically never updates to new versions of software (until you upgrade Debian). Instead they "backport" security fixes into the older software versions, preserving the old version numbers but adding some stuff on the end to reflect Debian's changes. The intent is that you get "only" security fixes, never features or improvements. So when you see "OpenSSL-1.0.c-stuffgoeshere" you are not looking at "OpenSSL" openssl anymore, but a version that Debian customized, probably to add security fixes. I say "Debian" here, but really most distros do it (RHEL, Ubuntu, CentOS, etc.) I'm just not familiar enough with their processes to comment specifically. Debian has disabled SSLv2 in its OpenSSL packages since 2010 [0], and if you are running a Debian OpenSSL version later than 1.0.0c-2 your OpenSSL version is not vulnerable. The current version of OpenSSL in stable is 1.0.1k-3+deb8u2, so unless your server has been under a rock for 5 years you should be fine. And if it's been under a rock for 5 years you have a lot of security vulnerabilities to be worried about. Of course you may have installed OpenSSL from somewhere else, or you may be using some other software for SSLv2 that doesn't involve OpenSSL at all. So merely upgrading your OpenSSL version is not a silver bullet, you need to think about every TLS deployment you have and how it might be used. More broadly, use this vulnerability as a wakeup call to learn about "where your software comes from", because everybody has a role to play in staying secure, including users. Debian is maintained by volunteers; you might be happier with a commercial vendor who guarantees response times. Debian backports security fixes; you might be happier with a distribution that upgrades to new vendor versions which may have avoided the confusion here. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706

chinathrow 11y ago

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 11y ago
Mostly. See the DROWN FAQ [1] regarding the SSLLabs test. [1] https://www.drownattack.com/#faq-ssllabs https://www.drownattack.com/#faq-ssllabs

fulafel 11y ago

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?

cjbprime 11y ago
Yes, seems that way.
pfg 11y ago
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

andygambles 11y ago

I guess DROWN has a better ring to it than DROWE

ColinDabritz 11y ago

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 11y ago
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 11y ago
  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.
- dadrian 11y ago
  The MITM attack is only viable due to a bug introduced by handling of export ciphers, even though it affects non-export ciphers. So export ciphers are the real issue here.

Mojah 11y ago

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

devit 11y ago

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 11y ago
If by "state actors" you mean "people who can afford $500 of AWS compute", then yes.

tptacek 11y ago

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

CiPHPerCoder 11y ago
As JP Aumasson said https://twitter.com/veorq/status/683360050199552001 https://twitter.com/veorq/status/683360050199552001 1998: Bleichenbacher's padding oracle attack on RSA 2016: still vulnerable systems http://framework.zend.com/security/advisory/ZF2015-10 I second "stop using RSA".
drdaeman 11y ago

nateberkopec 11y ago

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

geertj 11y ago

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-vulnerability/ http://cloudformsblog.redhat.com/2016/03/01/drown-openssl-vu...

level 11y ago

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

tamana 11y ago

Why does everyone bug need its own domain name?

thrillgore 11y ago
It's a lot easier to convince the CTO to do something if there's marketing behind it.
pekk 11y ago
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 11y ago
  > 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."

outworlder 11y ago

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?

chejazi 11y ago

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

api 11y ago

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.

eggie5 11y ago

does cloudflare block this?

pfg 11y ago
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.

jcoffland 11y ago

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

jaxr 11y ago

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 11y ago
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.

deleted 11y ago

[deleted]

chmike 11y ago

How can I test if my servers are vulnerable ?

pekk 11y ago

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.

pmcao 11y ago

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/CVE-2015-7547 https://github.com/CSLDepend/itestbed/tree/master/repo/mitm/... If anyone is interested in developing such testbed for reproducible security experiments, let me know @pmcao

joeyh 11y ago
Are you familiar with version control systems?

developer2 11y ago

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

fosco 11y ago

Additional write-up on this. --> https://blog.qualys.com/securitylabs/2016/03/01/drown-abuses-ssl-v2-to-attack-rsa-keys-and-tls https://blog.qualys.com/securitylabs/2016/03/01/drown-abuses... more technical detail