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

[The MAZZTer]

So I guess we should just give up on Linux with yum, rpm, and apt?

Also nuget for .NET stuff but Linux makes a better example.

Re:Frameworks

[605dave]

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

Re:Frameworks

[rainmouse]

Yeah why bother with distributed shared effort when you can reinvent the wheel in house and keep your unscrutanised code all to yourself?

Re:Frameworks

[GWXerog]

This is Terry A Davis you CIA n*gger

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

[Anonymous Coward]

That project clearly serves no purpose except to typo-squat on a popular project and load a crooked dependency. And it is currently getting over 10k downloads a week RIGHT NOW.

I always enjoy when someone who clearly has no idea about security tries to point out absolutely nothing of value to anyone.

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

[barbariccow]

You know just installing it doesn't mean you're CALLING it right? Like, you'd literally have to install that package and then call aws-cli.deleteAllMyShit();

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.

Newly created, popular, and deprecated

[iYk6]

Newly created, popular, and deprecated. That doesn't sound right.

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.

Re:Newly created, popular, and deprecated

[kaizendojo]

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

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

[The MAZZTer]

Yup. JS is, if anything, a bit better than other languages since you CAN go through the source code of packages you install. The only thing that keeps it from being better in this regard is that node can have native modules which are binary blobs, and so you won't be able to tell what those are doing, same as libraries you might link to in other languages.

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.

This makes me irrationally angry.

[Anonymous Coward]

While real programmers working in real languages are getting laid off or outsourced millennial programming languages like javascript and tools like npm get made and get widely distributed around the internet. I hope the whole stack gets wannacried/code reded soon.

Re:This makes me irrationally angry.

[Anonymous Coward]

Reference: Node.js is Badass Rockstar Tech

Re:This makes me irrationally angry.

[barbariccow]

Most all products these days are inherited. Sure, if starting a brand new ecosystem with a bunch of interns maybe nodejs is the way to go. maybe.

Re:A fucking library for cookies?

[Anonymous Coward]

Because, like everything in Javascript, all the different browsers and all the different versions of the browsers will have quirks, little bugs, different ways of doing things, handle edge cases differently, etc etc etc. So you need a common library to act as an adapter.

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:Dangers of relying on the Tower of Abstraction

[cyberfunkr]

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.

THIS! A thousand times this.

Seems like no one knows how to actually write code any more, they just know how to tape together a bunch of other peoples snippets.

Re:Dangers of relying on the Tower of Abstraction

[barbariccow]

If you don't need to support IE 5, 6, 7, or 8 (which thankfully are falling out of favour), there's really no need to have heavy abstraction libraries. They just make things slow and complicated and dependant on 3rd party. For years I've had a 150 line JS script with stuff like "get parent element of passed element containing passed class name" and it handles everything splendidly. It's not hard if you understand how the DOM works, you're almost just working within XML, which is another lost art...

Re:Dangers of relying on the Tower of Abstraction

[omnichad]

Please, don't call XML anything to do with art. Unless you're a Tolkien fan, I guess.

Re:Dangers of relying on the Tower of Abstraction

[Zontar The Mindless]

If you don't understand that there really are suitable use cases for DOM/XML, then please don't comment on them.

(Hint: What does the "D" in "DOM" stand for?)

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 ..."

The news isn't that someone tried it

[Anonymous Coward]

It's that it was detected and prevented. How many backdoors are in there that went undetected?

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

[Zontar The Mindless]

After (I think) 3 years, APK is still rankled that I really was able to track him down.

(And I do admit to feeling just a teeny-tiny bit of a warm glow every time he whinges about it.)

BTW, all the postcard said was, "Greetings from Stockholm. Behave yourself. Regards, Z."

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.

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

[thegreatbob]

Also possible we're not talking about the same Zontar.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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

[barbariccow]

I don't understand your last point. Even if you're using gentoo and compiling from source, are you REALLY auditing all the code before you compile it? So... what's the difference? I mean hell, at some point you have to have a pre-packged compiler which could be checking for some routine, like check password, and compiling it differently so even a source code audit wouldn't fix it and you'd have a backdoor into all UNIX systems.

Re:A fucking library for cookies?

[omnichad]

Of course, the common library is supposed to be ECMAScript. Regardless, Node is a server-side language and does not deal with browser quirks in that way.

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

[Zontar The Mindless]

Yeah, he tries really hard to do the Tar Baby thing, and usually I just ignore him.

But the bit about *threatening* him via the mails is completely false.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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

[Zontar The Mindless]

This is the only Slashdot account that I have.

And I don't need to waste mod points on you--your crap is almost always modded down by the time I see it, in any case.

And why do you insist on talking about yourself in the 3rd person? You think no-one can tell, do you?

Meanwhile, you keep right on modding my 5 most recent posts as Offtopic or Overrated whenever one of your sockpuppets gets mod points, if it really makes you feel better.

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

[thegreatbob]

Confirmed. I tried again last night, and came back to consciousness today singing a song in a tongue I did not know, but understanding that it was in his praise.