Live data from Hacker News

Compromising Angular via expired NPM publisher email domains

thehackerblog.com

51–60 of 82 posts

Re: Compromising Angular via expired NPM publisher email domains

#51

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

Whether it is good or bad on balance is a complicated question; I think the author is pointing out that it would have addressed this particular issue.

Re: Compromising Angular via expired NPM publisher email domains

#52
post #40
post #37

I just so happen to have a dataset of every single email address in the NPM registry (and any publicly accessible email addresses for associated GitHub repo users). It wouldn't take long for me to stream those records using that domain lookup command to discover which were no longer registered. I wonder if that would have any intrinsic value to the community at large?

Probably? The author limited their audit to the top 1,000 packages + dependencies. I would not be surprised if both of the following things are true: 1) a lot of damage can still be done outside of that scope; 2) there are domains that NPM/GitHub have not attempted to send mails to since expiration, and those accounts have therefore not yet been flagged for manual intervention by the support team.

That is very possible. The only emails I ever get from npm are when I initiate an action. If the way to identify expired domain is by random emails being sent to them we can be sure most vulnerable accounts are not flagged.

Re: Compromising Angular via expired NPM publisher email domains

#53

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

Re: Compromising Angular via expired NPM publisher email domains

#54

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.

Re: Compromising Angular via expired NPM publisher email domains

#55
post #12

I have been writing for years that package managers are a big security risk, and if you’re writing a platform that’s going to be used everywhere, you should import code by hand and verify what has changed. Or just write it yourself. Yes, seriously. Learn what your code base does. If your library is used N times then every hour you spend saves N people-hours. It’s just like using Slack: you think you’re saving time be…

I plug this every time, but here goes: https://github.com/crev-dev/crev solves this by providing code reviews, scales via a web-of-trust model, and relies on cryptographic identities. That way, you can depend on a package without having to trust its maintainers and all future versions.

Re: Compromising Angular via expired NPM publisher email domains

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

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.

Re: Compromising Angular via expired NPM publisher email domains

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

Re: Compromising Angular via expired NPM publisher email domains

#58

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

Re: Compromising Angular via expired NPM publisher email domains

#60
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'm surprised Microsoft didn't categorise it as "Important, Spoofing".

https://github.com/oskarsve/ms-teams-rce/blob/main/README.md

Post reply on HN