Supply Chain Attacks on NPM Repositories

Using open source packages in software development is a great alternative to save on expenses and maintenance, and of course on development times. Since instead of taking care of developing certain predetermined functions on our own, we can rely on open source and use these previously designed functions.

However, in recent years there has been an increase in the number of attacks on the open source software supply chain, specifically the NPM repository supply chain. (NPM is the default package management system for Node.js , one of the most used technologies today and mainly in web development). Attackers use various methods to infect open source packages and distribute malicious code, effectively poisoning the repository that feeds millions of other programs.

A study by researchers at the University of North Carolina and Microsoft offers a new approach to protecting software supply chains, using empirical, data-driven methods to predict which open source packages are most likely to become targeted. of the attacks. The study of 1.63 million packages in the NPM repository reveals six indicators of weakness in the open source software supply chain.

Acting on these findings can help package maintainers and users make better security decisions and thus protect their software against potential supply chain attacks. The study carried out highlights the following weak points in the NPM package supply chain, which are more susceptible to being compromised in an attack:

‍

1. There were 2,818 maintainers whose domains had expired. An attacker can buy an expired domain and use it to hijack maintainers' accounts unless it is protected by two-factor authentication (2FA).

2. About 2% (33,000) of the packages included installation scripts. Installation scripts run automatically before, during, or after a package installation. If compromised, they can allow attackers to perform malicious activities on host devices, such as transferring user data, downloading malicious payloads, running reverse shells, deleting files and directories.

3. About 59% of the packages did not receive maintenance for two years. Additionally, 44% of maintainers were inactive for two years. Unmaintained packages have a higher chance of being compromised undetected. Inactive maintainers can be subject to account hijacking attacks without realizing it.

4. A small percentage of the packages had too many maintainers, increasing the chances that at least one of the maintainers' accounts was compromised.

5. Some packages had too many contributors, making it difficult for maintainers to keep track of all the changes. An attacker can use social engineering to become a trusted contributor to such packages before infiltrating malicious code.

6.The top 1% of maintainers were overloaded, owning an average of 180 packages. Attackers have a greater incentive to target such maintainers because, firstly, they are more likely to miss changes to any particular package, secondly, if compromised, their accounts can provide access to many packages.

Of the points seen above, point 3 can be highlighted, since in security audits it is one of the most frequently found vulnerabilities, obsolete dependencies packages, used in critical applications. Therefore, we urge you to be aware of what dependencies we use in our applications and ensure that they have the latest updates and if we depend on a technology with very long update periods, look for another alternative with better support.

‍

‍