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 g…
Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
41–50 of 235 posts
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#42None 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 g…
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#43Earlier quoted context omitted.
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.
You write that like it's a bad thing.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#44None 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 g…
"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
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#45None 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 g…
"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
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#46Earlier quoted context omitted.
>a new initiative at NSA dubbed "Turn a New Leaf," More like "do the actual job they are paid to do"
They are paid to collect intelligence for the benefit of the american people, not american companies. Luckily citizens united hasn't stretched that far.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#47None 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 g…
"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
That said, this same patch set also has a separate pre-auth RCE on Microsoft's Remote Desktop Gateway, which has been documented as CVE-2020-0609 (not ...-0601). See https://www.kb.cert.org/vuls/id/491944/
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#48Given 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
This attack --- related but not identical to what we suspect today's announcement is --- broke an earlier version of ACME (the LetsEncrypt protocol).
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#49Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#50From 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…