handful of people have POC now https://twitter.com/layle_ctf/status/1217390040441147393
"Quick explanation what this is: The 7zip installer is not signed if you download it from their website but I signed it with a bogus certificate that exploits the CVE to make the installer look trusted, even though the certificate is not trusted."
I know I wished that the 7-Zip installer was a signed executable, but this is not what I meant.
1. Find an ecc root cert C
2. Create C' with the same public key and curve but set the generator to the public key of C
3. Create a normal signing cert C'' with key pair (pk'',sk'') and sign software/cert with sk''
4. Sign C'' with sk=1
5. Ship software/cert with C'' and C'
This degenerate case was just confirmed to work…
edit: in reply >
Firefox is safe: NSS doesn't accept the certificate.
Chrome is fooled by the certificate, but it throws NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED. will need to investigate.
You forge a certificate to attack a Windows victim..
- Chrome uses Windows' broken cert validation when run on Windows. So that passes.
- But then it also checks SCTs. An SCT is a signature from a public Certificate Transparency log saying they've logged this exact certificate and it's available to the public.
You get to pick in your bogus cert from two options
A: Just use SCTs from some other certificate which was logged. Chrome (not Windows) checks the signatures and they don't match so your certificate is rejected.
B: Try to log your bogus certificate to obtain an SCT. But the log checks certificate signatures and isn't running Windows, so it rejects the attempt.
The SCTs needn't be baked into a certificate (if you're a random server operator yours probably are, but for some applications the extra work to do it another way was worth it) but that doesn't help an attacker because they can't get a valid SCT for their bogus certificate.
Updated with: Things that might work
Google only made logging mandatory for new certificates from April 2018. A February 2018 certificate could have the old maximum lifetime (39 months) and be exempt from the SCT requirement. So I think a forged cert which claims notBefore 2018-02-27 and notAfter 2021-04-01 or whatever would work with no SCTs inside it, against unpatched Windows systems.
Certificates which aren't from the Web PKI skip the SCT check. So if you have a company CA which does ECC then a certificate could be forged from that CA and used to attack you in Chrome because the SCT checks don't fire.
Set your notBefore to a date earlier than 2018-05-01 and you're golden.
https://cs.chromium.org/chromium/src/net/cert/cert_verify_pr...
Method HasTooLongValidity splits certs into four categories
First, really old certs with notBefore prior to 2012-07-01. This is before the Baseline Requirements, and so Chrome gives them the benefit of the doubt and presumes they might honestly have been issued with up to 10 years to expire BUT fortunately this grandfathering of old garbage was designed to end in July 2019 so all these certs are now distrusted. Any real ones were probably long gone by then anyway.
Second, those from 2012-07-01 but before 2015-04-01 get up to 60 months = 5 years. So a cert issued 2015-03-31 must expire within about ten weeks from now, a workable demo but not a long-lived attack tool.
Third, from 2015-04-01 but before 2018-03-01 it was 39 months. So any cert from 2015-04-01 is long expired, but one claiming it was issued 2018-02-28 expires in May 2021, that's a nice long time to exploit this bug.
Finally from 2018-03-01 it was shortened to 825 days. A cert from 2018-04-30 would thus expire in August 2020.
So the sweet spot is claiming issuance in February 2018.
Edited: I can't count to four apparently.
- haven't had time to confirm it yet.