The hard part is the deploying. Yes if you can get control of the crowdstrike deployment machinery, you can do whatever you want on hundreds of millions of machines. but you don’t need any vulnerabilities in the crowdstrike deployed software for that only the deploying servers.
Call me crazy but that is a real worry for me, and has been for a while. How long until we see some large corporate software have their deployment process hijacked, and have it affect a ton of computers that auto-update?
One of the most dangerous versions of this IMO is someone who compromises a NPM/Pypi package that's widely used as a dependency. If you can make it so that the original developer doesn't know you've compromised their accounts (spear-phished SIM swap + email compromise while the target is traveling, for instance, or simply compromising the developer themselves), you don't need every downstream user to manually update - you just need enough projects that aren't properly configured with lockfiles, and you've got code execution on a huge number of servers.
I'm hopeful that the fallout from Crowdstrike will be a larger emphasis on software BOM risk - when your systems regularly phone home for updates, you're at the mercy of the weakest link in that chain, and that applies to CI/CD and end user devices alike.
As always, a relevant xkcd[1]. I would not be surprised if the answer to “how many machines can be compromised in 24 hours by threatening one person” was less than 8 figures. If you can find the right person, probably 9+.
I mean, isn't that roughly the solarwinds story? There is no real shortage of supply chain incidents in the last few years. The reality is we are all mostly okay with that tradeoff.
