Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security IT

A Third of All HTTPS Websites Vulnerable To DROWN Attack (drownattack.com) 72

Posted by timothy from the that-guy's-just-waving-about-sharks dept.
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.
This discussion has been archived. No new comments can be posted.

A Third of All HTTPS Websites Vulnerable To DROWN Attack More

A Third of All HTTPS Websites Vulnerable To DROWN Attack

Comments Filter:

  • 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)

      by Anonymous Coward

      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)

      by Anonymous Coward

      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)

        by Anonymous Coward

        Looks like they took a page out of Congress's book with the ridiculous acronyms.

  • the attack uses an improperly patched issue (from 1998)

    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)

      by Anonymous Coward on Tuesday March 01, 2016 @01:18PM (#51616527)
      Use open source software. OSS has had years if not decades of eyeballs scouring it for vulnerabilities. While occasionally something still gets found, it is not typically severe and is quickly patched.

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

    • I don't see how it relies on badly written software rather than bad sysadmin practices. The exploit need both TLS and SSLv2 configured on the server. These days, if someone has SSLv2 active on his/her website, you can call it a bad sysadmin practice for sure. Anyone with SSLv2/SSLv3 active on his/her website deserve to be kicked in the butt. And a third of the sysadmins deserve exactly that.

  • Hiawatha (Score:3)

    by Aethedor ( 973725 ) on Tuesday March 01, 2016 @12:57PM (#51616379)
    So glad that I'm using a webserver [hiawatha-webserver.org] that does NOT use this abomination called OpenSSL and was writting with security in mind. Drown, Heartbleed, Slowloris, etc, never caused me any trouble.

    • Re:Hiawatha (Score:5, Informative)

      by robmv ( 855035 ) on Tuesday March 01, 2016 @01:00PM (#51616401)

      It is not an OpenSSL exclusive problem, Is a protocol one. If you have SSLv2 enabled, you are vulnerable

      • Re:Hiawatha (Score:5, Interesting)

        by Aethedor ( 973725 ) on Tuesday March 01, 2016 @01:03PM (#51616429)
        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.

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

      • 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)

      by WaffleMonster ( 969671 ) on Tuesday March 01, 2016 @01:47PM (#51616757)

      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)

        by BuGless ( 31232 )

        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.

        • 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)

      by Anonymous Coward

      So glad that I'm using a webserver that does NOT use this abomination called OpenSSL and was writting with security in mind. Drown, Heartbleed, Slowloris, etc, never caused me any trouble.

      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

      • Personally I am less likely to consider Hiawatha if it's beloved by ignorant people....

        Speaking of ignorance...

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

    • >> A quarter of admins don't seem to know how to disable it.

      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)

      by guruevi ( 827432 )

      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.

      • 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

      • 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)

        by Dogers ( 446369 )

        On Windows since at least 2008R2, SSLv2 is explicitly disabled by default..

      • 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)

        by jrumney ( 197329 )
        The default in Apache is not to have an https server set up at all. The instructions I followed 3 years ago for enabling it had SSLv2 and SSLv3 disabled (I just checked my config, and it was already disabled), so maybe these third of all websites are following some guys blog instead of the vendors documentation.
    • SSLv3 is vulnerable to the POODLE attack and other attacks. It doesn't seem like any version of SSL is truly safe. What are the alternatives? Documentation on SSL3 vulnerabilities- https://isc.sans.edu/forums/di... [sans.edu]

  • [REDUNDANT] (Score:5, Funny)

    by darkain ( 749283 ) on Tuesday March 01, 2016 @01:40PM (#51616691) Homepage

    [REDUNDANT]

    Good thing /. isn't vulnerable at all, thanks to its lack of HTTPS support!

  • Absolutely astonished that anyone has SSL v2 enabled. You can pick any modern security standard (like PCI DSS or SSAE16) and it reads something like, "disable all obsolete or vulnerable protocols". I mean, I haven't had SSL v3 enabled on anything I'm responsible for since 2010.

  • Ha ha, no worries here, I don't use SSL on my sites!

    Oh, wait...

Slashdot Top Deals

If all else fails, lower your standards.

Close