Hanz Ostmaster’s revenge: An SSL Validation issue

Why would I title a blog post with the name 'Hanz Ostmaster'? Don't worry, it's not some new named vulnerability, but it turns out this name has some significance. Do you see it? It requires a bit of imagination - consider a typical email policy: first letter of your first name, last name @ example.com. With our friend Mr. Ostmaster this will result in hostmaster@example.com. Does that seem like a problem to you? Turns out this email address can be a massive issue. To find out why, we need a bit of background.

Many of us are familiar with the concept of Secure Socket Layer (SSL). It is the technology that allows servers to exchange sensitive information such as credit card numbers, social security numbers, and more in a secure manner. It functions by establishing an encrypted link between a server and a client and was first developed in 1994. Currently it is required by PCI and Trustwave is key in its deployment worldwide.

SSL offers a great advantage over a strictly symmetric key system in that its central certificate authority (CA) removes the need of the client to know all the cryptographic keys of every other server it will communicate with. The client simply needs to verify the keys of the CA.. These CA's have their certificates shipped with operating systems and browsers and will vouch for the trustworthiness of sites by 'signing' their site's certificates.

figure 1: Symmetric vs Asymmetric encryption

This, of course, puts an unusually high level of security trust in the CA. A natural follow-up question is: How does one become a trusted CA? At this point the most common answer is that you're a large company (Symantec, Trustwave, etc) for whom there is already a perceived trust.

So if CAs are trusted because their certificates are shipped with browsers and OSs, how do these CAs know if they can vouch for the sites who will ask them to do so. Well, the common sequence of events is as follows:

• Site: Hello I represent example.com and I'd like to get a certificate for my site.
• CA: Howdy, that's all great, but I need proof you're the owner of example.com
• Site: Here is my proof. (we are leaving this intentionally vague)
• CA: Wonderful, I will sign your certificate and you can present that as proof that you are actually example.com.
• Site: Thanks CA, have a great day.

Verifying the legitimacy of the client is the topic of today's post. There are a number of different methods that ICANN has specified for allowing CA's to verify sites/users:

• HTTP Validation – Can be performed by uploading a special text/html file into the root directory of the domain name.
• DNS-based validation - For this validation method you need to create a certain CNAME record in the DNS settings of your domain.
• Email Validation – Users will be validated by an email that belongs to the domain

Of those you may be most surprised by the email validation option, as sites often give out email addresses belonging to their domain (anyone have a Gmail account for instance?). It's important to know that until late 2015 there was no strict specification on which email addresses could be used for verification by the CA. This ambiguity ended up manifesting itself as CERT Vulnerability note 591120 (https://www.kb.cert.org/vuls/id/591120). The notice specified 16 certificate authorities as affected (the status of many others was unknown) and noted that it was not possible for site administrators to know which email addresses should be reserved for SSL use. If an admin is not aware of all the sensitive email addresses and allows users to be assigned one, this can lead to a duplicate certificate being issued for their domain. In a short survey the following addresses were allowed by various CAs to register certificates, but strictly speaking it was up to each CA to determine which email addresses were acceptable:

• admin@yourdomain.com
• administrator@yourdomain.com
• webmaster@yourdomain.com
• ssladmin@yourdomain.com
• root@yourdomain.com
• hostmaster@yourdomain.com
• postmaster@yourdomain.com
• ssladministrator@yourdomain.com
• it@yourdomain.com

This is coupled with another issue, CAs don't communicate amongst themselves, so if a CA was asked to signed a certificate for www.example.com, it wouldn't check if any other CA had already signed a valid certificate for that domain. In fact, many organizations have taken to doing this on their own as part of their Incident Repsonse practices.

The fix was rather straightforward. CAs were instructed to only use the email addresses specified in RFC2142 - MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. The only exception is that CAs were also allowed to use the email listed in the WHOIS contact for the domain being registered. Beyond the whois email, the only allowed email addresses after the fix should be:

• PostMaster@example.com - Reserved for SMTP
• Hostmaster@example.com - Reserved for DNS
• Webmaster@example.com - Reserved for Web

This largely solved the underlying problem but every CA in existence needs to update their policies accordingly, otherwise the issue isn't fixed. At the time of writing it was still possible to find some CAs whose policies did not conform to this guidance. This means that given a situation such as that in the image below, all one would have to do is find a CA that still allows registering that email address (ssladmin@...) and, just like that, a valid certificate for the domain would be given to a potentially malicious actor.

figure 2: setting up an email to register a certificate

So everything's good once the fix is in place, right? Well, no. It turns out that the vast majority of technical folks don't know that the three email addresses listed should be reserved in order to safeguard their SSL security. Sure most people know about postmaster - but when surveying a room of security professional at BSides-Rochester 2016, only two raised their hand in recognition that hostmaster should be a sensitive (and therefore reserved) email address.

There is also a little issue here about trust. One of the popular services that domain registrars will push when you sign up, is free, or low cost, whois protection (like whoisgaurd). The problem here, is that if you sign up for that service it is effectively possible for anyone who can generate whoisgaurd email addresses to register an SSL cert on behalf of your site. This is demonstrated below:

figure 3: using a whoisguard email address

Ok, there are some problems here, but how often can you really register these email addresses. Certainly hostmaster@gmail.com is already taken (it is) and there aren't often situations where you can access someone else's email account. It turns out there is one big location where this rule relaxes. There are a number of services that offer anonymized email access.

What makes these targets so great is they often let you not only have email accounts on their domain, but they will allow others to point their MX record to their SMTP server. This trick makes getting around domain blocking simple. However it also potentially makes all the domains that have their MX record pointing to a given SMTP server vulnerable to having their SSL certificates registered by a malicious entity.

So how common is this issue? Well, it turned out that every service I tested was vulnerable with the exception of mailinator.com.

figure 4: using a hostmaster account to provide CA verification


While some were very easy, to access such as maildrop.cc, others often tried to be more intelligent about security. Most would not directly allow me to check 'hostmaster@example.com' but given spaces, case, dots, null characters, etc. almost all services tested were vulnerable. In the end I ended up with temporary certificates for quite a few of these domains some of which are shown below.

figure 5: domains validated for certificate signing using this technique

Generally there are some easy steps to fixing mitigating these issues. From the consumer side if possible you should pin your certificates and use the HPKP header if supported. Also, if it is financially feasible, you should consider an extended validation (EV) certificate. These EV certificates require additional scrutiny to get and are presented in a different manner than conventional certificates.

CAs can also improve this process and many CA's are moving away from email based authentication for the very reason we described. Hopefully in the future we will also see some better communication between CAs to prevent the types of issues described.