Re:Compromising Angular via expired NPM publisher email domains
by robbie-c on Sunday February 20, 2022 @11:28AM
(#30406881)
> 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.
Re:Compromising Angular via expired NPM publisher email domains
by codingkev on Sunday February 20, 2022 @05:13PM
(#30409753)
What do you suggest as an alternative to password reset based on the account email?
Re:Compromising Angular via expired NPM publisher email domains
by tedunangst on Sunday February 20, 2022 @05:17PM
(#30409782)
If you retired the email because the domain expired, maybe don't let it reset existing accounts. It's dead.
Re:Compromising Angular via expired NPM publisher email domains
by dane-pgp on Sunday February 20, 2022 @02:59PM
(#30408799)
I'm surprised Microsoft didn't categorise it as "Important, Spoofing".
https://github.com/oskarsve/ms-teams-rce/blob/main/README.md
Re:Compromising Angular via expired NPM publisher email domains
by lxe on Sunday February 20, 2022 @02:22PM
(#30408461)
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.
> 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?