SSL's DROWN not as bad as Heartbleed, still a security ship wreck 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 …
My understanding is that TLS was a 'rebranding' of SSL when it got to v3.1 (i.e. TLS v1.0 = SSLv3.1) . However reports often seem to mix the terms as we have in this story ( "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.")
So in simple terms is my TLSv1.2 connection vulnerable simply because the server still supports SSLv2 (even if I'm not using it) or only if my connection is actually SSLv2?
And if I'm confused (as an experienced IT person) what hope does the average user have?
...and also, Mr. Cracker (not a hacker) has to know where to look and when to listen to get this job done.
Now, I hope the major banking sites et al are OK.
You could really relate this to say that 70% of homes in the UK have the wrong fuse fitted on electrical items and it could be dangerous - but in reality it isn't - but might be.
If your server supports SSLv2, also connections over TLSv1.2 are at risk. An evesdropper can collect encrypted streams sent over TLSv1.2. He can then use the DROWN attack with crafted packets to get a session key. That session key can be used to decrypt one of the encrypted TLSv1.2 streams.
If your server still accepts SSLv2 connections and you've used the same private key to generate your SSLv2 and TLSv1.2 certificates then you are vulnerable.
If for example it's an Apache web server and it's configured to accept SSLv2 HTTPS connections then a hacker could theoretically use the weaknesses in SSLv2 to reverse engineer the private key being used. Once they have that, they can decrypt all TLS traffic as it's using the same private key.
In practice, this means bombarding the server with SSLv2 connections to work out the private key and then the hacker needs to be able to capture any TLS traffic to your server so that they can decrypt it. That's a lot easier said than done.
The simple solution is just to disable SSLv2 support on your server (unless you know you need it). This seems to be a fairly complex and difficult to achieve hack (unless you're GCHQ) so it's not the end of the world if you haven't yet disabled SSLv2 but I would definitely recommend reviewing what versions of SSL/TLS you currently allow and disable any that aren't needed.
If for example it's an Apache web server and it's configured to accept SSLv2 HTTPS connections then a hacker could theoretically use the weaknesses in SSLv2 to reverse engineer the private key being used.
No, the attack does not reveal the private key, it reveals (or may reveal) a particular session key, so only one message may be compromised (at a time).
Note that for the attack to be as 'easy' as described the suspect server must not only support both SSLv2 an TLS with the same keyset, it must also support 'export grade' (weak) encryption. If the server doesn't support export grade encryption it can still be attacked, but the attack is rather harder.
SSLv2 is inherently insecure to brute force and protocol vulnerabilities, and if cracked then you'll discover the session key, which gives you access to all the data that you captured (for that session) - which is the only reason you need to disable it.
DROWN is different, because you can expose the servers private key used for the connection, this is used to encrypt the session key, if you have the private key, then you can decrypt the handshake to get the session key for any previously captured session (or any future one), and you can do it at real-time speed.
So, if the server supports a legacy SSLv2, you can connect (with your own session, which allows you to snoop/inject/manipulate on your own network), obtain the private key and then use that private key to decrypt anyone else's session - assuming you can also snoop their session (decrypting the handshake to get the session key and any subsequent renegotiation) so, even if somebody is using the latest TLS1.2 with an AES512 session key you can pwn it (as the kids say).
Solution: don't enable SSLv2, OpenSSL is helping you with this by switching it off in a default build - IMHO, this should have happened a bajillion years ago, you could of course dig your own grave, by switching the compile option back on.
>> Solution: don't enable SSLv2, OpenSSL is helping you with this by switching it off in a default build
DROWN is worse than that. Unless your software is specifically configured to block SSLv2 ciphers, a bug in OpenSRS (up until the versions released a few days ago) will let the client still select SSLv2 ciphers and commence the attack.
So, just disabling SSLv2 isn't good enough. Your software needs to be configured to specifically reject all SSLv2 ciphers as well. (or patched within the last few days).
As previously reported, code breaking involves sending lots and lots of probes to a server that supports SSLv2
Given the figures being touted around - circa 40,000 probes (from the same IP address?), it does make you wonder whether websites would be better served to implement better DDOS and probe attack detection - it might prevent the exploitation of other as yet to be published vulnerabilities.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
