12 ms·

None of these links describe how the exploit works. I found this: https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PD

None of these links describe how the exploit works. I found this: https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF 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?

tptacek 7y ago
Good find. This page should almost certainly be the headline article on HN, at least until someone does a full write-up of the vulnerability --- but the vulnerability here looks very simple (and gross): if you can define your own curve parameters and get CryptoAPI to honor them, you can sign anything.
- deleted 7y ago
  [deleted]
- dc352 7y ago
  The only way to do it (I'm lazy so didn't read any of the documents - my gut feeling of an engineer) ... is to use ECDH, which provides EC params in ServerKeyExchange. CryptoAPI might have used those and just pull the public key from the cert.
Hello71 7y ago
Sounds similar to the post from a few days ago about the Firefox WebCrypto allowing too much adjustment of DH parameters: https://news.ycombinator.com/item?id=21980199 https://news.ycombinator.com/item?id=21980199
- tptacek 7y ago
  It is indeed very similar in spirit, and of course much more devastating here. Another attack, implemented on ECDSA and similar in spirit (though not the same attack) is in Sean Devlin's Set 7 of Cryptopals: https://toadstyle.org/cryptopals/61.txt https://toadstyle.org/cryptopals/61.txt
richardwhiuk 7y ago
"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
- flatiron 7y ago
  i know that when i had a windows machine on my companies network they could just install stuff willy nilly. maybe the attacker could dupe and pretend they are you admin and just do what they wish?
- RL_Quine 7y ago
  Depends how you read it. Could just be that any SSL connection to download a binary could be MITM'd and replaced with malware, and that would be "remote code execution" by some definitions.
- rst 7y ago
  The pseudonymous but well-connected 'swiftonsecurity' twitter account reports on background that 'RCE' chatter about this particular vulnerability does indeed relate to compromised software update channels. (Not just AuthentiCode, but also MITM on, say, connections to the npm package server.) See https://twitter.com/SwiftOnSecurity/status/1217159434880847879 https://twitter.com/SwiftOnSecurity/status/12171594348808478... 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/ https://www.kb.cert.org/vuls/id/491944/
  - est31 7y ago
    > connections to the npm package server Doesn't npm use node.js for this, which uses openssl? > https://nodejs.org/api/tls.html#tls_tls_ssl https://nodejs.org/api/tls.html#tls_tls_ssl Third party tools connecting to the npm server that use Window's TLS library would absolutely be affected though.
    - 7y ago
dang 7y ago
Ok, we've changed the URL from https://www.kb.cert.org/vuls/id/849224/ https://www.kb.cert.org/vuls/id/849224/. Thanks!
SlowRobotAhead 7y ago
So... Wait, they weren't calculating the signature based on ALL the contents of the cert? There was an "unprotected" section in the cert that allowed for curve details? This seems... too obviously bad.
- bodeadly 7y ago
  Not exactly but I'm not sure it matters. It sounds like if the curve parameters are crafted just-so, they can dodge validation and use anyone's public key and yet still negotiate successfully and decrypt everything. The "gramdma" explaination is basically the green lock next to the URL in your browser doesn't mean spit at this particular moment in time.
- mzs 7y ago
  Basically there are standard curves and software assumed parameters matched, bad design. edit: more detail https://news.ycombinator.com/item?id=22048619 https://news.ycombinator.com/item?id=22048619
  - SlowRobotAhead 7y ago
    Ah I see. It wasn’t that they didn’t secure parts of the cert, it’s that they assumed they didn’t need to add some data. The generator was assumed standard... and surely no one would ever abuse that intention!
munchbunny 7y ago
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? Generally no, if only because of Microsoft’s sheer size. For something like this issue, while its potential impact is big, I would guess that it only tied up the team(s) that work on CryptoAPI.
- Godel_unicode 7y ago
  And Windows defender.
anaisbetts 7y ago
A lot of what happens at MSRC is auditing for related vulnerabilities - trying to find any place where similar code might make the same mistake. In this case, since roll-your-own cryptography is so strongly discouraged (with good reason), I suspect that there won't be as many places to audit
rasz 7y ago
>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. This sounds exactly how pdf signatures were attacked and successfully defeated https://media.ccc.de/v/36c3-10832-how_to_break_pdfs https://media.ccc.de/v/36c3-10832-how_to_break_pdfs https://www.youtube.com/watch?v=k8FIDGmmYvs https://www.youtube.com/watch?v=k8FIDGmmYvs
baby 7y ago
So you mean the signature algorithm was not fully part of the signature? Indeed that’s a recipe for disasters as the numerous TLS attacks have shown (logjam, freak, drown)

