[HN Gopher] Compromising Angular via expired NPM publisher email...
___________________________________________________________________
Compromising Angular via expired NPM publisher email domains
Author : fransr
Score : 184 points
Date : 2022-02-20 07:07 UTC (15 hours ago)
(HTM) web link (thehackerblog.com)
(TXT) w3m dump (thehackerblog.com)
| the8472 wrote:
| Entirely avoidable if people could buy domains for 100years, paid
| up-front.
| wink wrote:
| For what percentage of the population? Going with an easy
| example of 12$/year for a .org - I can tell you I can think of
| exactly 0 people in my circle of friends who would put down
| 1200$ for a domain.
| ShakataGaNai wrote:
| > 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.
| burrows wrote:
| 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.
| tjoff wrote:
| Having your own domain shoulders you from google or any other
| mail provider. Surely that is vastly better.
| burrows wrote:
| 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?
| jmull wrote:
| You're giving the article more credit than it's earned.
|
| Indeed, a developer should understand the risks and benefits
| associated with using an email address on domains they
| control vs. domains someone else controls.
|
| Too bad the article doesn't make that point.
|
| (Seems obvious to me that a domain you control is less risky
| since the mitigations are relatively straight-forward and
| reliable, while for a domain you don't control, you really
| don't have any reliable mitigations if the domain owner
| decides to shut you down. Not to mention that a third-party
| domain also has the risk of expiring or being highjacked. A
| third-party domain only makes sense if you want to trade risk
| for dollars: a cheaper or free email address for a greater
| risk of losing control of the email address.)
| lrem wrote:
| 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?
| techsupporter wrote:
| > 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.
| ghughes wrote:
| 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?
| lxe wrote:
| 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.
| draw_down wrote:
| dane-pgp wrote:
| I'm surprised Microsoft didn't categorise it as "Important,
| Spoofing".
|
| https://github.com/oskarsve/ms-teams-rce/blob/main/README.md
| robbie-c wrote:
| > 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.
| codingkev wrote:
| What do you suggest as an alternative to password reset based
| on the account email?
| tedunangst wrote:
| If you retired the email because the domain expired, maybe
| don't let it reset existing accounts. It's dead.
| raesene9 wrote:
| 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 for well. Mostly the registry
| will only know an author by their e-mail account, so if that's
| compromised it could be hard to tell the difference between the
| author genuinely losing their creds and an attacker who has taken
| over the domain.
| cotillion wrote:
| 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.
| cutemonster wrote:
| 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 :-))
| Jenk wrote:
| 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.
| vbezhenar wrote:
| 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.
| Jenk wrote:
| Maybe "ssh keys" alongside those identity documents should
| become a thing in the digital age.
| jazzyjackson wrote:
| 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.
| isoos wrote:
| > 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
| raesene9 wrote:
| 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)
| lozenge wrote:
| 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.
| jefftk wrote:
| 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.
| politelemon wrote:
| 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.
|
| Example: https://registry.npmjs.org/leftpad/
| qxmat wrote:
| leftpad != left-pad
|
| Tom MacWright's email - https://registry.npmjs.org/leftpad/
|
| azer - https://registry.npmjs.org/left-pad/
| andrew_ wrote:
| 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.
| jacquesm wrote:
| 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.
| beny23 wrote:
| Would be interesting to draw up a list of package registries and
| whether they require MFA...
| dadadad100 wrote:
| This is really a story about the weakness of digital identity.
| Stringing together identities proofed to IAL1 yields an IAL1
| identity. Authenticating to AAL2 can never change that
| dessant wrote:
| 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.
| nhoughto wrote:
| Maybe as way to help users contact authors without the registry
| not having to sit in the middle of it which would take effort.
| Should be an opt-in tho you'd think
| cute_boi wrote:
| Maybe, having email allows other people to contact if there is
| any vulnerability etc.? Not all project are on GitHub and there
| should be someway to contact the author, right?
| [deleted]
| dessant wrote:
| The user interface does not show your account email, it is
| only exposed by the registry API. NPM has a button on every
| package listing to report malware and security issues in the
| package.
| andrew_ wrote:
| Much about the registry exists due to legacy and its rather
| informal beginnings.
| paradite wrote:
| I have 2FA for my npm account, does 2FA prevent this kind of
| attack?
| dstick wrote:
| I'd say so. You can't reset an account's password without the
| second factor. There'd be very little point to it otherwise.
| raesene9 wrote:
| Often the problem with MFA setups is, what's the fallback
| mechanism for when the user loses their password+MFA token,
| none of the options are perfect.
|
| 1) Permanently lock them out of their account. Not a good
| customer experience and problematic in this setup (orphaned
| libraries)
|
| 2) Written "back-up codes", fine in theory but I'd guess a
| decent proportion of them are not well managed
|
| 3) Fall-back to manual verification (e.g. phone call
| establishing secondary information). Expensive and error
| prone.
| andrew_ wrote:
| 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?
| ghughes wrote:
| 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.
| elwebmaster wrote:
| 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.
| Lucasoato wrote:
| What about checking the whois expiration of every email domain
| and locking out all the expired ones?
| remram wrote:
| 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.
| dane-pgp wrote:
| 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.
| [deleted]
| spiffytech wrote:
| That moves this in the right direction, but still has secerity
| challenges. You need a path for the legitimate package author
| to reactivate their account after domain expiration, which
| means you need another way to trust you're talking to the same
| human as before the domain expired. This is where stuff like
| PGP comes up, but that comes with yet more challenges.
| [deleted]
| 01acheru wrote:
| 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 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...
| arccy wrote:
| at least they allow you to verify and restrict who can do this
| now https://docs.github.com/en/pages/configuring-a-custom-
| domain...
| pbalau wrote:
| 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...
| jffry wrote:
| 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.
| bombcar wrote:
| A CNAME like the ones AWS load balancers give you would
| also give GitHub the flexibility to change IPs as
| necessary.
| RKearney wrote:
| 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.
| 01acheru wrote:
| > 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
| <somerandomstuff>.github.com which then routes you
| appropriately, all Github has to do is remove that
| <somerandomstuff> 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.
| loo wrote:
| That's not the case. Generate a unique ID on activation.
| Ask us to CNAME => <unique-id>.pages.github.tld. Drop the
| record when page is deactivated. Sorted.
| 01acheru wrote:
| Did someone pee in your coffee?
|
| All actors should take care of security, you should expect
| people to make mistakes especially if you're as big as
| Github. Your take on security is like talking about law and
| justice with a cowboy.
| cutemonster wrote:
| Nevertheless, I wonder, couldn't this be made more secure, by
| requiring those who publish the page HTML, to sign sth with a
| private key that [those who control the DNS record prove is
| their key]? So they prove that they have the same private key
| batch12 wrote:
| I have found a similar issue affecting thousands of root
| domains on another service. They still sit there, ripe for the
| taking.
| [deleted]
| [deleted]
| EGreg wrote:
| 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 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
| indymike wrote:
| > 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.
| ris wrote:
| > 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.
| tonyedgecombe wrote:
| 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.
| remram wrote:
| 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.
| josteink wrote:
| > 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)?
| jefftk wrote:
| 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.
| remram wrote:
| 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.
| josteink wrote:
| > 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.
___________________________________________________________________
(page generated 2022-02-20 23:01 UTC)