The event-stream package had a major vulnerability. The malicious code was actually found in version 0.1.1 of flatmap-stream, but event-stream was the true source of the issue as it’s a popular package and introduced flatmap-stream in version 3.3.6 as part of the hack.
In a number of my projects it was an indirect dependency of nodemon, which is a dev dependency we use for local development and is never run in production. However I’m sure it’s a dependency or a dependency of a dependency (of a dependency) of a number of packages being used in production by plenty of applications.
In regards to nodemon, package maintainers have updated their code to remove that dependency from the tree, so what we needed to do was to simply update nodemon to remove that bad package. There’s a few different ways to do this with npm, the following works just fine: npm update nodemon.
To see if you’re vulnerable audit your repos with npm audit.
NPM and other code repositories like Python’s PyPI and Ruby’s RubyGems have been dealing with the problem of compromised package libraries for years. Despite the ongoing addition of defenses like automated vulnerability scanning and of reporting mechanisms, the risks are unlikely to go away while people have the freedom to publish unvetted code.
Source: https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/
At the end of the day this is just a reminder that npm can be quite vulnerable for a number of reasons. To name just a few:
- You’re able to publish different code from what’s tracked in source control…to those of us that don’t like to commit minified files that seems great, but it also allows for less visibility into what actually makes it into your code.
- Regardless of the above, obfuscated code is nearly impossible to scan for malicious stuff. To think npm could scan for malicious code on publish is misguided.
- The sheer number of dependencies a project could have, and even more contributors…you just have to trust there’s no bad actors in that dependency tree. Not to mention good packages publishing bugs that could result in vulnerabilities.
This will always be a concern in open source communities, but we should take this opportunity to look into what we can do to mitigate. Stricter CSP’s, making sure never to blindly update all packages, running `npm audit` often, and maybe consider putting that in your CI/CD process to catch (known) vulnerabilities before deployment. Here’s some other great ideas to secure your node apps.
Here’s two really good resources that have surfaced in the aftermath of this incident, one being a twitter discussion, which led me to the other one, which is one of the best articles I’ve read in a long time, written back in January (and a follow up article detailing possible solutions).
Here’s a detailed explanation of the hack that was just published in the latest version of JS weekly, and it goes a bit more in depth than the npm blog post.
