Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

761–770 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#761

Post by twistedpair »

jwpapi wrote: post #732
theodorejb wrote: post #717

Earlier quoted context omitted.

My guess would be so they don't have to embed an IP address or hostname in the malware to send secrets to, which could then be blocked or taken down.

But they could encrypt it, its just double b64 encoded, everybody can read it.

That one stumped me. Why not just encrypt with a hardcoded public key, then only the attacker can get the creds.

The simple B64 encoding didn't hide these creds from anyone, so every vendor out there's security team can collect them (e.g. thinking big clouds, GitHub, etc) and disable them.

If you did a simple encryption pass, no one but you would know what was stolen, or could abuse/sell it. My best guess is that calling node encryption libs might trigger code scanners, or EDRs, or maybe they just didn't care.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#762

Post by bilalq »

mbreese wrote: post #678
bilalq wrote: post #278

Earlier quoted context omitted.

You're probably already planning this, but please setup an alarm to fire off if a new package release is published that is not correlated with a CI/CD run.

Or require manual intervention to publish a new package. I'm not sure why we need to have a fully automated pipeline here to go from CI/CD to public package release. It seems like having some kind of manual user interaction to push a new version of a library would be a good thing.

This is orthogonal to the issue at hand. The problem is a malicious actor cutting a release outside of the normal release process. It doesn't matter if the normal process is automated or manual.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#763

Post by serial_dev »

bilalq wrote: post #762
mbreese wrote: post #678

Earlier quoted context omitted.

Or require manual intervention to publish a new package. I'm not sure why we need to have a fully automated pipeline here to go from CI/CD to public package release. It seems like having some kind of manual user interaction to push a new version of a library would be a good thing.

This is orthogonal to the issue at hand. The problem is a malicious actor cutting a release outside of the normal release process. It doesn't matter if the normal process is automated or manual.

It could have eliminated an attack surface where they steal the credentials from the CI/CD...

...But then you if I understand NPM publishing well, you would still have the credentials on someone's computer laying around? I guess you could always revoke the tokens after publishing? It's all balancing convenience and security, with some options being bad at both?

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#764

Post by serial_dev »

vintagedave wrote: post #2

Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…

Couldn't similar issues happen with Rust, Python, Dart, C#, Java, Ruby? Supply chain attacks are not unique to Node / NPM.

I'm sure the list of available attacks are somewhat different, but you can get pwned in all of these ecosystems.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#765

Post by jkl5xx »

nathan_compton wrote: post #426

I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container. I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.

This is smart and a good first step. Everyone can't be trusted to do the security dance flawlessly, though. We need sane defaults. Least privilege by default for 3rd-party code. Deno's headed in the right direction with this. But I think the solution needs to exist deeper in the stack. The surge in popularity of `curl -fsSL https://my-cool-ai-starup.ai/install.sh | bash` style installers is particularly concerning to me in this regard.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#766

Post by mbreese »

woodruffw wrote: post #759
mbreese wrote: post #752

Earlier quoted context omitted.

But that’s the person I think is mandatory. You’re saying that whatever is in the source repository should be uploaded in the npm index, right? If the code is tagged as release, the built artifact is automatically uploaded to npm. Is that what you’re proposing? That exactly what got PostHog into this position. The keys to publish to npm were available to an engineer or GitHub to push a malware build into npm automati…

> You’re saying that whatever is in the source repository should be uploaded in the npm index, right? If the code is tagged as release, the built artifact is automatically uploaded to npm. Is that what you’re proposing? No, I'm saying that the source repository should act as an authentication principal itself . A human should still initiate the release process, but the authentication process that connects the source…

I think we agree more than we don’t and the rest are personal preferences and policy differences. But we largely agree in principle.

I like the idea of having a person whose job is approving releases. Kind of like a QC tag — this release was approved by XX. I saw the issue as PostHog having a credential available to the CI/CD that had the authority to push releases automatically. When a new GitHub action was added, that credential was abused to push a bad update to npm. I might be wrong, I don’t deal with npm that much.

There are many ways to fix this.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#767

Post by sapiogram »

kibwen wrote: post #745
sapiogram wrote: post #446

Earlier quoted context omitted.

Rust's standard library hasn't received any major additions since 1.0 in 2015, back when nobody was writing web services in Rust so no one needed logging.

This is patently false. The majority of the "features" that get added to Rust in every release are additions to the standard library.

Depends on your definition of "major". Small utility functions are added on nearly every release, but they definitely aren't major.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#768

Post by int_19h »

TheDong wrote: post #711
robot-wrangler wrote: post #370

Earlier quoted context omitted.

No built in logging seems pretty crazy. Is there a story behind that?

It seems like the normal and rational choice to not include logging to me. Java included 'java.util.logging'. No one uses it because it's bad, everyone just uses slf4j as the generic facade instead, and then some underlying implementation. Golang included the "log" package, which was also a disaster. No one used it so they introduced log/slog recently, and still no one uses that one, everyone is still using zap, logr…

Python includes logging, and packages generally use it. It's far from perfect, but it's important to have at least a standard interface so that all components use it in concert. When you have a proliferation of logging libraries with no standard, other packages either don't do any logging at all, or do it in idiosyncratic ways that are hard (or impossible) to integrate.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#769

Post by int_19h »

latentsea wrote: post #755
HighGoldstein wrote: post #403

Earlier quoted context omitted.

Yes, but the 3rd party dependencies tend to be conveniences rather than foundational. Easier mapping, easier mocking, easier test assertions, so a more security minded company can very easily just disallow their use without major impact. If it's something foundational to your project then what you're doing is probably somewhat niche. Most of the time there's some dependency from Microsoft that's rarely worse enough t…

I dunno, there's definitely stuff that's convenience related, sure, and then there's stuff that's less so. Things like MediatR, Dapper, Serilog, Refit are all pretty common in .NET projects. There's usually always some library for generating PDFs for reporting purposes etc. The ecosystem of NuGet packages is pretty large. It's definitely not all just Microsoft dependencies, nor is that usually how developers in the e…

OP might be remembering how things were 10 years ago or so, before .NET Core became the .NET. Although there are still many companies with legacy codebases running on .NET 4.

That aside, dependency graphs in .NET land still tend to be much smaller.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#770

Post by int_19h »

whizzter wrote: post #282
dotancohen wrote: post #29

Earlier quoted context omitted.

Historically, arguments of "it's popular so that's why it's attacked" have not held up. Notable among them was addressing Windows desktop security vulnerabilities. As Linux and Mac machines became more popular, not to mention Android, the security vulnerabilities in those burgeoning platforms never manifested to the extent that they were in Windows. Nor does cargo or pip seem to be infected with these problems to the…

Compared to the JS ecosystem and number of users both Python and Rust are puny, also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies). As for Windows vs the other OS's, yes even the Windows NT family grew out of DOS and Wi…

> Compared to the JS ecosystem and number of users both Python and Rust are puny

This is just plainly false in case of Python.

> also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies).

Rust is already "native" so Cargo doesn't need to do anything.

Python has the logic to do native builds baked into pip and friends, so a Python package can just specify what to build in the manifest. But it also allows for precompiled wheels, and most popular packages do them for all major OSes, so users rarely need to actually build stuff in practice.

Post reply on HN