5 ms·

"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 the

"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.
  - thw0rted 7y ago
    I suspect the answer is "it's complicated". For example, you can specify a package version string as `git://...` and it will grab the package from a git repository. It's possible that this uses a JS-native Git implementation, but it's also possible that it uses a locally-installed Git binary, which could in turn use MSCAPI, especially if it's configured to use an external SSH provider.
    - est31 7y ago
      That's a good point. I'm not too familiar with npm code but it seems that they are indeed using git from the CLI instead using it via a library: https://github.com/npm/cli/blob/ba7f1466436cc22e27f8a14dede3aadbc3147f9a/lib/utils/git.js https://github.com/npm/cli/blob/ba7f1466436cc22e27f8a14dede3...
cesarb 7y ago
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.
- mike_d 7y ago
  It does allow you to modify TLS streams (the WU downloads), and code signing (checking that a binary can run), but it is unclear if any of the trusted WU validation keys (confirming the update is from a signed manifest) are ECC. So: maybe.
- tptacek 7y ago
  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.
- munchbunny 7y ago
  Only if Microsoft is using ECC for its Windows Update certificates. I would guess not given how many past OS versions Windows Update has to support.
ynik 7y ago
The attack allows faking https certs as well as code signing certs; so it seems plausible that a MitM attacker could trick Windows Update (or other auto-updaters) into executing malicious code.
- heartbreak 7y ago
  That this exploit can be used to spoof the Windows Update system is a big yikes. You can’t necessarily trust today’s update itself.
  - munchbunny 7y ago
    That depends on whether Windows Update is using ECC certificates. A quick scan of my Windows 10 trusted root certificate store shows almost exclusively RSA based certificates, so I’d guess 80% odds that Windows Update itself isn’t affected.
    - shakna 7y ago
      It may still be affected, the system may accept a bad ECC cert and override the RSA cert.
      - GhettoMaestro 7y ago
        This is pure speculation and garbage.
- atxlurker 7y ago
  What about user certs. Some windows systems allow for authenticating with a user cert. depending on how bad the validation bug is, seems like spoofing a user certificate could be a valid attack vector.
mzs 7y ago
I read it simply as malicious update passes as from a trusted source due to this vuln and the malicious update runs it's code as part of the update process, not as a buffer overflow or something of that sort.
Uptrenda 7y ago
It's scarier the more you think about it because digital sigs are the first place you look for most "secure protocols." I think reading between the lines there are multiple attack scenarios: - Fake windows updates - The notorious SMB protocol -- "The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets." Could prob impersonate a Windows server or computer in a home group, IDK. - Likely fractal attacks on active directory that would allow injecting admin accounts on any work station in a network and enabling remote desktop. - Fake SSL certs -- also: hey user, here's a [trojan] to fix the latest Windows vuln [fake Microsoft.com]. It's a race to update with the offical update, really. If attackers were to DDoS the update service, it would be very very bad. - Fake signed trusted programs that security software may "ignore" and that windows itself would allow to run with fewer warnings. Trusted MS programs could be a very good way to write persistent root kits. I'm sure windows experts can think of more stuff. But for me it's a good lesson for how much we depend on the certificate system for security.
- sillysaurusx 7y ago
  Love the shock. Take a job as a pentester (or don’t) and you’ll look at your list, nod, and say “Yes. This is normal.” It’s normal to be broken. That’s why to do pentests on every piece of security infrastructure. The hypothesis that systems like this ought to be secure is empirically false. I am trying to shake the shock out of you, because your surprise = my surprise before being a pentester. But the job forces you to come to terms with the fact that everyone, everywhere, is broken, always, and this is neither surprising nor (and you’ll hate this part) a big deal. Bug is fixed. Life goes on. Yes, of course the infrastructure could have been attacked from any time between “forever ago” and that fix. Ask yourself: why is this surprising to me? And carefully examine the assumptions with which you want to say “because it’s their job to make it secure...” To be clear, I wish the world were different. But I wish we’d take a hard look at reality and the history of vulnerabilities. Stop thinking things are secure just because the label says “secure”. People devote their entire existence to seeking out and exploiting the tiniest imperfections, sometimes for no reason other than because it’s fun to do so. There is zero chance software would end up impenetrable under those conditions. Hell, even Tarsnap screwed up once, and Colin is pretty much cryptographically-signed Jesus. So if someone as smart and dedicated as him can make these mistakes, what hope have we? Especially when “we” consists of a large number of programmers working together, and all the complexities that entails?
