DEV Community

npm package discovered to have bitcoin-stealing backdoor

Ben Halpern on November 26, 2018

I think people expected this would happen, or was already happening. This is a serious security risk we've all been dealing with in open source. ...
Collapse
 
rhymes profile image
rhymes

Npm is the perfect attack vector. Thousands of ill maintained packages with thousands of transitive dependencies.

Email one fed up maintainer, get commit rights, spread the malware.

I don't even completely blame the maintainer, he like many probably couldn't wait to take that weight off his shoulder.

I can't think of an easy solution. A package with millions of weekly installs shouldn't be unmaintained, but how do you solve this issue once and for all?

Collapse
 
ben profile image
Ben Halpern

It’s probably much easier said than done to cut this off at the head, but static analysis + web crawling can probably go a lot further.

One side conversation is the dependency mayhem we engage in for reasons that have nothing to do with security.

  • Performance
  • Maintainability
  • Customizability

Lots of reasons to to trend conservative on including dependencies, especially on the client.

Left-pad had a big affect on me.

Collapse
 
nektro profile image
Meghan (she/her)

Be very careful of adding dependencies

Collapse
 
rhymes profile image
rhymes

It's easier said than done.

For example:

Collapse
 
david_j_eddy profile image
David J Eddy

This is one of the reasons every project should have a security point of contact. If not only to audit any dependencies added to the project; but to help the team stay ahead of emerging threats.

Multiple providers now offer security scanning as whole or part of the offered services. This can/does catch many security compromises before the code reaches any environments. Security needs to be a first class concern just like UX usability, performance, and database integrity. I dislike using trending works but this is a cornerstone of DevSecOps. DevOps + Security bakes in.

As a side note event-stream has nearly 2 MILLION downloads a week; wow.

Collapse
 
gypsydave5 profile image
David Wickes

As a side note event-stream has nearly 2 MILLION downloads a week; wow.

Everytime you delete that bloody node_modules directory and start again...

Collapse
 
pbnj profile image
Peter Benjamin (they/them)

Came here to say just that, but you beat me to it.

A few things developers can do right now to introduce or elevate the security posture of their projects:

  1. Incorporate a security static code analysis tool to ensure the code you're writing is safe (e.g. awesome-static-code-analysis).
  2. Incorporate compositional analysis tools to ensure your dependencies are free of vulnerabilities (e.g. snyk, npm audit).
  3. Enable & require MFA when publishing modules to npm.
  4. Be cautious of dependencies that don't do any of the above and prefer a little copying over bringing in an entire dependency if the scope of the dependency is small enough.
Collapse
 
david_j_eddy profile image
David J Eddy

(e.g. awesome-static-code-analysis). <- Awesome List is awesome! Thank you for the other tools as well. Very good mind set and security policies.

Collapse
 
yaser profile image
Yaser Al-Najjar

That's why I HATE deleting-issue feature in github!

Collapse
 
yorodm profile image
Yoandy Rodriguez Martinez

True that

Collapse
 
aturingmachine profile image
Vince

So this hack is actually kind of beautiful, from an engineering standpoint. It is meant to only trigger when run by a certain bitcoin wallet package, which has the original affected package as a dependency. The code then grabs your wallets private key. It requires the malicious code through an obfuscated require call. Which then only tries to do bad things if it reads a certain npm package description, the one from copay I believe. Equally beautiful and malicious.

The REAL kicker is that the malicious code only lived in the minified source of the flatmap-stream package. It was only able to decode and run when it hit the proper NPM package description.

The culprit loaded in malicious code into a widely used package distributed over loads of projects to hit a single package that used it as a dependency.

Collapse
 
yorodm profile image
Yoandy Rodriguez Martinez • Edited

Mmm, malicious code that targets Javascript and the Blockchain....I will call it Buzzware 😝

Collapse
 
gypsydave5 profile image
David Wickes

Great. Left-pad's evil twin finally arrived.

One of the reasons I've never liked the Node ecosystem is the ill managed nature of NPM. 'The largest package system in the world' - sure, but it's massive swamp of crap for the most part. I'd deliberately try to use the most minimal tools when bringing things in to my projects - tape instead of ava for instance.

