Server certificate domain validation bug

[Robin Alden]

We received a report of bugs in the construction of the emails we send out
in order to confirm authorization by the domain name registrant prior to
issuing a server certificate.

Colloquially these are known as Domain-Control Validation Emails.



The security researcher, Matthew Bryant, followed a responsible disclosure
process and we were afforded the opportunity to resolve this bug before he
published his blog post at

https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-
certificates-from-comodo-via-dangling-markup-injection/index.html



We are pleased to report that no certificates were issued contrary to the
terms of our CPS.



We have informed our external WebTrust auditors of the report and of its
resolution.



We will be further engaging with external security consultants to ensure
that our systems remain secure so that we may continue to meet our policy
obligations.



Regards

Robin Alden

Comodo



This email has also been posted to pub...@cabforum.org
<mailto:pub...@cabforum.org>

[Hanno Böck]

Hi,

I just saw this report and my initial reaction was that it seems to be
a grave security risk to use HTML emails with user controlled content
for email domain validation.

I don't see any need for this and would strongly recommend that a
policy forbidding that practice gets implemented. The alternative would
be carefully preventing XSS issues, but honestly, XSS is complicated
and subtle, I don't see it as realistic to prevent all XSS issues.

The domain validation process is one of the most security sensitive
pieces of the CA ecosystem, therefore I recommend that:
* Domain validation mails must not use HTML and must not contain any
user-controlled content.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Nick Lamb]

Hi Robin,

On Friday, 29 July 2016 18:54:56 UTC+1, Robin Alden wrote:
> We received a report of bugs in the construction of the emails we send out
> in order to confirm authorization by the domain name registrant prior to
> issuing a server certificate.
>
> Colloquially these are known as Domain-Control Validation Emails.

Indeed. A few questions arise. First about this specific occurrence, all questions are about the state prior to the incident. It's interesting to hear about things which have changed, but my focus at first is on how things were _before_ you knew about this specific problem.

1. Did Comodo grasp that these emails were a critical element of their CA systems? e.g. do you have a document that calls them out as being important in this way and distinguishes them from marketing communications and other "fluff" that, though it may be important to your business, is not vital to the web PKI ?

2. Was it impressed upon the software engineers responsible for Comodo's software which sends these emails how critical this content was ? Were they given suitable training e.g. based on OWASP in how to make the software secure against well-known risks like this ?

3. Had Comodo engaged a third party to conduct penetration testing of their web site https://secure.comodo.com/ ? If so, did that engagement include these emails as part of the system to be tested ? How often was this testing done ?

4. How long had this bug been present in your production systems, and to what certainty do you know this answer ?

> https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-
> certificates-from-comodo-via-dangling-markup-injection/index.html

Thanks for the link.

> We are pleased to report that no certificates were issued contrary to the
> terms of our CPS.

Two more, this time from the point of view of Comodo after the problem was reported:

5. What methods were actually used to determine whether any certificates had been issued contrary to the terms? Were those methods independent of the specific technique used in this incident, or did they assume that this method was the only possible means by which certificates might be mis-issued by Comodo at this time ?

6. Given the timeline established in question 4, were you able to perform such checks for the whole period affected, or only some of it ?

> We will be further engaging with external security consultants to ensure
> that our systems remain secure so that we may continue to meet our policy
> obligations.

Now a final question from the point of view of the incident having happened, but independent of Comodo itself:

7. In your view what new requirements should be imposed on CAs by CA/B or by the individual trust stores in order to reduce the risk of this sort of incident in future, whether at Comodo or another CA ?

[yuhong...@hotmail.com]

It is not "XSS" BTW when emails don't used JavaScript.

[Gervase Markham]

On 30/07/16 00:03, Nick Lamb wrote:
>> Colloquially these are known as Domain-Control Validation Emails.
>
> Indeed. A few questions arise.

These are good questions. I would also be interested in the answers.

Gerv

[Hanno Böck]

On Thu, 11 Aug 2016 19:08:25 +0100
"Robin Alden" <ro...@comodo.com> wrote:

> Simplicity is certainly a powerful aid to security.
> I like the text-only idea for the DCV emails.

