Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/WoSign Issues: Difference between revisions
Jump to navigation
Jump to search
Update N and P
(Initial draft) |
(Update N and P) |
||
| Line 108: | Line 108: | ||
It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report. | It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report. | ||
==Incident N: | ==Incident N: Additional Domain Errors (June 2015)== | ||
''(a.k.a. "Incident 1")'' | ''(a.k.a. "Incident 1")'' | ||
In June 2015, an applicant found | In June 2015, an applicant found some problems with WoSign's free certificate service. There were actually two bugs, which we will denote N1 and N2. | ||
Bug N1 was an issue where someone proving control of <subdomain>.example.tld also was given a cert covering example.tld. | |||
Bug N2 was an issue where arbitrary domains can be added to an existing request after validation. | |||
* The lack of revocation of the ucf.edu certificate strongly suggests that WoSign either did not or could not search their issuance databases for other occurrences of the same problem. Mozilla considers such a search a basic part of the response to disclosure of a vulnerability which causes misissuance, and expects CAs to keep records detailed enough to make it possible. | The reporter proved that there was a problem in two ways. They accidentally discovered that there was a problem when trying to get a [https://crt.sh/?id=29805563 certificate] for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then used their control of schrauger.github.com/schrauger.github.io to get [https://crt.sh/?id=29647048 a cert] for github.com, github.io, and www.github.io. They also obtained [https://crt.sh/?id=29805567 another github cert] using a different subdomain of github.io. These are both, in fact, instances of bug N2. | ||
They reported this to WoSign, giving only the Github certificates as an example. Those certs were revoked. However, no further investigation was performed, and several other certificates were misissued subsequently. The bugs were fixed two months later, on August 10th, in an unrelated major update. | |||
* Recently, the reporter of the issue got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later. The lack of revocation of the ucf.edu certificate strongly suggests that WoSign either did not or could not search their issuance databases for other occurrences of the same problem. Mozilla considers such a search a basic part of the response to disclosure of a vulnerability which causes misissuance, and expects CAs to keep records detailed enough to make it possible. | |||
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed." | * The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed." | ||
| Line 130: | Line 134: | ||
[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33. | [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33. | ||
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report]. | 2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report]. The report explains the two bugs, N1 and N2. WoSign classifies the misissuances as 21 N1 and 12 N2. However, they have misclassified one - line 2 of Figure 14 - so the actual numbers are 20 N1 and 13 N2. | ||
====Bug N1==== | |||
N1 allowed an applicant to get a certificate for the base domain if they were able to prove control of any subdomain. According to WoSign, this was caused by an engineer misunderstanding the rule that if a base domain was validated, the "www" variant could be added for free. He instead applied the rule in the other direction. | |||
====Bug N2==== | |||
Issue N2 is described in the report as follows: | |||
<blockquote><i> | |||
This mis-issued certificate was a system vulnerability that when the subscriber finished the domain validation, they can add any domain before submitting this order to system. | |||
</i></blockquote> | |||
Looking at their list of misissued domains in the report, this really does mean "any domain". For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. This effectively bypasses domain validation for any attacker who owns a domain of their own. | |||
===Further Comments=== | |||
* | * An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw. It is not clear whether it was possible to do this in the standard workflow or if it required hacking form parameters. Given the number of misissued certs, the former seems more likely. | ||
* The report seems to suggest an "issue first, ask questions later" approach whereby a cert is issued to the subscriber even if it is flagged as questionable, and the remediation mechanism is revocation rather than lack of issuance. Furthermore, their validation team works 9-5, so an applicant could have many hours to abuse a misissued certificate before it was discovered. | * The report seems to suggest an "issue first, ask questions later" approach whereby a cert is issued to the subscriber even if it is flagged as questionable, and the remediation mechanism is revocation rather than lack of issuance. Furthermore, their validation team works 9-5, so an applicant could have many hours to abuse a misissued certificate before it was discovered. | ||
| Line 144: | Line 158: | ||
* Although it seems like the system issued a certificate which did not match what was validated, this was not investigated further. The report says: "the employee treated it as an unusual case that did not reported it as a bug." This is amazing, if true. If WoSign's employees don't think that misissuing a certificate is a big deal, something is quite badly wrong. | * Although it seems like the system issued a certificate which did not match what was validated, this was not investigated further. The report says: "the employee treated it as an unusual case that did not reported it as a bug." This is amazing, if true. If WoSign's employees don't think that misissuing a certificate is a big deal, something is quite badly wrong. | ||
* The | * The report seems surprised that the applicant did not follow the WoSign Terms of Use. I would not expect an actual attacker to care about the WoSign Terms of Use. | ||
* The certificate involved here were all clearly misissued; even if the person could have proved control of the parent domain, they did not do so during the process. Therefore, failure to revoke these certificates immediately (as WoSign argued it didn't need to during the public discussion) constitutes a further BR violation, as per Section 4.9.1.1 of the [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf BRs], in particular, item 4 and item 9. | * The certificate involved here were all clearly misissued; even if the person could have proved control of the parent domain, they did not do so during the process. Therefore, failure to revoke these certificates immediately (as WoSign argued it didn't need to during the public discussion) constitutes a further BR violation, as per Section 4.9.1.1 of the [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf BRs], in particular, item 4 and item 9. | ||
| Line 156: | Line 170: | ||
* [https://crt.sh/?id=30773511 1st SM2 cert in crt.sh]; [https://crt.sh/?id=30613201 cert with same serial number in crt.sh] | * [https://crt.sh/?id=30773511 1st SM2 cert in crt.sh]; [https://crt.sh/?id=30613201 cert with same serial number in crt.sh] | ||
* [https://crt.sh/?id=30773585 2nd SM2 cert in crt.sh]; [https://crt.sh/?id=30613200 cert with same serial number in crt.sh] | * [https://crt.sh/?id=30773585 2nd SM2 cert in crt.sh]; [https://crt.sh/?id=30613200 cert with same serial number in crt.sh] | ||
Secondly, for the first pair of certs, the validity period is 4 years, which is 9 months longer than allowed by the BRs. | |||
===WoSign Response=== | ===WoSign Response=== | ||
| Line 194: | Line 210: | ||
''(a.k.a. "Incident 2")'' | ''(a.k.a. "Incident 2")'' | ||
In July 2016, it became clear that there was some problems with the StartEncrypt automatic issuance service recently deployed by the CA StartCom. | In July 2016, it became clear that there was some problems with the StartEncrypt automatic issuance service recently deployed by the CA StartCom. This was a StartCom-branded service and was not publicised as being able to issue certificates from WoSign. However, changing a simple API parameter in the POST request on the submission page changed the root certificate to which the resulting certificate chained up. The value "2" made a certificate signed by "StartCom Class 1 DV Server CA", "1" selected "WoSign CA Free SSL Certificate G2" and "0" selected "CA 沃通根证书", another root certificate owned by WoSign and trusted by Firefox. | ||
Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm. (XXX To investigate: did the chain contain some SHA-256 certs?) | Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm. (XXX To investigate: did the chain contain some SHA-256 certs?) | ||
| Line 202: | Line 218: | ||
* The issuance of backdated certificates is not forbidden, but is included in [https://wiki.mozilla.org/CA:Problematic_Practices#Backdating_the_notBefore_date Mozilla's list of Problematic Practices]. It says "Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not." | * The issuance of backdated certificates is not forbidden, but is included in [https://wiki.mozilla.org/CA:Problematic_Practices#Backdating_the_notBefore_date Mozilla's list of Problematic Practices]. It says "Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not." | ||
* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "[https://bugzilla.mozilla.org/show_bug.cgi?id=1293366#c3 this date is the day we stop to use this code]". If that is true, it is not clear to us how StartCom came to | * WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "[https://bugzilla.mozilla.org/show_bug.cgi?id=1293366#c3 this date is the day we stop to use this code]". If that is true, it is not clear to us how StartCom came to be able to call WoSign code that WoSign itself had abandoned. | ||
* The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed." | * The misissuance incident was not reported to Mozilla by WoSign as it should have been. Section 1 of the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla CA Certificate Enforcement Policy] says: "When a serious security concern is noticed, such as a major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed." | ||
| Line 216: | Line 230: | ||
* This incident does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice. | * This incident does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice. | ||
* The question of why StartCom was | * The question of why StartCom was able to trigger certificate-issuance code which WoSign has stopped developing and maintaining is also still open. | ||
==Other Points of Note== | ==Other Points of Note== | ||
* While not a violation of any Mozilla policy, WoSign has promised to log all certs to CT after a certain date, and yet has not yet managed to comply with the Chrome CT policy of logging to at least one Google and one non-Google log. Arguably, this speaks to competence. | * While not a violation of any Mozilla policy, WoSign has promised to log all certs to CT after a certain date, and yet has not yet managed to comply with the Chrome CT policy of logging to at least one Google and one non-Google log. Arguably, this speaks to competence. | ||