Changes

==Incident N: Subdomain Additional Domain Errors (June 2015)==

In June 2015, an applicant found a problem some problems with WoSign's free certificate service. There were actually two bugs, which allowed them to get a certificate for the base domain if they were able to prove control of a subdomainwe will denote N1 and N2.

The reporter proved the problem in two ways. They accidentally discovered it when trying to get a [https://crt.sh/?id=29805563 certificate] for med.ucf.edu and mistakenly also applied for www.ucf.edu, which Bug N1 was approved. They then confirmed the problem by using their an issue where someone proving control of schrauger<subdomain>.githubexample.com/schrauger.github.io to get [https://crt.sh/?id=29647048 tld also was given 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 githubcovering example.iotld.

They reported this Bug N2 was an issue where arbitrary domains can be added to WoSign, giving only the Github certificates as an example. Those certs were revoked and the vulnerability was fixed. However recently, the reporter got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year laterexisting request after validation.

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.

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:

WoSign state that there were two bugs Looking at their list of misissued domains in play herethe 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.

* The second root cause An arbitrary unvalidated ownership domain misissuance bug is that if www.examplean extremely serious flaw.tld It is validated, not clear whether it was possible to do this in the code gave a cert covering examplestandard workflow or if it required hacking form parameters.tld as wellGiven the number of misissued certs, which is clearly incorrectthe former seems more likely.

* The response 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.

In July 2016, it became clear that there was some problems with the StartEncrypt automatic issuance service recently deployed by the CA StartCom. In particularThis 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.

* 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 deploy be able to call WoSign code that WoSign itself had abandoned. * It seems clear from publicly available information that StartCom's issuance systems are linked to WoSign's issuance systems in some way. Nevertheless, it should not have been possible for an application for a cert from StartCom to produce a cert signed by WoSign.

* The question of why StartCom was deploying able to trigger certificate-issuance code which WoSign has stopped developing and maintaining is also still open.