Many of you may have heard about the DROWN attack on SSL/TLS encryption in the media over the last week or so, not to mention previous issues such as the Heartbleed Bug. I wanted to take a moment though to talk about the former and its impact on businesses worldwide.
“DROWN” stands for “Decrypting RSA with Obsolete and Weakened eNcryption.” For those of you of a technical inclination, you can read the technical paper or for a less technical discussion, simply visit the DROWN website. The long and short of it is that given the proper situation, it is possible to attack the encryption of the relatively secure TLS protocol, through SSLv2, in a way that it would be possible to decrypt the contents of encrypted network traffic at a relatively low cost. The core issue is that although TLS is reasonably secure, SSL is not and servers that run both can lead to a compromise of the more secure protocol.
The attack requires two essential elements:
- The ability to intercept (or “Man in the Middle” attack) a client’s connection. This typically means getting access to the local network of the client or one of the networks that the client’s traffic passes through. While this may seem like a significant barrier, it is often easier than you think, particularly with access to the local network and tools such as Responder.py.
- Servers that support both TLS and SSL encryption. Although it is often the case that this means web servers, it is not always so, and can often include services such email (IMAPS, POP3S, SMTPS) or file transfer (FTPS). In fact, SSL has been deprecated for some time and the IETF has explicitly said not to use it. Similarly, for those subject to PCI (credit card data handling), removing SSL will soon be required for compliance. As an IT professional, I would be especially concerned about services that have any type of authentication.
In addition to these two main issues, there are a few other requirements that I believe need to be in place for this attack to succeed:
- Fast computation. The attack relies on the ability to perform a cryptographic attack within the default TLS timeout, which is stated to be one minute. This can easily be done with modern cracking hardware, and the paper authors were able to do this using cloud servers well within the timeout period and for a very reasonable price.
- A decent network connection. In order for the attack to work, it is necessary to make a number of connections to the TLS server in order to perform the attack. The authors were able to do this quite handily, but it appears that they were doing this at Ethernet speed. Ironically, a very bad web server on a slow connection might increase security in this regards.
In order to minimize this risk, I strongly suggest that you assess (at the least) your Internet facing servers for this vulnerability. There are a few ways to do this:
- Use the lookup tool on the DROWN attack website to determine if your Internet facing servers have the vulnerability. There is also a client-side scanning tool hosted on GitHub.
- Perform a vulnerability assessment or penetration test. If you use a modern scanning tool such as Tenable’s Nessus, you can quickly and easily do this yourself right now at minimal cost. There are also any number of service providers (including CDW) that can do this for you. I strongly suggest you scan all of your devices on all ports, as SSL can live on many areas you might not expect, including database servers, embedded devices and network appliances that may not be part of your normal patch cycle. Start with external servers, to be sure, but don’t neglect the internal systems either as getting internal access is probably not as hard as you think!
- Use a passive monitoring device to identify vulnerable servers. Many intrusion prevention devices can detect this risk. CDW offers a zero-cost assessment service known as the “CDW Threat Check” that can also detect this risk.
- Manually patch your servers. Consult your vendor’s resources for the most effective approach.