Would you be interested in working on a proposal on that for the
CA/B-Forum? (I'm not allowed to post there, so I can't directly
have that disucssion.)
I'm a bit disappointed that this incident hasn't caused more
discussion. I think the domain validation process is one of the most
sensitive pieces of the CA ecosystem and should receive extra security
care. And the verification emails are an extremely common way of doing
domain validation.

> Not containing any user controlled content is a harder sell, I think,
> because we really want to give the domain owner all the information
> we can about the certificate request that has been submitted.

I understand that use-case, yet I still see a significant risk in any
user-controlled content even in text-only mails (there are most likely
mail implementations out there that can be tricked into rendering html
inside a text-only mail).

I wonder if user-controlled content could at least be restricted to
customers that have some kind of long-term relationship with a CA, e.g.
through payment, contracts etc. Because that business case doesn't seem
to be like something that the average "I want to get a cert quick,
cheap (free) and easy" use case.

If forbidding user-controlled content is a no-go for some I'd like to
see at the very least some very clear and specific guidelines on how to
filter or escape them. What I'd like to have is something that can be
checked and pointed out by security researchers if it isn't done.

[Ryan Sleevi]

On Monday, August 15, 2016 at 5:21:44 AM UTC-7, Hanno Böck wrote:
> Would you be interested in working on a proposal on that for the
> CA/B-Forum? (I'm not allowed to post there, so I can't directly
> have that disucssion.)

https://twitter.com/sleevi_/status/573520611139440641
https://twitter.com/sleevi_/status/657451590110982144

Or just apply as an "Interested Party", as described at https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.4.pdf , as some members of this list already have.

> I'm a bit disappointed that this incident hasn't caused more
> discussion. I think the domain validation process is one of the most
> sensitive pieces of the CA ecosystem and should receive extra security
> care.

The CA/Browser Forum just passed an update to 3.2.2.4, which took nearly two years, which significantly overhauls the system. It could be that

1) People are somewhat exhausted right now after the significant overhaul that just worked to close much more serious lapses in validation methods
2) This is not, in the scheme of things, as significant a risk as some of the other ways to screw up
3) There hasn't been a concrete proposal that attempts to resolve the various concerns between usability, security, and practicality of attack.

> And the verification emails are an extremely common way of doing
> domain validation.

I hesitate to say "citation needed," but I know there's simply no public source that can support that claim of extremely common.

In the grand scheme of things, I don't think this is as urgent a security issue as it would seem you may feel, but I think if you are passionate about finding a solution, and have concrete suggestions and the willingness to understand the tradeoffs, joining/signing the IPR policy and proposing solutions is a great way.

You could, alternatively, propose solutions here as they apply to the Mozilla Policy, in the hope they'll be "upstreamed" to the Baseline, but either way, there's plenty of avenues at your disposal to improve things if you feel.

> I understand that use-case, yet I still see a significant risk in any
> user-controlled content even in text-only mails (there are most likely
> mail implementations out there that can be tricked into rendering html
> inside a text-only mail).

Usually, in cases like this, it helps if you think about the threat models and actually elaborate them, otherwise, there's unlikely to be any improvement or compromise.

I certainly agree with Robin here - that there's a real usability issue for such a blanket ban, and I'm not sure it practically improves things in the grander scheme.

> If forbidding user-controlled content is a no-go for some I'd like to
> see at the very least some very clear and specific guidelines on how to
> filter or escape them. What I'd like to have is something that can be
> checked and pointed out by security researchers if it isn't done.

I'm not sure this is really a practical thing, as you're discussing moreso the hypothetical - indepedendent security researchers doing blackbox testing of the entire CA ecosystem is ... somewhat unreasonable. This is why we have procedures like audits, which ensure a common baseline across the industry. If you think in the mindset of auditable controls (as your first-line defense), rather than thinking blackbox testing (which simply can't scale appropriately to the entire ecosystem to be considered a reasonable defense), it may lead to alternative solutions.

Anyways, if you would like to review what's actually in the BRs, apply an "auditable policy" hat (either through disclosure in CP/CPSes or as samples auditors can perform), that'd be good. Ideally, you want to describe something technically enforcible, so it might be able to examine an entire corpus of emails. But, from experience, I would say it's much easier to say what we'd like to see, and much harder to actually word that in a concrete proposal (either for the BRs or for Mozilla Policy) that can actually be consistently evaluated and enforced.

Cheers!