What about checking the whois expiration of every email domain and locking out all the expired ones?
Compromising Angular via expired NPM publisher email domains
11–20 of 82 posts
Re: Compromising Angular via expired NPM publisher email domains
#12I 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 because of the immediacy, but wind up paying the price down the line because 1 person can save N people time with threaded asynchronous stuff.
Others have said this as well: https://news.ycombinator.com/item?id=15272394
Re: Compromising Angular via expired NPM publisher email domains
#13What about checking the whois expiration of every email domain and locking out all the expired ones?
[deleted]
Re: Compromising Angular via expired NPM publisher email domains
#14I 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
Like all tools used by humans, package managers are used for great good, and terrible evil. The great good (from a security point of view) is that we can distribute new features and patches quickly and freely. The bad: we can distribute nefarious code just as easily.
> Or just write it yourself.
Writing code is how bugs are created. Often popular libraries are much more robust and secure than bespoke code. Sometimes they are not.
> Learn what your code base does.
Great advice.
Re: Compromising Angular via expired NPM publisher email domains
#15It'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…
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.
Re: Compromising Angular via expired NPM publisher email domains
#16It'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…
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 show some kind of "verified" label for those people, that might be enough to push people.
Re: Compromising Angular via expired NPM publisher email domains
#17I 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.
Re: Compromising Angular via expired NPM publisher email domains
#18It'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.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
Re: Compromising Angular via expired NPM publisher email domains
#19It'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 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.
Re: Compromising Angular via expired NPM publisher email domains
#20A 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.
They never replied...