51–60 of 296 posts
So far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though. I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?
Probably the differentiating factor here is that the phishing message was very plausible. Normally they're full of spelling mistakes and unprofessional grammar. The domain was also plausible. I think where they got lucky is > In hindsight, the fact that his browser did not auto-complete the login should have been a red flag. A huge red flag. I wonder if browsers should actually detect if you're putting login details…
Is this related to npm debug and chalk packages being compromised? https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
Earlier quoted context omitted.
2FA for such high profile packages should be enforced
It is, if your packages are popular enough then npm will force you to enable 2FA. They started doing that a few years ago. It clearly doesn't stop everything though, the big attack yesterday went through 2FA by tricking the author into doing a "2FA reset".
Are they actively forcing it? I've received the "Remember to enable 2FA" email notifications from NPM since 2022 I think, but haven't bothered since I'm not longer publishing packages/updates.
Besides, the email conveniently mentions their "automation" tokens as well, which when used for publishing updates, bypasses 2FA fully.
So far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though. I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?
>> So far, it seems to be a bog-standard phishing email The fact this is NOT the standard phishing email shows how low the bar is: 1. the text of the email reads like one you'd get from npm in the tone, format and lack of obvious spelling & grammatical errors. It pushes you to move quicker than you might normally, without triggering the typical suspicions. 2. the landing domain and website copy seem really close to l…
Also, I really don't see what this has to do with gen AI, or what "democratizing the global phishing industry" is supposed to mean even.
Is this comment AI generated?
Earlier quoted context omitted.
It is, if your packages are popular enough then npm will force you to enable 2FA. They started doing that a few years ago. It clearly doesn't stop everything though, the big attack yesterday went through 2FA by tricking the author into doing a "2FA reset".
> It is, if your packages are popular enough then npm will force you to enable 2FA. Are they actively forcing it? I've received the "Remember to enable 2FA" email notifications from NPM since 2022 I think, but haven't bothered since I'm not longer publishing packages/updates. Besides, the email conveniently mentions their "automation" tokens as well, which when used for publishing updates, bypasses 2FA fully.
https://old.reddit.com/r/node/comments/xftu7i/comment/iooabn...
Is this related to npm debug and chalk packages being compromised? https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
Seems to have been targeted by the same phishing campaign.
Is it just me who think this could have been prevented if npm admins put in some sort of cool off period to only allow new versions or packages to be downloaded after being published by "x" amount of hours? This way the npm maintainer would get notifications on their email and react immediately? And if it is urgent fix, perhaps there can be a process to allow npm admin to approve and bypass publication cool off perio…
Earlier quoted context omitted.
I think you should unpublish rather than deprecate... `npm unpublish package@version` ... It's possible within 72h. One reason is that the patched version contains -alpha... so tools like npm-check-updates would keep the 1.3.3 as the latest release for those who installed it
Yes we tried, but npm would not let us because of "dependencies". We've reached out to them and are waiting for a response. In the meantime, we re-published the packages with newer versions so people won't accidentally install the compromised version.