Posted by WhyNotHugo 4 days ago
- Update your 2FA credentials
What does that even mean? That's not something that can be updated - that's kind of the point of 2FA.
- It's been over 12 months since you last 2FA update
Again - meaningless nonsense. There's no such thing as a 2FA update. Maybe the recipient was thinking "password update" - but updating passwords regularly is also bad practice.
- "Kindly ask ..."
It would be very unusual to write like that in a formal security notification.
- "your credentials will be temporarily locked ..."
What does "temporarily locked" mean? That's not a thing. Also creating a sense of urgency is a classic phishing technique and a red flag.
- A link to change your credentials
A legit security email should never contains a link to change your credentials.
- It comes from a weird domain - .help
Any nonstandard domain is a red flag.
I don't use NPM, and if this actually looks like an email NPM would send, NPM has serious problems. However security ignorant companies do send emails like this. That's why the second layer of defense if you receive an email like this and think it might be real is to just log directly into (in this case) NPM and update your account settings without clicking links in the email.
NEVER EVER EVER click links in any kind of security alert email.
I don't blame the people who fell for this, but it is also concerning that there's such limited security awareness/training among people with publish access to such widely used packages.
> What does that even mean? That's not something that can be updated - that's kind of the point of 2FA.
I didn't sit and read and parse the whole thing. That was mistake one. I have stated elsewhere, I was stressed and in a rush, and was trying to knock things off my list.
Also, 2FA can of course be updated. npm has had some shifts in how it approaches security over the years, and having worked within that ecosystem for the better part of 10-15 years, this didn't strike me as particularly unheard of on their part. This, especially after the various acquisitions they've had.
It's no excuse, just a contributing factor.
> It would be very unusual to write like that in a formal security notification.
On the contrary, I'd say this is pretty par for the course in corpo-speak. When "kindly" is used incorrectly, that's when it's a red flag for me.
> What does "temporarily locked" mean? That's not a thing. Also creating a sense of urgency is a classic phishing technique and a red flag.
Yes, of course it is. I'm well aware of that. Again, this email reached me at the absolute worst time it could have and I made a very human error.
"Temporarily locked" surprises me that it surprises you. My account was, in fact, temporarily locked while I was trying to regain access to it. Even npm had to manually force a password reset from their end.
> Any nonstandard domain is a red flag.
When I contacted npm, support responded from githubsupport.com. When I pay my TV tax here in Germany (a governmental thing), it goes to a completely bizarre, random third party site that took me ages to vet.
There's no such thing as a "standard" domain anymore with gTLDs, and while I should have vetted this particular one, it didn't stand out as something impossible. In my head, it was their new help support site - just like github.community exists.
Again - and I guess I have to repeat this until I'm blue in the face - this is not an excuse. Just reasons that contributed to my mistake.
> NEVER EVER EVER click links in any kind of security alert email.
I'm aware. I've taught this as the typical security person at my respective companies. I've embodied it, followed it closely for years, etc. I slipped up, and I think I've been more than transparent about that fact.
I didn't ask for my packages to be downloaded 2.6 billion times per week when I wrote most of these 10 years ago or inherited them more than five ago. You can argue - rightfully - about my technical failure here of using an outdated form of 2FA. That's on me, and would have protected against this, but to say this doesn't happen to security-savvy individuals is the wrong message here (see: Troy Hunt getting phished).
Shit happens. It just happened to happen to me, and I happen to have undue control over some stuff that's found its way into most of the javascript world.
The security lessons and advice are all very sound - I'm glad people are talking about them - but the point I'm trying to make is, that I am a security aware/trained person, I am hyper-vigilant, and I am still a human that made a series of small or lazy mistakes that turned into one huge mistake.
Thank you for your input, however. I do appreciate that people continue to talk about the security of it all.
"This is a 10/10 phishing email."
It's not. But it doesn't mean I wouldn't also fall for it because I was tired/in a hurry or whatever else could let me drop my guard.
Humans are humans.
> However security ignorant companies do send emails like this
exactly
That's why you need vuln scanners and not upgrade to the latest thing as soon as released.
Let's say there's a company named Awesome...and i register the domain name of AwesomeSupport.com. I could be a total dark hat/evil hacker/neverdoweller....and this domain may not be infringing on any trademark, etc. And, then i can start using all the encryption you noted...which merely means that *my domain name* (the bad one) is "technically sound"...but of course, all that use of encryption fails to convey that i am not the legitimate Awesome company. So, how is the victim supposed to know which of the domains is legit or not? Especially considering that some departments of the real, legit Awesome company might register their own domain name to use for actual, real reasons - like the marketing department might register MyAwesome.com...for managing customer accounts, etc.
Is encryption necessary in digital life? Hellz yeah! Does it solve *all issues*? Hellz no! :-)
Thing is, where are the user's credentials stored. In a goverment's computer probably. Greece is taking some steps towards this [1].
A Greek citizen to obtain a digital signature, he has to go to a bank, the bank verifies him, he pays a fee and then the government can accept his digital signature. My guess is that the dictatorship banks established with the Covid excuse might start to bear some fruits finally.
But, people on the internet might want something more advanced, more secure than some COBOL computers storing their identity. Then we save digital certificates and digital identities on the blockchain, making essentially the blockchain the heart of the internet.
When a person from a company sends a message to a client, he can sign the message with his own identity and the identity of the company. Problem solved. No one get's confused when the cryptographic signatures are not verified. The message is invalid and it is redirected to the spam folder.
[1] https://www.gov.gr/en/ipiresies/polites-kai-kathemerinoteta/...
There aren't that many websites. The e-mail provider could have a list of "popular" domains, and the user could have their own list of trusted domains.
There is all sorts of ways to warn the user about it, e.g. "you have never interacted with this domain before." Even simply showing other e-mails from the same domain would be enough to prevent phishing in some cases.
There are practical ways to solve this problem. They aren't perfect but they are very feasible.
To your more recent points, i agree that there are other several protections in place...and depending on a number of facotrs, some foks have more at their disposal, and others might have less...but, still there are mechnisms in place to help - without a doubt. But yet with all these mechanisms in place, people still fall prey to phishing attacks...and sometimes those victims are not lay people, but actual technologists. So, i think the solution(s) to solve this are not so simple, and likely are not only tech-based. ;-)
Wouldn't help in this case where someone bought a domain that looked a tiny bit like the authentic one for a very casual observer.
With the way things are going, I can't tell at a glance whether they mean crypto, VR, or AI when they say "web 3."
Email is such an utter shitfest. Even tech-savvy people fall for phishing emails, what hope do normal people have.
I recommend people save URLs in their password managers, and get in the habit of auto-filling. That way, you’ll at least notice if you’re trying to log into a malicious site. Unfortunately, it’s not foolproof, because plenty of sites ask you to randomly sign into different URLs. Sigh…
The first article I ever read discussing the possibility of npm supply chain attacks actually used coloured text in terminal as the example package to poison. And ever since then I have always been associated coloured terminal in text with supply chain attack
The sense of urgency is always the red flag.
You should still never click a link in an email like this, but the urgency factor is well done here
but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2
ok, maybe there is some browser cache issue, whatever, so you trigger your password manager to provide your auth to the website -- but here, every single password manager would immediately notice that the domain in the browser does not match the domain associated with the auth creds, and either refuse to paste the creds thru, or at an absolute minimum throw up a big honkin' alert that something is amiss, which you'd need to explicitly click an "ignore" button to get past. red flag 3
nobody should be able to publish new versions of widely-used software without some kind of manual review/oversight in the first place, but even ignoring that, if someone does have that power, and they get pwned by an attack like this, with at least 3 clear red flags that they would need to have explicitly ignored/bypassed, then CLEARLY this person cannot keep their current position of authority
The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's.
> but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2
Why wouldn't I be? I don't stay logged into npm at all.
the from: address in every email is an arbitrary and unverified text string that the sender provides, anyone can send an email to anyone else and specify a from: president@whitehouse.gov and that's how it will show up to the recipient
what do you mean by the URL scheme? a URL scheme is the http or https part of it? and for sure the host part of the URL was not the same as the real npm's host part of their URL?
i'm not sure what this comment is trying to accomplish, it parses as FUD
DKIM et al came back clean.
As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1.
> As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1.
"scheme" is a well-defined domain term that refers to the e.g. `https://` part of a URL/URI -- but that aside, I still don't get what you're saying here? what is "format and layout of URLs" and how does that relate to "mitm attack"?
to cut to the chase, a malicious email maybe contains a link, to a URL, that a victim can click on. but if that link says it goes to `https://npm.org` then it actually does go to `https://npm.org` and there isn't like any special secret way for an email to hijack or mitm that domain or URL resolution. if the link is actually `https://npn.org` then that's a totally different thing, it's not a mitm attack, there is no concept of "format or layout" of that totally different URL "matching 1:1" with `https://npm.org` -- unless you're talking about something totally different to what I'm understanding?
edit: wait are we talking about an email sent from a domain `npmjs.help`? DKIM and DMARC and URL scheme validation don't even enter the picture here, this was no kind of mitm attack by any definition -- "npmjs.help" is clear-as-day a malicious domain, and any email from it a clear-as-day phishing attempt.. ! it's fine, we're all human and etc. but it just underscores the issue here being minimizing blast radius of failures, and not anything related to any specific user/human
1. My email client does the validation of certain integrity and security checks and shows a checkmark next to senders that pass. Since npmjs.help was a domain legitimately owned by the attackers, it passed.
2. The link in the email lead to their site at the same domain, most likely performing a MITM between my browser and npm's official servers.
3. You're arguing semantics about "scheme". Please try to understand what I'm attempting to convey: The URLs appeared to match the official npm's site. There was no <a href> trickery. Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.
4. Emails themselves are not MITM attacks, no. I didn't respond to an email with my credentials. I would never do that. But that isn't what I've ever claimed to have happened.
5. The URLs being similar or identical to npm's isn't how they technically achieved the MITM. The URLs being similar was to avoid arousing suspicion.
Hopefully that's explanatory enough.
The domain "npmjs.help" is pretty clearly malicious at a glance, just from the ".help" TLD alone, but yeah as you say
> Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.
well except that presumably you clicked on a npmjs.help link and the new tab ended up at npmjs.com? but yeah it's a tough break, don't mean to needle you, hopefully learning experience
It was obviously good enough.
Snark aside, you only need to trick one person once and you've won.