What we know so far about the Windows CryptoAPI spoofing vulnerability | Hacker News Reader

What we know so far about the Windows CryptoAPI spoofing vulnerability

blog.lessonslearned.org

80 pointsTerretta23 comments

Several people have POC'd the vulnerability at this point, including Saleem Rashid, who rickrolled GITHUB.COM in IE with it, so I think it's pretty safe to say we have a grip on what the vulnerability actually is.

A fun additional note: this post references Cas Cremers tweet-sized recitation of the vulnerability, but he followed it up with an even better, even tweetier variant attack, which I'll paraphrase:

1. Find an ECC root cert.

2. Let Q be its ECC-point public key.

3. Let G be the P-256 generator; set it to Q.

4. Let k be the corresponding secret key; set it to 1.

5. Profit.

TBH, vulnerability is sad, but probably not worth the attention it gets. It is not an RCE, was not actively exploited ASAWK, and even if it would be, you would still need to fish the victim, or actively intercept communication to a legitimate server.

handful of people have POC now https://twitter.com/layle_ctf/status/1217390040441147393

Quote (from 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."

Dear Genie.

I know I wished that the 7-Zip installer was a signed executable, but this is not what I meant.

another this time showing SSL https://twitter.com/saleemrash1d/status/1217495681230954506

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.

The result with Chrome makes sense and I hadn't thought of that outcome. Let's walk through it for anybody else as slow as I am.

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.

Bypassing CT on Chrome in this context should be trivial: https://cs.chromium.org/chromium/src/components/certificate_...

Set your notBefore to a date earlier than 2018-05-01 and you're golden.

Probably not too much earlier

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.

> https://twitter.com/CasCremers/status/1217517133074182145

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…

There's also this POC code on github and around twitter: https://github.com/ollypwn/cve-2020-0601

- haven't had time to confirm it yet.

“According to NSA, the bug was introduced in July 2015” great

Will the patch include any kind of auditing mechanism to determine if your system already has files w/spoofed signatures? Or is there a recommended procedure to execute this audit?

I would expect the signatures to start failing after you update and restart.

Sorry, I'm not familiar with basic details: signature verification happens each time the program is started? Or only when it's installed? If it fails the signature check, what is the default policy? Not to install/execute the binary? Or just log/warn?

already there, read threads below for more details

>No fancy EDR required to capture CVE-2020-0601 attempts (after patching). Just ensure you're forwarding Application log events. Currently, CVE-2020-0601 is the only Microsoft code (AFAIK) that calls the CveEventWrite API so event noise is not a concern.

https://twitter.com/mattifestation/status/121717969800806809...

I'm guessing the most serious impact will be non-browser certificate-based authentication, such as RDP or line-of-business apps that use standard Windows APIs. Local files (ex. fake codesigning) can be detected using anti-virus and third-party browsers are not quite common in the workplace and for home users.

>Part of the confusion is that this particular software library, crypt32.dll has in fact been a core component of Windows going back all the way to NT.

If the vulnerability is specific to ECC, that didn't exist until around 2004.

The vulnerability is specific to the API accepting different parameters for the curve. That wasn't in any versions of the crypto32 api pre Win10.

So, as we were discussing Monday, would formal methods have addressed this vulnerability?

We're branding this Chain of Fools now?

My vote was for, "Whose Curve is it Anyway? Where the points don't matter and the generators are made up." or WhoseCurve for short.

Curve Your Enthusiasm

Thanks for changing the title, I was hardly expecting a surprise HN profile so soon, my blockchain project pitch deck is still a single slide with the word HODL and clip art of the ATHF mooninites

Reply on news.ycombinator.com