Did the submitter include any timeline? Happy to CC them on this bug to remove an intermediate communication step.

I've attached the cert itself, which wasn't logged to CT, nor did WoSign issue any public incident report (to root stores or to the CA/B Forum).

Deleted: wosign.pem 1.7 KB

wosign.pem 1.7 KB Download

I mentioned to Patrick the behaviour of Chrome (which is "Respect if OS has cached revocation, but don't actively fetch it"), while the OS UI we use does actively fetch it (there's a bug about it for OS X). The added twist to the OS X story is that OS X supports loading cached CRLs, but they biffed up how cached OCSP is handled, so even if the OS has a cached OCSP response, we can't reach it from Chrome. This is part of the "revocation is bad and should feel bad story"

Actions:
1) Try to get details about when this certificate was issued or other certificates that may have been misissued.
2) Internal discussions to be held about appropriate steps to protect Chrome users
3) Minimally, adding this cert to CRLSets, as well as any other the reporter can provide, if we can reach them
4) Notify other root stores (Microsoft, Mozilla, Apple) of this incident, as we have with the other WoSign issues of recent.

Oh, Ryan Sleevi asked me to also indicate if we are ok with sharing details to other root stores (MSFT, Apple, Mozilla). That is fine. 

Ryan - I don't have additional timeline details. What do you need to CC in the original reporter (an email address associated with a chrome bug tracker login I would assume)?

Yup, that'd work :)

You can add dymutaos@gmail.com to this thread so he can provide additional details. 

Thanks Patrick, added.

dymutaos@, could you check out Comment #1?

Ryan,

Here's a basic timeline of how I found the bug:

On June 9, 2016, I was attempting to get an SSL/TLS certificate for the subdomain “med.ucf.edu” from the Certificate Authority “WoSign”.

WoSign, like all certificate authorities, requires you prove that you own the domain in order to get a certificate from them. And like many CAs, they gave me a small text file to upload to the website in order to provide proof. After WoSign verified they could read the file, they approved that subdomain for my Certificate Signing Request (CSR).

Out of habit, I added “www” as an alternate domain. However, I accidentally added “www.ucf.edu”, rather than “www.med.ucf.edu”, which I was trying to add. Much to my surprise, WoSign did not require that I prove ownership over “www.ucf.edu”. When I continued with the CSR, they accepted both domains and gave me their signed public certificate, valid for 3 years.

After double-checking, I found that indeed, I was able to use the certificate for both “med.ucf.edu” (my domain). And I could use it for “www.ucf.edu”, the main campus domain, which I most certainly do not control!

This led me to try another site: github.com. Github lets its users create their own subdomain and control it completely. I already “owned” schrauger.github.com and schrauger.github.io, so I decided to test these domains with WoSign.

WoSign happily accepted that I owned schrauger.github.com and .io after I followed the text file verification. It then let me add the primary domains, github.com and github.io, along with www.github.io, to my certificate request (I forgot to add www.github.com, doh!). Lo and behold, I had just acquired a perfectly valid certificate for github!

Since WoSign is a CA that is accepted by all major browsers, I could now easily masquerade as GitHub, provided I had the opportunity to become a man-in-the-middle or could control DNS requests.

In fact, if you set up a host entry pointing to 198.12.67.10 (one of my personal servers) for github.io, you’ll be able to connect to it via https and get a valid certificate using Google Chrome.

