New Timing Attack Against NPM Registry API Could Expose Private Packages

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^[1]
and then masquerade public packages, tricking employees and users
into downloading them,” Aqua Security researcher Yakir Kadkoda
said^[2].

The Scoped Confusion attack banks on analyzing the time it takes
for the npm API^[3]
(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^[4] 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^[5]), 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.