The past few years saw a rise in the variety and volume of software supply chain attacks. The threat landscape is evolving too fast to neglect the latest updates. The article shows how researchers discovered an npm API vulnerability.
that reminds developers to stay on top of their security practices.
Aqua researchers recently discovered a novel timing attack against the npm’s registry API that hackers can exploit to potentially expose private packages used by organizations, putting them at risk of supply chain threats. The attackers leverage the time npm API (registry. npmjs[.]org) takes to return the “HTTP 404” error message when a user queries for a private package.
In the scoped confusion attack, the threat attackers compare the response time with the one for a non-existing module. The cybercriminals’ ultimate motive is to identify packages that organizations use internally, create their public versions, and attempt to compromise the software supply chain.
Why Do Developers House Code Dependencies on npm?
The internal developer projects mostly use standard, trusted code dependencies housed in private repositories on npm, PyPi, etc. The developers do it to prevent code dependency issues and software supply chain attacks and to protect the sensitive internal developer code.
However, if cyber criminals manage to hijack or weaponize them, the code repositories provide an attractive avenue for threat actors looking to crack organizational networks and access sensitive information. A timing attack helps cybercriminals launch malicious code attacks at corporate targets by cloning private package names.
How the Latest Timing Attack is Different From Dependency Confusion Attacks
The latest findings about the npm API confirm that the attack differs from dependency confusion attacks because it requires the threat actors to guess the private package names used by an enterprise and then publish malicious packages with the same name available to the public.
In contrast, dependency confusion attacks (or namespace confusion) rely on package managers checking and confirming public code registries for a package before private registries, helping them retrieve a higher malicious version package from the public repository.
Leveraging Sophisticated Search Methods for Private Package Names
“If a hacker sends about five consecutive requests for information concerning a private package and analyzes the time taken to get a reply from npm, it is possible for him to identify whether the private package exists.”
According to the research, there are a few methods that threat actors can use to create a list of private package names and test them with the timing attack. These include:
- They can utilize the patterns found in the organization’s public package nomenclature and perform a dictionary attack to guess the names of the private packages.
- They can utilize online public data sets (like libraries.io) and access historical information about the deleted public packages that the organizations converted to private ones.
The Aqua Security team disclosed the npm bug to the Microsoft-owned subsidiary GitHub on March 8, 2022. However, GitHub responded that the timing attack would not get fixed due to architectural limitations.
“Because of the architectural limitations, we cannot stop timing attacks from determining if a specific private package exists on npm,” GitHub explained to Aqua Security.
Thus, the researchers say that the responsibility to take preventive action lies with the organizations, who can frequently search npm for malicious packages that spoof their private packages with similar or duplicate names.
A Risky Time for Dependencies in the Software Supply Chain
The software supply chain is crucial to the applications and websites’ lifecycle. The common interdependencies and components in modern software development infrastructure can increase the attack surface and allow threat actors to bypass robust security layers IT teams add to their infrastructure.
Only one vulnerability in the code base is enough to compromise the entire software supply chain. The primary issue is that current projects have numerous dependencies. Additionally, software development relies heavily on third-party vendors and open-source platforms because it speeds up the process, offering developers standard libraries. Since many organizations or people maintain the code, it becomes challenging to prevent security flaws.
Steps Organizations Can Take to Protect Themselves
Here are tips for businesses to mitigate the risks:
- Gather a list of all the organization’s public and private packages on all the package management platforms.
- Actively look for typosquatting, masquerading packages, or lookalikes. Verify that no packages have the same name as the organization’s internal private packages.
- If you discover similar packages, ensure they do not contain malware and notify the relevant stakeholders immediately.
- If there are no public packages similar to the organization’s internal packages, you can create public packages as placeholders to mitigate such threats.
- To prevent any typosquatting attacks, you can register a public registry with the private registry’s name.
- Organizations must use a stricter vendor policy (e.g., using the exact version number, not “*” or “^” to prevent silent updates during installations).
- The owner or maintainer of a package must enable multi-factor authentication.
- Developers must never deploy sourcemaps and configuration files in production.
- They must keep all the dependencies updated.
What Security Researchers Have to Say
-
Yakir Kadkoda, Aqua Security researcher
“The threat actors can create a potential package names list and detect the organizations’ scoped private packages. Then, they can masquerade public packages and trick users and employees into downloading them.”
He further explained that it takes less time, on average, to get a reply for a non-existent package than for an existing one. “If you don’t find public packages resembling your internal packages, consider creating placeholder public packages to prevent such attacks,” Kadkoda said.
-
Lance Vick, security consultant
On software supply chain vulnerabilities, he commented that as a developer, if you don’t maintain a code, you cannot control it, and most of your project’s code is not your code these days. However, few developers understand that they must review the code copied from the internet (written by strangers) with the same scrutiny, if not higher, as the code written by employees.
“The reality is most organizations trust code written by strangers more than their employees, and it causes embarrassing headlines,” he remarked.
-
Nusrat Zahan, corresponding author of a Preprint study and a doctoral student at North Carolina State University
“Packages may include more than the listed vulnerabilities.” For example, some studies show how researchers found 95 times more vulnerabilities than reported. Hence, if we perform in-depth studies for detecting vulnerabilities, we can find more than we know, and in such a case, we believe we need to focus on secure coding.
“Note that the scorecard tool mentioned in our study gives us a way of measuring the security practices, but it is up to the organizations to determine how they can improve their package security.”
Final Words
Cybercriminals often seek unique ways to penetrate your organization. Recent years have seen a significant increase in software supply chain attacks. Developers have many tools to help keep their software supply chain safe. However, in the above case, as GitHub shrugged off the responsibility of the potential vulnerability, it becomes critical for organizations to take proactive steps to mitigate the risks.