bluebay2014 - Fotolia
Compromised NPM package highlights open source trouble
A compromised NPM package targeted a popular bitcoin wallet with cryptocurrency-stealing code and experts say the issue highlights the lack of a chain of trust in open source software.
A highly targeted attack abused a lax chain of trust for an open source library and potentially infected millions via a compromised NPM package that averages 1.5 million downloads per week.
NPM is the package manager for the Node.js JavaScript runtime environment, and a popular package -- event-stream -- had malicious code added to it without anyone realizing for more than one month. The malicious code was added to the NPM package on Oct. 5, went unnoticed until Nov. 20 and it wasn't determined what the code did until Nov. 26. The incident occurred after ownership of the module was transferred from the original developer to an anonymous user, who added the malicious code.
The malicious code was highly targeted and specifically searched for users with the Copay bitcoin wallet in order to steal cryptocurrency. Because of this, it is still unclear how many users were victimized despite the popularity of the compromised NPM package -- thousands of other packages are dependent on NPM.
According to Kevin Beaumont, a security architect based in the U.K., the reach of the compromised NPM package could be vast.
Almost 5k packages in NPM have the trojaned NPM package as a co-dependency. It has also been trojaned for several months. In other words, it is in apps everywhere, oops.
— Kevin Beaumont (@GossiTheDog) November 26, 2018
Gary Bernhardt, a software developer based in Seattle, said on Twitter that NPM was especially suited to an attack like this.
Why did this happen to NPM and not another system? Partly, NPM is just a big target. But partly because NPM modules are tiny, so there are more modules and maintainers, which means more attack surface area. Create-react-app 2.1.1 installs 1,770 dependencies (excluding dupes).
— Gary Bernhardt (@garybernhardt) November 26, 2018
Jarrod Overson, director of engineering at Shape Security, wrote in a Medium post that "[t]he amount of effort this took was not trivial. This exploit took a lot of research and planning and likely had backup routes in the case that event-stream wasn’t able to be hijacked. Given the way the attack played out it seems plausible that the actor had targeted Copay specifically rather than grabbing a valuable library and planning out an attack from there. The popularity of event-stream meant that the attacker had an easy route in to privileged computers in hundreds of companies across the globe."
Responsibility for the compromised NPM package
Ayrton Sparling, a computer science student at California State University, Fullerton, who goes by the username FallingSnow on GitHub, discovered the malicious code in the compromised NPM package and tied the issue to the original author, Dominic Tarr, handing over maintenance of the package to a little-known user in early September.
Tarr, a software engineer based in New Zealand, defended his decision to give up control of the package on GitHub by noting that he doesn't get anything from maintaining the module and hasn't used it "for years."
Others, like Jake Williams, founder and president of Rendition Infosec, based in Augusta, Ga., said Tarr shouldn't be blamed because "there's a serious supply chain risk here that we need to wake up to sooner than later."
That said, it's not hard to see that we need a better mechanism for evaluating trust in package management tools like npm. We really need to ask what we're trusting: the developer/development team or the package name. I would argue we're getting it wrong today. 6/6
— Jake Williams (@MalwareJake) November 26, 2018
Overson said blame for issues like this compromised NPM package was "so distributed that there is no use in placing blame."
"The problem is that so much software is built on the backs of people who are expected to work for free. They deliver useful software once but are expected to maintain it until the end of time. If they can't, either they go dormant and ignore requests or security vulnerabilities or they pass the baton over to someone else hoping that they can get away without getting tagged ever again," Overson said. "Sometimes it works, sometimes it doesn't, but no outcome can excuse the security vulnerabilities this exposes in the software supply chain. Even the discovery of, research into, and subsequent damage control for this exploit was done largely by unpaid volunteers of the open source ecosystem."
Mounir Hahad, head of Juniper Threat Labs, said one way to reduce lone threat actor attacks like this would be to use "mandatory code reviews and processes to approve code changes by committers."
"Enterprises must have their finger on the pulse of message boards regarding hardening packages they use," Hahad said. "It may not be an easy task given most companies rely on hundreds and sometimes thousands of open source packages. Having a dedicated staff for this task may make it feasible."
Craig Young, computer security researcher for the Vulnerability and Exposure Research Team at Tripwire, said this type of dependency management can be "particularly challenging in the NPM ecosystem where projects commonly include extremely long lists of modules from a wide range of authors."
"It is not uncommon for node.js/NPM projects to have upwards of 1,000 dependencies in a project. This has greatly increased the odds that a single malicious module commit can undermine the security of many end projects," Young said. "Organizations developing code with node.js/NPM need to really keep a close eye on what is being imported, who controls the code, and whether it is trustworthy. This is especially true when projects rely on free, community developed code."
