I don't like GitHub's security screener dismissing this report because of the "social engineering" aspect. There is a real problem here; it's easy to imagine this disclosure leading to another major OSS supply chain incident. I hope GitHub security folks are taking this more seriously than indicated by the response to the researcher.
> Their response seemed to indicate that the account was flagged due to previous issues sending emails, which would be expected with the domain having expired.
It's entirely possible that the domain could have been re-registered long before their next attempt to send an email to it.
I wonder if it's safer (and plausible) to run a daily whois audit job for all maintainer email domains and block anything that enters the redemptionPeriod status?
> I don't like GitHub's security screener dismissing this report because of the "social engineering" aspect.
Agreed.
I get where it comes from, npm isn't responsible for individual contributors getting social-engineered, but this is much deeper than that, and part of the flaw is with npm's support allowing the password reset to go through.
These "social engineering" vulnerabilities could be the maximum severity low hanging fruit for hackers. Github should definitely revisit their policies and reward the people disclosing these.
It's a shame Github Support haven't (AFAIK) expanded on what they mean by "This is something we’ve been tracking internally and have mitigations in place for.”
This problem is likely common to every public registry. Even if the registry doesn't publish e-mail addresses, it's often easy to work them out from other sources, so attackers can build up a list of targets relatively easily.
It seems like a hard one to solve for well. Mostly the registry will only know an author by their e-mail account, so if that's compromised it could be hard to tell the difference between the author genuinely losing their creds and an attacker who has taken over the domain.
> This problem is likely common to every public registry.
Not necessarily, it depends on what kind of authentication you are using. For example a Google account has a unique OAuth ID, and if your GSuite/Workplace/whatever account expires, and you recreate it again (regardless of the domain expiry/transfer in-between), the OAuth flow will present a new ID alongside the email address.
Dart/Flutter's package manager pub.dev uses Google accounts as authentication and has this extra OAuth ID check to prevent hostile ownership takeovers.
Interesting. Out of curiousity, is there a flow for if a package author gets permanently locked out of their google account? There have been cases of people losing access to their entire google account due to ToS breaches on one site (e.g. Youtube).
The safest option here would be to create an orphan package, but that has some usuability concerns (will people realise it's orphaned and update accordingly)
The mitigation against this was probably the restriction on password resets which support lifted. They just forgot to train support how to deal with it.
Auto-flagging every push from an account for a while after a password reset
Automatically scanning code of frequently downloaded packages for unusual changes (like: adding a postinstall script, contacting a new server in the postinstall script, obfuscated code, near-total rewrite of the code, inclusion of cryptomining, access of sensitive files like /etc/passwd or /etc/sudoers).
The vagueness of the statement suggests to me they're talking about their defense-in-depth and have never thought about this specific route to account takeover before.
In this case, if NPM has any mitigations like that, they would not have been triggered, because the reporter stopped once they had full access to the account.
People will lose their GPG/SSH keys. That would cause great havoc with thousands of projects being re-published under new names every year because their authors did not back up his ssh key.
The only proper way to handle that is to ask for national IDs, full names, document numbers. And in case of uncertainty ask photo with those docs and have human support to check it. Of course it should not be required, but just show some kind of "verified" label for those people, that might be enough to push people.
> Developers using custom domains for their email address should seriously consider the risks they are taking on by using the email for their online accounts. If this domain expires or is hijacked, where does that leave them?
This high level point really irritates me. What if your let your domain expire? What if your domain is hijacked? This applies to EVERYONE doing ANYTHING online with their own domain name - aka every business. What if you let your email account get hacked? What if you stop logging into your gmail account and they deactivate it for inactivity?
At the end of the day there are a hundred ways your accounts can have issues, if you don't care. If you don't pay attention. If you don't set up the proper alerting. Custom domains are not magically worse than using a gmail account.
As a normal, non-business, person... The longest running domain I've had was registered in 2005. It is still setup to receive email and works reliably, as it has done so for the last 17 years. Yes, it's been through several different email services in that time - but because I care about it I make sure it keeps working.
I also have a personal domain that's nearing 20 years of being online. Today qt.io refused registering an account because they didn't like said domain. I refuse to use another one. Despite already having written a repro and found where is the bug in their code. What have we come to?
> Today qt.io refused registering an account because they didn't like said domain.
Did their form say what wasn't liked about your domain? I'm curious because I remember a time, you may as well, when lots of account forms only accepted domains from known residential ISPs and would try to guess domains used by freemail providers.
These days, I'm curious why a group like QT would care.
Seems like the author is making a reasonable point to me. The risk profile for a gmail email address and a custom domain email address are different and developers may benefit from understanding this difference.
I don’t think he’s attacking the character or intelligence of people who use custom domains, he’s pointing out a gotcha that they may not be aware of.
You're giving the article more credit than it's earned.
Indeed, a developer should understand the risks and benefits associated with using an email address on domains they control vs. domains someone else controls.
Too bad the article doesn't make that point.
(Seems obvious to me that a domain you control is less risky since the mitigations are relatively straight-forward and reliable, while for a domain you don't control, you really don't have any reliable mitigations if the domain owner decides to shut you down. Not to mention that a third-party domain also has the risk of expiring or being highjacked. A third-party domain only makes sense if you want to trade risk for dollars: a cheaper or free email address for a greater risk of losing control of the email address.)
> This raises a point that I don’t think many developers consider. By registering and using a custom domain as their main email address, they implicitly give that domain and their TLD complete control over most of their online accounts.
That’s a feature, not a bug. This is what allows you to take full ownership of your online identity.
If you use @gmail.com or another address where you rent the address-space, someone else can at a random whim completely erase or compromise all your things and accounts everywhere.
Is the author here really pitching that as a good thing(tm)?
But you rent the domain as well. With the additional caveat that the domain will be available for renting by anybody else once you stop paying, whereas Gmail won't.
> With the additional caveat that the domain will be available for renting by anybody else once you stop paying
Not with the “additional” caveat. That’s the only caveat, and it’s a simple, understandable and known risk.
Using gmail.com or whatever puts you in a situation where the risks are numerous and unknown, and as a non-paying freeloader you get nothing to say in how access to your digital identity is managed.
If you care about your digital identity, there’s literally only one obvious answer.
Is there a good reason for making NPM profile emails public? I have an unique email address on NPM, and it receives a considerable amount of phishing emails that target NPM and Mailgun.
Maybe as way to help users contact authors without the registry not having to sit in the middle of it which would take effort. Should be an opt-in tho you’d think
Maybe, having email allows other people to contact if there is any vulnerability etc.? Not all project are on GitHub and there should be someway to contact the author, right?
The user interface does not show your account email, it is only exposed by the registry API. NPM has a button on every package listing to report malware and security issues in the package.
The registry's docs are famously incorrect and out of date. I don't have the time to enumerate all of them that are incorrect, but a great example are the docs around claiming dead or abandoned packages and orgs - that document is still discoverable via Google, and last I checked, was still on the main docs site.
A tangential issue related to this since Github is involved: Github pages.
If you point a DNS entry to a Github page and then delete the page without deleting the entry on you DNS table someone can create a new page with the same name and hijack your DNS entry for malicious purposes.
I've written to Github already about this, if they want to let you point your DNS to the page they should give you a unique entry to point to, so that if it is recreated in the future your entry will not point to the new page. Not asking you to point to the public page name that can be taken over.
It is good they finally worked this out, it's been years I wrote them about this (and many many others did the same, I was not the first nor the last to warn them).
I just don't understand why taking so long to fix this, and why they fixed it in such a complicated fashion when it's a really basic use case with a simple and straightforward solution that adds no burden to the end user.
If you point a dns entry to an ip and later someone takes control of that ip, guess what happens... This is a YOU problem, not a GitHub problem. Talking about dilettantes in the tech world...
Yes, and what the parent post was suggesting was that GitHub would have you use a CNAME to point your DNS entry to a unique FQDN (that it can tie back to your specific repo) instead of an IP, which would centrally prevent this issue without relying upon every single user to act perfectly.
All actors should take care of security, you should expect people to make mistakes especially if you're as big as Github. Your take on security is like talking about law and justice with a cowboy.
Nevertheless, I wonder, couldn't this be made more secure, by requiring those who publish the page HTML, to sign sth with a private key that [those who control the DNS record prove is their key]? So they prove that they have the same private key
Identity management is a very hard problem a lot of systems identify people by, or anchor trust to an email address, that mostly works, but has some very gnarly edges[0]. I don't think a private company can solve this (the company itself becomes a point of failure, what if they go out of business, or are acquired and change line of business?)
I really wish the USPS would get into managing digital identity, or at the very least, attack the lowest of hanging fruits: assign everyone[1] an email address that won't suddenly be closed for ToS violation on a domain that won't expire in anyone's lifetime. Lost your password/authenticator? Walk into a post office with your government issued identity.
Cleverer people than I am should be able to figure out how to create anonymous identities from your official one and have them linked unidirectionally, i.e. Alice can voluntarily prove she owns/created the Alana identity, but it's otherwise computationally impossible/expensive to do the reverse (unmask Alice from just the Alana pseudo ID)
0. Losing access to a mailbox means losing access to account recovery functionality, and mailbox takeovers result in TFA.
1. This is US-centric, but hopefully an international standard may be set, so that governments or delegated authorities are responsible for basic online identity; just like the way TLD's are managed
Readit News
> Their response seemed to indicate that the account was flagged due to previous issues sending emails, which would be expected with the domain having expired.
It's entirely possible that the domain could have been re-registered long before their next attempt to send an email to it.
I wonder if it's safer (and plausible) to run a daily whois audit job for all maintainer email domains and block anything that enters the redemptionPeriod status?
Agreed.
I get where it comes from, npm isn't responsible for individual contributors getting social-engineered, but this is much deeper than that, and part of the flaw is with npm's support allowing the password reset to go through.
https://github.com/oskarsve/ms-teams-rce/blob/main/README.md
Dead Comment
This problem is likely common to every public registry. Even if the registry doesn't publish e-mail addresses, it's often easy to work them out from other sources, so attackers can build up a list of targets relatively easily.
It seems like a hard one to solve for well. Mostly the registry will only know an author by their e-mail account, so if that's compromised it could be hard to tell the difference between the author genuinely losing their creds and an attacker who has taken over the domain.
Not necessarily, it depends on what kind of authentication you are using. For example a Google account has a unique OAuth ID, and if your GSuite/Workplace/whatever account expires, and you recreate it again (regardless of the domain expiry/transfer in-between), the OAuth flow will present a new ID alongside the email address.
Dart/Flutter's package manager pub.dev uses Google accounts as authentication and has this extra OAuth ID check to prevent hostile ownership takeovers.
Disclaimer: I'm contributor to pub.dev
The safest option here would be to create an orphan package, but that has some usuability concerns (will people realise it's orphaned and update accordingly)
(There was no 2FA enabled)
(I think the "email address doesn't work, so disabled sending to it" theory sounds more plausible actually :-))
Auto-flagging every push from an account for a while after a password reset
Automatically scanning code of frequently downloaded packages for unusual changes (like: adding a postinstall script, contacting a new server in the postinstall script, obfuscated code, near-total rewrite of the code, inclusion of cryptomining, access of sensitive files like /etc/passwd or /etc/sudoers).
The vagueness of the statement suggests to me they're talking about their defense-in-depth and have never thought about this specific route to account takeover before.
The only proper way to handle that is to ask for national IDs, full names, document numbers. And in case of uncertainty ask photo with those docs and have human support to check it. Of course it should not be required, but just show some kind of "verified" label for those people, that might be enough to push people.
This high level point really irritates me. What if your let your domain expire? What if your domain is hijacked? This applies to EVERYONE doing ANYTHING online with their own domain name - aka every business. What if you let your email account get hacked? What if you stop logging into your gmail account and they deactivate it for inactivity?
At the end of the day there are a hundred ways your accounts can have issues, if you don't care. If you don't pay attention. If you don't set up the proper alerting. Custom domains are not magically worse than using a gmail account.
As a normal, non-business, person... The longest running domain I've had was registered in 2005. It is still setup to receive email and works reliably, as it has done so for the last 17 years. Yes, it's been through several different email services in that time - but because I care about it I make sure it keeps working.
Did their form say what wasn't liked about your domain? I'm curious because I remember a time, you may as well, when lots of account forms only accepted domains from known residential ISPs and would try to guess domains used by freemail providers.
These days, I'm curious why a group like QT would care.
I don’t think he’s attacking the character or intelligence of people who use custom domains, he’s pointing out a gotcha that they may not be aware of.
Indeed, a developer should understand the risks and benefits associated with using an email address on domains they control vs. domains someone else controls.
Too bad the article doesn't make that point.
(Seems obvious to me that a domain you control is less risky since the mitigations are relatively straight-forward and reliable, while for a domain you don't control, you really don't have any reliable mitigations if the domain owner decides to shut you down. Not to mention that a third-party domain also has the risk of expiring or being highjacked. A third-party domain only makes sense if you want to trade risk for dollars: a cheaper or free email address for a greater risk of losing control of the email address.)
That’s a feature, not a bug. This is what allows you to take full ownership of your online identity.
If you use @gmail.com or another address where you rent the address-space, someone else can at a random whim completely erase or compromise all your things and accounts everywhere.
Is the author here really pitching that as a good thing(tm)?
Not with the “additional” caveat. That’s the only caveat, and it’s a simple, understandable and known risk.
Using gmail.com or whatever puts you in a situation where the risks are numerous and unknown, and as a non-paying freeloader you get nothing to say in how access to your digital identity is managed.
If you care about your digital identity, there’s literally only one obvious answer.
Deleted Comment
> maintainers: and array of objects containing author objects as listed in package.json
> author: object with name, email, and or url of author as listed in package.json
However, the email address against the user's profile gets listed even if your package.json does not contain an email address.
Example: https://registry.npmjs.org/leftpad/
Tom MacWright's email - https://registry.npmjs.org/leftpad/
azer - https://registry.npmjs.org/left-pad/
If you point a DNS entry to a Github page and then delete the page without deleting the entry on you DNS table someone can create a new page with the same name and hijack your DNS entry for malicious purposes.
I've written to Github already about this, if they want to let you point your DNS to the page they should give you a unique entry to point to, so that if it is recreated in the future your entry will not point to the new page. Not asking you to point to the public page name that can be taken over.
They never replied...
Deleted Comment
I just don't understand why taking so long to fix this, and why they fixed it in such a complicated fashion when it's a really basic use case with a simple and straightforward solution that adds no burden to the end user.
Deleted Comment
All actors should take care of security, you should expect people to make mistakes especially if you're as big as Github. Your take on security is like talking about law and justice with a cowboy.
I really wish the USPS would get into managing digital identity, or at the very least, attack the lowest of hanging fruits: assign everyone[1] an email address that won't suddenly be closed for ToS violation on a domain that won't expire in anyone's lifetime. Lost your password/authenticator? Walk into a post office with your government issued identity.
Cleverer people than I am should be able to figure out how to create anonymous identities from your official one and have them linked unidirectionally, i.e. Alice can voluntarily prove she owns/created the Alana identity, but it's otherwise computationally impossible/expensive to do the reverse (unmask Alice from just the Alana pseudo ID)
0. Losing access to a mailbox means losing access to account recovery functionality, and mailbox takeovers result in TFA.
1. This is US-centric, but hopefully an international standard may be set, so that governments or delegated authorities are responsible for basic online identity; just like the way TLD's are managed