Domain Validation Vulnerability in Symantec Certificate Authority
Symantec was disregarding
in email addresses when parsing WHOIS records, allowing certificate
misissuance for domains whose WHOIS contacts contained these characters.
The vulnerability has been reported and fixed. Read on for more...
There are three common ways for the requester of a domain-validated SSL certificate to prove control over the domain in the certificate request: add a record to the domain's DNS, publish a file on the domain's website, or respond to an email sent to an administrative address at the domain. The basic idea is that getting a DV certificate should require doing something that only the domain administrator can do. Adding a DNS record is the best way to ensure this: it's unlikely that anyone but the administrator could add records to a domain's DNS. Publishing a file on the domain's website is pretty good too, although some websites accept user uploads in a way that might be abused.
Email validation, on the other hand, is the worst way. Besides being impossible to automate, it's certainly the easiest to abuse. One problem is that the person receiving an email at an "administrative" address might not actually be an administrator. This is a big problem for email service providers who allow users to register arbitrary email addresses at their domains. In 2008, Mike Zusman was able to register the email address email@example.com and use it to approve an SSL certificate for live.com. Back then, certificate authorities allowed you to choose from quite a large list of possible administrative addresses, which compounded the problem. Now, the Baseline Requirements (the rules governing public certificate issuance) define the administrative addresses as admin@, administrator@, hostmaster@, postmaster@, and webmaster@, which helps but is not a panacea: just last year, an unnamed Finn was able to register firstname.lastname@example.org and use it to obtain a certificate for live.fi.
The Baseline Requirements also allow email addresses from the domain's WHOIS record to be used for certificate approval. These addresses don't suffer from the problem above: the WHOIS record is controlled by the domain's registrant, who wouldn't list an email address if it didn't belong to an administrator of the domain. Unfortunately, there's a pretty major implementation pitfall awaiting those who use WHOIS: WHOIS records are not machine-readable. They are unstructured, human-readable text. Even worse, every TLD uses its own format!
How does one take an unstructured, human-readable document, and extract
some bit of information such as an email address from it in realtime?
I suspect that most solutions are going to involve a regular
expression that matches a sequence of characters that look like an email address. What
constitutes a valid email address? The answer may surprise you. The relevant standard,
allows a shocking assortment of characters to appear in the local part (the part
to the left of the at sign) of an email address, including, but not limited to,
If you escape or quote the local part, you can even include control characters, although
the madness of permitting control characters is considered obsolete.
If a certificate authority does not properly consider the full range of characters when
parsing a WHOIS record, they risk extracting the wrong email address for a domain, allowing
an unauthorized party to obtain certificates for it. Last October, I discovered that Symantec's DV certificate
products (RapidSSL, QuickSSL) did not consider
= characters when parsing WHOIS
records. If an email address in WHOIS contained either character, Symantec would treat
the part of the address following the character as a valid administrative address. For example,
if a domain's WHOIS contact was this:
then Symantec would allow the following address to approve certificates for the domain:
This was a serious flaw.
+ is commonly used in email addresses for
which permits email@example.com to be used as an alias for
firstname.lastname@example.org. Several popular email service providers, including
Gmail, Outlook.com, and Fastmail support sub-addressing with the plus
character, and I know from my experience running SSLMate that it is not
uncommon for domain administrators to use an email address such as
email@example.com for their WHOIS contact. An attacker could register
firstname.lastname@example.org and fraudulently obtain certificates from Symantec for
any domain whose WHOIS contact followed this pattern.
As a proof of concept, I set all three WHOIS email addresses of a test domain, cloudpork.com, to email@example.com:$ whois cloudpork.com | grep Email Registrant Email: ALICE+BOB@CLOUDPORK.COM Admin Email: ALICE+BOB@CLOUDPORK.COM Tech Email: ALICE+BOB@CLOUDPORK.COM Registrar Abuse Contact Email: firstname.lastname@example.org
I then went to RapidSSL to obtain a DV certificate for www.cloudpork.com, and was presented with the following choice of email addresses:
I selected email@example.com, received the approval email at that address, and after approving the certificate was issued a valid SSL certificate for www.cloudpork.com, despite firstname.lastname@example.org not being a valid administrative address for cloudpork.com.
I reported the vulnerability to Symantec on October 21, 2015. I also reported it to the four major trust store operators (Google, Mozilla, Microsoft, and Apple), which I believe is appropriate for vulnerabilities in publicly-trusted certificate authorities. Symantec reported that the issue was fixed on October 28, which I confirmed. Symantec then conducted a rather lengthy audit of previously-issued certificates to ensure that this vulnerability had not been exploited. The vulnerability was publicly disclosed yesterday.
In the end, I was able to confirm that Symantec properly handled
. characters in email addresses.
I wish I could have tested with additional non-alphanumeric characters, but I couldn't find a domain registrar who would let me
include such characters in WHOIS. Fortunately, the likelihood of someone
using a special character besides
. in their domain's WHOIS contact is pretty low.
Furthermore, email providers tend not to allow such bizarre characters in email addresses, so if someone
were to use such an email address, it would most likely be hosted at their own domain, where the risk
of the email being misdirected to an unauthorized person would be low.
I'm glad this vulnerability is fixed, but it serves as a reminder that the certificate authority system still has much room for improvement. I have high hopes for Certificate Transparency, a system which would require certificate authorities to log all certificates they issue to public, append-only, and auditable logs (browsers would enforce this by only accepting a certificate if it was accompanied by cryptographic proof of the certificate's inclusion in a log). Domain owners could monitor these logs for certificates related to their domain, so if a vulnerability such as this one were exploited to misissue certificates, it would be detected. The Certificate Transparency experiment is already underway: many certificates have been logged, and can be searched using the awesome crt.sh tool from Comodo. I'm working on some of my own tools to help domain owners use Certificate Transparency; stay tuned!
Post a Comment
Your comment will be public. If you would like to contact me privately, please email me. Please keep your comment on-topic, polite, and comprehensible. Use the "Preview" button to make sure your comment is properly formatted. Name and email address are optional. If you specify an email address it will be kept confidential.