Shai-Hulud Returns: Over 300 NPM Packages Infected

This is why I am not a huge fan of separate package managers for libraries, such as in the case of rust, or node. The C style of sharing deps. couldn't really be simpler as just including the headers in your Makefile.

We really don't need more package managers other than the ones provided by your operating system, but I dunno maybe its just me.

containerize all the things...Nix, Podman, Docker. It's not a big hassle once you get through the initial steps.

Would be good to see projects (like those recently effected) nudging devs to do this via install instructions.

As a marketer who relies on tools like Zapier and PostHog and n8n, etc - terrifing. Since it means the dev/security teams may take our toys away :(

I use the following to at least sandbox things in containers with an easy to use develop experience.

https://github.com/jrz/container-shell

- There is a single root dependency somewhere which gets overtaken

- A new version of this dependency is published

- A CI somewhere of another NPM package uses this new version dependency in a build, which trigger propagation by creating a new modified version of this dependency?

- And so on...

Am I getting this right?

Both of these attacks have used trufflehog. Is there an out of the box way to block that executable by name or signature?

Is there a terminal AI assistant that doesn't have heaps of depenedancies and preferably no node? Claude and codex both require node. I'm a fan of the lightweight octofriend. But also node. I do not like installing node on systems that otherwise would not require it.

Is this a problem with Python package management too? If not, what distinguishes Python from NPM or makes it more resistant etc?

Maybe, we have to rethink depencies from the ground up.

Implementing everything yourself probably won't cut it.

Copying a dependency into your code base and maintaining it yourself probably won't yield much better results.

However, if a dependency would be part of the version control, depends could at least do a code review before installing an update.

That wouldn't help with new dependencies, that come in with issues right from.the start, but it could help preventing new malware from slipping in later.

A setup like that could benefit from a crowd-sourced review process, similar to Wikipedia.

I think, Nimble, the package manager of Nim, uses a decentralised registry approach based on Git repos. Something like that could be a good start.

I have never tried NPM. Somehow I can still find the software I want, or write it myself. I think I would find Javascript too slow

Friends don’t let friends NPM.

Would the adoption of a Deno-like security posture in NPM have mitigated this?

I’m looking for info on whether MalwareBytes would catch this and not finding anything.

My motto wrt language choices: "It's the standard lib, stupid!"

My ultra hot take: there are only¹ two² programming ecosystems suitable for serious³ work:

  - .net (either run on CLR or compile as an AOT standalone binary)
  - jvm

  __
  1. I don't want other programming languages to die, so I am happy if you disagree with me. Other valid objection: some problems are better served by niche languages. Still, both .net and java support a plethora of niche languages.
  2. Shades of gr[e|a]y, some languages are more complete out of the box than others. 
  3. cf «pick boring tools»

> bun_environment.js is a highly obfuscated malicious JavaScript file. It is over 10MB in size and contains a significant amount of built-in logic for information theft.

That seems a bit silly. Even on the beefy boi I used to work on a 10MB hiccup in deployable size would have been sufficient to make me look.

I released one of the packages I work on last night so of course this drew my eye. I assume checking the unpacked size hasn’t gotten ridiculous confirms that your code is not infected yeah? And looks like it’s past time for me to set up a separate account for release management.

"This appears to have limited the imapct of the attack at this time."

typo after the listed affected packages

This is still happening -- github should implement a hotfix to disallow creation of repos with this exact name and structure...

Funny coincidence reading this while in the middle of rewatching Dune 2 on Netflix

And this, kids, is why you should vendor your dependencies

the left-pad fiasco seems to have been the only time npm changed a policy and reacted to a security problem, since then it seems that supply chain attacks just belong to the npm-eco-system

How was the attack detected in the first place?

Thought this was about the band ...

See also: https://news.ycombinator.com/item?id=46005111

As it arguably would have reduced impact

(I'm one of the Renovate maintainers and have recently pushed for this to be more of a widely used feature)

Once again, you cannot ask the open source world to provide you with free dependencies and security.

At some point, someone has to pay for an organisation whose job will be to review the contents of all of these modules.

Maybe one could split the ecosystem into "validated" and "non validated" stacks ? much like we have stable and dev branches ?

The people validating would of course give their own identity to build trust. And so, companies (moral person) should do that.

these packages stood out for me

shinhan is a large korean bank and this admin area geo json util seems to be embedded in many korean gov services.

shinhan-limit-scrap

korea-administrative-area-geo-json-util

Very concerning, so that was what the "impending disaster" was as I first noted. [0] Quite worrying that this happened again to the NPM ecosystem.

Really looking forward to a deeper post-mortem on this.

[0] https://news.ycombinator.com/item?id=46031864

Will the list of affected packages expand? How were these specific packages compromised in the first place?

More:

SHA1-Hulud the Second Comming – Postman, Zapier, PostHog All Compromised via NPM

https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting...

Here's the underlying problem: let's imagine someone very smart. They figure out a way to solve this problem. They are not going to make any money by doing so. That's why we have this problem.

The list of affected packages is concerning - indeed.

If you always run npm inside of docker does that pretty much prevent attacks like this?

GitHub back in September already published their roadmap of mitigations to NPM supply chain attacks:

https://github.blog/security/supply-chain-security/our-plan-...

I'm guessing no one yet wants to spend the money it takes for centralized, trusted testing where the test harnesses employ sandboxing and default-deny installs, Deterministic Simulated Testing (DST), or other techniques. And the sheer scale of NPM package modifications per week makes human in the loop-based defense daunting, to the point that only a small "gold standard" subset of packages that has a more reasonable volume of changes might be the only palatable alternative.

What are the thoughts of those deep inside the intersection of NPM and cybersecurity?

why don't web devs just learn html and css properly, and maybe xslt for the really complex transformations then use vanilla js only when it's truly necessary?

instead we've got this absolute mess of bloated, over-engineered junk code and ridiculously complicated module systems.

[dead]

[dead]

I wish everyone here would read https://en.wikipedia.org/wiki/Capability-based_security and then realize that maybe, JUST MAYBE, THE PROGRAMMING LANGUAGES WE USE SHOULD NOT ALLOW IMPORTED PACKAGES TO ACCESS EVERYTHING, AND THEIR LACK OF SECURITY GUARANTEES AND ACCESS RESTRICTION MECHANISMS MAKES THEM DANGEROUS!

The number and range of affected devices may be reduced with any number of package manager level workarounds, but NOT the impact of attacks once any succeeds. For this, you NEED the above.

What we need is an open source industry standard stdlib equiv developed and maintained by MS, GOOG and some open source players.

All libraries should strive to have dependency only on it.

There are actually hundreds more NPM packages infected, see here: https://www.koi.ai/incident/live-updates-sha1-hulud-the-seco...