GitHub Fixes a Private-Package-Names Leak and Serious Authorization Bug (bleepingcomputer.com) 21
In 2020 Microsoft's GitHub acquired NPM (makers of the default package manager for Node.js). The company's web page boasts that npm "is a critical part of the JavaScript community and helps support one of the largest developer ecosystems in the world."
But now BleepingComputer reports on two security flaws found (and remediated) in its software registry. Names of private npm packages on npmjs.com's 'replica' server (consumed by third-party services) were leaked — but in addition, a second flaw could've allowed attackers "to publish new versions of any existing npm package that they do not own or have rights to, due to improper authorization checks."
In a blog post this week GitHub's chief security officer explained the details: During maintenance on the database that powers the public npm replica at replicate.npmjs.com, records were created that could expose the names of private packages. This briefly allowed consumers of replicate.npmjs.com to potentially identify the names of private packages due to records published in the public changes feed. No other information, including the content of these private packages, was accessible at any time. Package names in the format of @owner/package for private packages created prior to October 20 were exposed between October 21 13:12:10Z UTC and October 29 15:51:00Z UTC. Upon discovery of the issue, we immediately began work on implementing a fix and determining the scope of the exposure. On October 29, all records containing private package names were removed from the replication database. While these records were removed from the replicate.npmjs.com service on this date, the data on this service is consumed by third-parties who may have replicated the data elsewhere. To prevent this issue from occuring again, we have made changes to how we provision this public replication database to ensure records containing private package names are not generated during this process.
Second, on November 2 we received a report to our security bug bounty program of a vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. We quickly validated the report, began our incident response processes, and patched the vulnerability within six hours of receiving the report.
We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file. This discrepancy provided an avenue by which requests to publish new versions of a package would be authorized for one package but would actually be performed for a different, and potentially unauthorized, package. We mitigated this issue by ensuring consistency across both the publishing service and authorization service to ensure that the same package is being used for both authorization and publishing.
This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously. However, we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020.
BleepingComputer adds: Both announcements come not too long after popular npm libraries, 'ua-parser-js,' 'coa,' and 'rc' were hijacked in a series of attacks aimed at infecting open source software consumers with trojans and crypto-miners. These attacks were attributed to the compromise of npm accounts [1, 2] belonging to the maintainers behind these libraries.
None of the maintainers of these popular libraries had two-factor authentication (2FA) enabled on their accounts, according to GitHub. Attackers who can manage to hijack npm accounts of maintainers can trivially publish new versions of these legitimate packages, after contaminating them with malware. As such, to minimize the possibility of such compromises from recurring in near future, GitHub will start requiring npm maintainers to enable 2FA, sometime in the first quarter of 2022.
But now BleepingComputer reports on two security flaws found (and remediated) in its software registry. Names of private npm packages on npmjs.com's 'replica' server (consumed by third-party services) were leaked — but in addition, a second flaw could've allowed attackers "to publish new versions of any existing npm package that they do not own or have rights to, due to improper authorization checks."
In a blog post this week GitHub's chief security officer explained the details: During maintenance on the database that powers the public npm replica at replicate.npmjs.com, records were created that could expose the names of private packages. This briefly allowed consumers of replicate.npmjs.com to potentially identify the names of private packages due to records published in the public changes feed. No other information, including the content of these private packages, was accessible at any time. Package names in the format of @owner/package for private packages created prior to October 20 were exposed between October 21 13:12:10Z UTC and October 29 15:51:00Z UTC. Upon discovery of the issue, we immediately began work on implementing a fix and determining the scope of the exposure. On October 29, all records containing private package names were removed from the replication database. While these records were removed from the replicate.npmjs.com service on this date, the data on this service is consumed by third-parties who may have replicated the data elsewhere. To prevent this issue from occuring again, we have made changes to how we provision this public replication database to ensure records containing private package names are not generated during this process.
Second, on November 2 we received a report to our security bug bounty program of a vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. We quickly validated the report, began our incident response processes, and patched the vulnerability within six hours of receiving the report.
We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file. This discrepancy provided an avenue by which requests to publish new versions of a package would be authorized for one package but would actually be performed for a different, and potentially unauthorized, package. We mitigated this issue by ensuring consistency across both the publishing service and authorization service to ensure that the same package is being used for both authorization and publishing.
This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously. However, we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020.
BleepingComputer adds: Both announcements come not too long after popular npm libraries, 'ua-parser-js,' 'coa,' and 'rc' were hijacked in a series of attacks aimed at infecting open source software consumers with trojans and crypto-miners. These attacks were attributed to the compromise of npm accounts [1, 2] belonging to the maintainers behind these libraries.
None of the maintainers of these popular libraries had two-factor authentication (2FA) enabled on their accounts, according to GitHub. Attackers who can manage to hijack npm accounts of maintainers can trivially publish new versions of these legitimate packages, after contaminating them with malware. As such, to minimize the possibility of such compromises from recurring in near future, GitHub will start requiring npm maintainers to enable 2FA, sometime in the first quarter of 2022.
Re: (Score:3)
AFAIK, in the object world, private package names (and other private data types) are not supposed to be accessible outside of the objects that use them in their implementation. Well designed OOD systems will not allow you to get inside of a public object even if you know the names of the internals. Others allow access (or can't prevent it), but expect developers not to fiddle around with internal object data. Preferring the users to access and modify such data using the public interfaces and methods and to
Re: (Score:2)
In this case it may look like "private packages" actually refers to publishing packages into the npm repo and sharing with a limited set of users/teams:
https://docs.npmjs.com/about-p... [npmjs.com]
I have very limited experience with npm, so not sure why anyone would want to do this. Can you not set up a private repo elsewhere and pull the private packages from there? For my company, where we do most of our development in Java with Maven as the package manager, we just set up our own Nexus Repository server and we add
Re: (Score:1)
NPM packages are a bit like deb/rpm packages. So you can think of it as a private APT/yum/etc. repository's package list being exposed publicly by the company hosting the repository.
Re: (Score:2)
Now ponder why NPM has a package for isEven().
Re: (Score:1)
Okay, I'm not a JS person.
Or any sort of programmer.
WHY you'd have something that was meant to be private uploaded to a third party site?
Tell this old fart what he's missing here.
You're probably not old enough for that to be an excuse why you don't know what a revision control system is, or why it might be hosted by the third party.
This is a website for nerds.
Re: (Score:2)
The person might have suggested that why host a revisions of your code at a 3rd party, when there is more than enough software available to set that up yourself on servers you own (on premise or in a separate data-center).
You sound too young to see there are some benefits to manage things yourself, instead of that near sickening desire to host everything with others, just because cloud/convenience/mental laziness. And no, I don't mention cheaper, as the cloud is more often than not on-par or more expensive.
Re: (Score:2)
Ok now learn what a userid is.
Why is NPM such a target? (Score:2)
Out of all the places in the world that host software for download, why does the NPM repository and the packages it holds seem to be such a target for hackers?
Re: (Score:3)
Because it is so easy and very effective.
The JS community has streamlined and simplified pulling packages from a remote repo and automatically incorporating them into your build.
The community has also encouraged a strong reliance on using libraries as the first answer to solving a problem (see left-pad).
There is no review or verification process for these remote packages. NPM provides no quality feedback mechanisms like an issue count or comment facility, just a report malware button.
From the outside, the m
security shit-show (Score:3)
Because NPM, and node.js, is a security shit-show. Node usually runs with full administrative privileges on the machine hosting it, and the entire design of Node and NPM leads developers to use many NPM packages which use many other NPM packages and so on. No-one can analyse or track all those dependencies in full detail, and they change rapidly. This gives a large and richly-permeable attack surface against any NPM-using installation.
Node is also very trendy among the "hack and don't look back" crowd, with
Re: (Score:2)
I've got to agree that Node and NPM are singularly the worst option for anyone who cares about any sort of quality. Security is really tricky - if not impossible, depending on your requirements. Trying to run things in a "proper production" way is also as good as impossible. Asking questions on the forums is usually met with "why are you doing that?" or "you're doing it wrong".
Aside from incredible problems with privilege separation between deploy and run, my go-to gripe about Node.js is that it insists on
Re: (Score:2)
Out of all the places in the world that host software for download, why does the NPM repository and the packages it holds seem to be such a target for hackers?
My stab at this is that it is because JS is a prototype-based language, so it is endlessly easy to obfuscate, and meta-programming techniques are also easy. So when you find an exploit, it is always easy to make use of it.
Identity in security (Score:2)
Seems like the typical cloud based organization consists of around 10% people who understand identity based security and 90% who start to sweat and eyes glaze over when someone speaks about SAML assertions, IdP/SP and OAuth tokens. As long as there are security people in cloud environments thinking an IP allowlist between two AWS microservices is sufficient security, this sort of thing will still make the news.
Start requiring maintainers to use 2FA in 2022 (Score:2)
Why not just make it a hard requirement immediately!? If npm maintainers are not capable of turning on 2FA at a moments notice, should they be trusted to maintain packages which can be randomly included into zillions of projects?
On second though, who gives a shit. Maybe every hipster cryptoasset exchange built on node.js that just pulled random packages in order to cash in on all the ponzis will get compromised by some hilarious supply chain attack and it'll take down both gross sectors in one go.