Web supply chain attacks are a real security threat, and enterprises are largely unprepared.
The security threats of relying on third-party code are mostly known within the scope of Magecart attacks, which consist of attackers injecting malicious code into third-party scripts to skim the credit card details of E-Commerce shoppers.
While Magecart is still a growing threat and deserves attention, too little attention goes to another type of third-party code: npm packages.
Too many dependencies, too large an attack surface
NPM itself tells us that the average web app today contains over 1,000 code dependencies, with some breaching the 2,000 mark.
From a security standpoint, each piece of third-party code can serve as an attack vector to inject malicious code into applications. A recent study by Markus Zimmermann et al. provided much-needed insight into how serious a security threat this code-reuse practice poses to the industry as a whole.
To explain why these threats exist, this team of researchers pinpoints characteristics of the npm ecosystem, including the abnormally high incidence of code reuse compared with other ecosystems, as I mentioned above. Two other characteristics also play an important role: the emphasis on micropackages and the lack of privilege separation.
The reliance on micropackages matters because, while they make up 47% of all packages, they often contain only a few lines of code, either because they perform trivial tasks or because they call other dependencies. However small and innocuous micropackages may appear, individually they carry the same security threat as more complex packages because their dependency chains are just as long.
When we look more closely at the JavaScript ecosystem’s dependency chains, we can see just how large an attack surface modern JS applications present.
Zimmermann et al. found that, on average, an npm package has 80 dependencies. While simply multiplying this figure by the 1,000 transient dependencies of the average web app is not accurate by itself (different packages often share the same dependencies), we can safely conclude that, just by getting to the second level of the web supply chain, we are already dealing with many thousands of code dependencies.
This brings us to the second and more important characteristic of the NPM ecosystem: the lack of privilege separation. Put simply, all third-party code has the same privileges as internally developed code. This means the security of the average JavaScript application is scattered across thousands of third parties, and it only takes a breach in one of them, no matter how small, to potentially launch a web supply chain attack.
When this same team of researchers further analyzed the actual maintainers of these packages, the overall finding was indeed concerning: 20 maintainer accounts can reach more than half of the ecosystem. A breach in one of these can essentially trigger a global supply chain attack.
These considerations wouldn’t raise much concern if the ecosystem were used only by non-commercial projects or small companies; what magnifies their importance is that every Fortune 500 company relies on the NPM ecosystem.
Enterprises whose apps often amass millions of users and handle sensitive data, such as credit card details or protected health information, are paydirt gold for attackers.
We have seen enough web supply chain attacks to know that we’re not doing enough to mitigate them. Mainstream security measures are still falling short. The key to an effective response may be a change in mindset.
A new security mindset: shifting from prevention to monitoring
There’s no doubt that the NPM ecosystem still has a long road ahead, security-wise.
The study by Zimmermann et al. urges NPM to audit packages responsibly to ensure their sources are trustworthy and to vet development accounts. Some progress has been made recently, namely with the addition of npm-audit, which automatically warns developers of known vulnerabilities in each package.
However, when critical enterprise applications are at stake, and millions of users could have sensitive data (such as financial or health details) stolen through client-side attacks, enterprises can’t afford to wait or trust. And yet, third-party code is here to stay. Solving this conundrum requires a mindset shift; there’s no infallible way to ensure these third parties aren’t injecting malicious code. The most reasonable fallback, therefore, is to gain complete visibility of client-side threats.
By implementing a web page monitoring solution, enterprises can react in real time when a rogue third party starts injecting malicious code, automatically triggering security measures to stop the attack.
Third-party code is still breaching companies. Malicious code can run undetected for months and cause significant business damage. Enterprises need to take concrete action to minimize this threat by using packages from the JavaScript npm ecosystem and monitoring the client side for malicious code.
This article was published on HelpNet Security and was edited to contain additional relevant insights from the study.
