On 01 Sep 2016, at 18:00, Ryan Sleevi <r...@sleevi.com> wrote: > > Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this > the only one? I wasn't clear from > https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ > > <https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ> > )
Hello, We obtained 2 certificates from the StartEncrypt API which had SHA-1 signatures and which were backdated to December 20, 2015. After WoSign announced that all certificates issued in 2015 were logged to their Certificate Transparency server, I analyzed them to check if any other certificates using SHA-1 signatures show signs of being backdated. Using the Python tools from Google’s Certificate Transparency repository I downloaded all certificates from the log and then queried them from an sqlite database. Considering this is the first time I’m working with Certificate Transparency logs, it might be better if someone else tries to reproduce my results. I’ve generated a table here: https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 (timestamps are in UTC). I found 1204 certificates with a SHA-1 signature issued after December 1, 2015. 53 of them included embedded SCT data, so can be dated more accurately. The most interesting pattern I noticed was from sorting the certificates based on the ID they have in WoSign’s Certificate Transparency log. Up to ID 109149 (https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a), the notBefore values are (approximately) chronologically ordered. Those which have embedded SCTs have timestamps which are about 2 hours later than the notBefore date. But after that follow 64 certificates which are all dated on December 20, 2015 (CST, UTC+8), including our two test certificates. Six of these have embedded SCT data, but they have a large discrepancy between the notBefore and the earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even has a SCT of January 18, 2016, almost a full month after the notBefore. (Unless I misunderstand the use of pre-certificates, this by itself already implies the certificate was signed using SHA-1 on or after January 18, 2016.) Aside from the 3 embedded SCTs on December 31, none of these certificates have been logged to a Certificate Transparency server before January 1, 2016. Then I checked crt.sh to look for the SANs used for these certificates, and found even more signs. For the domain “mail.gd.gov.cn”, two certificates have been logged recently: https://crt.sh/?id=12356371 SHA-1 signature and notBefore December 20, 2015. https://crt.sh/?id=12362293 SHA-256 signature and notBefore January 26, 2016. Both were first logged to Certificate Transparency by Google on January 28, 2016. For “ebank.pcnkbank.com”, similar: https://crt.sh/?id=30773634 SHA-1 signature and notBefore December 20, 2015. https://crt.sh/?id=15425430 SHA-256 signature and notBefore January 28, 2016. For “congfubao.com”: https://crt.sh/?id=30773528 SHA-1 signature, notBefore December 20, 2015 and 3 embedded SCTs for January 5, 2016. https://crt.sh/?id=11900532 SHA-256 signature, notBefore January 5, 2016 and 3 embedded SCTs for January 5, 2016. These SCTs were issued approximately 17 seconds later than those on the other cert. And many other examples exist within these 62 certs for which a SHA-256 certificate was issued in January/February and a SHA-1 certificate was “issued” on December 20, but not logged to Certificate Transparency (until last week) or just after the SHA-256 certificate was issued. All of this together strongly suggests WoSign was generating SHA-1 and SHA-256 certificates at the same time (not uncommon in 2015 to maximise compatibility, I think), but continued doing this on December 31, 2015 for at least a month by intentionally backdating the SHA-1 certificate. Best regards, Thijs Alkemade Computest • Pine Digital Security E: talkem...@computest.nl • I: www.computest.nl A: Signaalrood 25 • 2718 SH Zoetermeer Pine Digital Security is part of Computest
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
