npm Timing Attack Could Lead to Future Supply Chain Attacks - Binary Defense

Threat Watch

Threat Watch npm Timing Attack Could Lead to Future Supply Chain Attacks

npm Timing Attack Could Lead to Future Supply Chain Attacks

Security researchers at Aqua Security have discovered a new npm timing attack that allows a threat actor to discover the name of private packages in a repository, which could lead to the deployment of malicious clones to trick developers into using them instead. This attack relies on a slight time difference when requesting a non-existent package via the API vs a private package. When requesting a non-existent package name, the average response time for the 404 error to be returned is just 101 milliseconds. However, when requesting a private package, the average response time is 648 milliseconds.

While the timing difference itself isn’t even a whole second, it is a large enough difference to be measurable, which could allow an attacker to map all the private packages that an organization has in their repository. Coupled with data on historical package information, the threat actor could also determine which of these packages used to be public. This could allow an attacker to create public packages that spoof those that are private to steal user credentials and install malware. Ultimately, this could lead to an attacker gaining access to the private repositories themselves with access to modify the packages, which could then lead to further compromise and disrupt the supply chain.

ANALYST NOTES

With supply chain attacks on the rise in the past year, this vulnerability is likely a first step that many threat actors will utilize to map the private repositories of organizations, allowing the actors to more carefully craft their typosquatting and other social engineering campaigns. While the researchers were informed by GitHub that this won’t be patched due to architectural limitations, there are some steps that organizations can take to ensure they are more protected against these attacks. First, organizations can map their own private repository and then search for any duplicates that may be spoofing them in the wild, reporting them for removal. Once removed, or if nonexistent, the organization can create their own public spoofs of their private packages, as npm doesn’t allow for same-name public packages. This would ensure that an actor is not able to create a malicious package with the same name as the private package. Ultimately, the best prevention is user education and what to look out for when navigating npm and other repositories.

https://www.bleepingcomputer.com/news/security/new-npm-timing-attack-could-lead-to-supply-chain-attacks/