Compromising Angular via expired NPM publisher email domains
thehackerblog.com
Compromising Angular via expired NPM publisher email domains
1–10 of 82 posts
Re: Compromising Angular via expired NPM publisher email domains
#2Is 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.
Re: Compromising Angular via expired NPM publisher email domains
#3Is 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.
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
Re: Compromising Angular via expired NPM publisher email domains
#4It'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.
Re: Compromising Angular via expired NPM publisher email domains
#5The 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/
Re: Compromising Angular via expired NPM publisher email domains
#6I have 2FA for my npm account, does 2FA prevent this kind of attack?
Re: Compromising Angular via expired NPM publisher email domains
#7I have 2FA for my npm account, does 2FA prevent this kind of attack?
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.
Re: Compromising Angular via expired NPM publisher email domains
#8It'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…
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.
Re: Compromising Angular via expired NPM publisher email domains
#9The 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…
leftpad != left-pad
Tom MacWright's email - https://registry.npmjs.org/leftpad/
Re: Compromising Angular via expired NPM publisher email domains
#10I have 2FA for my npm account, does 2FA prevent this kind of attack?
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.
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.