NPM fixes private package name leak, a serious authorization bug

The largest Node.js package software registry, npm, has revealed several security vulnerabilities that have been identified and fixed recently.

The first flaw concerns the leak of private npm package names on the ‘replica’ server of npmjs.com, whose feeds are consumed by third-party services.

While the second flaw allows attackers to release new versions of any existing npm package to which they do not own or do not have rights, due to improper authorization checks.

Private npm package names leaked

This week, npm’s parent company, GitHub, revealed two security vulnerabilities that were identified and fixed in the npm registry between October and this month.

The first is a data leak on the npmjs replication server caused by “routine maintenance”. The leak exposed a list of private npm package names, but not the contents of those packages during the maintenance window.

“While maintaining the database that feeds the public npm replica to replicate.npmjs.com, records were created that could expose private package names, ”says Mike Hanley, GitHub’s security manager in a blog post.

“This briefly allowed consumers to replicate.npmjs.com to potentially identify private package names due to records posted to the public change stream. No other information, including the content of these private packages, was available at any time. “

Note that although the content of private packages has not been exposed, knowing the names of private packages is sufficient for malicious actors to conduct targeted dependency confusion and typosquatting attacks in an automated manner, as we have seen. seen many times.

The leak is specifically for extended private npm libraries that look like “@ owner / package“and were created before October 20. The names of these libraries were exposed” between October 21 13:12: 10Z UTC and October 29 15: 51: 00Z UTC, according to GitHub.

The data leak was identified by GitHub on October 26, and on October 29, all records containing private package names were deleted from the npm replication database. Although GitHub warns that despite this, the replicate.npmjs.com the service is consumed by third parties who may therefore continue to keep a copy or “have replicated the data elsewhere”.

To prevent such an issue from reoccurring, GitHub has made changes to its process for building the public replication database, which should eliminate the possibility of private package names being leaked in the future.

A flaw could allow the unauthorized publication of new versions

Additionally, GitHub revealed a serious bug that could “allow an attacker to release new versions of any npm package using an account without proper authorization”.

The vulnerability was caused by improper authorization checks and data validation between multiple microservices that process requests to the npm registry.

“In this architecture, the authorization service correctly validated user authorization for packages based on the data passed in request URL paths. However, the service that performs the underlying updates of the Registry data determined which package to publish based on the contents of the downloaded package file, ”says Hanley.

“This discrepancy provided a means by which requests to release new versions of a package would be allowed for one package, but would actually be made for a different and potentially unauthorized package. We have mitigated this issue by ensuring consistency between the Publish Service and Authorization Service to ensure that the same package is used for both authorization and publishing. “

Researchers Kajetan Grzybowski and Maciej Piechota were credited for responsibly reporting the vulnerability via GitHub security bug bounty program.

And, so far, there appears to be no evidence of exploitation. The vulnerability existed in the npm registry “beyond the time period for which we have telemetry to determine if it has ever been maliciously exploited”, but there is some assurance.

GitHub has said with great certainty that the vulnerability has not been maliciously exploited since at least September 2020, which is around the time that telemetry became available.

“We promptly validated the report, began our incident response processes, and corrected the vulnerability within six hours of receiving the report,” says GitHub.

npm will require two-factor authentication from 2022

Both announcements come shortly after popular npm libraries, “ua-parser-js”, “coa” and “rc” were hijacked in a series of attacks aimed at infecting consumers of open source software with horses. Trojans and crypto-miners.

These attacks have been attributed to the compromise of npm accounts [1, 2] owned by the maintainers behind these libraries. None of the managers of these popular libraries had enabled two-factor authentication (2FA) on their accounts, according to GitHub.

Attackers who successfully hack into maintainers’ npm accounts can trivially post new versions of these legitimate packages, after contaminating them with malware.

As such, to minimize the possibility of such compromises recurring in the near future, GitHub will begin requiring npm maintainers to activate 2FA, in the first quarter of 2022.

When it comes to instances where typosquatting and dependency confusion malware is posted to npm from an account owned by an attacker, rather than a hacked account, GitHub continues to invest in resources and resources. Security enhancements to automate real-time malware detection in newly released versions of npm packages. .