
What we know so far about the Windows CryptoAPI spoofing vulnerability - Terretta
https://blog.lessonslearned.org/chain-of-fools/
======
tptacek
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.

------
lostmsu
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.

------
mzs
handful of people have POC now
[https://twitter.com/layle_ctf/status/1217390040441147393](https://twitter.com/layle_ctf/status/1217390040441147393)

~~~
mzs
another this time showing SSL
[https://twitter.com/saleemrash1d/status/1217495681230954506](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.

~~~
CiPHPerCoder
Bypassing CT on Chrome in this context should be trivial:
[https://cs.chromium.org/chromium/src/components/certificate_...](https://cs.chromium.org/chromium/src/components/certificate_transparency/chrome_require_ct_delegate.cc?rcl=ae2f49f1fce4cacac5232782d9133239ff60821a&l=182)

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

~~~
tialaramex
Probably not _too_ much earlier

[https://cs.chromium.org/chromium/src/net/cert/cert_verify_pr...](https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc)

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.

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

------
wyldfire
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?

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

~~~
wyldfire
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?

------
morpheuskafka
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.

------
dboreham
>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.

~~~
to11mtm
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.

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

------
CiPHPerCoder
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.

~~~
nkrisc
Curve Your Enthusiasm

------
ChainOfFools
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

