1311713 - Comodo: CA Comodo used broken OCR and issued certificates to the wrong people

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[steffen]

Hello,
I tried to find an existing bug about this but I couldn't. I also tried the search function on Comodo.com, but nothing. No mention in their newsroom either.

Per https://www.heise.de/security/meldung/Zertifikats-Klau-Fatale-Sehschwaeche-bei-Comodo-3354229.html (german) Comodo has issued a wrong certificate for a domain of a huge Austrian provider (a few million customers) due to a shocking hole in their procedures. Worse yet, it would appear the programmers of the faulty software were aware of the faults, yet it was still used for a security-critical step in the issuance of certificates.

Following an English summary of the discoveries in the above link:
- Comodo uses WHOIS service to obtain the authorised email address for a domain
- This is not possible for .eu and .be as those do not give email addresses with the WHOIS service
- So for such TLDs Comodo deemed it appropriate to use OCR to parse the picture of the email address returned by web-whois.
- The OCR has a reproducible bug and has trouble differentiating small l and the number 1. It also has trouble differentiating the number 0 and the small o. Instead of fixing the bug or not using such obviously unsuitable software the software apparently evaluates the following characters - if there is a number after the small l it reads the l as the number 1. Similar issues with o/0.
- This was tested with the domain a1-telekom.eu, which had the email [e-mail] registered. As feared Comodo misread this as [e-mail] and sent the email to the wrong address.
- The testers registered altelekom.at and were able to receive the email, use the link and thereby obtain a trusted certificate for a1-telekom.eu.

I see multiple major problems in this incident:
1. It is hard to believe that anyone at Comodo thought it would be a good idea to use OCR for this task. This reminds me of the recent troubles at StartCom
2. It is even harder to believe that this mistake has not been caught by Comodo's internal procedures and raises the question of the effectiveness of these procedures.
3. Given the behaviour of the OCR software it appears clear that at least the authors of the code were aware that is grossly inaccurate. Even if the authors deceived Comodo, this would've been caught in basic testing. Since it wasn't one must assume that Comodo didn't even bother testing the OCR before deploying it in a security-critical function.
4. The fact that there is no mention of this on the Comodo website (assuming Comodo is capable of maintaining a search for their own website - I believe this should be assumed) is disturbing. I searched for the domain a1-telekom.eu as that is the one for which an unpermitted certificate was issued.
5. Either I was too stupid to find the existing bug for this incident, in which case I apologise. But I looked pretty hard. If Comodo indeed didn't report this incident to Mozilla and the other browser vendors it is a further indictment of Comodo.
6. According to the article Comodo said the broken OCR has been in use since late July until it was turned off in late September.

I would like to propose the following action by Mozilla:
1. Require a full report by Comodo over the issue in the OCR.
2. Require a full report as to why this wasn't caught in testing.
3. Require meaningful improvements to internal procedures especially with respect to sign-off on changes to the procedures of issuing certificates and testing.
4. An explanation why this was being kept from Mozilla (if that was indeed the case).

Of course any final consequences will depend on what Comodo can produce in terms of explanation and corrective measures. However, as it stands, I would argue the failure to perform basic testing, the internal procedure problems and the apparent failure to disclose the incident each individually justify revoking trust.

Credit:
The issue was discovered by Florian Heinz and Martin Kluge of Vautron Rechenzentrum AG. I did not verify it and Comodo claims the system has been deactivated in any case. Nevertheless such incidents at the very least need to go on the record, especially as Comodo has made big mistakes in the past.

Comment 1

[Ryan Sleevi]

Comodo notified Mozilla immediately - https://www.mail-archive.com/[e-mail]/msg04654.html

Comment 2

[steffen]

If the timestamp at the top of that link is correct Comodo took 26 days. That is a bit slow. There is also no mention of any procedural or testing changes being looked at. Simply deactivating a system where several independent procedural safeguards (especially testing) should've prevented initial provisioning is not sufficient, I think.
Since Comodo found time to criticise the procedures of the registrars it is especially troubling that there is no indication of any improvements in Comodo's procedures to prevent recurrence of such obvious errors.

Comment 3

[steffen]

In fact, the linked incident report refers to the heise article I also linked. So Comodo chose to "publish" this immediately after it was made public by others. That would be quite a coincidence. This raises the question of whether Comodo would've informed Mozilla at all if the media hadn't picked up on it.

Comment 4

[Ryan Sleevi]

Without wanting to make a statement of fact, and perhaps it's unintentional, but we try to presume good intent and gather details before making accusations of malice. I think as a venue, the most useful thing to do is present your findings and thoughts on the thread linked.

Comment 5

[steffen]

Of course. I thought bugzilla was the place for such things. I did not intentionally imply malice, though I can see how what I wrote could be taken that way. I'll put together everything that isn't already covered in that ML thread and send it there.

Comment 6

[M E]

Status: UNCONFIRMED seems inappropriate now.
Based on the (signed) emails to dev-security-policy, it's certainly confirmed that "CA Comodo used broken OCR and issued certificates to the wrong people".

Arguably, it could be considered RESOLVED.  The tardiness of the reporting has been acknowledged and use of the known-broken 0CR system ceased.

However: 
1)I don't see an indication that the corrective measures have been adequate.  Perhaps one OCR system has replaced another?

Indeed, it is indeed regrettable that the registries in question, .be and .eu, refuse to provide the relevant emails even to CAs so the CAs can do their jobs as reliably and efficiently as they'd like to.  Yet EURid do offer to help, saying, "if you are visually impaired, please contact us at [e-mail]" - which seems worth doing...especially if you have someone visually impaired on staff.


I wonder if .at has the same or a similar issue, because a whois on a1-telekom.at returns no email addresses either.

Comment 7

[Kathleen Wilson]

Rob and Gerv, What's the status of this mis-issuance? Are there action items still pending?

Comment 8

[Robin Alden]

Kathleen,
There are no outstanding actions so far as we are aware.
As we stated in https://www.mail-archive.com/[e-mail]/msg04654.html :
"Comodo's immediate response to the disclosure was ... to disable the use of OCR in the interpretation of WHOIS
responses for the validation new certificate requests."
That remains the case today.  We do not use OCR to scrape any WHOIS results at all.

Regards
Robin Alden
Comodo

Comment 9

[Gervase Markham [:gerv]]

I think this incident can be considered RESOLVED FIXED, as Comodo has ceased use of the offending technology.

Gerv