A Third of All HTTPS Websites Vulnerable To DROWN Attack (drownattack.com) 72
An anonymous reader writes: The OpenSSL project has released versions 1.0.2g and 1.0.1s to address a high severity security issue known as the DROWN attack (CVE-2016-0800) which allows attackers to break HTTPS and steal encrypted information. In layman terms, the attack uses an improperly patched issue (from 1998) in SSL to attack websites using the more modern TLS protocol. Servers where admins use SSL and TLS are in danger. Additionally, servers where only TLS is used, but the admins are sharing the same certificate for other servers where they have SSL, are also vulnerable, since the attack targets RSA, employed in both SSL and TLS. The entire attack is also easy to carry out, costing only $440 on Amazon EC2.
The name (Score:2)
The name "DROWN" probably has something to do with how admins feel about using OpenSSL by now (or perhaps what they think should be done to it, or both). It goes well with names like heart-bleed.
Re: (Score:3, Informative)
It's actually an acronym(-ish) for Decrypting RSA with Obsolete and Weakened eNcryption.
It also lends itself to the term "my server got dr0wned".
Re: (Score:1)
As we saw with Heartbleed, is it now a requirement that every vulnerability have its own logo? I didn't know that security teams needed to hire graphic artists.
Re: (Score:1)
Looks like they took a page out of Congress's book with the ridiculous acronyms.
Wow, really? (Score:2)
So I take it this is an issue which hasn't been properly fixed by vendors and nobody is using web servers from 1998?
This sounds more like badly written software than bad admin practices. How the heck are you supposed to prevent that?
Re:Wow, really? (Score:4, Funny)
Re: Wow, really? (Score:1)
Like OpenSSL?
Re: Wow, really? (Score:2)
Re: (Score:2, Informative)
LibreSSL is more robust and is a lean version of OpenSSL.
Re: (Score:2)
LibreSSL is more robust and is a lean version of OpenSSL.
LibreSSL is vulnerable as well since it is an design flaw of SSLv2 more than a product defect.
Re: Wow, really? (Score:5, Informative)
Um, LibreSSL removed SSLv2, so no. It is not vulnerable.
http://undeadly.org/cgi?action=article&sid=20160301141941&mode=expanded
Re: (Score:2)
And was forked from OpenSSL long after this bug was in the codebase.
Re: (Score:2)
...This sounds more like badly written software than bad admin practices. How the heck are you supposed to prevent that?
Prevent?
Microsoft is still in business today. That should tell you something about prevention.
Re: (Score:2, Interesting)
To be fair, the described attack requires resources that haven't been available to the majority of the world until very recently. Had you managed to sit on this zero-day for twenty years, and you'd started the computations listed on consumer-grade equipment in the late 90s, you might be halfway done by now. Bottom line is, now that datacenter-level resources are becoming available to any script kiddie with a credit card, you're going to see a lot more of this kind of attack, regardless of the source.
Re: (Score:3)
Hiawatha (Score:3)
Re:Hiawatha (Score:5, Informative)
It is not an OpenSSL exclusive problem, Is a protocol one. If you have SSLv2 enabled, you are vulnerable
Re:Hiawatha (Score:5, Interesting)
Re: (Score:2)
Sure, but that's how mbed TLS (former PolarSSL, the TLS library used in Hiawatha) and Hiawatha helped me. mbed TLS dropped support for it long ago and Hiawatha uses sane and secure default settings. Without any tweaking, it gives you an A rating at ssllabs.com.
OpenSSL also disables SSLv2 by default. The problem is that some people apparently overrides the safe defaults.
Re: (Score:2)
Thanks... good to know. I really need to get off OpenSSL - go with one of the leaner distributions... we all do.
Re:Hiawatha (Score:4, Insightful)
So glad that I'm using a webserver that does NOT use this abomination called OpenSSL
It uses the abomination called PolarSSL with its own history of exploitable vulnerabilities.
and was writting with security in mind
Using naÃve heuristics to defend against SQLi and XSS demonstrates the opposite.
Drown, Heartbleed, Slowloris, etc, never caused me any trouble.
Whose fault is allowing SSLv2 and export ciphers in 2016? All those poor site operators... OpenSSL made me do it!!
--
https://technet.microsoft.com/... [microsoft.com]
Re: (Score:1)
It uses the abomination called PolarSSL with its own history of exploitable vulnerabilities.
True, but genetic diversity in this case is what can save your bacon. Organisms have been doing it for ages.
and was writting with security in mind
Using naive heuristics to defend against SQLi and XSS demonstrates the opposite.
Well, the Hiawatha project is notoriously bad at PR, nevertheless, it's open source, and there are multiple people scrutinising the code. But if you ignore those toy-like security kludges and the over-the-top claims of security, it turns out to be a rather solid platform.
Re: (Score:2)
Why do you think it has notoriously bad PR? What do other webserver projects do what Hiawatha doesn't?
Yes, the author himself has said that many security features are/were experimental, but why do you think it has toy-like security kludges and over-the-top claims? I found many of its security features very useful.
Your ignorance is showing. (Score:1)
This flaw, which is common to all SSLv2 implementations, was discovered and proven with help from the OpenSSL team. So tell me how horrible OpenSSL is again?
Incidentally, none of my servers (many of which use OpenSSL) were vulnerable to DROWN because SSLv2 has been turned off on all of them for years.
There's nothing wrong
Re: (Score:2)
Speaking of ignorance...
Disable SSLv2 (Score:2)
It seems to say that if you have SSLv2 enabled on any service with your keys, you're vulnerable. Otherwise, not. A quarter of admins don't seem to know how to disable it.
Re: (Score:2)
SSLv3? TLS 1.0 is no longer even PCI compliant due to vulnerabilities.
Re: (Score:2)
In many cases, the problem is "downstream" of the admins originally tasked with disabling it. E.g., Original website gets locked down with TLS only, but then a proxy/CDN/accelerator project comes along and "front-ends" some or all of the HTTPS services/content, and the new HTTPS-serving service isn't locked down and could even be invisible to the admins in charge of the original web application boxes. (Yes, I've seen this happen before bot
Re: (Score:2)
The default in most packages (I'm talking Exchange, IIS, Apache, nginx, Postfix, Dovecot, ...) is that it is enabled. The problem is that disabling it could break a lot of clients, especially those on Windows XP, IE6 or older versions of Java.
Re: (Score:3)
The default in most packages (I'm talking Exchange, IIS, Apache, nginx, Postfix, Dovecot, ...) is that it is enabled. The problem is that disabling it could break a lot of clients, especially those on Windows XP, IE6 or older versions of Java.
Which is why I want to strangle slashdotters who claim anything after XP is for the sake of change and that old software is the best thing since sliced bread.
System admins get the horde of the hostily more than the helpdesk folks. It is their fault for being hacked, yet users and management never want to upgrade or spend any money because it works just fine. Meanwhile if something is hacked or breaks it is on the system admin for not fixing it even though management didn't follow their own procedures
Re: (Score:3)
You're confusing it with SSLv3, which was still used by Win XP, IE6, Java 6, ancient Androids maybe. I can't think of anything that depends on SSLv2 and would be in common use today.
SSLv2 has been obsolete for decades. Both should be turned off--the bare minimum for secure sites is TLS v1.0, and PCI DSS requires all older protocols to be disabled, if you need such certifications.
Re: (Score:3)
On Windows since at least 2008R2, SSLv2 is explicitly disabled by default..
Re: (Score:3)
No, that would be SSLv3. SSLv2 was deprecated in 1998 - 18 years ago, we had years of downgrade attacks like this before it became standard practice to drow all SSLv2 support, and that is already some 10 years ago. Unless you need to support crap from the 1990s that havne't been updated, you have no excuse for support SSLv2, and if you need to support that old crap, you really should have it on a secure intranet.
Re: (Score:2)
Well, if you want to enable SSL, you go to the documentation right? NEITHER Apache 2.4 nor nginx documentation mention the SSL Protocol directives on their pages or any warning about why you should disable them. Vendor defaults (I just went through it on Ubuntu LTS) do have commented out SSL directives for Postfix/Dovecot but do not have any warning nor SSL protocols disabled.
Re: (Score:2)
Re: (Score:2)
If you don't explicitly disable it, it will be enabled. Yes, the defaults is to not have SSL, but this is the documentation
https://httpd.apache.org/docs/... [apache.org]
This page doesn't even make mention of the SSLProtocol directive.
Re: (Score:2)
Re: (Score:2)
[REDUNDANT] (Score:5, Funny)
[REDUNDANT]
Good thing /. isn't vulnerable at all, thanks to its lack of HTTPS support!
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
Obviously because it doesn't support SSLv2.
The problem is not in the library but in the protocol, the reason people continue to use OpenSSL is BECAUSE it supports all sorts of SSL versions and thus more flexible to use than any other OpenSSL-wannabe-dropin.
This OpenSSL version however breaks stuff by disabling it by default and changing the API when you DO want to use it; given that the only applications that would use it are ancient, I doubt there would be any fixes for those applications to use the new AP
Re: (Score:2)
Astonished (Score:1)
Re: (Score:1)
Ha ha, no worries (Score:2)
Ha ha, no worries here, I don't use SSL on my sites!
Oh, wait...