You'd not get this madness in, say, Perl. Or even Go. Is the culture to blame? Massive frontend frameworks? A failure to recognize what we owe to each other when we publish software?

Collapse
 
rhymes profile image
rhymes

It's a mixture of many things in my opinion.

Maintainers that aren't paid and get fed up at some point, carelessness, the absence of a vetting system or a network of trust, the absence of static security analysis, the absence of a standard library, the culture of writing small modules for everything (search the is true package).

There's a thread going around where a developer counted that the react starter kit installs 1700 packages. Most of them are transitive dependencies.

The package in question is a transitive dependency of transitive dependencies, most people don't even know it exists.

The graph of most packages, not just frameworks, it's just stupid

Collapse
 
theodesp profile image
Theofanis Despoudis • Edited

The real problem here is when you had old packages that include the infected packages.

You have to go an update everything to the latest version, possibly breaking stuff and pray that npm ls event-stream flatmap-stream does not show anything suspicious.

img

Collapse
 
awwsmm profile image
Andrew (he/him)

Apparently React has something like 1800 dependencies. How can anyone expect to know everything going into their code when we've reached a state like that?

Collapse
 
bennypowers profile image
Benny Powers 🇮🇱🇨🇦 • Edited
Collapse
 
ben profile image
Ben Halpern
Collapse
 
elmuerte profile image
Michiel Hendriks

This is a serious security risk we've all been dealing with in open source.

That's right. In propriety software you cannot even deal with it. It cannot easily be detected, and once detected you cannot fix it yourself.

Collapse
 
rhymes profile image
rhymes

Also keep in mind that huge companies and small startups alike all basically depend on the same graph of packages, and nobody noticed in time.

I still can't believe that the maintainer of the package is also the maintainer of other hundreds of packages, that's absurd. Nobody should be in charge of so many dependencies by themselves

Collapse
 
kayis profile image
K • Edited

I think André sums it up pretty good.

Collapse
 
rhymes profile image
rhymes • Edited

There has to be something to be said about an ecosystem that allows/entrusts/lets a single human being be in charge of 700 packages. It's too much

Collapse
 
antonrich profile image
Anton

That's beyond too much. That's too freaking much.

Collapse
 
phlash profile image
Phil Ashby

Possibly, what strikes me is that there seems to be a culture of taking and not giving back going on - otherwise the original maintainer would have some /help/ looking after what are obviously popular packages? Or is this a symptom of a rapidly evolving package landscape, where /nobody/ has enough help because they are all spread so thinly re-writing similar things? In this case it may be that the evolutionary pressures (like malware infestation!) whittle the noise down and leave us with fewer, better maintained things.

Full-disclosure: I've tried to use NPM once (not by choice), it b0rked with missing packages and I walked away (thanks 'dotnet new react' template).

Collapse
 
timosarkar profile image
Timo Sarkar

Holy crap

Collapse
 
bgadrian profile image
Adrian B.G.

expecting to happen

This is only the beginning, when the avg packages imported per project is over 1000 what could go wrong?

Collapse
 
ulimn profile image
Ulimn

I'm curious: does Maven (Java) has issues like this? I'm thinking of Maven Central repository mainly here.

Collapse
 
fnh profile image
Fabian Holzer

I'm not aware of attacks that follow a similar format as the one described, but what is quite common is that you have a neglected POM file and thereby get outdated dependecies into your class path. There is for example a plugin for java build tools that checks your project depencencies against known vulnerabilites (OWASP_Dependency_Check).

The problem is, even if you are rather conservative with your third-parties, unless you eliminate them completely, the node ecosystem will still be too fragmented into small packages, as that anybody could ensure the integrity of all dependencies by manual review, which is frankly a major headache.

Collapse
 
yb profile image
yb

My question is... Who codes with the same computer on which he manages his (crypto) currencies?

Everybody from the crypto sphere should know that those kind of attacks will never stop.

Collapse
 
aturingmachine profile image
Vince

The idea was to hit a certain crypto package that used event-stream as a dependency. The code would only execute when run by that package.