Comment by junon
3 months ago
Ignore anything coming from npm you didn't expect. Don't click links, go to the website directly and address it there. That's what I should have done, and didn't because I was in a rush.
Don't do security things when you're not fully awake, too. Lesson learned.
The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things coming from well-intentioned sites before. Since npm has historically been in contact about new security enhancements, this didn't smell particularly unbelievable to my nose.
The email went to the npm-specific inbox, which is another way I can verify them. That address can be queried publicly but I don't generally count on spammers to find that one but instead look at git addresses etc
The domain name was `npmjs dot help` which obviously should have caught my eye, and would have if I was a bit more awake.
The actual in-email link matched what I'd expect on npm's actual site, too.
I'm still trying to work out exactly how they got access. They didn't technically get a real 2FA code from the actual, I don't believe. EDIT: Yeah they did, nevermind. Was a TOTP proxy attack, or whatever you'd call it.
Will post a post-mortem when everything is said and done.
I see (I think): they tricked you into entering a TOTP code into their site, which they then proxied to the real names, thereby authenticating as your account. Is that correct?
It only proves that TOTP is useless against phishing.
Every day brings me another reason to ask the question: "Why the hell did they throw away the idea of mutual TLS?". They then went onto invent mobile OTP, HOTP, TOTP, FIDO-U2F and finally came a full cycle by reinventing the same concept, but in a more complex incarnation - Passkeys.
14 replies →
TOTP isnt designed to be against phishing. Its against weak, leaked or cracked passwords.
2 replies →
No. It only proves that TOTP, as implemented by mobile apps, is useless against phishing.
The extension from https://authenticator.cc, with smart domain match enabled, would have caught this by showing all other TOTP codes besides the one intended by NPM.
On a Mac, Keychain would also have caught this by not autofilling: https://support.apple.com/en-ph/guide/passwords/mchl873a6e72...
Yes. This attack would not have worked if FIDO2 (or the software emulation Passkey) had been used.
Seems so, yes.
Did they also phish the login password after clicking the link or did they already have it?
They phished username, password (unique to npm), and a TOTP code.
They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.
Damn, that's an impressively well-done attack. Curious, do you use a password manager? If so, did it not autofilling feel like a red flag to you?
I've always wondered if I ever get phished if I'll notice bc of that or if I'll just go "ugh 1password isn't working, guess i'll paste my password in manually" and end up pwned
2 replies →
> because I was in a rush
That's how they get you.
Using a security key as 2FA instead of TOTP would have prevented this attack, right?
If you maintain popular open source packages for the love of God get yourself a couple of security keys.
Well, that would also require all the services to support webauthn/FIDO, which a lot of them don't. Some who do support it only allow one key or trivial bypass via "security questions".
> The domain name was `npmjs dot help` which obviously should have caught my eye, and would have if I was a bit more awake.
It's a good thing the WebPKI cartel mostly did away with EV certs.... these days any old cert where only the SAN matches the domain and your browser gives a warm fuzzy "you're secure!"
The browsers mostly did away with EV certs[1], against sustained pushback from CAs, because of research invariably showing that the feeling of security is mostly unfounded. (Both because users are garbage at reading security indicators—and unscrupulous companies are eager to take advantage of that, see Cloudflare’s “security of your connection”—and because the legal-name namespace is much more Byzantine and locale-dependent than any layman can parse[2].)
By contrast, OV certs, which were originally supposed a very similar level of assurance, were did away with by CAs themselves, by cost-optimizing the verification requirements into virtual nonexistence.
That said, it remains a perpetual struggle to get people to understand the difference between being connected to the legitimate operator of satan.example (something an Internet-wide system mostly can guarantee) and it being wise to transact there (something extensive experience shows it can’t and shouldn’t try to). And if you’re a domain owner, your domain is your identity; pick one and stick to it. Stackoverflow.blog is stupid, don’t be like stackoverflow.blog.
[1] https://www.troyhunt.com/extended-validation-certificates-ar...
[2] https://arstechnica.com/information-technology/2017/12/nope-...
> That said, it remains a perpetual struggle to get people to understand the difference between being connected to the legitimate operator of satan.example
That's because the browser implementers gave up on trying to solve the identity problem. It's too difficult they said, we'd rather push other things.
Google implemented certificate pinning in Chrome for themselves and a few friends, said fuck everyone else, and declared the problem solved. Who cares about everyone else when your own properties are protected and you control the browser?
Meanwhile the average user has no idea what a certificate does, whether it does or doesn't prove identity.
No wonder they removed the lock icon from the browser.
1 reply →
People never paid attention to the special EV cert markers. And even if they did, what would stop someone from registering a company named "npm, Inc." and buying an EV cert for it? Sure, it’s going to cost some money upfront, but you can make much more by stealing cleptocurrency.