Somebody Tried to Hide a Backdoor in a Popular JavaScript npm Package (bleepingcomputer.com)

Catalin Cimpanu, reporting for BleepingComputer: The Node Package Manager (npm) team avoided a disaster today when it discovered and blocked the distribution of a cleverly hidden backdoor mechanism inside a popular -- albeit deprecated -- JavaScript package. The actual backdoor mechanism was found in "getcookies," a relatively newly created npm package (JavaScript library) for working with browser cookies. The npm team -- which analyzed this package earlier today after reports from the npm community -- says "getcookies" contains a complex system for receiving commands from a remote attacker, who could target any JavaScript app that had incorporated this library.

Comments

Frameworks

[GWXerog]

Just more fuel on the dumpster fire. If you *need* a third party to maintain all of your useless frameworks then it's time to stop

Re:Frameworks

[605dave]

That's different! We do that through the command line so we know it's secure.

And that's why we can't have nice things

[Anonymous Coward]

As a Dev NOT working with JS and NPM: Given the vast number of packages on NPM https://developers.slashdot.org/story/17/01/14/0222245/nodejss-npm-is-now-the-largest-package-registry-in-the-world I'd wager a pretty penny there are more foul packages out there.
Dependency managers like Maven, Gradle, NPM, Pipenv and Bundler have made linking against other peoples libraries a walk in the park. Regardless if you draw your packages from public servers or your private Artifactory Server.

YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.
They spotted that one on time, but rest assured, there are probably hundreds of other packages out there (not only on NPM) that are either faulty, insecure or downright malicious.

We should take this as a shot across the bow. Be vigilent and don't rely on the competence of others to sort out the rotten apples for you. Think twice before you include some nifty lib into your project. If in doubt, get the source code (where available) and vet the source you got the binary from. Developers supplying packages should have their packages cryptographically signed for their own protection. It's not like this technology didn't exists. We only don't use it out of convenience and trust me ... the road to hell the most convenient one there is.

Re:And that's why we can't have nice things

[Anonymous Coward]

One day I accidently ran "npm install aws-cli" instead of "pip install aws-cli", and ended up finding this little gem:

https://www.npmjs.com/package/aws-cli

which at the time had 60k downloads a WEEK, and was some random script that would delete your AWS certs...

in addition to importing a dependency which installs a backdoor designed by some communist crypto currency secret society:

https://www.npmjs.com/package/operetta

just follow the trail and youll get here: http://telekommunisten.net/ ... and that leads to dark places

Re:And that's why we can't have nice things

[Anonymous Coward]