After asking the community how to report this (https://security.stackexchange.com/questions/91292/how-do-i-report-a-security-vulnerability-about-a-trusted-certificate-authority), I contacted Dan Kaminsky about the vulnerability, and he got in contact with the CA WoSign. They promptly fixed the vulnerability, and they revoked my github certificate.

However, after more than a year, they have still not revoked my www.ucf.edu certificate. Which concerns me, since anyone else could have found out about the vulnerability before I reported it and still have malicious, yet valid, certificates for other domains. Which means WoSign apparently didn’t do any auditing after the vulnerability was reported. As a side note, they offer wildcard certificates (though not for free, so I didn’t test that) so those could be out there also.

Did you mean June 9, 2015? That would be more consistent with the cert dates.

Could you attach the cert you got for www.ucf.edu (if you still have it)?

Also, drat that you missed my answer to that post - https://security.stackexchange.com/questions/91292/how-do-i-report-a-security-vulnerability-about-a-trusted-certificate-authority#answer-91306

The schrauger.github.io certificate (with Subject Alternate Domains for github.com and github.io) was created about June 9, 2015. And it was revoked the next day, June 10, after I talked with Dan Kaminsky (and he contacted them).

I have emails about the certificate creation and revoking with timestamps on June 10, 2015 at 2:03am and June 10, 2015 at 10:31pm respectively.

Attached is the public key for med.ucf.edu with a SAN for www.ucf.edu.

Deleted: www.ucf.edu.crt 1.6 KB

www.ucf.edu.crt 1.6 KB Download

Oops, yes, I meant 2015, not 2016.

Thanks. I can confirm that WoSign did not disclose this privately to either browsers or to their auditors during their annual audit - https://cert.webtrust.org/SealFile?seal=2019&file=pdf

Feel free to send your correspondence to sleevi@google.com , I'm going to kick off #2-4 after double-checking the info in comment #13

Mozilla is interested in following-up directly. I shared the details from Comment #10 and the related certs. If you contact security@mozilla.org , they'd appreciate it.

I sent them an email, so they have my contact info now.

> I already “owned” schrauger.github.com and schrauger.github.io, so I decided to test these domains with WoSign.

I just wanted to clarify one point related to this. The discussion regarding the issuance of the github.com cert was that ownership was “proven" by using a subdomain og github.com(schrauger.github.com). But, those style URLs are legacy GitHub Pages URLs, and are 301 redirected to the github.io domain. And, that GitHub Pages site has a custom domain setup (not sure if this was the case when the actual cert was issued), so the github.io URL actually 301 redirects to whatever custom domain is setup. If you watch the network requests to https://schrauger.github.com you will see a 301 redirect to https://schrauger.github.io and then a final 301 redirect to https://www.schrauger.com. This makes me wonder whether the core issue goes beyond using a subdomain to prove ownership of a parent domain. It seem like they might have allowed any arbitrary redirect from a domain to another domain to prove ownership. And, if that is/was the case, is even more worse, given the prevalence of arbitrary redirects vs control of subdomains. I can try validating this later in the week, but thought I'd post here just in case anyone had corresponded with WoSign or tested this scenario already. 

I think I had a standard GitHub Pages site when I created the certificate. I can't remember if github.com redirected to github.io, but I think I was able to upload the verification file directly to GitHub Pages at least at the github.io page.

Though I feel like schrauger.github.com did redirect to schrauger.github.io when I validated the domains. I do remember I tried to create a brand new github account to do more tests. But while I could view mynewuser.github.io, I couldn't access mynewuser.github.com. It was only because my "schrauger" account was created long before that I had the grandfathered dns rule.

So I think WoSign followed the redirect anyway, at least from github.com to github.io.

Yes, new GitHub users don't get the redirect from username.github.com to username.github.io. We grandfathered people in to that when we made the change of domains. Based on the timelines, the redirect to github.io definitely should have been happening, as we made that redirect change quite long ago. So, while you were able to add the verification file to https://schrauger.github.io, that should have been completely unusable to validate https://schrauger.github.com (and of course https://github.com). The fact that their domain validation logic follows off-site redirects boggles the mind a little bit (or maybe not :-)). 

This cert was brought to my attention.

https://crt.sh/?id=29805567

This was also generated by me. That was the new account I created for testing, and as seen in the SANs was only valid for github.io, since github.com didn't redirect new accounts.

I posted a comment on the Mozilla discussion, but the comment is still pending approval, so I thought I'd comment here as well. I forgot to mention it before since I'd forgotten about it, and I didn't seem to keep a copy of either the public or private key on my computer. 

This other certificate was also revoked the day after I created it. So WoSign did do a cursory check, at least. That is, only the schrauger.github.com certificate was produced to the CA, and they were able to revoke the motorstoiclathe.github.io certificate at the same time back in June 2015, even though both certificates were created by separate WoSign accounts (though admittedly by the same IP address).

rsleevi: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Andrew's already added the first batch to the CRLSet, and we're investigating more what steps to take.

rsleevi: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Friendly ping from Security Sheriff: should we do anything else here?

We can remove this from the security queue. We're finalizing the announcement internally, and then remediations will land. But we're gated on non-technical concerns atm.

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Setting labels to remove this from the security queue. I'm guessing this should probably stay view-restricted (?) due to the details about how this was discovered, but it's not a security vulnerability in Chrome per se.

Merging into  Issue 661003  now that https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html is out

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot