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
