The discovery of a HTTPS encryption vulnerability, dubbed DROWN, again proves that supporting tired old protocols weakens modern crypto systems.
DROWN (aka Decrypting RSA with Obsolete and Weakened eNcryption) is a serious design flaw that affects HTTPS websites and other network services that rely on SSL and TLS – which are core cryptographic protocols for internet security.
DROWN basically allows a miscreant to snoop on and decrypt a victim’s encrypted web connections, allowing crooks to swipe passwords and so on.
http://www.theregister.co.uk/2016/03/01/drown_crypto_flaw_analysis/
Posted from WordPress for Android
7 Comments
Tomi Engdahl says:
One-third of all HTTPS websites open to DROWN attack
Hackers can break TLS using SSLv2
http://www.theregister.co.uk/2016/03/01/drown_tls_protocol_flaw/
Security researchers have discovered a new technique for deciphering the contents of supposedly secure communications.
The DROWN attack – it has already got a name, like recent high profile crypto attacks Lucky13, BEAST, and POODLE – is a “cross-protocol attack that can decrypt passively collected TLS sessions from up-to-date clients”.
One version of the attack exploits a combination of thus far unnoticed protocol flaws in SSLv2 to develop a new and stronger variant of the earlier Bleichenbacher attack. “A typical scenario requires the attacker to observe 1,000 TLS handshakes, then initiate 40,000 SSLv2 connections and perform 250 offline work to decrypt a 2048-bit RSA TLS cipher-text,” the researchers explain.
Number-crunching using supercomputers is not needed to pull off the attack, which is way below the level of sophistication of intel agencies. A team of researchers from universities in Germany, the US and Israel as well as two OpenSSL developers – implemented the attack and can decrypt a TLS 1.2 handshake using 2048- bit RSA in under eight-hours using Amazon EC2, at a cost of $440.
The DROWN Attack
https://drownattack.com/
Tomi Engdahl says:
SSL’s DROWN not as bad as Heartbleed, still a security ship wreck
Just set SSLv2 on fire
http://www.theregister.co.uk/2016/03/02/drown_exploitability_analysis/
Security experts are split on how easy it is for hackers to exploit the high-profile DROWN vulnerability on insecure systems.
One-third of all HTTPS websites are potentially vulnerable to the DROWN attack, which was disclosed on Tuesday. DROWN (which stands for Decrypting RSA with Obsolete and Weakened eNcryption) is a serious design flaw that affects network services that rely on SSL and TLS. An attacker can exploit support for the obsolete SSLv2 protocol – which modern clients have phased out but is still supported by many servers – to decrypt TLS connections.
As previously reported, code breaking involves sending lots and lots of probes to a server that supports SSLv2 and reuses the same private key across multiple protocols.
Threat intel consultancy iSight Partners has concluded following an initial analysis of the problems that the vulnerability poses only a moderate threat to users.
Widespread exploitation of the flaws by hackers is unlikely, according to iSIGHT Partners.
“Since the attacker needs to be in a position to intercept traffic, we believe most victims will be targets of opportunity, not targeted. Therefore, we anticipate limited actor interest and do not expect widespread exploitation.”
Tod Beardsley, security research manager at Rapid7, the firm behind Metasploit, conceded that a potential hacker would already need to be on a targeted network. He nonetheless suggested it’s too early to downplay the significance of the flaw.
Tomi Engdahl says:
Learn things? DROWN HTTPS flaw proves we don’t even test things
You knew SSLv2 was poison, so why was it still there?
http://www.theregister.co.uk/2016/03/02/drown_proves_people_didnt_test_their_servers_after_poodle/
In the wake of the DROWN vulnerability, organisations like the Australian Signals Directorate that offer security incident mitigation strategies might consider adding another item to their lists: test your configuration to make sure it’s what you expected.
The DROWN flaw in HTTPS would not be anything to worry about, except that developers working on server-side software made the fatal assumption that since there were no clients left to request a deprecated SSL connection, they didn’t need to update their code to kill older SSL completely.
We now know that assumption was wrong. DROWN is a cross-protocol attack: the buggy code in SSL v2 implementations is what enables the decryption attack on vastly more secure TLS encryption. This was compounded by a now-fixed bug that meant admins could configure a system thinking that SSLv2 was off, but have it sitting there still supported anyhow.
In other words: if you believed your configuration was secure without going back to test it, you may have ticked all the boxes in your “best practice” list and remain vulnerable.
Are people going back to run post-configuration tests? All too rarely, it seems. According to the Australian Communications and Media Authority’s daily publication of a third-party’s scan (Shadowserver, here) of the country’s address space, a stunning 180,000 hosts here are still vulnerable to POODLE. Similar results are to be expectd around the world.
It’s easy to blame the user – to say “if you had SSL v3 enabled it’s your fault”. And sysadmins were already on notice: the POODLE vulnerability of 2014 was a get-rid-of-SSL warning.
Tomi Engdahl says:
DROWN – Cross-protocol attack on TLS using SSLv2 – CVE-2016-0800
https://access.redhat.com/security/vulnerabilities/drown?elqTrackId=67dc1b3dc8844d57adc968b89978fb1f&elq=f40ea053bad549f2a62033bfc187e5ac&elqaid=25444&elqat=1&elqCampaignId=105781
Red Hat Product Security has been made aware of a vulnerability in the SSLv2 protocol, which has been assigned CVE-2016-0800 and is used in a cross-protocol attack referred to as DROWN – Decrypting RSA using Obsolete and Weakened eNcryption. This issue has been rated as Important .
Background Information
A group of security researchers discovered that SSLv2 (Secure Sockets Layer protocol version 2.0) is vulnerable to the Bleichenbacher RSA padding oracle attack, which can be used to decrypt RSA cipher text without the knowledge of the matching private RSA key. This can be done by observing responses from a server that has the private key and performs the decryption of attacker-provided cipher texts using that key. The researchers also demonstrated a new cross-protocol attack which allows decryption of SSL/TLS sessions using newer protocol versions – SSLv3 or any current TLS (Transport Layer Security) version (1.0 – 1.2) – using this SSLv2 weakness. This flaw is a SSLv2 protocol issue and affects all implementations of the protocol. Researchers refer to this attack as general DROWN.
Additionally, flaws were found in the SSLv2 protocol implementation in the OpenSSL cryptography and SSL/TLS library, which make it possible to perform a more efficient variant of the DROWN attack, referred to as special DROWN. These issues were assigned CVE-2016-0703 and CVE-2016-0704 , and were already recently corrected as part of the fix for CVE-2015-0293 .
Tomi Engdahl says:
OpenVPN vs DROWN from https://www.reddit.com/r/VPN/comments/48h7qg/new_vulnerability_the_drown_attack_impacts/
how might it be possible to misconfigure OpenVPN to use SSLv2?
You don’t have to, you just have to reuse of the cert on something that does talk SSLv2. Unlikely but who knows what odd things people do.
Long and short of it is if you have any service that talks SSLv2 or v3 they should be tweaked to only talk TLS
I don’t have any idea how it could possibly work, because of the issue you mentioned. I too can’t even purposefully get an SSLv2/v3 connection working over OpenVPN, so I don’t see how you could do it unless your build of OpenVPN was ancient.
This definitely doesn’t impact anyone running a build of OpenVPN made in the last 5 years, unless i’m missing some novel method of attack.
Tomi Engdahl says:
The DROWN Attack
https://drownattack.com/
What can the attackers gain?
Any communication between users and the server. This typically includes, but is not limited to, usernames and passwords, credit card numbers, emails, instant messages, and sensitive documents. Under some common scenarios, an attacker can also impersonate a secure website and intercept or change the content the user sees.
Who is vulnerable?
Websites, mail servers, and other TLS-dependent services are at risk for the DROWN attack, and many popular sites are affected. We used Internet-wide scanning to measure how many sites are vulnerable:
Is my site vulnerable?
Modern servers and clients use the TLS encryption protocol. However, due to misconfigurations, many servers also still support SSLv2, a 1990s-era predecessor to TLS. This support did not matter in practice, since no up-to-date clients actually use SSLv2. Therefore, even though SSLv2 is known to be badly insecure, until now, merely supporting SSLv2 was not considered a security problem, because clients never used it.
DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.
A server is vulnerable to DROWN if:
It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our measurements show that 17% of HTTPS servers still allow SSLv2 connections.
or:
Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same certificate and key on their web and email servers, for instance. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. When taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS servers at risk.
How do I protect my server?
To protect against DROWN, server operators need to ensure that their private keys are not used anywhere with server software that allows SSLv2 connections. This includes web servers, SMTP servers, IMAP and POP servers, and any other software that supports SSL/TLS. You can use the form above to check whether your server appears to be exposed to the attack.
Disabling SSLv2 can be complicated and depends on the specific server software. We provide instructions here for several common products:
OpenSSL: OpenSSL is a cryptographic library used in many server products. For users of OpenSSL, the easiest and recommended solution is to upgrade to a recent OpenSSL version. OpenSSL 1.0.2 users should upgrade to 1.0.2g. OpenSSL 1.0.1 users should upgrade to 1.0.1s.
Microsoft IIS (Windows Server): IIS versions 7.0 and above should have SSLv2 disabled by default. (A small number of users may have enabled SSLv2 manually and will need to take steps to disable it.)
Network Security Services (NSS): NSS is a common cryptographic library built into many server products. NSS versions 3.13 (released back in 2012) and above should have SSLv2 disabled by default.
Other affected software and operating systems:
Instructions for: Apache, Postfix, Nginx
Browsers and other clients: There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack.
Full technical paper
DROWN: Breaking TLS using SSLv2 [PDF]
https://drownattack.com/drown-attack-paper.pdf
Tomi Engdahl says:
OpenSSL Patches TLS Flaw Exposing Many HTTPS Servers
http://www.securityweek.com/openssl-patches-tls-flaw-exposing-many-https-servers
he OpenSSL Project has released updates to patch several vulnerabilities in the crypto library, including a high severity TLS issue that can be exploited to crack encrypted communications and steal potentially sensitive data.
A team of researchers has published a paper on “DROWN” (Decrypting RSA with Obsolete and Weakened eNcryption), a cross-protocol attack method that involves SSLv2, an old version of the protocol that is still supported by many servers.
The vulnerability, tracked as CVE-2016-0800, is believed to affect a quarter of the top one million HTTPS domains and one-third of all HTTPS websites.
“A typical scenario requires the attacker to observe 1,000 TLS handshakes, then initiate 40,000 SSLv2 connections and perform 2^50 offline work to decrypt a 2048-bit RSA TLS ciphertext,” researchers explained in their paper. “We implemented the attack and can decrypt a TLS 1.2 handshake using 2048-bit RSA in under 8 hours using Amazon EC2, at a cost of $440.”