"found out right away"... by people with time to review security bulletins. There's loads of places I could see this slipping through the cracks for months.

▲

andrewstuart2 4 days ago | parent | next [-]

I'm assuming they meant the account takeover was likely to be found out right away. You change your password on a major site like that and you're going to get an email about it. Login from a new location also triggers these emails, though I admit I haven't logged onto NPM in quite a long time so I don't know that they do this.

It might get missed, but I sure notice any time account emails come through even if it's not saying "your password was reset."

▲

benoau 4 days ago | parent | prev | next [-]

There's probably already hundreds of thousands of Jira tickets to fix it with no sprint assigned....

▲

brazzy 3 days ago | parent | next [-]

I feel attacked.

And very, very happy that we're proxying all access to npm through Artifactory, which allowed us to block the affected versions and verify that they were in fact never pulled by any of our builds.

	▲	Aeolun 3 days ago \| parent \| next [-]
		Only problem is the artifactory instance is on the other side if the world instead of behind the convenient npmjs CDN, so installing packages takes 5x longer..
	▲	pixl97 3 days ago \| parent \| prev [-]
		About to say, if you're in a company of any size and you're not doing it this way, you're doing it wrong.

▲

hylaride 3 days ago | parent | prev [-]

Ugh, have some respect. Some of us have PTSD dealing with security issues where the powers that be prevented us dealing with them due to them deprioritizing them during backlog grooming. My last company literally refused to do any security work except CVE turndowns - because it was contractually promised via a customer contract.

▲

zahlman 4 days ago | parent | prev | next [-]

Yes, but this is an ecosystem large enough to include people who have that time (and inclination and ability); and once they have reported a problem, everyone is on high alert.

▲

wongarsu 4 days ago | parent [-]

If you steal the cookies from dev machines or steal ssh keys along with a list of recent ssh connections or do any other credential theft there are going to be lots of people left impacted. Yes, lots of people reading tech news or security bulletins is going to check if they were compromised and preemptively revoke those credentials. But that's work, meaning even among those informed there will be many who just assume they weren't impacted. Lots of people/organisations are going to be complacent and leave you with valid credentials

▲

ameliaquining 4 days ago | parent | next [-]

If a dev doesn't happen to run npm install during the period between when the compromised package gets published and when npm yanks it (which for something this high-profile is generally measured in hours, not days), then they aren't going to be impacted. So an attacker's patience won't be rewarded with many valid credentials.

▲

giveita 3 days ago | parent [-]

Dev, or their IDE, agent, etc.

▲

komali2 3 days ago | parent [-]

Their build chain, CI environment, server...

	▲	ameliaquining 3 days ago \| parent [-]
		npm ci wouldn't trigger this, it doesn't pick up newly published package versions. I suppose if you got a PR from Dependabot updating you to the compromised package, and happened to merge it within the window of vulnerability, then you'd get hit, but that will likewise not affect all that many developers. Or if you'd configured Dependabot to automatically merge all updates without review; I'm not sure how common that is.

▲

com2kid 4 days ago | parent | prev [-]

But that is dumb luck. Release an exploit, hope you can then gain further entry into a system at a company that is both high value and doesn't have any basic security practices in place.

That could have netted the attacker something much more valuable, but it is pure hit or miss and it requires more skill and patience for a payoff.

VS blast out some crypto stealing code and grab as many funds as possible before being found out.

> Lots of people/organisations are going to be complacent and leave you with valid credentials

You'd get non-root credentials on lots of dev machines, and likely some non-root credentials on prod machines, and possibly root access to some poorly configured machines.

Two factor is still in place, you only have whatever creds that NPM install was ran with. Plenty of the really high value prod targets may very well be on machines that don't even have publicly routable IPs.

With a large enough blast radius, this may have worked, but it wouldn't be guaranteed.

▲

joshuat 4 days ago | parent | prev [-]

The window of installation time would be pretty minimal, and the operating window would only be as long as those who deployed while the malicious package was up waited to do another deploy.