3 Steps to Deal With the Aftermath of the Highjacked Eslint-Scope Package
In the popular eslint repository on GitHub, this package ran into a serious security breach last month. Click here for three steps for dealing with the aftermath of the attack.
Join the DZone community and get the full member experience.Join For Free
The eslint-scope package is hugely popular with over 2 million downloads each week. An estimated 4500 tokens have been leaked, due to this implication. Npm, Inc. announced yesterday that they will be revoking all user tokens created before the event.
In a post-mortem published by the eslint project, they apologized for the event and published a timeline of the attack. They offered recommendations, like always using lockfiles with package managers over open version ranges.
The good news is that this situation was handled expertly by the entire open source community and shows the power of being able to audit and inspect the code being pulled in. It is now the duty of each consumer of open source to take advantage of the great work being done in the community to ensure that you can find and address the issue as fast as possible.
According to Laurie Voss (@seldo), users of npm 6 or newer will automatically be notified of this issue if they attempt to build with the component. If you are using a private artifact repository manager internally, like our Nexus Repository, you might want to consider revoking all internal tokens as well, if you discover this component was downloaded by your organization.
Below are three steps that you can take today to deal with the aftermath of this package event.
1. Discover Which Applications Have the Bad Version of Eslint-Scope and Eslint-Config-Eslint
Our data team fast-tracked all security notices related to this component, so the users of our Nexus Lifecycle and Firewall will be covered.
If you have continuous monitoring turned on, you will already have received automatic notices of the issue. To manually search for applications that might have potentially pulled this malicious component, see my previous post on the subject.
2. Revoke all Npmrc Tokens in Nexus Repository Manager and Delete the Components
The best way to avoid any adverse effects is to delete the component from NXRM immediately. The affected components are
Deleting components from Nexus through the API: https://help.sonatype.com/repomanager3/rest-and-integration-api/components-api#ComponentsAPI-DeleteComponent
Deleting components through the GUI:
Search and locate the component and delete it from the GUI. As an example, deleting the component engine.io-client:
As an additional precaution, you may also wish to revoke all authentication tokens for npm. This is simply done by forcing the user's password to change if using the internal Nexus user account management or using old style npm authentication strings.
Revoking all user tokens: User tokens can be invalidated by hitting the "Reset all user tokens" button on the user tokens screen administration screen. User tokens are format agnostic and will reset for ALL formats.
Using the internal user manager of Nexus, administrative users can force a password change using Nexus' built-in user manager on each user.
You can also temporarily disable the npm bearer auth token Realm if you do not wish for users to be able to access the system while this change is happening.
3. Stay Calm and Test for It
The staple of any good dependency management diet is preferring absolute versions via lockfiles over open version ranges or latest. Including these practices with your build is absolutely vital in preventing automatic downloads of new components as they are being published.
The Sonatype Intelligence group monitors hundreds of different sources for issues every day and update our security intelligence on how to mitigate the issue several times a day.
The Nexus Lifecycle helps users automate discovering and fixing issues with actionable intelligence. To find out more, see the below demo of our full stack and run a free application health check to identify what's in your application.
Published at DZone with permission of Ilkka Turunen, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.