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

41–50 of 82 posts

Re: Compromising Angular via expired NPM publisher email domains

#41

Post by robbie-c »

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.

Re: Compromising Angular via expired NPM publisher email domains

#42

Post by tonyedgecombe »

ris wrote: post #17
EGreg wrote: 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 have been writing for years that package managers are a big security risk "Wild-west"-style package managers (more specifically, their repos) are a big security risk. It's possible to have far more confidence in "maintained" packaging repositories.

The general trend has been towards less confidence in 3rd party software and packages. I'm not sure that is going to reverse any time soon.

Re: Compromising Angular via expired NPM publisher email domains

#43

Post by raesene9 »

isoos wrote: post #18
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…

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

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)

Re: Compromising Angular via expired NPM publisher email domains

#44

Post by RKearney »

jffry wrote: post #24
pbalau wrote: post #22

Earlier quoted context omitted.

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.

They would need a unique IP for every single repo. While this isn't a problem for IPv6, it is completely unrealistic for IPv4.

When github.example.com is configured as a CNAME to my-gh-page.my-repo.github.com, the IP that is returned will have no idea that it's my-gh-page.my-repo.github.com that is being requested as github.example.com will be what is sent in the Host header and part of the TLS SNI.

EDIT: I misunderstood what OP was suggesting. Pointing a CNAME to a repo specific domain name would work only if that name is removed after the repo goes away. As previously mentioned, this should not be Github's responsibility and it is a domain owners responsibility to properly maintain their records.

Re: Compromising Angular via expired NPM publisher email domains

#45

Post by [deleted] »

01acheru wrote: post #20

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

[deleted]

Re: Compromising Angular via expired NPM publisher email domains

#46

Post by josteink »

> 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)?

Re: Compromising Angular via expired NPM publisher email domains

#47

Post by 01acheru »

RKearney wrote: post #44
jffry wrote: post #24

Earlier quoted context omitted.

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.

They would need a unique IP for every single repo. While this isn't a problem for IPv6, it is completely unrealistic for IPv4. When github.example.com is configured as a CNAME to my-gh-page.my-repo.github.com, the IP that is returned will have no idea that it's my-gh-page.my-repo.github.com that is being requested as github.example.com will be what is sent in the Host header and part of the TLS SNI. EDIT: I misunders…

> They would need a unique IP for every single repo

I don't think this is true. If your CNAME myghpage.example.com points to .github.com which then routes you appropriately, all Github has to do is remove that subdomain when you delete the page and that's it, myghpage.example.com will fail to resolve and you're safe.

This would work even if Github only had a single public IP address.

edit: The issue with Github pages is that they make you point your CNAME to something.github.io not something.youraccount.github.io, so anyone can recreate something.github.io after you delete it. If they simply created the pages as something.youraccount.github.io you would be safer, unless you lose your account name. That's why the random subdomain is preferable.

Re: Compromising Angular via expired NPM publisher email domains

#48

Post by loo »

RKearney wrote: post #44
jffry wrote: post #24

Earlier quoted context omitted.

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.

They would need a unique IP for every single repo. While this isn't a problem for IPv6, it is completely unrealistic for IPv4. When github.example.com is configured as a CNAME to my-gh-page.my-repo.github.com, the IP that is returned will have no idea that it's my-gh-page.my-repo.github.com that is being requested as github.example.com will be what is sent in the Host header and part of the TLS SNI. EDIT: I misunders…

That's not the case. Generate a unique ID on activation. Ask us to CNAME => .pages.github.tld. Drop the record when page is deactivated. Sorted.

Re: Compromising Angular via expired NPM publisher email domains

#49

Post by draw_down »

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…

No post body was provided.

Re: Compromising Angular via expired NPM publisher email domains

#50

Post by jefftk »

lozenge wrote: post #19
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…

Some mitigations could be: 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 vaguene…

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.
Post reply on HN