Researchers outline the six key indicators that an NPM package may be compromised
The growing use of open source packages in modern software development has come with the increased threat of supply chain attacks.
Attackers can choose from several methods to infect open source packages and distribute malicious code, effectively poisoning the well that feeds millions of other programs.
A new study by researchers at North Carolina University and Microsoft offers a new approach to securing software supply chains, using data-based empirical methods to predict which open source packages are more susceptible to becoming the target of attacks.
The study, conducted on 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 therefore safeguard their software against potential supply chain attack.
Weak links in the NPM supply chain
“Security researchers in academia and industry are actively investigating attacks in ecosystems to propose solutions; these approaches seem to be based on specific instances of malicious attacks (e.g. typosquatting, dependency confusion),” Nusrat Zahan, PhD student at NCSU and lead author of the paper, told The Daily Swig.
“Hence, they are especially effective in preventing malicious code distribution. But recent attacks show evidence that out-of-the-box exploit strategies will appear again and again.”
Zahan warned: “Any ad-hoc solution is not enough to prevent an attack that we have not witnessed yet.”
In their study, the researchers found six key indicators that an NPM package may be compromised by malicious actors:
- There were 2,818 maintainers whose domains had expired. An attacker can purchase an expired domain and use it to hijack the maintainers’ accounts unless it is protected by two-factor authentication (2FA).
- About 2% (33,000) of the packages included install scripts. Install scripts run automatically before, during, or after a package installation. If compromised, they can enable attackers to perform malicious activity on host devices, such as transferring user data, downloading malicious payloads, executing reverse shells, or removing files and directories.
- Around 59% of the packages were unmaintained for two years. Moreover, 44% of the maintainers were inactive for two years. Unmaintained packages have a greater chance of getting compromised without detection. Inactive maintainers might be targeted with account hijacking attacks without noticing.
- A small percentage of the packages had too many maintainers, which increases the chances of at least one of the maintainers’ accounts being compromised.
- Some packages had too many contributors, which made it hard for maintainers to keep tabs on all changes. An attacker can use social engineering to become regarded as a trusted contributor to such packages before sneaking in malicious code.
- The top 1% maintainers were overloaded and owned an average 180 packages. Attackers have a greater incentive to target such maintainers because first, they are more likely to overlook changes to any particular packages, and second, if compromised, their accounts can provide access to many packages.
Next steps
“If we think about different supply chain attacks, we will often see attackers using new techniques that we have not witnessed yet to propose a solution,” Zahan said.
“Our study aims to motivate practitioners to adopt best security practices instead of waiting for an attack to happen.”
The researchers corroborated their findings through a survey of hundreds of NPM package maintainers. Most participants agreed with the severity of the first three indicators and were interested in being notified about potential problems in these areas.
Read more of the latest infosec research news
It might be possible for the maintainers of the NPM repository to compute and display a risk model based on scoring the indicators of potential problem they identify, the researchers suggest.
Such a model would enable package managers to evaluate the security of their packages and address areas of potential weakness. It will also enable package users to make more educated, data-driven decisions and comparisons before incorporating new packages into their development pipelines.
“Please think about package security before selecting any package,” Zahan concluded. “Do not use a package just because other people are using the same package. Our proposed weak link signals along with the OpenSSF Metrics, Scorecard, and Best Practices Badge projects can be a good start to measure package risk in the supply chain.”
YOU MAY ALSO LIKE AWS security tool protects against dangling elastic IP takeovers
