Ever since the Web development ecosystem evolved to the current paradigm of code reuse, companies have placed themselves too close to the abyss. Web supply chain attacks are a real security threat – and one which the enterprise is vastly unprepared for.
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 in third-party scripts to skim credit card details of E-Commerce shoppers. While Magecart is still a growing threat and deserves consideration on its own, too little attention is paid to a very different 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. Security-wise, each of these pieces of third-party code can actually serve as an attack vector to inject malicious code into applications. A recent study by Markus Zimmermann et al. provided much-needed insight into just how serious a security threat this practice of reusing code poses to the industry as a whole.
To frame why these threats actually exist in the first place, this team of researchers pinpoints some characteristics of the npm ecosystem, one of which is the abnormally large incidence of code reuse when compared to other ecosystems – which I mentioned above. Apart from this, two other characteristics play an important role: the accented use of micropackages and the lack of privilege separation.
The reliance on micropackages is especially relevant because, while they comprise 47% of all packages, they simply contain a few lines of code – usually because they either perform trivial tasks or are used to 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.
And when we take a deeper look at the JavaScript ecosystem’s dependency chains, we can truly visualize just how large an attack surface modern JS applications display. The study by Zimmermann et al. found that, on average, an npm package has 80 dependencies of their own. 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. Boiling this down simply, this means that all pieces of third-party code have the same privileges as code that is developed internally. Not only does this mean that the security of the average JavaScript application is scattered over thousands of different third-parties, it also means that it only takes a breach in one of them – no matter how small – to potentially launch a web supply chain attack.
And when this same team of researchers further analyzed the actual maintainers of these packages, the overall finding was concerning indeed: 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.
All of these considerations wouldn’t show much cause for concern if this ecosystem was only used by non-commercial projects, or even small companies – what magnifies their importance is that every single 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 – paydirt gold for attackers.
We have seen enough examples of web supply chain attacks to know that there still isn’t enough being done to actually mitigate these attacks. Mainstream security measures are still falling short. And the key to a suitable response may come from a change of mindset.
A new security mindset: Shift 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 responsibly audit packages, to make sure that their source is trustworthy whilst vetting dev accounts. Some progress has been made in this direction recently, namely with the addition of npm-audit to automatically warn developers of known vulnerabilities in each package.
However, when critical enterprise applications could be at stake, and when millions of users could have sensitive data (such as financial or health details) stolen through client-side attacks, enterprises can’t afford to wait nor to trust. And yet, third-party code is here to stay. Solving this conundrum requires a change of mindset – there’s no infallible way of making sure that these third-parties aren’t injecting malicious code. The most reasonable fallback therefore, is to gain complete visibility of client-side threats.
By putting in place a web page monitoring solution, enterprises can react in real-time whenever a rogue third-party starts injecting malicious code – automatically triggering security measures to stop the attack. Unfortunately, companies are still being breached by third-party code, with malicious code running undetected for months and resulting in significant business damages. It’s high time that the enterprise took concrete action towards minimizing this security threat, using packages from the JavaScript npm ecosystem responsibly and monitoring the client-side for malicious code.
Security
via https://www.aiupnow.com
Help Net Security, Khareem Sudlow
