As if we haven't learned anything from the Left-pad debacle on November 26th the Javascript world was shaken once again.
A popular Npm library with over 2 million installs had a backdoor. Wait, what?! Yep, you heard it correctly the event-stream library which was not archived at that time and was used all over the place from your garage script kiddie to enterprise systems was infected with an obnoxious back-door, a crypto miner /stealer/something. From now on we will call it the C - virus for dramatic effect.
Damn crypto hype, it's high time the bubble burst and let us go on with our lives. - Me, December 2018
But, how did it happen? Well, a combination of unfortunate circumstances and the author's faith in people led us here where we are today.
The author stopped using and maintaining the library a long time ago. Since it wasn't archived over time it became a dependency of many projects and lo and behold one day a good Samaritan slid into his inbox and offered to take the burden of maintaining the library upon himself and to carry the torch onwards, but he was not good, was he now.
Felix Krause@krausefx
Step 1️⃣ Go through the most popular inactive open source libraries
Step 2️⃣ Reach out to author and ask to help out
Step 3️⃣ Get push access and release a compromised version
Step 4️⃣ Reach 2 million applications within a week
github.com/dominictarr/ev…18:33 PM - 26 Nov 2018
The author transferred the rights of the Npm module to this kind stranger but left the module's code on his Github account since there were some problems with name conflict when he tried to transfer it to the stranger's account, or so he says, but I suppose they weren't accidental either. This Samaritan was one nefarious schemer.
As soon as he got hold of the library he removed the publishing rights of the old author, added the flatmap-stream module which contained the C-virus, did a minor version bump and finally a new release on Npm.
The event-stream library was updated to the new minor version all over the world.
As soon as he planted the C-virus, he removed the flatmap-stream module from the library and then he did a major version bump and once again a new release on Npm. Quite smart isn't it? Now there was nothing suspicious in the codebase but since it was a major version update most of the systems wouldn't update to it because they are version locked to the previous major version thus they would still have the infected code.
Even one of my coworkers got infected, barely anyone noticed, but Kevin Beaumont.
🎅🏿 Kevin Beaumont 🎅🏽@gossithedogNPM library with 2m installs has a backdoor, looks to be some kind of Trojan (stealer?) github.com/dominictarr/ev…18:39 PM - 26 Nov 2018
That was a brief summary and I probably missed a step or two but you get the picture.
SHORT NOTICE:
We shouldn't blame the author, he probably didn't really think it through that much but maintaining open source software is a real hassle and can be really mentally draining on the authors, especially in today's entitled society where people expect everything for nothing. So let's not put the blame on him.
Now let's get back on track! Oh, here's another gem by Kevin Beaumont
🎅🏿 Kevin Beaumont 🎅🏽@gossithedogOne of the things to emerge over last few years is npm and Node.js ecosystem - billion dollar companies and startups alike are building complex systems on top of often unmaintained code written by random people for no pay.18:57 PM - 26 Nov 2018
Hallelujah, praise the Lord! Preach! People didn't come up with this meme for no reason:
Key takeaways from this mess:
- Sometimes we take for granted and don't think what we Npm install/composer require/yarn add
- Developers have become lazy. We have started taking "don't reinvent the wheel too literally", instead of writing a few extra lines we'd rather require a library, sometimes even for the most trivial of tasks (especially in the Javascript World this seems to be the trend)
- You should always put careful thought in what you require as a dependency, more dependencies can sometimes mean more technical debt
- Add a layer of abstraction and design an interface as a bridge/adapter between your domain logic and libraries, so you can swap them more easily if the need arises
- When a library stops being maintained we now own that code and it is our responsibility to fix it as part of our codebase or find a suitable replacement for it
These lessons were once again learned the hard way by many businesses this November.
Thanks for reading my long rant!
Before you go…
If you enjoyed reading this post please share it. You should check out our other publications, you might like them too! We write from time to time about software development, tips and tricks, and how to become a better developer and business person in general. Join us on the journey of constant improvement!
Follow us on Facebook, Twitter, LinkedIn, Medium or DEV.to.
Originally published at jsguru.io.
Top comments (7)
Article was well written and thanks for the informative look at something important to know :)
I do take issue, though, with your assertion that installing dependencies without checking their source or github history is "lazy". The world of software, especially web, development is super competitive nowadays. If a client is demanding a tighter timeline, and a smaller budget... you have a choice; Cut the corner and get the job, or Go hungry -- because someone else will cut that corner.
I want to believe that the huge benefits and time-savings we've created are due to pressure, not laziness. Clients now demand excellent, hugely interactive, and fast experiences at the same price they've always paid. Where can you create that extra value if not at the development phase?
Hey Simon thanks for reading and thanks for the reply. I never said in the post that developers which don't check dependencies on Github are lazy, I said that developers who choose to install dependencies for even the most trivial things instead of writing a few extra lines of code are lazy. The perfect example for that is the left-pad library. :)
And I feel you, clients nowadays usually want everything for pennies done yesterday, but it is our responsibility to our industry to explain to them that they have 3 options but can only choose 2:
On this same note, I was talking with another dev the other day, that its incredible that you can't easily on npmjs.org sort repos by dependencies, nor easily see how many dependencies the repo's dependencies will pull in. It makes it very hard to make an informed decision about an individual module you want to include. It's very hard to tell if that lib you pulled in(or one its dependencies) will pull in the entire npm ecosystem and thus some nefarious lib.
Thanks for the reply and you are absolutely right!
I have become such a paranoid now when installing packages I never used before. I go into the GitHub to check the code. Then I even go to unpkg to make sure the code on GitHub is the same on NPM. 😂😂😂😂
Better safe then sorry ;)
Thanks for reading the post and your suggestion, it's done :)