2

I maintain a departmental server hosted on a subdomain of my organizational network, as in department.example.com.

Both example.com and department.example.com use HTTPS, but run on completely different machines, use a different Certificate Authority, and use different key pairs.

department.example.com (the server which I am over) does not support SSLv2 or SSLv3; it only support TLSv1.0 and above. The version of OpenSSL on this machine is completely up to date.

However, the example.com subdomain supports SSLv2, and uses a wildcard *.example.com certificate. It uses an out of date version of OpenSSL.


When I ran my website through the DROWN attack vulnerability checker at https://drownattack.com/#check, it still told me that my website was vulnerable (to a man in the middle attack if I read it correctly). If the server key pairs on my subdomain department.example.com are completely separate from the example.com's key pair, my version of OpenSSL is up to date, and I don't support SSLv2, how could I still be vulnerable to the DROWN attack?

Can a "secured" subdomain be vulnerable because of the bad management of the example.com server? If so, how does this work?

2

A not properly configured server can actually make you vulnerable to DROWN, let me show you how. As illustrated in DROWN's original website in order to be vulnerable, one of these 2 conditions has to be met:

  1. The server 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

  2. 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.

DROWN Attack

The second case (the one on the right) is of our interest here. example.com or one of its subdomains support SSLv2 and your server at department.example.com happens to use the same SSL Certificate (which means its using the same public/private key pair). Even if your server only supports TLS protocol and not SSL, the attacker can abuse the one subdomain that uses SSLv2 to do the DROWN attack and decrypt your secure TLS session.

Mitigations

  1. Get other servers which use the same certificate to apply secure configurations and disable old and insecure protocols (SSLv2).
  2. If for any reason number 1 is impossible, get another single domain certificate with fresh keys for your own server on your subdomain. (This is an ugly patchy solution though)
  • I am already using a key pair that is exclusive to the subdomain server, and I am using the key pair only for HTTPS (we do not run a mail server for instance). The key pair on my server is not shared to any other server for any purpose. – therealrootuser Jun 9 '16 at 5:59
  • @mattingly890 in that case I suspect the testing tool didn't check if you're actually using the same public key on both of your certificates or not, and that's a false positive. – Silverfox Jun 9 '16 at 6:01
1

If a site is affected by the DROWN attack only depends on the setup of the server serving this site, not on any relation to other servers. Thus if your server is configured to not support SSLv2 it should not be affected by the DROWN attack.

Which means that either the report is wrong or your site has a different than expected setup or the outside DNS points to a different server than your inside DNS or something else went wrong. Given the information you provide it is impossible to say which of these is the case and the problem can not be reproduced to get more information.

  • If the same certificate (Public/Private Pair) is used on another server which serves SSLv2, you'll be vulnerable. Say your mailserver uses the same certificate as your webserver and supports SSLv2 while your webserver doesn't, in such scenario DROWN attack still applies. – Silverfox Jun 9 '16 at 5:39
  • @Silverfox: of course if the key pair gets compromised because of a successful attack against another server then it is compromised on all places it is used. But this is not specific to DROWN and I don't think that this is the focus of the question. – Steffen Ullrich Jun 9 '16 at 6:15
  • I'm not talking about the key getting compromised, I suggest you have a review on my answer, the image on the right shows how you can mount the attack if the same key is used on a 2nd server which supports SSLv2 and break the TLS channel on your secure server. – Silverfox Jun 9 '16 at 6:18
  • 1
    @Silverfox: I see what you mean and you are right. – Steffen Ullrich Jun 9 '16 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.