There’s a recurrent pattern with these package compromises: the attacker exfiltrates credentials during an initial phase, then pivots to the next round of packages using those credentials. That’s how we saw them make the Trivy to LiteLLM leap (with a 5 day gap), and it’ll almost certainly be similar in this case.

The solution to this is twofold, and is already implemented in the primary ecosystems being targeted (Python and JS): packagers should use Trusted Publishing to eliminate the need for long lived release credentials, and downstreams should use cooldowns to give security researchers time to identify and quarantine attacks.

(Security is a moving target, and neither of these techniques is going to work indefinitely without new techniques added to the mix. But they would be effective against the current problems we’re seeing.)

▲

paustint 3 hours ago | parent | next [-]

In this case, the author's NPM account was taken over, email address changed to one the attacker controls, and the package was manually published.

Since the attacker had full control of the NPM account, it is game over - the attacker can login to NPM and could, if they wanted, configure Trusted Publishing on any repo they control.

Axios IS using trusted publishing, but that didn't do anything to prevent the attack since the entire NPM account was taken over and config can be modified to allow publishing using a token.

▲

staticassertion 3 hours ago | parent | next [-]

Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).

▲

erikerikson 2 hours ago | parent [-]

Instead they took away TOTP as a factor.

Scaling security with the popularity of a repo does seem like a good idea.

	▲	mayhemducks 38 minutes ago \| parent \| next [-]
		Are there downsides to doing this? This was my first thought - though I also recognize that first thoughts are often naive.
	▲	moebrowne 19 minutes ago \| parent \| prev [-]
		TOTP isn't phishing resistant

▲

woodruffw 3 hours ago | parent | prev | next [-]

Well, that sucks! It’ll be interesting to learn how they obtained a valid second factor or 2FA bypass; that will inform the next round of defenses here.

▲

dboreham an hour ago | parent | prev [-]

One wonders if Microsoft/npm.js should allow new packages to be published immediately following an account email address change? I mean changes to email address are already recognized as potential attack vectors, so emails are sent to the old address warning of potential account take over. But this seems to have been done at night, so the warning email would not be seen yet. Even so a new package could be published and served to the world immediately. Unless I misunderstand something about the facts this would indicate an extreme lack of imagination in the people at Microsoft who already went through several cycles of hardening the service against supply chain poisoning attacks.

▲

paulpauper an hour ago | parent | prev | next [-]

Was this an drive-by/auto-install attack?

▲

MattDaEskimo 3 hours ago | parent | prev [-]

There are solutions, the problem is almost always discipline.

▲

woodruffw 3 hours ago | parent [-]

I don’t know what this means. Discipline is good, but I think you need to have good tools/primitives in place to help people exercise discipline.

(The classic example being passwords: we wouldn’t need MFA is everybody just “got good” and used strong/unique passwords everywhere. But that’s manifestly unrealistic, so instead we use our discipline budget on getting people to use password managers and phishing-resistant MFA.)

	▲	MattDaEskimo 2 hours ago \| parent [-]
		Really? You don't know the difference between having a door lock, and using it? MFA is typically enforced by organizations, forcing discipline. Individual usage of MFA is dramatically lower