Eslint-scope@3.7.2 compromised, steals NPM credentials

The NPM package eslint-scope at version 3.7.2 contained an exploit that sent your .npmrc file to a 3rd party service in a postinstall hook. It was live for a few hours. More details: https://github.com/eslint/eslint-scope/issues/39

It is possible that other packages may have been infected or may be infected in the future using NPM credentials stolen via this method.

To mitigate:

  1. Set up 2FA on your NPM account.
  2. Revoke and regenerate any NPM tokens you have and change your password for good measure (unsure which of these were affected).
4 Likes

It should be resolved now, more info can be found here: https://status.npmjs.org/incidents/dn7c1fgrr7ng

2 Likes

It is perhaps worth looking at the risks and mitigations around compromised dependencies in Elixir. I wrote about this in the past, but let’s summarise and update a few points here:

  • In Elixir, compiling code means running code. So when you add a dependency and then compile your project (mix compile, mix deps.compile, or any task that depends on those), any malicious code in any direct or transitive dependency will have a chance to run.

  • When pulling in dependencies from Git, other SCM sources or through a path reference, the dependency’s ‘mix.exs’ file gets executed during dependency resolution. This would allow malicious code to be triggered even earlier, during mix deps.get. This does not apply to Hex packages.

  • There is no guarantee that a package on hex.pm contains the code you see on the associated GitHub repo. The Hoplon package tries to detect mismatches, but I’m not sure how accurate it is in practice.

To minimise the risk of malicious dependencies, here are a few things you can do:

  1. Carefully consider any new 3rd party software dependency you are introducing, including its transitive dependencies: Does it come from a trusted source? Is it being maintained? Are its size and complexity justified given your immediate needs (e.g. add a package with 15 dependencies because you need one helper function from that top-level package)?

  2. When fetching and compiling new or updated dependencies for the first time, run on a sandbox VM or container that does not contain sensitive data (credentials), does not have access to private networks and that you can easily discard if something bad happens. Add some tooling to monitor for suspicious activity, such as network traffic or OS command execution.

This may seem paranoid, but I’m convinced that compromised/vulnerable 3rd party software is the number one security risk for many projects. Hex and GitHub are awesome resources to tap into, but use them carefully and stay safe!