The basic problem is that ANY package may contain something malicious. How in the world can you possibly audit them? Many packages depend upon other packages as well. There is often a whole chain of dependencies. Any single one of those packages could have code injected into them (on purpose or because the maintainer got hacked and submitted a signed package that wasn't really theirs).

So, the choice is to reinvent the wheel or to accept a certain level of risk. A company with the resources of Apple or Google probably prefers to reinvent. But most companies don't have those resources. It is very expensive to audit (and you would have to audit every single version change).

I am not suggesting people ignore the problem. One does need to be vigilant, but often the cost/benefit is not there to do a thorough job of vetting.

Re:And that's why we can't have nice things

[skids]

YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.

Any library can become bogus and malicious at any given time. One compromised laptop and a keystroke logger to get the DSA key+password is all it takes. I don't think many developers would sign up for a system of "if you write code, you have to stick around and watch that code and all its dependencies vigilantly" because you'd have to stop writing code at age 25 and spend the rest of your life on the full-time job of monitoring what you wrote. The point of volunteer OSS is you are supposed to be able to contribute what you are willing to, when you want to.

Libraries are a double-edged sword security-wise... bugs and compromises in them affect everything, but on the bright side, you only have to fix them in one place, not hunt variants of them down in the thousands. (Not to say that there are not tons of completely redundant libraries due to NIH, megalomania, or just not being aware of other solutions.)

When you see something like TFA happen you need only ask: what work was too menial for anyone to do on a volunteer bases that this was not caught and then you know what the OSS community needs to find someone to pay someone to do.

Re:And that's why we can't have nice things

[AuMatar]

You don't need to audit every change. You freeze a version, and use that until you need to update. You know, like we've been doing for 50 years.

You also employ layered trust. Is it likely a major open source library, or a library from a major company is safe? Yes. Is some random thing off some guy on github? No. You avoid the second type, trust the first, and audit those in between.

Re:And that's why we can't have nice things

[squiggleslash]

YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.

1. Best practices dictates you should never reinvent the wheel. Someone else, apparently, has done it better than you have somewhere. You should seek them out and use their code.

2. Best practices dictates you should always keep on top of updates, and ensure that you're always running the latest version of every bit of code you get externally

3. Apparently you should also know, somehow, that a project you use now contains malicious code.

Honestly guys, we need a new set of "best practices" because this shit isn't working. We want to program, not be sysadmins for a giant ball of interconnected third party plug-ins.

Re:Newly created, popular, and deprecated

[The Fat Bastard]

You must not be familiar with JavaScript development. The moment you learn a JS framework, ten more JS frameworks will pop up and your newly learned JS framework will already be depreciated.

So much JS hate here

[Arkham]

I don't personally do any significant JS development, but the suggestion that this is a JS-specific problem is silly. This could have just as well been in a Java or C++ framework. We all use third party libraries and frameworks all the time without doing a line-by-line code review.

The real story here isn't that someone tried to slip in a backdoor. The story should be about how the NPM team did their due diligence and protected all of their users by catching this. Good job to them.

Re:So much JS hate here

[TheRaven64]

I don't personally do any significant JS development, but the suggestion that this is a JS-specific problem is silly. This could have just as well been in a Java or C++ framework. We all use third party libraries and frameworks all the time without doing a line-by-line code review.

There's one difference: when I use a C/C++ library, I almost always install it via my operating system's package manager. The version installed won't have been checked for backdoors, but it will at least be a released version that has gone through some minimal QA. The fact that it's included at all typically means that upstream has a half-competent release process or that some other applications are depending on it and making it worth packaging.

Newer languages all seem to feel the need to create a per-language package manager. This works fine as long as all software is written in that language, but is really painful for multi-language software (i.e. most non-trivial programs). NPM isn't quite the worst - the default way of including stuff in a Go program is to point at the upstream project's git repo and have your build environment clone the head revision and statically link it into your binary - but it's pretty bad.

Re:Newly created, popular, and deprecated

[kaizendojo]

That's got to be the first time a misspelling still worked as a valid sentence. Cheers! ;)

Dangers of relying on the Tower of Abstraction

[ErichTheRed]

We all know that JavaScript is a pretty messy language to work with unless you're using some sort of framework. Part of that is that it's been pushed to do way more than it ever was designed to do and is hyper-complex as a result.

I guess my question is how far up the abstraction tower goes. Why would developers pull hundreds of libraries from dozens of sources just to build a simple program? And more importantly, why would you dynamically pull these resources instead of building against a known-good set, and only update one of your dependencies when you've tested it completely?

I know software is all about move-fast-and-break-things these days, but the "trust the Internet implicitly for all my source packages" is one thing I can't get my head around.

Re:If they didn't need frameworks...

[cascadingstylesheet]

... then they'd be half decent coders and wouldn't be coding in babyscript, sorry, javascript. This language is where idiots and MBAs straight off an "Anyone can code!" course end up, writing Hello World style programs using half a dozen libraries to create a Hello factory and a World factory with another factory that joins factories which then creates a HelloWorld object that eventually outputs a string via some StringOutputter object.

You do realize that you are describing Java (or some other "real" language), right? Not JavaScript?

JavaScript usually only ends up looking like that because someone comes to it thinking "I have to make this more like a "real" language ..."

Re:Zontar starts w/ me I finish it (see ps)

[thegreatbob]

I let him crash on my couch at one point, and now he won't leave.