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.
...
For further actions, you may consider blocking this person and/or reporting abuse
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?
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.
Lots of reasons to to trend conservative on including dependencies, especially on the client.
Left-pad had a big affect on me.
Be very careful of adding dependencies
It's easier said than done.
For example:
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.
Everytime you delete that bloody
node_modulesdirectory and start again...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:
(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.
That's why I HATE deleting-issue feature in github!
True that
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
requirecall. Which then only tries to do bad things if it reads a certain npm package description, the one fromcopayI believe. Equally beautiful and malicious.The REAL kicker is that the malicious code only lived in the minified source of the
flatmap-streampackage. 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.
Mmm, malicious code that targets Javascript and the Blockchain....I will call it Buzzware 😝
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 -
tapeinstead ofavafor 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?
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
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-streamdoes not show anything suspicious.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?
unpkg.com/@polymer/lit-element@0.6...
unpkg.com/lit-html@0.13.0/package....
For more:
Let's Build Web Components! Part 5: LitElement
Benny Powers
Great blog post from the left-pad saga
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.
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
I think André sums it up pretty good.
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
That's beyond too much. That's too freaking much.
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).
Holy crap
This is only the beginning, when the avg packages imported per project is over 1000 what could go wrong?
I'm curious: does Maven (Java) has issues like this? I'm thinking of Maven Central repository mainly here.
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.
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.
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.