
Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf] - Moral_
https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF
======
tptacek
From a conversation with Thomas Pornin, a plausible explanation given the
details provided in the DoD advisory:

Given an ECDSA signature and control over the curve domain parameters, it's
straightforward to create a second private key that matches the original
public key, without knowledge of the original signing private key. Here's how:

To start with, you need to understand a little bit about how curve
cryptography works. A curve point is simply the solution to an equation like

    
    
        y^2 = x^3 + ax + b mod p
    

The "curve" itself consists of the parameters a, b, and p; for instance, in
P-256, a is -3, b is (ee35 3fca 5428 a930 0d4a ba75 4a44 c00f dfec 0c9a e4b1
a180 3075 ed96 7b7b b73f), and p is 2^256 - 2^224 + 2^192 + 2^96 - 1.

To use that curve for cryptography, we standardize a base point G, which
generates all the points we'll use. A private key in ECC is simply a scalar
number k mod p; the public key corresponding to that private key is kG (the
curve scalar multiplication of the point G times our secret k). Everybody
using P-256 uses the same base point; it's part of the standard.

Assume that we have a signature validator in CryptoAPI that allows us to
specify our own nonstandard base point. We're ready to specify the attack;
it's just algebra:

Let's call Q the public key corresponding to the signature; for instance, Q
could be the ECC public key corresponding to an intermediate CA.

Q is a point on a named curve (like P-256). Q = xG for some private key x; we
don't, and won't ever, know x. G is the standard generator point for (say)
P-256.

