More than 800,000 free and reusable software packages are available through the npm (“node package manager”) software package registry. Should an attacker breach one of these at-risk accounts, it could bring down the digital supply chain worldwide, the findings of the Technical University of Darmstadt (TU Darmstadt) in Germany indicate.
In their report for Usenix, Small World with High Risks: A Study of Security Threats in the npm Ecosystem, Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel shine a light on the widespread use of npm packages throughout the internet and the implications for cybersecurity. In their paper, they highlight the immediate and deleterious effect that malicious changes to this underlying software would have.
When attackers can compromise one or more of the code elements of a solution before that solution is executed, this action causes the resultant output to be faulty, crippling the individual computer or whole networks and/or causing data breaches.
The TU Darmstadt team puts it this way: “[A] very small number of maintainer accounts could be used to inject malicious code into the majority of all packages, a problem that has been increasing over time.”
“Very Small” Cause. Maximum Damage.
A threat action could be caused by a package that, without its developer’s knowledge, is running vulnerable or malicious code introduced by the third-party dependencies bound to the same package.
Another finding of the TU Darmstadt team illustrates that this risk isn’t just a theoretical possibility. 40% of all npm packages, the authors point out, rely on code that is known to be vulnerable. “When installing an average npm package,” they write, “a user implicitly trusts around 80 other packages due to transitive dependencies.“
How NPM Interdependencies Multiply Threats
A popular package can reach more than 100,000 other packages by being used directly by a developer or being used by a program which is then used by the developer, making such shrink-wrapped code a prime potential target for attacks.
For example, in March 2016, a small utility package called left-pad was removed from the npm ecosystem. This, in turn, caused a large percentage of packages to become unavailable because they directly or indirectly depended on left-pad.
In July 2018, compromising the credentials of the maintainer of the popular eslint-scope package enabled an attacker to release a malicious version of the package, which - once installed - tried to send local files to a remote server.
Target and Gateway: The Local Browser
As the primary online tool in business, the traditional browser is not only the most widely used piece of web-facing software. Its tight integration with the operating system and local resources also makes it the gateway for at least 70% of cyber attacks.
That includes attacks on the software supply chain, which have increased in frequency over the past years. One prominent example was an attack against British Airways that resulted in a record fine levied against the company under the European Union’s General Data Protection Regulation (GDPR) by UK authorities.
Another real-life example are watering hole attacks. Web visitors get profiled for pin-pointed targeting of government or financial institutions. Take your pick.
How Third, Fourth, Fifth Party Risks Threaten Compliance
Let’s face it: third-party suppliers are a security liability for the enterprise, because they can unintentionally open the door for code infiltration and data exfiltration.
Yet for modern businesses, forfeiting the competitive advantages of using third parties by going it alone is not an option.
This puts especially tightly regulated industries between a rock and a hard place. In a 2019 survey, Gartner found 80% of legal and compliance leaders state that third parties (such as startups and business model innovators) - rather than incumbent service providers - provide new-in-kind technology services for organizations.
The same survey shines a light on how the attack surface for such exploits is widening. Gartner found that 83% of organizations still uncovered third-party risks after they had conducted due diligence.
Would you be surprised to learn that more than half of the respondents said they rely on trust alone to evaluate third-party security? And get ready for more bad news - the Gartner findings also indicate that the problem will likely not get solved from within the supply chain, by the vendors themselves.
Inhouse lawyers and compliance managers reported that the third parties they oversee are working with an increasing number of their own third parties (fourth and fifth parties).
As a consequence, the potential victims are bearing the burden of preventing data breaches caused by npm maintainer account exploits and other means. How can IT shield the organization
What Can IT and Compliance Managers Do?
Best practices in preparing for this kind of attack include:
- establishing a standard baseline security posture for the enterprise that applies to internal areas and third parties alike; this means that all parts of the enterprise have to look at these security areas when vendor choices are to be made.
- writing the policies down in a canonical always-available form (not just an email); this ensures that policies are disseminated across the enterprise with all content intact.
- Verifying the policies in practice; the enterprise needs proper documentation of compliance with the requirements of PCI, HIPAA, and location-dependent security policies such as GDPR.
As part of this verification, a diagram of data flow can prove useful. The enterprise will be held accountable by regulators for where and how data is generated (and stored). Third parties must be able to show (and know) where an enterprise/supplier data mix is flowing to show their compliance.
Granted - you can write anything on paper (or in an email). So trust (but verify) that what you assume is happening on the vendor’s side is indeed demonstrably occurring.
And above all, keep in mind that the ultimate targets of most supply chain attacks, including such leveraging npm maintenance accounts, are your organization or its customers’ local web browsers.
That means that functional isolation of all web activities outside your organization’s IT perimeter may be the only effective path to prevent and disincentivize generalized digital supply chain attacks in the future.
Web isolation precludes code from the internet from being processed by locally installed browsers. Instead, it provides users with a visual display stream (benign pixels, essentially) of the web session from a secure container in the cloud.
Because any browsing activity and web application usage occur in isolation offsite, no code can touch the endpoint and infect your local network.
No matter if one, twenty, or more of npm maintainer accounts have been compromised - it’s not your worry anymore.