None of these links describe how the exploit works.
I found this: https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA...
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?
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.
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://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
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
ChainComparePublicKeyParametersAndBytes used to just be a memcmp before the patch. Same with any calls to IsRootEntryMatch. Both new functions.
The actual advisory from Microsoft (CVE-2020-0601):
https://portal.msrc.microsoft.com/en-US/security-guidance/ad...
> 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.
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.
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.
Guess this is what Krebs was referring to yesterday: https://krebsonsecurity.com/2020/01/cryptic-rumblings-ahead-...
And the discussion on HN: https://news.ycombinator.com/item?id=22039481
Anyone got any news on Windows 7 seeing as it's still 25% market share approx according to statcounter?
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.
It's been reported that Windows Defender can detect and report on malicious certificates:
https://twitter.com/AmitaiTechie/status/1217156973268893696
Of course, that relies on not having Defender disabled by an alternate product.
Following a couple of twitter threads led me to this PDF: https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA...
(the tweet where I found it at https://mobile.twitter.com/NSAGov/status/1217152211056238593 has an image version of that PDF, in case you don't trust that domain)
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
:)
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...
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.
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/
Interesting, makes you wonder how many exploits the NSA purposely doesn't mention to the vendor for their own benefit
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?
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?
At least this only affects Windows 10 (as far as I can tell)
When will they learn that the only way to respond to a hostile government is to overthrow it?
Do any browsers use CryptoAPI for TLS certificate validation?
Globalist conspiracy. X files intro music
Some things never change...
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?!
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
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
This attack --- related but not identical to what we suspect today's announcement is --- broke an earlier version of ACME (the LetsEncrypt protocol).