We’ve gotten over our bleeding hearts, our fear of Poodles, and we learned not to Freak out in 2015, it seemed like we were due for another test of the TLS (aka SSL) infrastructure security. That came with the launch of a new vulnerability notice called Drown.
Drown stands for for Decrypting RSA with Obsolete and Weakened eNcryption. Yes, the vulnerabilities seem to have marketing teams these days complete with acronyms and logos at the release of the CVE notice.
What is Drown?
There is a full paper which goes into the details (https://drownattack.com/drown-attack-paper.pdf). In fact, this is one that is a worthy read if you like to nerd out like I do. The gist of the situation is that this an attack on the SSLv2 protocol which has been widely known to be challenged, but is still active on many web server environments.
It is described as a cross-protocol Bleichenbacher padding oracle attack. The attack itself requires time and a relatively brute force attack method. Using the computation from the detailed paper, it is estimated that an EC2 attack would require 40,000 attempts.
The mitigation strategy is relatively simple with this one as long as you just disable SSLv2 on your web server except that it’s used everywhere, and can be challenging to do this easily. Protecting your private keys and ensuring they aren’t used by software that uses SSLv2 is the best way.
At the time of the publishing of the article there is not much detail on known, active exploits of the bug, and we should find out more in the coming days on the extent of the vulnerability. We will also see lots of notices coming from vendors over the approaching couple of weeks as well. Given the reach of OpenSSL, this will be one that stretches across on-premises and cloud environments alike. Widely reaching at that.
Who is affected?
A lot of servers. At the moment, it’s estimated that 25% of the top million domains are affected as you can see from this chart:
The best way to know for sure is to use the domain checker that has been provided here: https://test.drownattack.com/
There is no harm in trying it, and denying what’s a potential vulnerability is dangerous. Using TLS/SSL is something that we should all be doing to protect data in transit.
Safer in Open Source
Despite what many would think, the open source ecosystem driving OpenSSL is not weaker as a result of these vulnerabilities. We should recognize that many of the issues discovered in the lifetime of OpenSSL have been because of the openness of the code and the collaborative ecosystem.
Thinking that a closed source product would be more effective against these types of vulnerabilities is not only silly, but it’s irresponsible. There is a reason that the second Tuesday of each month is known as Patch Tuesday thanks to Microsoft. Apple releases security fixes regularly also, so don’t go getting all smug because you have a little lit up fruit on the back of your laptop.
When the Heartbleed vulnerability was discovered, it also proved out that many, if not most, vendors who use SSL within their closed source products were actually using OpenSSL to power that part of their infrastructure. The end result is that the open community made their products safer when it discovered the fixes.
It's a wild ride in the infrastructure security realm. This hammers home the importance of automation, systems management, and systems thinking. Let's not let this one sit idle and then be caught saying "I don't know what happened" in 6 months when something does take advantage of this, or another vulnerability.
Image sources: http://drownattack.com