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

771–780 of 797 posts

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

#771

Post by int_19h »

CodesInChaos wrote: post #196
CharlieDigital wrote: post #136

Earlier quoted context omitted.

2020 State of the Octoverse security report showed that .NET ecosystem has on average the lowest number of transitive dependencies. Big part of that is the breadth and depth of the BCL, standard libraries, and first party libraries.

The .NET ecosystem has been moving towards a higher number of dependencies since the introduction of .NET Core. Though many of them are still maintained by Microsoft.

I think first-party Microsoft packages ought to be a separate category that is more like BCL in terms of risk. The main reason why they split them out is so that they can be versioned separately from .NET proper.

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

#772

Post by Ygg2 »

eichin wrote: post #670
Ygg2 wrote: post #259

Earlier quoted context omitted.

> countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx ) Don't make me tap the sign: https://news.ycombinator.com/item?id=41727085#41727410 > Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. They add a layer of convenience. C/C++ are missing that convenience because they aren't as composable and have a long tail of pre-pac…

Or from another angle, dpkg/apt is the package manager for C/C++ ...

Yeah, but it's not immune to supply chain attacks. Counting on maintainers of dpkg is not that different from counting on maintainers of random crate package.

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

#773

Post by jwpapi »

twistedpair wrote: post #761
jwpapi wrote: post #732

Earlier quoted context omitted.

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 cal…

Or they just wanted to prove a point.

They surely seemed to be smart enough to choose encryption over encoding.

Hard to believe encryption would be the one thing that would trigger code scanners.

Also it’s not just every vendor, also every bad actor could’ve scraped the keys. I wonder if they’ve set up the infrastructure to handle all these thousands of keys…

Like what do you even do with most of it on scale?

Can you turn Cloud, AWS , AI api keys to money on a black market?

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

#774

Post by int_19h »

skydhash wrote: post #178
mschuster91 wrote: post #138

Earlier quoted context omitted.

> That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. Yeah, that's why I said that this is the other end of the pendulum. > In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. Oh I'm aware of that. My point still stands - that comes at a serious maintenance cost…

Wait what? That’s just fearmongering, how hard is it to add a few methods that split a string or pad it? It’s not rocket science.

This kind of thing is precisely the stuff that needs to be in stdlib.

C++ is hardly a good example to follow here, but then again it does have Boost which is the de facto "extended standard library" in practice, and gets treated differently from other dependencies by many.

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

#775

Post by int_19h »

jalapenos wrote: post #379
kunley wrote: post #373

Why the biggest package mess is always with the Node ecosystem? Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good") Why certain kind of mindset is typical to this community? Why the…

Feels good, just for a second, to type pretence you're above everyone doesn't it? Just for those few seconds, you're better than a big whole arbitrary collection of people, and for those few seconds you have relief from the reality of your life.

The reality of my life is that I have to write code targeting Node because of choices that other people made for their libraries and products.

I didn't hate JS & npm with a passion before. I do now, and it hasn't even been two years.

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

#776

Post by int_19h »

tjpnz wrote: post #158
creata wrote: post #133

Earlier quoted context omitted.

There's nothing technically different between NPM and, say, Cargo, here that would save Cargo, is there?

This is a cultural problem created through a fundamental misunderstanding (and mis-application) of Unix philosophy. As far as I'm aware the Rust ecosystem doesn't have a problem appropriately sizing packages which in turn reduces the overall attack surface of dependencies.

It's kinda funny because "Unix philosophy" was never a coherent thing in the first place. Arguably Plan 9 came the closest to that in practice, but, well, you might note it didn't exactly have a strong uptake. Unix itself is a pile of hacks though, and it's both sad and amusing to watch people trying to divine some kind of methodology out of that.

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

#777

Post by junon »

woodruffw wrote: post #760
junon wrote: post #748

Earlier quoted context omitted.

It's not a silver bullet in that it can open up other vectors of much more probable attack. If I have a FOSS project where there are other contributors with write access but not publish access (very common) OIDC now allows them to publish via workflows, opening you up to Jia Tan type attacks. Like I said, if it works for your org, great. Otherwise it can cause bigger problems.

Sorry, what's the threat model in which you're giving people write access to your repository but assuming that they can't publish? To establish a baseline here: the assumption with Trusted Publishing is that people are already using CI/CD to publish to places like PyPI. All Trusted Publishing does is replace the user-managed credential with a machine-intermediated one. In other words: if someone had write access to y…

> Sorry, what's the threat model in which you're giving people write access to your repository but assuming that they can't publish?

So that I'm the arbiter of what people download, and can review locally what changes were made prior to pushing it out to everyone.

> To establish a baseline here: the assumption with Trusted Publishing is that people are already using CI/CD to publish to places like PyPI.

That's not the narrative. People have been saying to switch to trusted publishing from local publishes. They're not 1:1 compatible. I agree that if you already publish via CD, then it probably already worked for your org and thus is a no brainer.

> If this isn't your user model, that's perfectly fine. But in that case you shouldn't be using CI/CD to publish at all (which is also fine); it's not an issue with Trusted Publishing per se.

That's exactly the point I'm making.

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

#778

Post by p3rspective »

gred wrote: post #751
p3rspective wrote: post #727

Earlier quoted context omitted.

Make no mistake, Maven Central does get multiple malware components uploaded each year, though not nearly to the same extent as npm or pypi. Sonatype (my former employer) just doesn't report on these publicly each time it happens. It's not an isolated problem but certainly harder to do with maven.

I assume you're talking about malware uploaded to new artifact coordinates (possibly named so as to try to confuse users), not hijacking of existing artifact coordinates (group ID, artifact ID)?

generally yes, although hijacking can and has happened on Central with expired maintainer domains reclaimed by threat actor who can then republish malicious versions of a previously legit group/artifact ID. there's also the problem of mirrors or copies of hijacked npm being replicated on Central -https://x.com/SocketSecurity/status/1993389518247149907

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

#780

Post by YetAnotherNick »

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.

You can't "require" manual intervention. Sure you can say that the keys stays on say 2 developers laptops, but personal devices have even more surface area for key leak than CI/CD pipeline. It wouldn't have prevented attacks like this issue in any case where the binary just searched for keys across the system.

One alternative is to do the signing on airlocked system stored in physically safe but accessible location, but I guess that's just way too much inconvenience.

Post reply on HN