{"id":25482,"date":"2022-10-12T19:46:54","date_gmt":"2022-10-12T19:46:54","guid":{"rendered":"https:\/\/www.esecurityplanet.com\/?p=25482"},"modified":"2022-10-12T22:48:14","modified_gmt":"2022-10-12T22:48:14","slug":"vulnerable-api-exposes-private-npm-packages","status":"publish","type":"post","link":"https:\/\/www.esecurityplanet.com\/threats\/vulnerable-api-exposes-private-npm-packages\/","title":{"rendered":"Vulnerable API Exposes Private npm Packages"},"content":{"rendered":"\n

Aqua Nautilus security researchers have revealed that threat actors could perform a timing attack on npm’s API<\/a> to uncover private packages.<\/p>\n\n\n\n

The timing attack on the JavaScript package manager can work even if npm returns a 404 error to unauthorized or unauthenticated users who try to request the following endpoint (generic pattern):<\/p>\n\n\n\n

https:\/\/registry.npmjs.org\/@<scope_name>\/<secret_package_name><\/p>\n\n\n\n

A malicious attacker can send multiple consecutive requests to determine if the package exists or has been removed. Such a timing attack consists of comparing \u201cthe time it takes to search for a private package that exists with a private package that doesn\u2019t exist,” Aqua’s Yakir Kadkoda wrote<\/a>.<\/p>\n\n\n\n

The researchers discovered it takes around five consecutive API requests to find that the API response takes significantly more time when the package exists or has been removed: 648ms vs. 101ms. Such a gap allows the discovery process to be automated by creating a list of potential package names to be tested.<\/p>\n\n\n\n

The issue was reported to GitHub\u2019s bug bounty program in March 2022, but the platform\u2019s answer is not reassuring: \u201cBecause of these architectural limitations, we cannot prevent timing attacks from determining whether a specific private package exists.\u201d<\/p>\n\n\n\n

See the Top Code Debugging and Code Security Tools<\/a><\/p>\n\n\n\n

How Hackers Can Exploit the API Design Flaw<\/strong><\/h2>\n\n\n\n

Kadkoda\u2019s methodology is quite straightforward: he created a private npm package under a \u201crandom-organization\u201d and uploaded some files.<\/p>\n\n\n\n

Then he verified that the package existed with an authenticated and authorized user (member of the organization). He did the same with an unauthenticated user but did not find notable differences with a single consecutive request. It\u2019s only after five consecutive requests from \u201cvarious systems\u201d that the results became significant:<\/p>\n\n\n\n

This information could be exploited to disclose private package names and perform various malicious techniques like typosquatting or dependency confusion to hack the software supply chain<\/a>.<\/p>\n\n\n\n

To achieve that, attackers could use generic or more customized dictionaries with names that contain the name of the organization. It\u2019s not uncommon for dev teams to apply some naming convention to keep things organized and clean.<\/p>\n\n\n\n

According to Aqua researchers, an attacker may also use public datasets to get a list of removed public packages that could have been converted to private packages.<\/p>\n\n\n\n

It\u2019s definitely not the first time npm (and other platforms) has been impacted by such threats, which put many organizations at risk (see Software Supply Chain: A Risky Time for Dependencies<\/a>).<\/p>\n\n\n\n

“Over the past few years, we\u2019ve seen a dramatic increase by hundreds of percentage points in supply chain attacks,” Kadkoda wrote. “In some cases, the threat actors\u2019 goal is to gain access to open-source packages\/projects and poison them. Other times they masquerade as private or public packages\/projects, deliberately misspelling their names in order to trick unsuspecting victims into downloading their malicious package instead of legitimate popular ones.”<\/p>\n\n\n\n

How to Protect Against the npm Timing Attack<\/strong><\/h2>\n\n\n\n

Aqua Nautilus recommends recording all private and public packages, a good practice that can be summarized as \u201cknow your supply chain.\u201d<\/p>\n\n\n\n

The researchers said dev and security teams should also look for typosquatting, lookalikes, or masquerading packages.<\/p>\n\n\n\n

“Verify that there are no other packages with the same name as your internal private packages,” they said. “If you find any similar packages, make sure that they do not contain malware and notify the relevant stakeholders.<\/p>\n\n\n\n

“If you don\u2019t find public packages similar to your internal packages, consider creating public<\/strong> packages as placeholders<\/strong> to prevent such attacks.”<\/p>\n\n\n\n

Because big software platforms have huge constraints, fixing flawed API design and other security holes can take a long time or even be marked as \u201cwon\u2019t fix.\u201d It does not mean companies should quit all third-party services and handle everything by themselves internally, however.<\/p>\n\n\n\n