Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compromising Angular via expired NPM publisher email domains

thehackerblog.com

Post reply on HN
Print view View original

61–70 of 82 posts

Re: Compromising Angular via expired NPM publisher email domains

#61

Post by tjoff »

burrows wrote: post #58
ShakataGaNai wrote: post #57

> 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 e…

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.

Having your own domain shoulders you from google or any other mail provider. Surely that is vastly better.

Re: Compromising Angular via expired NPM publisher email domains

#62

Post by josteink »

remram wrote: post #53
josteink wrote: post #46

> 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…

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.

Re: Compromising Angular via expired NPM publisher email domains

#63

Post by burrows »

tjoff wrote: post #61
burrows wrote: post #58

Earlier quoted context omitted.

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.

Having your own domain shoulders you from google or any other mail provider. Surely that is vastly better.

We can do a risk profile for an email with a custom domain versus a gmail domain.

Do we need to differentiate between custom email domain with self-hosted mail server and custom email domain with gmail?

If I self-host the mail server then I’ll have a machine running on digital ocean or ec2 and this machine will accept connections from the Internet. I think this machine should be included in the assessment. So now the risk of a custom email domain depends on when/how I apply patches and how ssh access is configured?

Re: Compromising Angular via expired NPM publisher email domains

#64

Post by lrem »

ShakataGaNai wrote: post #57

> 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 e…

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?

Re: Compromising Angular via expired NPM publisher email domains

#65

Post by dane-pgp »

remram wrote: post #54
Lucasoato wrote: post #11

What about checking the whois expiration of every email domain and locking out all the expired ones?

You still can't tell whether a domain was automatically renewed at expiration by the owner or by an attacker. A lot of registrars will auto-renew at the expiration date, or close enough that you can't tell from WHOIS records.

Maybe there should be some metadata that indicates whether a renewal is approved by the previous owner. That might require some extra administration by domain registrars and probably couldn't be applied retrospectively, but it would be useful.

The other place where this potentially matters is CAs issuing TLS certificates for domains that expire before the certificate does. If they detect that a domain they have issued a certificate for has been subsequently registered by a new entity, they should revoke the old certificate.

Re: Compromising Angular via expired NPM publisher email domains

#66

Post by jazzyjackson »

Jenk wrote: post #31
vbezhenar wrote: post #16

Earlier quoted context omitted.

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 sh…

Maybe "ssh keys" alongside those identity documents should become a thing in the digital age.

Estonia includes cryptographic keys with their identity docs, it's like plugging in your passport to be able to prove your identity and sign documents. It sounds like a great system, they only had to re-issue certificates once a few years ago when they realized the keys were too weak, but I can't find any other country that's taken up the decade-old technology.

They also have a state-provided email inbox for official communications, which I wish we had. A friend of mine had her car towed because the registration had lapsed -- she had ignored a letter from the DMV asking for proof of insurance b/c it looked like a scam to her. If only the government had a way to prove ITS identity.

Re: Compromising Angular via expired NPM publisher email domains

#67

Post by techsupporter »

lrem wrote: post #64
ShakataGaNai wrote: post #57

> 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 e…

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.

Re: Compromising Angular via expired NPM publisher email domains

#68

Post by jacquesm »

The fault is not with the domains or the publishers, but with the authentication used and not looking ahead beyond the 'happy path' of setting things up and making them work initially. That's the easy part. The hard part is to think through to the long term consequences of all those choices.

Re: Compromising Angular via expired NPM publisher email domains

#69

Post by cutemonster »

cotillion wrote: post #8
raesene9 wrote: post #4

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…

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.

If so, what could support have done? How could they verify that the new person was the same as the old

(There was no 2FA enabled)

(I think the "email address doesn't work, so disabled sending to it" theory sounds more plausible actually :-))

Re: Compromising Angular via expired NPM publisher email domains

#70

Post by codingkev »

robbie-c wrote: post #41
ghughes wrote: post #36

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 iss…

> 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.

What do you suggest as an alternative to password reset based on the account email?
Post reply on HN