What does the recent NPM malware mean for the future of open source trust?
If you and your organization were affected with malicious malware from a “trusted” source like NPM, how would you respond?
By Amit Sethi and Arthur Hinds
Earlier this month, the open source community went into high alert. The problem’s epicenter was the Node Package Manager (NPM), which affected what is currently believed to be 40 packages.
Typosquatting
Specifically, someone performed a ‘typosquatting’ attack against packages distributed via the NPM.
First, the attacker downloaded popular Node.js packages from NPM. They added malicious code to send a copy of environment variables on systems where they run to the attacker’s server. Next, the attacker re-published them under names that were similar to the original package names. Environment variables are often used to store secrets needed by applications to authenticate to other systems (e.g. database credentials, cloud providers’ API keys, etc.).
In one instance, the attacker published a modified version of the popular ‘cross-env’ package under the name ‘crossenv.’ In the two weeks that the packages went undetected, if a developer wanted to use the functionality provided by the cross-env package in an application, but mistakenly used the crossenv package, the attacker would be able to steal environment variables on systems where the developer’s application runs. Depending on what’s in the environment variables, the attacker might be able to hijack an organizations’ applications, cloud systems, and more.
Typosquatting attacks are not new. They are the reason why Synopsys owns domain names like synopsis.com that redirect to the real site at synopsys.com. Otherwise, users that make typographical errors would unknowingly end up on malicious websites.
Preventing copycats in open source
Imagine living in a world where you see copycat stores and products everywhere (e.g., Starbuck’s instead of Starbucks or Safe-way instead of Safeway). It would quickly become confusing for customers. In the real world, we have trademarks and other legal controls to deter copycat businesses and products. The required initial investment and the subsequent legal issues generally act as sufficient deterrents. However, in the open source community where the initial investment for creating a copycat (or slightly modified) product is small, and there is no large organization willing to pay the legal fees to find and prosecute attackers, the likelihood of these attacks is higher. Thus, organizations need to closely monitor open source software usage in their applications themselves.
If you were lucky enough not to be affected by this round of NPM malware, consider performing a thought exercise as a way to look ahead proactively:
If you and your organization were affected with malicious FOSS from a “trusted” source like NPM, how would you respond?
In the short term, deal with this the same way you would deal with any type of system compromise. Determine what systems are infected and what the malicious software did. Then, devise a remediation plan. In this particular case, you need to replace the malicious packages with the original versions (by changing the dependency package names in your Node.js applications). You also need to change any secrets that may have been stolen. Determine if the stolen secrets were used for any malicious purposes. Depending on what the attacker might have done with the secrets, you may have some long workdays ahead of you.
More importantly, how can you assure that this won’t happen again?
RELATED: Best practices for free and open source software vulnerability management
We recommend you read and internalize these best practices for free and open source software vulnerability management. But, the quick and dirty is to architect a FOSS inclusion system with risk and security inputs.
Does it still make sense to move fast and break things?
We’re seeing individuals and teams throughout the industry embracing the idea that each new iteration of the SDLC should be faster than before—a paradigm shift in development culture. As the SDLC moves to CI/CD and as automation hopes to ensure quality and security, we are at the mercy of the lock-in that we create. We know that situations like the NPM malware distribution caught us unaware and the remediation involved is more than a little heavy lifting.
If we are thorough and thoughtful when evaluating all components of the systems we fabricate we can reduce the risks while still keeping the pace.
Moving forward
The idea of bootstrapping existing technologies and ideas is practically primordial. As an industry, technology, or field, it’s good to strive to learn how to bootstrap more efficiently and with fewer issues. Free and open source software is no different. But there may be an undeserved trust associated with even well-maintained FOSS software. Open or closed, source code is source code. Vulnerabilities and malicious software are often inherited in that source code. Create an issue-resistant free and open source software vulnerability management program while remaining fast and agile. We can assist you in that process.
