Hacking Node.js: “May I Have This Repo?”
The Unbelievable Danger of Upstream Dependencies
This article reviews multiple cases of social engineering takeovers of JavaScript repositories unleashing incredible attacks on unsuspecting users and software. First up: the BitPay compromise.
EventStream Hack
On November 20th, 2018 Ayrton Sparling opened an issue, loudly, in the Github repo for the NPM module EventStream: a new repo maintainer had injected malicious code into one of the revisions and then covered it up.
The story is as ridiculously simple as it is brazen: EventStream, an upstream dependency (e.g. auto-imported in NPM dependency chains) was essentially an unmaintained repo originally created by Dominic Tarr.
A random user with low commits and minimal reputation, right9ctrl, asked if he could take over maintenance.
Dominic agreed.
The new maintainer, right9ctrl, then proceeded to include the compromised/payload-laden flatmap-stream, injected the bad code into one revision, published it, then removed/hid the bad code and created a new update — leaving anyone using the last version compromised.
Multiple users rallied to the investigation after Ayrton’s report, and the details of what the payload could do were devastating:
Worse: tons of crypto-projects were dependent on EventStream. Including BitPay.
And this isn’t the first time the teetering LEGO tower of JavaScript has doomed hundreds or thousands of projects.
Remember Azer Koçulu’s epic un-publish?
Kik’d to the Curb
Azer Koçulu wrote a lot of NPM modules. One happened to be named Kik, and the lawyers at the Kik messaging app decided they wanted to appropriate the NPM spot that Koçulu’s project was taking up with their own.
He refused to rename his project.
NPM took it away, triggering an epic “unpublish” of everything he had contributed to NPM.
A unexpectedly large swath of the internet immediately went down as NPM dependency checks failed due to a particular missing project: left-pad.
That’s right: so many other projects had incorporated this trivial functionality as a library rather than implementing their own solutions that when their automated build processes went to compile they failed.
NPM actually un-unpublished the project just to end the panic.
The Dark Tower
Upstream dependencies are the new normal for Node.js developers.
Indeed, so many LEGO-like bricks exist in the Node.js ecosystem, made so easily accessible by the node package manager, that vetting and security are ever-increasing in difficulty.
What has been assembled, as demonstrated in the case of EventStream, is a “dark tower” of dependencies in which some percentage of required projects are abandonware, unmaintained, or unsecured.
As in the first case mentioned a simple social engineering attack can be all that stands between enterprise software and the security of their users.
What mechanisms exist for resolving this? What bodies review the condition of these dependency chains?
Sure, NPM reacts when informed, but why can’t there be a proactive methodology for assessing these risks?
Also, can we not invent a mechanism to reward original maintainers to keep an interest in their work when it becomes heavily used? (Any simple such reward system would naturally fall prey to rigging, but I think it’s worth exploring).
Test Yourself
Is your project affected by the EventStream hack?
Go to your project folder and run npm ls event-stream flatmap-stream to find out.
A good result looks like this:
But a bad result will show the dependency, as was user lcl22hope’s case:
Summary
- NPM packages have long, sometimes-weakly-secured, dependency chains.
- A single weak-link can lead to automated execution of malware and exploits.
- We probably aren’t doing enough to secure legacy projects that are highly used but offer no incentive to the original developers.
- Repo owners are somehow assumed to have some sort of lasting responsibility for their contributions, as the criticism of Dominic shows. Is such personal criticism warranted or are the mechanisms themselves to blame?
