7 ms·
Compromising Angular via expired NPM publisher email domains
- dessant 5y agoIs 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 5y agoMaybe 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 5y agoMaybe, 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 5y ago[deleted]
- dessant 5y agoThe 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_ 5y agoMuch about the registry exists due to legacy and its rather informal beginnings.
- raesene9 5y agoIt'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 5y agoThe 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 5y agoIf 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 5y agoPGP/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 5y agoPeople 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 5y agoMaybe "ssh keys" alongside those identity documents should become a thing in the digital age.
- jazzyjackson 5y agoEstonia 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.
- politelemon 5y agoThe 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/ https://registry.npmjs.org/leftpad/
- qxmat 5y agoleftpad != left-pad Tom MacWright's email - https://registry.npmjs.org/leftpad/ https://registry.npmjs.org/leftpad/ azer - https://registry.npmjs.org/left-pad/ https://registry.npmjs.org/left-pad/
- andrew_ 5y agoThe 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.
- paradite 5y agoI have 2FA for my npm account, does 2FA prevent this kind of attack?
- dstick 5y agoI’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 5y agoOften 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.
- Lucasoato 5y agoWhat about checking the whois expiration of every email domain and locking out all the expired ones?
- deleted 5y ago[deleted]
- spiffytech 5y agoThat 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 5y ago[deleted]
- remram 5y agoYou 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 5y agoMaybe 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.
- remram 5y agoYou might as well use something out-of-band to verify emails, like PGP.
- EGreg 5y agoI 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 https://news.ycombinator.com/item?id=15272394
- indymike 5y ago> 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 5y ago> 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 5y agoThe 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 5y agoI plug this every time, but here goes: https://github.com/crev-dev/crev 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.
- 01acheru 5y agoA 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...
- pbalau 5y agoIf 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...
- cutemonster 5y agoNevertheless, 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
- jffry 5y agoYes, 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 5y agoA CNAME like the ones AWS load balancers give you would also give GitHub the flexibility to change IPs as necessary.
- RKearney 5y agoThey 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.
- dadadad100 5y agoThis 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
- beny23 5y agoWould be interesting to draw up a list of package registries and whether they require MFA…
- ghughes 5y agoI 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?
- robbie-c 5y ago> 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 5y agoWhat do you suggest as an alternative to password reset based on the account email?
- tedunangst 5y agoIf you retired the email because the domain expired, maybe don't let it reset existing accounts. It's dead.
- draw_down 5y ago
- lxe 5y agoThese "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.
- andrew_ 5y agoI 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 5y agoProbably? 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 5y agoThat 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.
- josteink 5y ago> 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 5y agoWhether 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 5y agoBut 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 5y ago> 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.
- remram 5y agoPeople have had their GoDaddy/NameCheap/... account social-engineered away from them too. That might be easier to fix than your Gmail (because you're a paying customer), but if your npm is already gone, having NameCheap apologize doesn't help much.
- ShakataGaNai 5y ago> 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 5y agoSeems 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 5y agoHaving your own domain shoulders you from google or any other mail provider. Surely that is vastly better.
- burrows 5y agoWe 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?
- the8472 5y agoEntirely avoidable if people could buy domains for 100years, paid up-front.
- wink 5y agoFor 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.
- jacquesm 5y agoThe 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.
- sangnoir 5y agoIdentity management is a very hard problem a lot of systems identify people by, or anchor trust to an email address, that mostly works, but has some very gnarly edges[0]. I don't think a private company can solve this (the company itself becomes a point of failure, what if they go out of business, or are acquired and change line of business?) I really wish the USPS would get into managing digital identity, or at the very least, attack the lowest of hanging fruits: assign everyone[1] an email address that won't suddenly be closed for ToS violation on a domain that won't expire in anyone's lifetime. Lost your password/authenticator? Walk into a post office with your government issued identity. Cleverer people than I am should be able to figure out how to create anonymous identities from your official one and have them linked unidirectionally, i.e. Alice can voluntarily prove she owns/created the Alana identity, but it's otherwise computationally impossible/expensive to do the reverse (unmask Alice from just the Alana pseudo ID) 0. Losing access to a mailbox means losing access to account recovery functionality, and mailbox takeovers result in TFA. 1. This is US-centric, but hopefully an international standard may be set, so that governments or delegated authorities are responsible for basic online identity; just like the way TLD's are managed