DROWNing in your own Honeypot

Graham Steel
March 16, 2016
honeypot

The DROWN attack on SSL/TLS has by now been pretty comprehensively covered both here and elsewhere. But two weeks after its announcement, it's clear that it's not being fixed very fast, at least compared to other recent SSL vulnerabilities like Heartbleed. Why not?

One possible explanation, based on the observation that DROWN exploits the long-deprecated SSLv2.0 protocol, is that a lot of these "vulnerable" servers are in fact honeypots: servers deliberately left vulnerable without real data on them to divert or gather intelligence on attackers. We've seen a lot of servers vulnerable to DROWN detected on our webtool at discovery.cryptosense.com in the least two weeks, and decided to follow up on some of them.

To do this, we looked at the logs from our tool and chose two security technology vendors operating servers vulnerable to DROWN. Both sell some kind of cloud security service, so the integrity of their TLS really matters.

One confirmed that the affected server was a honeypot (which we suspected by some other fishy-looking things about its configuration: it seemed to want to handle mail, but mail for the company's domain was being routed elsewhere, etc.), and when we examined the RSA key used by the vulnerable SSLv2 service, we could see that key was not used elsewhere on the site.

However, the other vendor we reported the vulnerability to, running what looked like a honeypot, was using the same wildcard RSA certificate for their honeypot as for their production server. So, an attacker could use the DROWN attack against the honeypot to decrypt live TLSv1.2 traffic on their main server! They were already aware of the issue and are working on fixing the problem.

The lesson is: don't DROWN in your own honeypot. It's a nice illustration of the difference between a cryptographic vulnerability and a regular bug: just fixing the vulnerable server is not enough if it shares cryptographic key material with other services. It's essential to use a separate certificate for servers deliberately left vulnerable.

Go to discovery.cryptosense.com to scan for DROWN and other vulnerabilities in TLS and SSH services.