npm Revoking All Tokens Was A Good Call

A week or so ago an ESLint project maintainer’s npmjs key was compromised. The compromised account was then used to upload alterations into some popular ESLint npm packages. The end goal of the altered code was to capture more credentials from open source package maintainers; presumably to create a truly malicious alteration at a future date.

A few things were interesting about the whole event. One of the first things that struck me was the quick and uniform responsiveness of the community. Looking through npmjs’ timeline and the initial bug report, it looks like the attacker published the malicious package at 3:40 AM PST on 7/12/2018. And the initial bug report came in around 4:17 AM PDT. That is an amazing turn around time of 27 minutes. It seemingly supports the open source mantra that “many eyes make a shallow problem”.

The response of the package maintainers and their community members was also fantastic. By 4:59 AM PDT (42 minutes after the report) they had determined that something was seriously wrong and they needed to (a) unpublish the package and (b) had already communicated with downstream sources that they needed to remove all references to the package. This wasn’t done by one person struggling to grapple with the situation, but everyone that was looking at the issue was seeing if they could inform other groups that a serious problem was occurring and action needed to be taken.

What really struck me was that npm’s administrators determined the correct course of action was to revoke all npmjs tokens created between 7/10/2018 at 5:00 PM PDT and 7/12/2018 at 5:30 AM PDT. npm’s administrators looked at the situation and instead of focusing on just the accounts that they knew to be compromised, they just said we don’t know who to trust right now. They had a reasonable expectation that something very wrong happened in that time frame and they weren’t going to take any chances with it. It was a really big decision, and I’m sure some people were really inconvenienced by it. But it was a well calculated move that took into consideration both security and scope. It was a good call.

Two things still bug me about the whole incident:

1. How did the package maintainer’s credentials become compromised?
2. What if the malicious update didn’t cause a compilation error? How long would it have gone undetected? Can many eyes make a shallow problem if there’s no problem to be seen?

The weird thing about this incident is that it reminds me of a blog post from January 2018, “I’m harvesting credit card numbers and passwords from your site. Here’s how.”. In the (hopefully fictitious) blog post it outlines how a small piece of malicious code could potentially be added into an open source project and get put into production use. If you take many of the reasonable claims that blog author makes and add to them the idea that a package maintainers publishing key is compromised, it would take the first set of eyes out of the equation. And those eyes are arguably the most important. The blog post posits truly cryptic code to get the pull request accepted. But, what if the attacker didn’t need to make the code overly cryptic, because the attacker had the ability to accept and publish?

I don’t know.

The one thing I take away from this is that the community acted very responsibly and swiftly; and that’s something to respect and strive to replicate.