tptacek 7y ago

Good find. This page should almost certainly be the headline article on HN, at least until someone does a full write-up of the vulnerability --- but the vulnerability here looks very simple (and gross): if you can define your own curve parameters and get CryptoAPI to honor them, you can sign anything.

deleted 7y ago
[deleted]
dc352 7y ago
The only way to do it (I'm lazy so didn't read any of the documents - my gut feeling of an engineer) ... is to use ECDH, which provides EC params in ServerKeyExchange. CryptoAPI might have used those and just pull the public key from the cert.

Hello71 7y ago

Sounds similar to the post from a few days ago about the Firefox WebCrypto allowing too much adjustment of DH parameters: https://news.ycombinator.com/item?id=21980199 https://news.ycombinator.com/item?id=21980199

tptacek 7y ago
It is indeed very similar in spirit, and of course much more devastating here. Another attack, implemented on ECDSA and similar in spirit (though not the same attack) is in Sean Devlin's Set 7 of Cryptopals: https://toadstyle.org/cryptopals/61.txt https://toadstyle.org/cryptopals/61.txt

richardwhiuk 7y ago

"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

flatiron 7y ago
i know that when i had a windows machine on my companies network they could just install stuff willy nilly. maybe the attacker could dupe and pretend they are you admin and just do what they wish?
RL_Quine 7y ago
Depends how you read it. Could just be that any SSL connection to download a binary could be MITM'd and replaced with malware, and that would be "remote code execution" by some definitions.
rst 7y ago
The pseudonymous but well-connected 'swiftonsecurity' twitter account reports on background that 'RCE' chatter about this particular vulnerability does indeed relate to compromised software update channels. (Not just AuthentiCode, but also MITM on, say, connections to the npm package server.) See https://twitter.com/SwiftOnSecurity/status/1217159434880847879 https://twitter.com/SwiftOnSecurity/status/12171594348808478... 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/ https://www.kb.cert.org/vuls/id/491944/
- est31 7y ago
  > connections to the npm package server Doesn't npm use node.js for this, which uses openssl? > https://nodejs.org/api/tls.html#tls_tls_ssl https://nodejs.org/api/tls.html#tls_tls_ssl Third party tools connecting to the npm server that use Window's TLS library would absolutely be affected though.
  - 7y ago

dang 7y ago

Ok, we've changed the URL from https://www.kb.cert.org/vuls/id/849224/ https://www.kb.cert.org/vuls/id/849224/. Thanks!

SlowRobotAhead 7y ago

So... Wait, they weren't calculating the signature based on ALL the contents of the cert? There was an "unprotected" section in the cert that allowed for curve details? This seems... too obviously bad.

bodeadly 7y ago
Not exactly but I'm not sure it matters. It sounds like if the curve parameters are crafted just-so, they can dodge validation and use anyone's public key and yet still negotiate successfully and decrypt everything. The "gramdma" explaination is basically the green lock next to the URL in your browser doesn't mean spit at this particular moment in time.
mzs 7y ago
Basically there are standard curves and software assumed parameters matched, bad design. edit: more detail https://news.ycombinator.com/item?id=22048619 https://news.ycombinator.com/item?id=22048619
- SlowRobotAhead 7y ago
  Ah I see. It wasn’t that they didn’t secure parts of the cert, it’s that they assumed they didn’t need to add some data. The generator was assumed standard... and surely no one would ever abuse that intention!

munchbunny 7y ago

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? Generally no, if only because of Microsoft’s sheer size. For something like this issue, while its potential impact is big, I would guess that it only tied up the team(s) that work on CryptoAPI.

Godel_unicode 7y ago
And Windows defender.

anaisbetts 7y ago

A lot of what happens at MSRC is auditing for related vulnerabilities - trying to find any place where similar code might make the same mistake. In this case, since roll-your-own cryptography is so strongly discouraged (with good reason), I suspect that there won't be as many places to audit

rasz 7y ago

>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. This sounds exactly how pdf signatures were attacked and successfully defeated https://media.ccc.de/v/36c3-10832-how_to_break_pdfs https://media.ccc.de/v/36c3-10832-how_to_break_pdfs https://www.youtube.com/watch?v=k8FIDGmmYvs https://www.youtube.com/watch?v=k8FIDGmmYvs

baby 7y ago

So you mean the signature algorithm was not fully part of the signature? Indeed that’s a recipe for disasters as the numerous TLS attacks have shown (logjam, freak, drown)