SAN FRANCISCO, CA - In the wake of a devastating supply chain attack in the npm registry that left millions of enterprise applications compromised and billions of user records exposed, developers across the JavaScript ecosystem expressed deep sorrow today, lamenting that such a crisis was completely unavoidable.
“It’s a shame, but what can you do? This is just the price of building modern web apps,” said Senior Frontend Engineer Mark Vance, echoing the sentiments of a community that completely relies on a 40-level-deep nested tree of unvetted packages maintained by pseudonymous strangers to capitalize a single string. “There’s absolutely no way to foresee or prevent someone from taking over a long-abandoned utility package and injecting a crypto-miner into every production build in the world. It’s just an act of nature.”
I disagree. There are many process failures and areas where security can be improved, independent of trusting a distro maintainer or developers.
For example, 2FA should probably be enforced for the process of publishing packages. It does appear to be enforced for new packages but older packages still have legacy settings. Github now forces 2fa for basically everything, and they applied that even to existing organizations and repos. There is no real reason that NPM (owned by Github) isn’t able to do the same.
Or another example, is sandboxed builds. Many of these packages, like NPM and Rust packages, have build time scripts, which are executed unsandboxed at compile/install time of these programs. That is how these NPM worms have been so pervasive. You don’t have to actually run the javascript package for it to do bad things, just merely installing it.
On the other hand, the build systems that distro’s use, often involve sandboxing the builds to limit the attack surfaces (including limiting network access). Although, Linux distros usually rip out build scripts and build systems in order to replace them with their own, but this also further limits the code you have to audit.
Even better is to sandbox the program itself to further limit harm but that’s not done on Linux distros and is somewhat outside the scope of this discussion.
If you are an NPM developer, I recommend Deno, with it’s built in, on by default sandboxing… that people like to disable. But it’s there and is better than giving random NPM package #245 access to your home directory. You could also use podman or docker but yeah.
The most successful recent attacks haven’t relied on stolen user credentials, so this point is kind of moot. API tokens are way easier to obtain and use. Typo squatting and phishing are more effective, and attackers generally don’t need to bypass 2FA.
Linux users who routinely download and compile src packages is a minuscule attack vector. Most users download binaries, so this point isn’t true either.
And look, I agree that MFA should be mandatory everywhere, and sandboxing is great, but the truth is that the JS ecosystem is chock full of lazy and sloppy devs. That’s just how it has been for the longest time, and no amount of security measures targeting them specifically is going to fix the current state of affairs, because as soon as one is implemented, someone will find it too cumbersome and will find a way to override it. The whole ecosystem needs adult supervision.
But honestly, I believe that JS in the backend has been a massive mistake and we all should abandon it as soon as possible. There are plenty of better languages and ecosystems out there, no need to keep self inflicting this kind of pain.
Api tokens are also a stolen credential. They are getting stolen via things like unsandboxed malicious packages that search for them.
That is TeamPCP’s main modus operandi, they have an infostealer that tries to nab whatever credentials it can find, and then uses those to spread more.