Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

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

Posted by msmash from the danger-averted dept.
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.
This discussion has been archived. No new comments can be posted.

Somebody Tried to Hide a Backdoor in a Popular JavaScript npm Package More

Somebody Tried to Hide a Backdoor in a Popular JavaScript npm Package

Comments Filter:

  • Frameworks (Score:3)

    by GWXerog ( 3151863 ) on Thursday May 03, 2018 @11:38AM (#56546956)
    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: (Score:2, Insightful)

      by The MAZZTer ( 911996 )

      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.

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

  • And that's why we can't have nice things (Score:5, Insightful)

    by Anonymous Coward on Thursday May 03, 2018 @11:46AM (#56547002)

    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: (Score:2, Interesting)

      by 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

      • Comment removed based on user account deletion

    • Re: (Score:3, Interesting)

      by 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 Googl

      • Re: (Score:3)

        by AuMatar ( 183847 )

        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 (Score:4, Insightful)

      by skids ( 119237 ) on Thursday May 03, 2018 @01:16PM (#56547680) Homepage

      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.

    • Comment removed based on user account deletion

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

  • So much JS hate here (Score:5, Insightful)

    by Arkham ( 10779 ) on Thursday May 03, 2018 @12:07PM (#56547138)

    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.

    • 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: (Score:3, Informative)

      by TheRaven64 ( 641858 )

      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-

  • This makes me irrationally angry. (Score:1, Interesting)

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

  • break the bones in both their hands.

  • Dangers of relying on the Tower of Abstraction (Score:4, Insightful)

    by ErichTheRed ( 39327 ) on Thursday May 03, 2018 @12:33PM (#56547342)

    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.

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

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

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

        • 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?)

  • The news isn't that someone tried it (Score:1)

    by Anonymous Coward

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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close