Live data from Hacker News

Compromising Angular via expired NPM publisher email domains

thehackerblog.com

31–40 of 82 posts

Re: Compromising Angular via expired NPM publisher email domains

#31
post #15

Earlier quoted context omitted.

PGP/SSH is surely the usable here as a 2fa. Have maintainers (or at the least owners) demonstrate their identity with both email and a key.

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.

Re: Compromising Angular via expired NPM publisher email domains

#33

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

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

Re: Compromising Angular via expired NPM publisher email domains

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

Re: Compromising Angular via expired NPM publisher email domains

#38
post #2

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.

Much about the registry exists due to legacy and its rather informal beginnings.

Re: Compromising Angular via expired NPM publisher email domains

#39

The NPM registry's API documentation seems to be wrong, or deliberately semi-vague, as well. It states (emphasis mine) > 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. Exam…

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.

Re: Compromising Angular via expired NPM publisher email domains

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