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/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/
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.
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.
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?
> There is zero chance software would end up impenetrable under those conditions.
Not when it is so impenetrably complex that there are always hidden errors. The only secure software is simple enough that a single human mind can comprehend it and verify correctness, and as an entire industry we have moved away from that entirely.
The problem is not with digital signatures. The problem is bad ECC certs used to generate digital signatures. So SMB is not affected. Code signed with one of these bad ECC certs is a concern. But considering that people install stuff that's not signed all the time, the primary issue is probably TLS MITM.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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/