Conversation

Nov 26, 2018

I think this npm incident falls into the category of "insider threats", which are pretty much every security professional's worst nightmare

Quote Tweet

Aaron Patterson

@tenderlove

Nov 26, 2018

Honestly I'm not even sure what the lesson to learn from this event-stream "event" is. Don't let others maintain your package? Don't trust anyone?

Tony "Abolish ICE" Arcieri

@bascule

Nov 26, 2018

Captain Hindsight sez...

Replying to

Do you feel that that's the responsibility of the maintainer?

Replying to

and

If they wanted him to have the responsibility of doing due diligence, companies depending on his library should have paid him. He stated that he was doing it for fun and it stopped being fun so he handed it off to someone else as quickly as they showed up. It was a hobby project.

Replying to

and

Or they should have done the due diligence themselves. Blindly upgrading to a new version of the library from a different maintainer was their choice. How were they even verifying the sources? Doesn't sound like anything was signed, and an account takeover could have done this.

Replying to

and

So apparently npm has no package signing. I didn't realize it was that bad. The previous developer didn't even need to hand over a signing key to the new developer, since nothing is being signed and verified anyway. What if they had simply chosen a bad / reused password for npm?

Replying to

and

hard to imagine how package signing works without key management, and key management doesn’t work at scale, so i’m not sure this is a super fair criticism

Tony "Abolish ICE" Arcieri

Replying to

and

I think TUF works well for managing a developer PKI and applying package AuthZ policies, however it’s also worth noting that would’ve done nothing to prevent this particular attack, since it was malware injected via transitive dependencies by an authorized publisher

Replying to

and

There are language package managers with package signing. At the very least, pinning the key fingerprint on first use with a mechanism for automatically rotating to requiring signatures from additional new keys works well.

Replying to

and

The developer might have just handed away their signing key, and I'm not claiming it would have prevented this attack. I'm just noting that npm doesn't even appear to have trust on first use package signing. There are many package managers that at least *try* to provide signing.

Replying to

and

They have a system for pinning versions of packages and could easily have automatic trust on first use key pinning as part of that. I'm just noting that an account takeover could have done the same thing. People were trusting the developer's choice of password for npm already.

11:13 PM · Nov 26, 2018Twitter Web Client