Slashdot Mirror


Compromised JavaScript Package Caught Stealing npm Credentials (bleepingcomputer.com)

An anonymous reader shares a report: A hacker gained access to a developer's npm account earlier this week and injected malicious code into a popular JavaScript library, code that was designed to steal the npm credentials of users who utilize the poisoned package inside their projects. The JavaScript (npm) package that got compromised is called eslint-scope, a sub-module of the more famous ESLint, a JavaScript code analysis toolkit. The hack took place on the night between July 11 and 12, according to the results of a preliminary investigation posted on GitHub a few hours ago. "One of our maintainers did observe that a new npm token was generated overnight (said maintainer was asleep)," said Kevin Partington, ESLint project member. Partington believes the hacker used the newly-generated npm token to authenticate and push a new version of the eslint-scope library on the npm repository of JavaScript packages.

2 of 44 comments (clear)

  1. Re:The risk of open source. by 110010001000 · · Score: 3, Informative

    Closed source software has been stealing credentials and data for years. It took a day to catch the open source one. Your phone is riddled with data stealing software right now.

  2. Re:congrats.... by Aighearach · · Score: 5, Insightful

    It is the same as everything else, if you're willing to install dependencies and allow them to automatically update, you're already p0wned.

    Is the correct way to handle code reuse to learn from code already written, and to reuse the code that does what you want, or is it a crutch that lets you write code you don't actually understand how to write?

    If I'm going to use a JS library, I'm going to choose it very carefully, and then place it inside my project. Even without the security considerations, just stuffing it into your project where the bleeding-edge version is automatically tracked, that's just asking to get hit early with every type of bug, not just the security ones and malfeatures from jerks and criminals. I don't want today's version; and if it is doing something critical where I need to care about updates, then using a third party project doesn't mean I can stop following the news about exploits; it actually means I have to follow it more closely than otherwise.

    Updates aren't magic, they're an attack vector; you need to have a human evaluate the situation and then do an update promptly if needed. Don't trust updates from a repo unless it is a repo that receives testing from human engineers! You OS updates you might therefore want to have on auto; but most package dependencies, you should be on a "stable" version. Don't develop your applications to development versions of dependencies, you don't actually need untested features.