New Timing Attack Against NPM Registry API Could Expose Private Packages

Cyber Security

A novel timing attack discovered against the npm’s registry API can be exploited to potentially disclose private packages used by organizations, putting developers at risk of supply chain threats.

“By creating a list of possible package names, threat actors can detect organizations’ scoped private packages and then masquerade public packages, tricking employees and users into downloading them,” Aqua Security researcher Yakir Kadkoda said.

The Scoped Confusion attack banks on analyzing the time it takes for the npm API (registry.npmjs[.]org) to return an HTTP 404 error message when querying for a private package, and measuring it against the response time for a non-existing module.

“It takes on average less time to get a reply for a private package that does not exist compared to a private package that does,” Kadkoda explained.

The idea, ultimately, is to identify packages internally used by companies, which could then be used by threat actors to create public versions of the same packages in an attempt to poison the software supply chain.

The latest findings are also different from dependency confusion attacks in that it requires the adversary to first guess the private packages used by an organization and then publish phony packages with the same name under the public scope.

Dependency confusion (aka namespace confusion), in contrast, relies on the fact that package managers check public code registries for a package before private registries, resulting in the retrieval of a malicious higher version package from the public repository.

Aqua Security said it disclosed the bug to GitHub on March 8, 2022, prompting the Microsoft-owned subsidiary to issue a response that the timing attack will not be fixed due to architectural limitations.

As preventive measures, it’s recommended that organizations routinely scan npm and other package management platforms for lookalike or spoofed packages that masquerade as the internal counterparts.

“If you don’t find public packages similar to your internal packages, consider creating public packages as placeholders to prevent such attacks,” Kadkoda said.