Yesterday at noon BST a new github issue was opened in the popular eslint repository on github. Someone had highjacked this package and published a version that attempts to download malicious javascript code from pastebin and then collects and sends out the user's npmrc token (a token used to authenticate with a remote repository) to the perpetrator.
The eslint-scope package is hugely popular with over two million downloads each week. An estimated 4500 tokens have been leaked, due to this implication npm inc announced yesterday they will be revoking all user tokens created before the event.
In a post-mortem published by the eslint project they apologised for the event and published a timeline of the attack. They then offered recommendations like always using lockfiles with package managers over open version ranges.
The good news is 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 done in the community to ensure you can find and address the issue as fast as is possible.
Today's incident was handled quietly, responsibly, and with good cheer by everyone involved. Everyone was focused on keeping the npm community safe, and on how we could do better putting tools in everyone's hands to do this.
— Ceej "Obtuse Leadership" Silverio (@ceejbot) July 13, 2018
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 organisation.
Below are three steps you can take today to deal with the aftermath of this package event.
Our data team fast tracked all security notices related to this component, so 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 potentially have pulled this malicious component see my previous post on the subject.
The best way to avoid any adverse effects is to delete the component from NXRM immediately. The affected components are eslint-scope@3.7.2 and eslint-config-eslint@5.0.2.
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:
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.
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.
Use @sonatype folks, because life is too short for the absolute cluster [bleep] that is javascript https://t.co/j7D0MIIqhx. Thanks for keeping me safe you beautiful bunch of angels 🔥😍🔥😍🔥
— Edward Prentice (@EdwardPrentice) July 12, 2018
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.