What we'll do is define a "new curve", which is exactly P-256, but with a new
generator point. We'll generate our own random private key --- call it x' \---
and then from that random private key compute a malicious generator G' =
(1/x')*Q.

On our "new curve", Q remains a valid point (in fact, our evil curve is the
same curve as P-256, just with a different generator), but now Q' = x'G', and
we know x'.

Now we sign a fake EE certificate with our evil private key x'. Presumably,
Windows is just looking at the public key value and, reading between the lines
of the DoD advisory, the curve equation, but not the base point. By swapping
base points, we've tricked Windows into believing the private key
corresponding to Q is x', a key we know, and not x, the key we don't know.

I'm paraphrasing a shorter writeup Pornin provided, and the basic curve
explanation is mine and not his, so if I've worded any of this poorly, blame
me and not Thomas Pornin. The actual exploit-development details of the attack
will involve figuring out in what circumstances attackers can swap in their
own base point; you'd hope that the actual details of the attack are subtle
and clever, and not as simple as "anyone could have specified their own base
point straightforwardly at any time".

See also this related exercise in Sean Devlin's Cryptopals Set 8:

[https://toadstyle.org/cryptopals/61.txt](https://toadstyle.org/cryptopals/61.txt)

This attack --- related but not identical to what we suspect today's
announcement is --- broke an earlier version of ACME (the LetsEncrypt
protocol).

~~~
_hl_
I hope that the actual vulnerability is far more complicated. If we can't even
get crypto libraries right (where you'd hope most of the formal verification
folks are), then there's not much hope of security for the rest of the
industry.

I'm normally not much of a pessimist but things like this really make me wish
we could just burn all the things and start over.

~~~
0xff00ffee
> just burn all the things and start over

Wrap all of this with an "IN MY OPINION"...

That would make things worse because we'd make the same mistakes again. I've
been on many start over projects (Xeon Phi, for example, threw out the P4
pipeline and went back to the Pentium U/V). It doesn't work. You know what the
most robust project I've worked on? The instruction decoder on Intel CPUs. The
validation tests go back to the late 1980's!

You make progress by building on top and fixing your mistakes because there
literally IS NO OTHER WAY.

Go read about hemoglobin, its the one of the oldest genes in the genome, used
by everything that uses blood to transport oxygen, and it is a GIGANTIC gene,
full of redundancies. Essentially a billion years of evolution accreted one of
the most robust and useful genes in our body, and there's nothing elegant
about it.

I think that's where we are headed. Large systems that bulge with heft but
contain so many redundant checking code that they become statistically more
robust.

~~~
_nedR
Yep : [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
leeoniya
> That LoadLibrary call is ugly but it makes the code work on old versions of
> Windows 95.

with the proper code comments for the hair (in the code or in the source repo)
and regression tests it becomes possible to clean up and even rewrite.

floppy disks are no longer a thing and neither is windows 95. RAM & swap space
are abundant, so that OOM may never happen any more IRL.

the app's whole architecture may have been carefully chosen for the hardware
and simplistic compilers of another age.

is it okay never to rewrite a webpage where 50% of the codebase is IE6 hacks?

if it is code that must be maintained, then at some point the hair may need to
be shaved; it simply cannot grow forever as the world moves on around it. the
doma of "never rewrite" is silly without further context.

~~~
_nedR
>if it is code that must be maintained, then at some point the hair may need
to be shaved; it simply cannot grow forever as the world moves on around it.
the doma of "never rewrite" is silly without further context.

"Shaving" seems more close to refactoring & partial rewrite than starting from
scratch. Which is what we are talking about.

Still, You make good points. Maybe, we should think of "restarting from
scratch" the same way we do premature optimization - (1. don't do it. 2. Don't
do it too early. 3. if you must do, measure first)

I think every developer dreams of rewriting from scratch because they hate how
hacky and ugly their code is probably due to rushed deadlines and because it
was just supposed to be an mvp. And they think about throwing it away and
starting clean and doing it the 'proper way'. This imo is the wrong reason to
start from scratch.

But if your technical debt is genuinely preventing your product from going
where it needs to go or do its job. That is the right reason. Again you have
to make the calculation whether the technical debt is greater than the cost of
rewriting from scratch, re-opening old bugs and introducing new ones, breaking
your customers workflow - they also invested a lot into your old program. How
many times have you liked a program until 'the damn devs went and ruined a
good thing' by 'fixing what wasn't broken'. Again, customers don't see or care
about the code or technical debt. They just need to get their work done.

------
Uptrenda
None of these links describe how the exploit works.

I found this:
[https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA...](https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-
WINDOWS-10-CRYPT-LIB-20190114.PDF)

So based on my limited understanding:

1\. The certificates have a place for defining curve parameters.

2\. The attacker specifies their own parameters so that they match the start
of a standard curve but choose the rest of the parameters themselves. With the
right ECC math they are able to generate a valid signature for the certificate
even though they don't own the private key corresponding to the original
curve.

3\. The old crypto API -didn't- check that certificates were signed from a
fixed set of valid parameters. It would just check for sig validity allowing
for spoofing of the cert.

Interesting stuff. So you might be able to cryptographically prove if there
was ever any attacks in the wild from this at a given time (if we assume dates
are checked at least)?

I wonder what happens at the Microsoft Security Response Center when a big
vuln hits like this? Does it tie up all their resources just working on the
one vuln?

~~~
richardwhiuk
"enable remote code execution." suggests it's worse than that - like the curve
parameters might allow a buffer overflow, or something of that nature.

Maybe they just mean because it can sign Authenticode signatures

~~~
cesarb
I haven't seen it mentioned anywhere yet, but I have to wonder... Does this
vulnerability allow MITM of _Windows Update_ itself?

I would expect all connections to the Windows Update servers to be protected
with TLS, and as a second layer the updates themselves to be signed, but if
this vulnerability allows bypassing both signatures, this could be really bad.

~~~
tptacek
This attack targets the nuts and bolts of how the Windows platform actually
implements TLS; a vulnerability in CryptoAPI that allowed you spoof any ECC
certificate would presumably break all of TLS. What might mitigate this in
Windows Software Update would be some kind of key pinning that prevented
arbitrary certificates from being used.

 _Later_

Dmitri Alperovitch at Crowdstrike says this doesn't impact Windows Update.

------
kornholi
From Krebs tweets:

The NSA's Neuberger said this wasn't the first vulnerability the agency has
reported to Microsoft, but it was the first one for which they accepted
credit/attribution when MS asked.

Sources say this disclosure from NSA is planned to be the first of many as
part of a new initiative at NSA dubbed "Turn a New Leaf," aimed at making more
of the agency's vulnerability research available to major software vendors and
ultimately to the public.

~~~
ct520
more like someone with some commonsense decided to capitalize on disclosing
issues when other countries get zero days. Oh well, guess we can't use this
anymore Bob, china has been exploiting it over the past week. Call Microsoft
lets at least get some free PR in exchange of having to give this up.

~~~
toyg
They have probably done that for a while (this is the first _public
attribution_ , not the first disclosure); but they are now blowing their
trumpet because they need some good PR. Why?

Snowden.

~~~
idlewords
Much more likely the bad reaction to Eternal Blue.

~~~
toyg
EternalBlue would have not received that much coverage had it not happened
after Snowden proved that the American public cannot trust the agency. They
had been dragged to the foreground before without repercussions, because
reactions were limited to the IT world. Snowden made it a general-public
issue, and now they are forced to to shape up.

------
es56yhse6
Interesting comment on reddit:

> _Within the federal space, we 've been making unprecedented plans for
> patching systems as soon as this patch is released today. In my agency we're
> going to be aggressively quarantining and blocking unpatched systems
> beginning tomorrow. This patch has been the subject of many classified
> briefings within government agencies and military._

[https://old.reddit.com/r/sysadmin/comments/eoll74/all_hands_...](https://old.reddit.com/r/sysadmin/comments/eoll74/all_hands_on_deck_major_ms_update_coming_today/)

~~~
Bluecobra
The Department of Homeland Security issued an emergency directive today for
federal agencies to patch their systems within 10 business days:

[https://cyber.dhs.gov/ed/20-02/](https://cyber.dhs.gov/ed/20-02/)

~~~
mzs
And that's for civilian systems. The only other time I can recall this
happened was with the DNS vuln.

------
mzs
>
> [https://twitter.com/randomoracle/status/1217198437281804290](https://twitter.com/randomoracle/status/1217198437281804290)

Some speculation on CVE-2020-0601.

Earlier version of Windows cryptography API only supported a handful of
elliptic curves from NIST suite-B. It could not handle say an arbitrary prime-
curve in Weierstrass form with user defined parameters

…

While it could not grok arbitrary curves, Windows API made an attempt to
recognize when a curve with explicit user-defined parameters was in fact
identical to "built-in" curve that is supported

It appears that mapping was "lazy:" it failed to check that _all_ curve
parameters are identical to the known curve.

In particular, switching the generator point results in a different curve in
which an attacker can forge signatures that match a victim public key

>
> [https://twitter.com/esizkur/status/1217176214047219713](https://twitter.com/esizkur/status/1217176214047219713)

It looks like this may be a caching issue: There's a CCertObjectCache class in
crypt32.dll. In the latest release its member function FindKnownStoreFlags
(called from its constructor) started checking the public key and parameters

>
> [https://twitter.com/thracky/status/1217175743316348929](https://twitter.com/thracky/status/1217175743316348929)

ChainComparePublicKeyParametersAndBytes used to just be a memcmp before the
patch. Same with any calls to IsRootEntryMatch. Both new functions.

------
cpascal
The actual advisory from Microsoft (CVE-2020-0601):

[https://portal.msrc.microsoft.com/en-US/security-
guidance/ad...](https://portal.msrc.microsoft.com/en-US/security-
guidance/advisory/CVE-2020-0601)

> A successful exploit could also allow the attacker to conduct man-in-the-
> middle attacks and decrypt confidential information on user connections to
> the affected software.

------
1970-01-01
So Win7 isn't affected? At this point in time I have to point out a fully
patched Win7, having ~8 hours of support life left, just happens to be more
secure than Win10 for trusting certs.

~~~
userbinator
It's called maturity... code that isn't radically changed or added to will
asymptotically approach being completely bug-free as all the bugs get
gradually discovered and fixed over time. This also implies that the majority
of bugs are found in the newest code.

------
trulyrandom
The advisory from Microsoft is quite bizarre. It focuses on code signature
validation, rather than X.509 as a whole. It also doesn't say anything about
how the vulnerability itself works. Vague advisories like this are dangerous,
because it gives adversaries an advantage over IT departments that don't know
which system they should patch first. It would be much better if everyone
understood exactly what the impact is from the get go. The NSA advisory is a
bit better, but still doesn't tell us how exactly the ECC certificate
validation bug works. We're left with only a few hints.

~~~
JackRabbitSlim
X509 as a whole is fine and this isn't so much arbitrary MITM of any web
server. It's specific to ECC public keys(not specifically X509 certs) that
validate from cryptoAPI which is a fairly limited but devastating scope. EG
Code signing.

Firefox uses its own NSS libraries not cryptoAPI to verify certs and is
completely unaffected. I assume every major browser uses NSS or their own APIs
as well. And of course RSA and AES certificates remain unaffected.

~~~
trulyrandom
TLS supports ECC certificates, so any web client using crypt32 to verify those
is affected. That includes web browsers and lots of other types of services,
so it's not primarily code signed executables.

Does Firefox still use NSS when using the Windows Certificate Store for the
source of trusted root certs? What about Chrome?

You're right that RSA certificates are unaffected. There's no such thing as
AES certificates, though.

~~~
tialaramex
> Does Firefox still use NSS when using the Windows Certificate Store for the
> source of trusted root certs?

Yes. When enabled this feature in Firefox just effectively copies certificates
from one of the Windows trust stores but continues to use its own (NSS) logic
for trust decisions. Note also that Firefox's config switch only looks at your
local changes - a corporate CA, a MITM proxy on a dev's workstation, something
like that. Firefox continues to rely on Mozilla's judgement not Microsoft's
for global trust policy.

> What about Chrome?

Chrome is probably affected. Chrome uses the platform (in this case
crypt32.dll) trust decisions and then layers on additional rules from Google,
such as the requirement for proof of CT logging. So unless an additional rule
is blocking the weird curves they'll pass on Chrome on Windows.

------
CrazyStat
Guess this is what Krebs was referring to yesterday:
[https://krebsonsecurity.com/2020/01/cryptic-rumblings-
ahead-...](https://krebsonsecurity.com/2020/01/cryptic-rumblings-ahead-of-
first-2020-patch-tuesday/)

And the discussion on HN:
[https://news.ycombinator.com/item?id=22039481](https://news.ycombinator.com/item?id=22039481)

------
m0xte
Anyone got any news on Windows 7 seeing as it's still 25% market share approx
according to statcounter?

~~~
floatingatoll
Does Windows 7 crypt32.dll support ECC?

~~~
withinrafael
Yes. [https://docs.microsoft.com/en-
us/windows/win32/secauthn/tls-...](https://docs.microsoft.com/en-
us/windows/win32/secauthn/tls-cipher-suites-in-windows-7)

~~~
mzs
but only shortname curves

~~~
rkagerer
Does that mean it's unaffected?

~~~
mzs
I would expect everything not patched today is unaffected for such a reason
yes.

~~~
BlueTemplar
But Win7 _was_ patched this Tuesday...

~~~
mzs
That was the last roll-up not this security update.

------
api
This is yet another illustration of why complexity is evil in cryptographic
and security critical code. It's evil everywhere, but it's particularly evil
there. The relationship between bugs and complexity is exponential, not
linear.

X.509 is an over-engineered legacy-cruft-encrusted nightmare. I've implemented
stuff that uses it and I _never_ , even after the most careful auditing by
myself and peers, leave with the sense that I have handled everything
correctly or that my code is totally air-tight.

~~~
rst
The bug is being publicly described as specific to the implementation of a
particular class of cryptographic primitives (ECC). If that's accurate,
simplifying the certificate data format (unnecessarily messy though it may be)
wouldn't do much to mitigate this particular issue.

~~~
tptacek
To the extent it's X.509 allowing curve parameters to be specified alongside
signatures and public keys, this is indeed a case where all the extra joinery
in X.509 is creating exploitable complexity, and the point 'api is making is
well taken.

------
technion
It's been reported that Windows Defender can detect and report on malicious
certificates:

[https://twitter.com/AmitaiTechie/status/1217156973268893696](https://twitter.com/AmitaiTechie/status/1217156973268893696)

Of course, that relies on not having Defender disabled by an alternate
product.

~~~
taspeotis
On Windows Server 2016 and newer it stays enabled even with an “alternate
product.”

[https://docs.microsoft.com/en-us/windows/security/threat-
pro...](https://docs.microsoft.com/en-us/windows/security/threat-
protection/windows-defender-antivirus/windows-defender-antivirus-on-windows-
server-2016)

> In Windows Server 2016, Windows Defender AV will not disable itself if you
> are running another antivirus product.

~~~
technion
True, but imagine you deployed SEP in accordance with supplier's instructions:

[https://support.symantec.com/us/en/article.tech237177.html](https://support.symantec.com/us/en/article.tech237177.html)

Or Mcafee:

[https://kc.mcafee.com/corporate/index?page=content&id=KB8245...](https://kc.mcafee.com/corporate/index?page=content&id=KB82450)
(search for DisableRealtimeMonitoring)

For a deeper dive: I ran into issues on a security assessment trying to run
procdump on lsass being blocked by Defender. Workaround.. was to find a
machine with McAfee installed where that behavior was allowed.

------
cesarb
Following a couple of twitter threads led me to this PDF:
[https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA...](https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-
WINDOWS-10-CRYPT-LIB-20190114.PDF)

(the tweet where I found it at
[https://mobile.twitter.com/NSAGov/status/1217152211056238593](https://mobile.twitter.com/NSAGov/status/1217152211056238593)
has an image version of that PDF, in case you don't trust that domain)

------
dc352
I suspect you're overcomplicating the attack with all the math and we can
ignore most of it.

The only way the attacker can tell the MS Crypto API is via the TLS protocol.
You can only do it if it's relevant. The only option for that is to use ECDH,
which allows the server to supply EC parameters for the Diffie-Hellmann
exchange.

My bet is that the problem is that MS Crypto API took those parameters as
correct without checking them against what's in the certificate. I.e.,

ServerKeyExchange - here's the EC spec, we just need the public key
Certificate - ah - here's public key, we have the ECparams - let's run the
math

:)

------
gelo
For those that need proof their machine is updated the article numbers listed
here are the KB numbers you should match in windows 10 update list.

[https://portal.msrc.microsoft.com/en-US/security-
guidance/ad...](https://portal.msrc.microsoft.com/en-US/security-
guidance/advisory/CVE-2020-0601)

------
cliqueiq
I think the scariest thing about this is if this was a PR stunt, the release
of an unknown vuln could be completely controlled by whoever knew about it.
Best case scenario is a relationships between Microsoft and the five eyes. It
could have just as easily been China, a independent group or whatever. It's
even possible that the top of Microsoft and/or NSA might not even know. But if
it wasn't planned, no one would admit it anyway.

------
dolmen
Oh great. Mozilla just added last week an option for entreprises to enable
trusting of system certificates on Windows. See Firefox 72.0 release notes:
[https://www.mozilla.org/en-
US/firefox/72.0/releasenotes/](https://www.mozilla.org/en-
US/firefox/72.0/releasenotes/)

~~~
dolmen
Note that from the release note the new option just allows to read
certificates from the system store. Validation is still done by Firefox, so
NSS crypto lib, not crypt.dll. So even if the option is enabled Firefox is not
affected by the vulnerability (except for code signing check of the Firefox
binary itself by the OS).

------
miguelmota
Interesting, makes you wonder how many exploits the NSA purposely doesn't
mention to the vendor for their own benefit

------
morpheuskafka
I'm assuming there will never be an official proof of concept release, so how
long do you all think it will be before we see widely available exploit code
and fake certificates out in the wild?

~~~
spuz
Tpcaek has said elsewhere in this thread:

> Saleem Rashid worked out a POC for this on Slack in something like 45
> minutes today

So I would be amazed if there were not some malicious certificates out there
already.

------
vermilingua
Could someone clarify: does this allow the creation of fake certificates that
are accepted as authentic by _any_ crypto library?

Or rather, does it treat such faked certificates as authentic itself?

~~~
gruez
> Could someone clarify: does this allow the creation of fake certificates
> that are accepted as authentic by any crypto library?

No, only the Windows native one. For instance, Firefox (which uses NSS) would
be safe.

~~~
emayljames
Although, if one point can be exploited to gain access to one area, then
privilege escalate or exploit from that vantage point, then a lot is at stake.

------
mrpippy
At least this only affects Windows 10 (as far as I can tell)

~~~
mrchucklepants
Windows 7 reached EOL today so they may leave it as is if it is affected.

~~~
gruez
According to [https://portal.msrc.microsoft.com/en-US/security-
guidance/ad...](https://portal.msrc.microsoft.com/en-US/security-
guidance/advisory/CVE-2020-0601), it doesn't look like windows 8.1 received a
patch either, and that's still in support. Maybe only windows 10 has ECC
support, and therefore any previous versions are not affected?

Also, according to
[https://support.microsoft.com/help/4534310](https://support.microsoft.com/help/4534310),
it looks like Windows 7 got security patches for this month.

~~~
BlueTemplar
Indeed, got like 3 patches for Win7 this Tuesday.

------
classified
When will they learn that the only way to respond to a hostile government is
to overthrow it?

------
chrismartin
Do any browsers use CryptoAPI for TLS certificate validation?

~~~
zokier
I think classic IE would do so.

~~~
svenfaw
So does Chrome, if I'm not mistaken

~~~
WorldMaker
Firefox might with an Enterprise flag on?

~~~
KwanEsq
That can only make it check the system certificate store for trusted roots
etc, it'd still use NSS for the crypto operations is my understanding.

------
akayoshi1
Globalist conspiracy. X files intro music

------
eeZah7Ux
Some things never change...

------
age_bronze
Nothing screams "we have microsoft keys!" harder than the fact that the only
vulnerabilities reported by the NSA is a cryptographic validation bug. If I
had to guess exactly what kind of vulnerabilities they do not need, this is
exactly those kind. Who needs crypto validation bug when you already own
microsoft's keys?!

~~~
macinjosh
I think you're spot on. Everything agencies at this level do is calculated and
weighed carefully. They definitely would not seek to patch a useful vuln. It
is a PR stunt.

~~~
william_T
The NSA's job is to gather information. They have >400mil people to protect,
and 6bn people to attack. They are in the business of using exploits, not
closing them.