deleted 7y ago
[deleted]

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.
- thw0rted 7y ago
  I suspect the answer is "it's complicated". For example, you can specify a package version string as `git://...` and it will grab the package from a git repository. It's possible that this uses a JS-native Git implementation, but it's also possible that it uses a locally-installed Git binary, which could in turn use MSCAPI, especially if it's configured to use an external SSH provider.
  - est31 7y ago
    That's a good point. I'm not too familiar with npm code but it seems that they are indeed using git from the CLI instead using it via a library: https://github.com/npm/cli/blob/ba7f1466436cc22e27f8a14dede3aadbc3147f9a/lib/utils/git.js https://github.com/npm/cli/blob/ba7f1466436cc22e27f8a14dede3...

cesarb 7y ago

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.

mike_d 7y ago
It does allow you to modify TLS streams (the WU downloads), and code signing (checking that a binary can run), but it is unclear if any of the trusted WU validation keys (confirming the update is from a signed manifest) are ECC. So: maybe.
tptacek 7y ago
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.
munchbunny 7y ago
Only if Microsoft is using ECC for its Windows Update certificates. I would guess not given how many past OS versions Windows Update has to support.

ynik 7y ago

The attack allows faking https certs as well as code signing certs; so it seems plausible that a MitM attacker could trick Windows Update (or other auto-updaters) into executing malicious code.

heartbreak 7y ago
That this exploit can be used to spoof the Windows Update system is a big yikes. You can’t necessarily trust today’s update itself.
- munchbunny 7y ago
  That depends on whether Windows Update is using ECC certificates. A quick scan of my Windows 10 trusted root certificate store shows almost exclusively RSA based certificates, so I’d guess 80% odds that Windows Update itself isn’t affected.
  - shakna 7y ago
    It may still be affected, the system may accept a bad ECC cert and override the RSA cert.
    - GhettoMaestro 7y ago
      This is pure speculation and garbage.
atxlurker 7y ago
What about user certs. Some windows systems allow for authenticating with a user cert. depending on how bad the validation bug is, seems like spoofing a user certificate could be a valid attack vector.

mzs 7y ago

I read it simply as malicious update passes as from a trusted source due to this vuln and the malicious update runs it's code as part of the update process, not as a buffer overflow or something of that sort.

Uptrenda 7y ago

It's scarier the more you think about it because digital sigs are the first place you look for most "secure protocols." I think reading between the lines there are multiple attack scenarios: - Fake windows updates - The notorious SMB protocol -- "The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets." Could prob impersonate a Windows server or computer in a home group, IDK. - Likely fractal attacks on active directory that would allow injecting admin accounts on any work station in a network and enabling remote desktop. - Fake SSL certs -- also: hey user, here's a [trojan] to fix the latest Windows vuln [fake Microsoft.com]. It's a race to update with the offical update, really. If attackers were to DDoS the update service, it would be very very bad. - Fake signed trusted programs that security software may "ignore" and that windows itself would allow to run with fewer warnings. Trusted MS programs could be a very good way to write persistent root kits. I'm sure windows experts can think of more stuff. But for me it's a good lesson for how much we depend on the certificate system for security.

sillysaurusx 7y ago
Love the shock. Take a job as a pentester (or don’t) and you’ll look at your list, nod, and say “Yes. This is normal.” It’s normal to be broken. That’s why to do pentests on every piece of security infrastructure. The hypothesis that systems like this ought to be secure is empirically false. I am trying to shake the shock out of you, because your surprise = my surprise before being a pentester. But the job forces you to come to terms with the fact that everyone, everywhere, is broken, always, and this is neither surprising nor (and you’ll hate this part) a big deal. Bug is fixed. Life goes on. Yes, of course the infrastructure could have been attacked from any time between “forever ago” and that fix. Ask yourself: why is this surprising to me? And carefully examine the assumptions with which you want to say “because it’s their job to make it secure...” To be clear, I wish the world were different. But I wish we’d take a hard look at reality and the history of vulnerabilities. Stop thinking things are secure just because the label says “secure”. People devote their entire existence to seeking out and exploiting the tiniest imperfections, sometimes for no reason other than because it’s fun to do so. There is zero chance software would end up impenetrable under those conditions. Hell, even Tarsnap screwed up once, and Colin is pretty much cryptographically-signed Jesus. So if someone as smart and dedicated as him can make these mistakes, what hope have we? Especially when “we” consists of a large number of programmers working together, and all the complexities that entails?

deleted 7y ago

[deleted]