16 ms·

We all dodged a bullet

• zamalek 1y ago
  WebAuthN/fido/passkey should be mandatory to publish a package with >N downloads. Email and TOTP codes can be MITMd.
• duxup 1y ago
  Is it possible to do the thing proposed in the email without clicking the link? I just try to avoid clicking links in emails generally...
  • loloquwowndueo 1y ago
    Should be - open another browser window and manually log into npm whatever, and update your 2fa there. Definitely good practice .
    • Dilettante_ 1y ago
      This is the Way. To minimize attack surface, the senders of authentic messages should straight-up avoid putting links to "do the thing" in the message. Just tell the user to update their credentials via the website.
      • viraptor 1y ago
        That's what the Australian Tax Office does. Just a plaintext message that's effectively "you've got a new message. Go to the website to read it."
        • amysox 1y ago
          My doctor's office does the same thing. So do some financial services companies.
        • duxup 1y ago
          All my medical places I use do that, with the note that you can also use their app. Good system.
          • foxglacier 1y ago
            Unfortunately, my doctor's office texts me their bank account number saying "please pay $75 to this account". It told them that's putting people at risk of phishing but they didn't care.
          • darthwalsh 1y ago
            Personally, I'd rather they put the HIPAA message content straight into the email, and let Gmail sort out the priority. About 90% "you have received a message" notifications are not actionable: "you made an appointment" or "take this survey nobody cares about."
      • Roguelazer 1y ago
        For most users, that'll just result in them going to Google, searching for the name of your business, and then clicking the first link blindly. At that point you're trusting that there's no malicious actors squatting on your business name's keyword -- and if you're at all an interesting target, there's definitely malvertising targeting you. The only real solution is to have domain-bound identities like passkeys.
    • hu3 1y ago
      That's what I always do. Never click these kinds of links in e-mail. Always manually open the website. This week Oracle Cloud started enforcing 2FA. And surely I didn't click their e-mail link to do that.
    • ares623 1y ago
      But won’t someone think of the friction? /s My theory is that if that companies start using that workflow in the future, it’ll become even _easier_ for users to click a random link, because they’d go “wow! That’s so convenient now!”
  • JohnFen 1y ago
    > I just try to avoid clicking links in emails generally... I don't just generally try, I _never_ click links in emails from companies, period. It's too dangerous and not actually necessary. If a friend sends me a link, I'll confirm it with them directly before using it.
  • 0cf8612b2e1e 1y ago
    The Microsoft ecosystem certainly makes this challenging. At work, I get links to Sharepoint hosted things with infinitely long hexadecimal addresses. Otherwise finding resources on Sharepoint is impossible.
• ChrisArchitect 1y ago
  Related: NPM debug and chalk packages compromised https://news.ycombinator.com/item?id=45169657 https://news.ycombinator.com/item?id=45169657
• dsff3f3f3f 1y ago
  > These kinds of dependencies are everywhere and nobody would even think that they could be harmful. Tons of people think these kind of micro dependencies are harmful and many of them have been saying it for years.
  • anonzzzies 1y ago
    Yes. It is a bit painful this is not rather obvious by now. But I do have, every code review, whine about people who just include trivial outdated one function npms :(
  • SebastianKra 1y ago
    Yeah, there's an entire community dedicated to cleaning up the js ecosystem. https://e18e.dev/ https://e18e.dev/ Micro-dependencies are not the only thing that went wrong here, but hopefully this is a wakeup call to do some cleaning.
    • skydhash 1y ago
      Discord server? Is it that much work to create a forum or a mailing list with anonymous access. Especially with a community you can vet that easily?
  • balder1991 1y ago
    Working for a bank did make me think much more about all the vulnerabilities that can go into certain tools. The company has a lot of bureaucracy to prevent installing anything or adding external dependencies.
    • benoau 1y ago
      Working for a fintech and being responsible for the software made me very wary of dependencies and weeding out the deprecated and EOL'd stuff that had somehow already found its way into what was a young project when I joined. Left unrestrained, developers will add anything if it resolves their immediate needs like you could probably spread malware very well just by writing a fake-blog advocating a malicious module to solve certain scenarios.
• ivape 1y ago
  Dat domain name. Yeah, stop those cute domain names. I never got the memo on Youtu.be, I just had “learn” it was okay. Of course people started to let their guard down because dumbasses started to get cute. We all did dodge a bullet because we’ve been installing stuff from NPM with reckless abandon for awhile. Can anyone give me a reason why this wouldn’t happen in other ecosystems like Python, because I really don’t feel comfortable if I’m scared to download the most basic of packages. Everything is trust.
  • 1-more 1y ago
    of all people my mortgage servicer is the worst about this. Your login is valid on like 3 different top level domains and you get bounced between them when you sign in, eventually going from servicer.com to myservicer.com to servicer.otherthing.com! It's as though they were training you to not care about domain names.
    • wzamqo 1y ago
      Paying US taxes online is just as bad. The official way to pay tax balances with a debit card online is to use officialpayments[.]com. This is what the IRS advises you to use. Our industry is a clown factory.
      • LorenDB 1y ago
        Wells Fargo apparently emails from epay@onlinemyaccounts[.]com.
  • deleted 1y ago
    [deleted]
  • jvdvegt 1y ago
    What about aka.ms, which is a valid domain for Microsoft. Why didn't they use microsoft.com, or windows.com? I always wonder if this aka is short for 'also known as'.
    • 1y ago
• Mystery-Machine 1y ago
  Always use password manager to automatically fill in your credentials. If password manager doesn't find your credentials, check the domain. On top of that, you can always go directly to the website, to make any needed changes there, without following the link.
  • fragmede 1y ago
    what do you mean bankofamericaabuse.com isn't a real website!? It's in the email and everything! The nice guy on the phone said it was legit...
  • teekert 1y ago
    Better yet, use password manager as the store of the valid domain and click there to go to resource.
  • Analemma_ 1y ago
    I don't think this really helps. I use Bitwarden and it constantly fails to autofill legitimate websites and makes me go to the app to copy-paste, because companies do all kinds of crap with subdomains, marketing domains, etc. Any safeguard relying on human attention is ultimately susceptible to this; the only true solutions are things like passkeys where human fuckups are impossible by design and they can't give credentials to the wrong place even if they want to. Passkeys are disruptive enough that I don't think they need to be mandated for everyone just yet, but I think it might be time for that for people who own critical dependencies.
    • teekert 1y ago
      It's a pita but BitWarden has quite some flexibility in filtering where what gets autofilled. I agree the defaults are pretty shit and indeed lead to constant copy-pasting. On the other hand, it will offer all my password all the time for all my selfhosted stuff on my 1 server.
  • dewey 1y ago
    Password managers are still too unreliable to auto-fill everywhere all the time, and manually having to copy paste something from the password manager happens regularly so it's not something that feels unusual if it doesn't auto-fill it for some reason.
• deleted 1y ago
  [deleted]
• Havoc 1y ago
  Really feels like these big open packages repos need a better security solution. Or at least a core subset of carefully vetted ones. Same issue with python, rust etc. It’s all very trust driven
  • lpln3452 1y ago
    In a case like this, the package maintainer's account itself has been hacked, so I'm not sure if that would be meaningful. The only solution would be to prevent all releases from being applied immediately.
    • dherls 1y ago
      A solution could be enforcing hardware keys for 2FA for all maintainers if a package has more than XX thousand weekly downloads. No hardware keys, no new releases.
      • ozim 1y ago
        Passkeys - no need for hardware key. They have it implemented. I created NPM account today and added passkey from my laptop and hardware key as secondary. As I have it configured it asked my for it while publishing my test package. So the guy either had TOTP or just the pw. Seems like should be easy to implement enforcement.
      • winkelmann 1y ago
        Crucially, it would have to be set up so they need to use the hardware key when pushing any changes. Just requiring a hardware key as a login method does nothing to protect against token stealing, which I believe is the most common form of supply chain attack right now.
    • dsff3f3f3f 1y ago
      There needs to be a massive push from the larger important packages to eliminate these idiotic transitive dependencies. Core infrastructure shouldn't rely on trivial packages maintained by a single random person from who knows where that can push updates without review. It's absolutely insane.
• _fat_santa 1y ago
  I know this isn't really possible for smaller guys but larger players (like NPM) really should buy up all the TLD versions of "npm" (that is: npm.io, npm.sh, npm.help, etc). One of the reasons this was so effective is that the attacker managed to snap up "npm.help"
  • VectorLock 1y ago
    There's like 1500 TLDs, now some of them are restricted and country-code TLDs but now it makes me wonder how much it would actual cost per year to maintain registration of every non-restricted TLD. I'm sure theres some SaaS company that'll do it.
    • saghm 1y ago
      OTOH, doesn't ICANN already sometimes restrict who has access to a given TLD? Would it really be that crazy for them to say "maybe we shouldn't let registrars sell npm.<TLD> regardless of the TLD", and likewise for a couple dozen of the most obvious targets (google., amazon., etc.)? No one needs to pay for these domains if no one is selling them in the first place. I don't love the idea of special treatment for giant companies in terms of domains, but we're already kind of there with the whole process they did when initially allowing companies to compete for exclusive access to TLDs, so we might as well use that process for something actually useful (unlike, say, letting companies apply for exclusive ownership of ".music" and have a whole legal process to determine that maybe that isn't actually beneficial for the internet as whole: https://en.wikipedia.org/wiki/.music https://en.wikipedia.org/wiki/.music)
      • VectorLock 1y ago
        The TLDs run the whole gamut from completely open to almost impossible to get.
      • ohdeargodno 1y ago
        >maybe we shouldn't let registrars sell npm.<TLD> regardless of the TLD Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? Nope, tough luck, some random dude pushes shitty javascript packages over there. Sorry for the existing npm.org address too, we're going to expropriate the National Association of Pastoral Musicians. Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ? At least they're paying dozens of millions to buy a shitty ass .google that noone cares about because more and more browsers are hiding the URL bar. I'm glad ICANN can use it to buy drinks, hookers instead of being useful.
• SirFatty 1y ago
  It's typical phishing email... and if the author when though any type of cybersecurity training, they would see that the email wasn't that great. The sense of urgency is always the red flag.
  • zaphar 1y ago
    I go through those trainings several times a year. That email is as close to perfect for a phishing email as I've ever seen.
    • deleted 1y ago
      [deleted]
    • kiitos 1y ago
      the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 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
      • junon 1y ago
        > the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 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.
• scotty79 1y ago
  Is there a tool that you can put between your npm client and npm web servers that serves package versions that are month old and possibly also tracks discovered malware and never serves infected versions?
  • balder1991 1y ago
    Something like this? https://jfrog.com/artifactory/ https://jfrog.com/artifactory/
  • JackFr 1y ago
    Artifactory. Nexus. I believe AWS/GCP/Azure have offerings. No bank, and almost no large corporations go directly to artifact/package repos. They all host them internally.
    • darthwalsh 1y ago
      Yes, but the public npmjs repository also blocks our corporate IP addresses, so our CI/CD pipelines can't ruin npm for everybody else.
  • singulasar 1y ago
    the company that first found this vulnerability also has a tool for this https://www.npmjs.com/package/@aikidosec/safe-chain https://www.npmjs.com/package/@aikidosec/safe-chain
  • lovehashbrowns 1y ago
    I'm looking at Verdaccio currently, since Artifactory is expensive and I think the CE version still only supports C++. Does anyone have any experience with Verdaccio?
  • mikebelanger 1y ago
    Artifactory works fairly well. Although admittedly, when a user grabs a new dependency, they're downloading from the npmjs registry like anyone else. Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.
• mikewarot 1y ago
  >Saved by procrastination! Seriously, this is one of my key survival mechanisms. By the time I became system administrator for a small services company, I had learned to let other people beta test things. We ran Microsoft Office 2000 for 12 years, and saved soooo many upgrade headaches. We had a decade without the need to retrain. That, and like other have said... never clicking links in emails.
  • blamestross 1y ago
    "Just wait 2 weeks to use new versions by default" is an amazing defense method against supply chain attacks.
    • kevinrineer 1y ago
      Its also really ineffective defense against 0 days!
      • blamestross 1y ago
        Sadly we don't have any defense against 0 days if an emergency patch is indistinguishable from an attack itself. Better defense would be to delete or quarantine the compromised versions, fail to build and escalate to a human for zero-day defense.
        • minitech 1y ago
          > Sadly we don't have any defense against 0 days if an emergency patch is indistinguishable from an attack itself. Reading the code content of emergency patches should be part of the job. Of course, with better code trust tools (there seem to have been some attempts at that lately, not sure where they’re at), we can delegate that and still do much better than the current state of things.
      • ozim 1y ago
        IF I put my risk management hat on - 0 days in npm ecosystem are not that much of a problem. They stop working before can use them.
• anon7000 1y ago
  The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated. This happened even if you had pinned dependencies and were on top of security updates. We need some deeper changes in the ecosystem. https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7...
  • captn3m0 1y ago
    Yeah, Editor extensions are both auto-updated and installed in high risk dev environments. Quite a juicy target and I am surprised we haven’t seen large scale purchases by bad actors similar to browser extensions yet. However, I remember reading that the VsCode team puts a lot of effort in catching malware. But do all editors (with auto-updates) such as Sublime have such checks?
  • zenmac 1y ago
    I usually make sure all the packages and db are local, so my dev machine can run in Airplane mode. And only turn on internet when use git push
    • pmontra 1y ago
      All docs are local too, like we used to do with man pages and paper reference books or do you use another system for them? A second computer, a tablet, a phone?
  • deleted 1y ago
    [deleted]
  • kardianos 1y ago
    > We need some deeper changes in the ecosystem. I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason. As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage. NPM will often have different source then the github repo source. How does anyone even trust the system?
• cataflam 1y ago
  Besides the ecosystem issues, for the phishing part, I'll repost what I responded somewhere in the other related post, for awareness --- I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA: TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough. I don't understand how most of the anti-phishing advice focuses on that, it's useless to borderline counter-productive. What really helps against phishing : 1. NEVER EVER login from an email link. EVER. There are enough legit and phishing emails asking you to do this that it's basically impossible to tell one from the other. The only way to win is to not try. 2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not. That is all there is. Any other method, any other "indicator" helps but is error-prone, which means someone somewhere will get phished eventually. Particularly if stressed, tired, or in a hurry. It just happened to be you this time.
  • progval 1y ago
    > 2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not. TOTP doesn't need to be phishing-proof if you use a password manager integrated with the browser, though.
    • shhsshs 1y ago
      I think it's more appropriate to say TOTP /is (nearly)/ phishing-proof if you use a password manager integrated with the browser (not that it /doesn't need to be/ phishing-proof)
    • ameliaquining 1y ago
      A browser-integrated password manager is only phishing-proof if it's 100% reliable. If it ever fails to detect a credential field, it trains users that they sometimes need to work around this problem by copy-pasting the credential from the password manager UI, and then phishers can exploit that. AFAIK all existing password manager extensions have this problem, as do all browsers' native password-management features.
• leoc 1y ago
  > Even then, that wouldn't really stand out to me because I've seen companies use new generic top level domains to separate out things like the blog at .blog or the docs at .guide, not to mention the .new stack. This is very much a 'can we please not' situation, isn't it? (Obviously it's not something that the email recipients can (usually) control, so it's not a criticism of them.) It also has to meaningfully increase the chance that someone will eventually forget to renew a domain, too.
  • NoahZuniga 1y ago
    Facebook sends legit account secuirty emails from facebookmail.com. Horrible.
    • leoc 1y ago
      For a company that is otherwise quite serious about security nowadays, MS seems to be the champion of this. Say hello to live.com and its friends …
  • junon 1y ago
    Anecdotally throughout all this, contacting npm got me a response from githubsupport.com. I had to double check if that was even real.
• PaulHoule 1y ago
  This has so many dimensions. An authentication environment which has gotten so complex we expect to be harassed by messages say "your Plex password might be compromised", "your 2FA is all fucked up", etc. And the crypto thing. Xe's sanguine about the impact, I mean, it just the web3 degens [1] that are victimized, good innocent decent people like us aren't hurt. From the viewpoint of the attacker it is all about the Benjamins and the question is: "does an attack like this make enough money to justify the effort?" If the answer is yes than we'll see more attacks like this. There are just all of these things that contribute to the bad environment: the urgent emails from services you barely use, the web3 degens, etc. [1] if it's an insult it is one the web3 community slings https://www.webopedia.com/crypto/learn/degen-meaning/ https://www.webopedia.com/crypto/learn/degen-meaning/
• sebstefan 1y ago
  Dodged a bullet indeed I find it insane that someone would get access to a package like this, then just push a shitty crypto stealer. You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit? You can exfiltrate API keys, add your SSH public key to the server then exfiltrate the server's IP address so you can snoop in there manually, if you're on a dev's machine maybe the browser's profiles, the session tokens common sales websites? My personal desktop has all my cards saved on Amazon. My work laptop, depending on the period of my life, you could have had access to stuff you wouldn't believe either. You don't even need to do anything with those, there's forums to sell that stuff. Surely there's an explanation, or is it that all the good cybercriminals have stable high paying jobs in tech, and this is what's left for us?
  • com2kid 1y ago
    > You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit? Because the way this was pulled off, it was going to be found out right away. It wasn't a subtle insertion, it was a complete account take over. The attacker had only hours before discovery - so the logical thing to do is a hit and run. They asked what is the most money that can be extracted in just a few hours in an automated fashion (no time to investigate targets manually one at a time) and crypto is the obvious answer. Unless the back doors were so good they weren't going to be discovered even though half the world would be dissecting the attack code, there was no point in even trying.
    • pluto_modadic 1y ago
      "found out right away"... by people with time to review security bulletins. There's loads of places I could see this slipping through the cracks for months.
      • zahlman 1y ago
        Yes, but this is an ecosystem large enough to include people who have that time (and inclination and ability); and once they have reported a problem, everyone is on high alert.
• tomasphan 1y ago
  The problem here is that a single dev account can make updates to a prod codebase, or in the case of NX a single CI/CD token. Something with 5 Million downloads per week should not be controlled by one token if it takes me 3 approvals to get my $20 lunch reimbursement. At the very least have an LLM review every PR to prod.
• ChuckMcM 1y ago
  Agree with most that this could have been way way worse. No doubt next time it will be. I keep expecting some new company to bring out this revolutionary idea of "On prem: your machine, your libraries, your business."
• torium 1y ago
  [flagged]
  • dang 1y ago
    Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
• empathy_m 1y ago
  How much money did the attackers make?
  • gazaim 1y ago
    5 cents of eth and $20 of a meme coin.
  • zahlman 1y ago
    According to a crypto tracking site linked indirectly via the other popular submission, about $500 worth of crypto.
  • ruuda 1y ago
    I'm not sure whether the compromised packages were the source of Kiln's API compromise, but it's plausible. It lead to theft of $41M worth of SOL. https://cointelegraph.com/news/swissborg-hacked-41m-sol-api-compromise https://cointelegraph.com/news/swissborg-hacked-41m-sol-api-...
    • junon 1y ago
      These were different. The vulnerable packages wouldn't have caused an API exploit vector except in the most bizarre of edge cases I suppose.
• nottorp 1y ago
  > With that in mind, at a glance the idea of changing your two-factor auth credentials "for security reasons" isn't completely unreasonable. No? How do you change your 2FA? Buy a new phone? A new Yubikey?
  • croemer 1y ago
    For TOTP it's as simple as scanning a new QR code. I agree that rotating 2FA should ring alarm bells as an unusual request. But that requires thinking.
• mrbluecoat 1y ago
  Does the Go ecosystem have a similar security screening process as NPM? This was caught because a company was monitoring a centralized packaging distribution platform, but I worry about all those golang modules spread across GitHub without oversight..
  • quectophoton 1y ago
    This page has a short explanation of the default way in which Go downloads modules, with links for more details: https://sum.golang.org/ https://sum.golang.org/
    • mrbluecoat 1y ago
      Thanks. It took a little more digging from that link but I eventually found https://go.dev/doc/security/vuln/#vulnerability-detection-for-go https://go.dev/doc/security/vuln/#vulnerability-detection-fo...
      • quectophoton 1y ago
        Right, my bad, seems like I misunderstood the question. Glad you could still find an answer. For more context on why I thought that link would have been helpful: In Go you download dependencies "straight" from the source[1], while in npm and other languages you download dependencies from a completely unrelated registry that can have any random code (i.e. whether the published artifact was built from the alleged source repository, is a flip of a coin). So not having this kind of third party registry eliminates the point of failure that caused the issue commented in the article. The issue was caught because of a centralized place, yes, but it was also caused because npm dependencies are downloaded from a centralized place and because this centralized place only hosts artifacts unrelated to the source code itself; package authors can `npm publish` artifacts containing the exact source code from their repos if they want though. If. With Go, having a mirror of the source code is still third party infra, but is more an optimization than anything else, and checksums are generated based on the source itself[2] (rather than any unrelated artifact). This checksum should match even for people not using any proxy, so if you serve different code to someone, there will be a mismatch between the checksum of the downloaded module and the checksum from the SumDB. This should catch force-pushes done to a git repository version tag, for example. Also, Go downloads the minimum version that satisfies packages, so it's less likely that you'll download a (semver) "patch" release that someone pushed hours ago. All this makes me both like and dislike how Go handles dependencies. [1]: Well, from a mirror, unless you set `GOPROXY=direct`. Reasoning explained in next paragraph. [2]: The checksum is calculated from a zip file, but it is generated in a deterministic way, and this checksum is also generated and validated locally when you download dependencies. More info at https://go.dev/ref/mod#zip-files https://go.dev/ref/mod#zip-files and https://go.dev/ref/mod#go-mod-verify https://go.dev/ref/mod#go-mod-verify
• lysace 1y ago
  This reads like a joke that's missing the punchline. The post's author's resume section reinforces this feeling: I am a skilled force multiplier, acclaimed speaker, artist, and prolific blogger. My writing is widely viewed across 15 time zones and is one of the most viewed software blogs in the world. I specialize in helping people realize their latent abilities and help to unblock them when they get stuck. This creates unique value streams and lets me bring others up to my level to help create more senior engineers. I am looking for roles that allow me to build upon existing company cultures and transmute them into new and innovative ways of talking about a product I believe in. I am prioritizing remote work at companies that align with my values of transparency, honesty, equity, and equality. If you want someone that is dedicated to their craft, a fearless innovator and a genuine force multiplier, please look no further. I'm more than willing to hear you out.
  • gertop 1y ago
    That kind of fake self-aggrandizement-delusion-driven story telling is part of the autistic trans subculture. That particular subculture tends to speak of themselves as goddesses, wizards, or other higher beings. Their websites are usually dark themed with pastel or neon forecolors and you'll find anime girls inserted every now and then . As far as I can tell it isn't a joke per se, but it is tongue-in-cheek and the ego is often very real.
• AlienRobot 1y ago
  Isn't it a bit crazy that phishing e-mails still exist? Like, couldn't this be solved by encrypting something in a header and using a public key in the DNS to unencrypt it?
  • 1970-01-01 1y ago
    100% solved and has been for a very long time. The PGP/GPG trust chain goes CLUNK CLUNK CLUNK. Everyone shuts it off after a week or so of experimentation.
  • procaryote 1y ago
    I might be missing the joke, but there are several layers like SPF and DMARC available to only allow your whitelisted servers to send email on the behalf of your domain. 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.
  • mxuribe 1y ago
    I'm not a top-level expert in cybersecurity nor email infra....but the little that i know has taught me that i merely have to create a similar-looking domain name... 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! :-)
    • AlienRobot 1y ago
      This honestly doesn't feel like it should be the case. 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.
• thefifthsetpin 1y ago
  Allowing just anybody to rent npmjs.help feels like aiding and abetting.
  • ameliaquining 1y ago
    Who should have stopped this from happening and how should they have gone about doing so?
• sega_sai 1y ago
  It seems to me that having an email client that simply disables all the links in the email is probably a good idea. Or maybe, there should be explicit white-listing of domains that are allowed to be hyperlinks.
  • 2OEH8eoCRo0 1y ago
    I've always thought it's insane that anyone on the planet with a connection can drop a clickable link in front of you. Clickable links in email should be considered harmful. Force the user to copy/paste URLs are also getting too damn long
    • falcor84 1y ago
      How would copy-pasting help in this scenario?
  • SahAssar 1y ago
    And who would control that whitelist? How would it be any different than the domain system or PKI CA system we have now? Do you think there would be the time to properly review applications to get on the whitelist?
    • toast0 1y ago
      In a world where those sending email were consistent, the user could control the whitelist. 'This link is from a domain you've clicked through X times, do you want to click through? Yes / Yes and don't ask again' If it's new, you should be more cautious. Except even those companies that should know better need you to link through 7 levels of redirect tracking, and they're always using a new one.
    • sega_sai 1y ago
      A user for example. By default nothing would be in the whitelist. Then you would add things to the whitelist manually. Since it's not that frequent this needs to be done, that probably would be a useful extra step to stop phishing.
    • 1y ago
• dang 1y ago
  In case you missed it: NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 https://news.ycombinator.com/item?id=45169657 - Sept 2025 (697 comments, including exemplary comments from the project maintainer)
• binarymax 1y ago
  There's only one thing that would throw me off this email and that is DMARC. But I didn't get the email, so who is to say if I actually would have been caught.
  • vel0city 1y ago
    This was a domain "legitimately" owned by the adversary. They controlled that DNS. They could set any SPF or DKIM records they wanted. This email probably passed all DMARC checks. From some screenshots, the email client even has a green check probably because it did pass DMARC.
  • junon 1y ago
    Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=smtp.mailtrap.live header.s=rwmt1 header.b=Wrv0sR0r; dkim=pass header.d=npmjs.help header.s=rwmt1 header.b=opuoQW+P; spf=pass (aspmx1.migadu.com: domain of ndr-cbbfcb00-8c4d-11f0-0040-f184d6629049@mt86.npmjs.help designates 45.158.83.7 as permitted sender) smtp.mailfrom=ndr-cbbfcb00-8c4d-11f0-0040-f184d6629049@mt86.npmjs.help; dmarc=pass (policy=none) header.from=npmjs.help
• fiatpandas 1y ago
  His email client even puts a green check mark next to the fake NPM email. UX fail.
  • yencabulator 1y ago
    The claim is valid -- it is legit from npm.help If you think npm.help is something it isn't, that's not something DKIM et al can help with.
    • kccqzy 1y ago
      Do you remember a few years ago that browsers used to put a lock icon for all HTTPS connections? That lock icon signified that the connection is encrypted alright. To a tech geek that's a valid use of a lock icon. But browsers still removed it because it's a massive UX fail. You have to consider what the lock icon means to people who are minimally tech literate. I understand and have set up DKIM and SPF, but you cannot condense the intended security feature of DKIM/SPF/DMARC into a single icon and expect that to be good UX.
      • yencabulator 1y ago
        Browsers moved away from the https lock icon after https become very very common. Email hasn't reached a comparable state.
        • kccqzy 1y ago
          We are talking about a UX failure regarding what a lock icon or a checkmark icon represents. Popularity is irrelevant. It's entirely about the disconnect between what tech geeks think a lock/checkmark icon represents and normal users think it represents.
          • yencabulator 1y ago
            Instead of ranting, can you say something constructive? I can think of 3 paths to improve situation (assuming that "everyone deploys cryptographic email infrastructure instantly" is not gonna happen). 1. The email client doesn't indicate DKIM at all. This is strictly worse than today, because then the attack could have claimed to be from npmjs.com. 2. You only get a checkmark if you have DKIM et al plus you're a "verified domain". This means only big corporations get the checkmark -- I hate this option. It's EV SSL but even worse. And again, unless npmjs.com was a "big corporation" the attacker could have just faked the sender and the user would not notice anything different, since in that world the authentic npmjs.com emails wouldn't have a checkmark either. 3. The checkmark icon is changed into something else, nothing else happens. But what? "DKIM" isn't the full picture (and would be horribly confusing too). Putting a sunflower there seems a little weird. Do you really apply this much significance to the specific icon? The path that HTTPS took just hasn't been repeatable in the email space; the upgrade cycles are much slower, the basic architecture is client->server->server not client->server, and so on.
• bob1029 1y ago
  "Batteries included" ecosystems are the ultimate defense against the dark arts. Your F100 first party vendor might get it wrong every now and then, but they have so much more to lose than a random 3rd party asshole who decides to deploy malicious packages. The worst thing I can recall from the enterprisey ecosystems is the log4j exploit, which was easily one of the most attended to security problems I am aware of. Every single beacon was lit for that one. It seems like when an NPM package goes bad, it can take a really long time before someone starts to smell it.
  • dghlsakjg 1y ago
    Solarwinds?
  • ameliaquining 1y ago
    Log4Shell didn't light up all the beacons because Java is "enterprisey", it was because it was probably the worst security vulnerability in history; not only was the package extremely widely used, the vulnerability existed for nearly a decade and was straightforwardly wormable, so basically everybody running Java code anywhere had to make sure to update and check that they hadn't been compromised. Which is just a big project requiring an all-out response, since it's hard to know where you might have something running. By contrast, this set of backdoors only existed for a few hours, and the scope of the vulnerability is well-understood, so most developers can be pretty sure they weren't impacted and will have quite reasonably forgotten about it by next week. It's getting attention because it's a cautionary tale, not because it's causing a substantial amount of real damage. I do think it's worth reducing the number of points of failure in an ecosystem, but relying entirely on a single library that's at risk of stagnating due to eternal backcompat obligations is not the way; see the standard complaints about Python's "dead batteries". The Debian or Stackage model seems like it could be a good one to follow, assuming the existence of funding to do it.
  • SahAssar 1y ago
    Heartbleed? Solarwinds? Spectre/Meltdown? Stuxnet? Eternal Blue? CVE-2008-0166 (debian predictable private keys)?
  • brushfoot 1y ago
• stevoski 1y ago
  “We all dodged a massive bullet” I don’t think we did. I think it is entirely plausible that more sophisticated attacks ARE getting into the npm ecosystem.
• padjo 1y ago
  “A utility function that determines if its argument can be used like an array” I see the JavaScript ecosystem hasn’t changed since leftpad then.
  • dmitrygr 1y ago
    My man, it has...in the worse direction...
• HL33tibCe7 1y ago
  Most phishing emails are so bad, it’s quite terrifying when you see a convincing one like this. 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…
• darepublic 1y ago
  > Formatting text with colors for use in the terminal ... > These kinds of dependencies are everywhere and nobody would even think that they could be harmful. 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
  • michaelti 1y ago
    I used to share this article with students https://david-gilbertson.medium.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://david-gilbertson.medium.com/im-harvesting-credit-car...
• jacobsenscott 1y ago
  This phishing email is full of red flags. Here are example red flags from that email: - 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.
  • yieldcrv 1y ago
    full of red flags present in many non phishing emails > However security ignorant companies do send emails like this exactly
  • junon 1y ago
    Hi, said person who clicked on the link here. Been wanting to post something akin to this and was going to save it for the post mortem but I wanted to address the increase in these sort of very shout-ey comments directed toward me. > 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.
• pcthrowaway 1y ago
  Is this not a good use case for AI in your email client (local-only to avoid more opportunities for data to leak)? Have the client-embedded AI view the email to determine if it contains a link to a purported service. Remotely verify if the service URL domain is valid, by comparing to the domains known for that service If unknown, show the user a suspected phishing message. This will occasionally give a false positive when a service changes their sending domain, but the remote domain<->service database can then be updated via an API call as a new `(domain, service)` pair for investigation and possible inclusion. I feel like this would mitigate much of the risk of phishing emails slipping past defenses, and mainly just needs 2 or 3 API calls to service once the LLM has extracted the service name from the email.
  • mwkaufma 1y ago
    No, the solution to a security problem is not to radically increase the vulnerable attack surface.
• 1970-01-01 1y ago
  At this super-wide level of near-miss, you must assume Jia Tan 3.0 will be coming for your supply chains.
• dirkc 1y ago
  I had a minor scare some time ago with npm. Can't remember the exact details, something like I had a broken symlink in my homedir and nodemon printed an error about the symlink! My first thought was it's a supply chain attack looking for credentials! Since then I've done all my dev in an isolated environment like a docker container. I know it's possible to escape the container, but at least that raises the bar to a level I'm comfortable with.
• mlinksva 1y ago
  As the post mentions wallets like MetaMask being the targets, AFAIK MetaMask in particular might be one of the best protected (isolated) applications from this kind of attack due to their use of LavaMoat https://x.com/MetaMask/status/1965147403713196304 https://x.com/MetaMask/status/1965147403713196304 -- though I'd love to read a detailed analysis of whether they actually are protected. No affiliation with MetaMask, just curious about effectiveness of seemingly little adopted measures (relative to scariness of attacks). Added: story dedicated to this topic more or less https://news.ycombinator.com/item?id=45179889 https://news.ycombinator.com/item?id=45179889
  • 1oooqooq 1y ago
    all that is inside the extension. meaningless if the extension got the changed address.
• karel-3d 1y ago
  "there is no way to prevent this", says the only ecosystem where this regularly happens
  • dzogchen 1y ago
    Exactly! Extremely lazy conclusion.
• zaik 1y ago
  We need a permission system for packages just like with Android apps. The text coloring package suddenly needs a file access permission for the new version? Seems strange.
  • danenania 1y ago
    Deno has taken steps in this direction. It’s probably doable for pure js packages, but nearly impossible for packages with native extensions.
• lxe 1y ago
  Gmail could have easily placed a red banner like > "Warning! This is the first time you have received a message from sender support@npmjs.help. Please be careful with links and attachments, and verify the sender's identity before taking any action."
• deleted 1y ago
  [deleted]
• mayhemducks 1y ago
  `Object.getPrototypeOf(obj)[Symbol.iterator] !== undefined` There I fixed it. Now I don't even need the package array-ish!
  • junon 1y ago
    `Symbol` wasn't supported when I wrote `is-arrayish`. Neither were spreads. It was meant to be used with DOM lists or the magical `arguments` variable.
• Zak 1y ago
  > If you were targeted with such a phishing attack, you'd fall for it too and it's a matter of when not if. Anyone who claims they wouldn't is wrong. I like to think I wouldn't. I don't put credentials into links from emails that I didn't trigger right then (e.g. password reset emails). That's a security skill everyone should be practicing in 2025.
  • gcau 1y ago
    "'such' a phishing attack" makes it sound like a sophisticated, indepth attack, when in reality it's a developer yet again falling for a phishing email that even Sally from finance wouldn't fall for, and although anyone can make mistakes, there is such a thing as negligent, amateur mistakes. It's astonishing to me.
    • greycol 1y ago
      Every time I bite my tongue (literal not figurative) it's also astonishing to me. Last time I did was probably 3 years ago and it was probably 10 years earlier for the time before that. Would it be fair to call me a negligent eater? Have you been walking and tripped over nothing? Humans are fallible and unless you are in an environment where the productivity loss of a rigorous checklist and routine system makes sense these mistakes happen. It would be just as easy to argue that anyone who uses software and hasn't confirmed their security certifications include whatever processes you imagine avoids 'human makes 1 mistake and continues with normal workflow' error or holds updates until evaluated is negligent.
      • gcau 1y ago
        Humans are imperfect and anyone can make mistakes, yes. I would argue there's different categories of mistakes though, in terms of potential outcomes and how preventable they are. A maintainer with potentially millions of users falling for a simple phishing email is both preventable and has a very bad potential outcome. I think all parties involved could have done better (the maintainer/npm/the email client/etc) to prevent this.
    • jowea 1y ago
• shadowgovt 1y ago
  I might need bloggers to not use "web 3" as a term. 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."
• btbuildem 1y ago
  Sometimes I think I'm a stubborn old curmudgeon for staunchly refusing to use node, npm, and the surrounding ecosystem. Pick and choose specific packages if I really have to. Then there's days like this.
• amradio1989 1y ago
  Great write up. I can understand the indignation at the exploit, but I believe it’s an A+ exploit for the chosen attack vector. Not only is it “proof of concept” but it’s a low risk high reward play. It’s brilliant really. Dangerously so.
• thrownaway561 1y ago
  The is the main reason why if you ever get a password reset email you ALWAYS go to the site directly and NEVER through the link provided in the email.
• superkuh 1y ago
  Wow! This site uses anubis with the meta-refreshed based challenge that doesn't require javascript. So I can actually read the article in my old browser. It's so rare for anubis deployals to be setup with any configuration beyond the defaults. What a delight.
  • aloer 1y ago
    The blog author is also the creator of Anubis
• lrvick 1y ago
  Daily reminder that no one can easily impersonate you if you sign your commits and make it easy to discover and verify your authentic key with keyoxide or similar.
  • junon 1y ago
    This wasn't a repository takeover. I do sign my commits.
    • lrvick 1y ago
      Fair. I should have expanded. If everyone signed commits with well published keys, -and- if NPM would stop rejecting every PR and feature request for clients to verify signatures from authors that opt in, this problem would not exist for packages from those authors. Unfortunately the official position of NPM since 2013 is that hashes solve the same security problem as signatures and that the signatures might make non signing package authors second class citizens. So no security for anyone, to avoid scaring off lazy maintainers. https://github.com/npm/npm/pull/4016 https://github.com/npm/npm/pull/4016
• frabjoused 1y ago
  I wrote the first commit for slice-ansi in 2015 to solve a baby problem for a cli framework I was building, and worked with Qix a little on the chalk org after it. It's wild looking back and seeing how these things creep in influence over time.
  • junon 1y ago
    Didn't expect things to grow how they have, that's for sure! Hope you've been well :)
    • frabjoused 1y ago
      Good to hear from you man, you too :)
• dang 1y ago
  Related. Others? DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware - https://news.ycombinator.com/item?id=45179939 https://news.ycombinator.com/item?id=45179939 - Sept 2025 (209 comments) NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 https://news.ycombinator.com/item?id=45169657 - Sept 2025 (719 comments)
  • jason-johnson 1y ago
    https://en.wikipedia.org/wiki/Peacenotwar https://en.wikipedia.org/wiki/Peacenotwar
• m463 1y ago
  Would recommend less click-baity: "NPM attack - we all dodged a bullet"
• benreesman 1y ago
  Now imagine if someone combined Jia Tan patience with swiss-cheese security like all of our editor plugins and nifty shell user land stuff and all that. Developer stuff is arguably the least scrutinized thing that routinely runs as mega root. I wish I could say that I audit every elisp, neovim, vscode plugin and every nifty modern replacement for some creaky GNU userland tool. But bat, zoxide, fzf, atuin, starship, viddy, and about 100 more? Nah, I get them from nixpkgs in the best case, and I've piped things to sh. Write a better VSCode plugin for some terminal panel LLM gizmo, wait a year or two? gg
  • jowea 1y ago
    Someday, someone, hopefully, will fix xkcd 1200.
• dzogchen 1y ago
  Lazy conclusion. People can and have been validating dependencies. We need an npm proxy with validated dependencies.
• theteapot 1y ago
  Article: > This is frankly a really good phishing email ... This is a 10/10 phishing email .. Phishing email: > As part of our on going commitment to account security, we are requesting that all users update their Two-Factor-Authentication (2FA) credentials ... What does that even mean? What type of 2FA needs updating? One 2FA method supported is OTP. Can't see a reason that would legitimately ever need to be updated, so doesn't really pass the sniff test that every single user would need to "update 2FA".
• jongjong 1y ago
  My open source projects were not affected but close call. I was using 2 of the dependencies (as sub-dependencies) but older versions. Seems that my philosophy of minimizing the number of dependencies and looking up dependency authors is paying off. I saw this kind of thing coming years ago. I never understood why people were obsessed with using tiny dependencies to save them 4 lines of code. These useless dependencies getting millions of weekly downloads always seemed very suspicious to me.
• kumavis 1y ago
  > all the malware did was modify the destination addresses of cryptocurrency payments mediated via online wallets like MetaMask A clarification: Despite MetaMask depending on the compromised packages it was not directly affected because: 1) packages were not updated while the compromise was live 2) MetaMask uses LavaMoat for install-time and run-time protections against compromised packages However the payload did attempt to compromise other pages that interact with wallets like MetaMask. Disclaimer: I worked on LavaMoat LavaMoat: https://github.com/lavamoat/lavamoat https://github.com/lavamoat/lavamoat
• monkpit 1y ago
  This article makes one faulty assumption that I think is really common - the author says it could be much worse, which implicitly assumes that we have noticed and caught every other time something like this has happened. Internally, we only noticed this because it caused a bunch of random junk to get barfed out into some CI logs. You really can’t say that nobody has ever done this better. Maybe they just did it so well that nobody noticed.
• easterncalculus 1y ago
  > This post and its online comment sections are blame-free zones The author is claiming control over other comment sections? Where is this entitlement coming from? They hide that behind some fictional persona, as if that changes anything. The author then proceeds to list several reasons someone would fall for this, carefully ignoring the most important detail of the email, being its address. The absolute very first step of detecting email phishing is looking at the address. Obviously the blame is on NPM for having a system that can be defeated by clicking a bad email, but the JS ecosystem has no interest in doing things right and there's no point in putting our heads in the sand about basic security practices.
  • ViscountPenguin 1y ago
    > Where is this entitlement coming from? They hide that behind some fictional persona, as if that changes anything. I hardly think a polite request is entitlement.
  • giveita 1y ago
    NPM should promptly email everyone to upgrade their 2FA
• duffpkg 1y ago
  For a very long time I have also used unique emails for each respective service that involves in email. When I sign up for npm it is something like email_npm@example.com . This makes it very easy to whitelist and also spot phishing emails because if an email for npm is coming to mail_cccoffee@example.com it screams that something is wrong. It is not bulletproof by any means but an additional layer that costs me almost nothing but requires effort on the part of attackers.
  • junon 1y ago
    That's exactly what I do, and have caught quite a lot of other phishing emails this way. They queried my npm email via the public API and sent it there.
• xyst 1y ago
  wow - people still get fooled by _phishing_ emails? I understand aging boomers with decreasing visual acuity, and deteriorating me tal state. But, the younger generations falling for these spearfish email attempts is wild. We are cooked.
• leviathant 1y ago
  I don't know what series of events transpired that resulted in common, slightly irregular use of the word "kindly" by scammers, but I'm glad it happened. Immediate red flag, every time.
• umvi 1y ago
  "A little duplication is better than a little dependency" - Golang Proverb (also applies to any other programming language...)
• keyle 1y ago
  "saved by procrastination!" made me smile. One of the common cases of being offline first, disconnected etc. pays off. Don't rush. Work on Hawaiian clock!
• beefnugs 1y ago
  We didn't dodge anything, this is just 1 of 1000 publicly found and reported on
• mdavid626 1y ago
  How would any normal person know that npmjs.help is phising, but npmjs.com is valid?
  • creesch 1y ago
    To state the obvious, one ends with "help" on with "com". It effectively is phishing awareness 101 that domains need to match. You still don't know then of course. When in doubt you shouldn't do the action that is asked through clicking on links in the mail. Instead go to the domain you know to be legit and execute the action there. Having said all that, even the most aware people are only human. So it is always possible to overlook a detail like that.
    • giveita 1y ago
      Corollary: dont click on any emails links. (Most use some dumb domain name that could be phishing)
      • mdavid626 1y ago
        There are many sites, which provide ONLY links, eg. with token in URL. What with those?
        • giveita 1y ago
          This is the problem. Those need to be very carefully clicked. The whole web is a darn mess! I have no ideas for solutions.
  • DecoySalamander 1y ago
    It wasn't a "normal person" it was a developer that put this into a README of his package > But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't become malicious over time. I expect him to know better.
• giveita 1y ago
  > One of the important things to take away from this is that every dependency could be malicious. We should take the time to understand the entire dependency tree of our programs, but we aren't given that time. At the end of the day, we still have to ship things. That's why you need vuln scanners and not upgrade to the latest thing as soon as released.
• arunc 1y ago
  Trying to read this on Brave on Android and I couldn't get past Anubis. Does anyone else observe the same?
• nedt 1y ago
  We haven't been saved by procrastination. We literally were saying "oh that's a new version, we are always behind anyway". Of course everything was still checked, but actually having the latest version on packages is almost never needed and we rather update when we have to (because version is old) instead of when there is a new version. Nothing new is that awesome.
• jFriedensreich 1y ago
  That post fails to address the main issue, its not that we don't have time to vet dependencies, its that nodejs s security and default package model is absurd and how we use it even more. Even most deno posts i see use “allow all” for laziness which i assume will be copy pasted by everyone because its a major pain of UX to get to the right minimal permissions. The only programming model i am aware if that makes it painful enough to use a dependency, encourages hard pinning and vetted dependency distribution and forces explicit minimal capability based permission setup is cloudflares workerd. You can even set it up to have workers (without changing their code) run fully isolated from network and only communicate via a policy evaluator for ingress and egress. It is apache licensed so it is beyond me why this is not the default for use-cases it fits.
  • mb2100 1y ago
    To be fair, the advantage of Deno here is really the standard library that includes way more functionality than Node. But in the end, we should all rely on fewer dependencies. It's certainly the philosophy I'm trying to follow with https://mastrojs.github.io https://mastrojs.github.io – see e.g. https://jsr.io/@mastrojs/mastro/dependencies https://jsr.io/@mastrojs/mastro/dependencies
  • berkes 1y ago
    Another main issue is how large (deep and wide) this "supply chain" is in some communities. JavaScript and python notable for their giant reliance on libs. If I compare a typical Rust project, with a same JavaScript one, JavaScript project itself often has magnitudes more direct dependencies (wide supply chain?). The rust tool will have three or four, the JavaScript over ten, sometimes ten alone to help with just building the typescript in dev. Worsened by the JavaScript dependencies own deps (and theirs, and theirs, all the way down to is_array or left_pad). Easily getting in the hundreds. In rust, that graph will list maybe ten more. Or, with some complex libraries, a total of several tens. This attitude difference is also clear in Python community. Where the knee-jerk reaction is to add an import, rather than think it through, maybe copy paste a file, and in any case, being very conservative. Do we really need colors in the terminal output? We do? Can we not just create a file with some constants that hold the four ANSI escape codes instead? I'm trying to argue that there's also an important cultural problem with supply chain attacks to be considered.
• YeGoblynQueenne 1y ago
  >> It sets a deadline a few days in the future. This creates a sense of urgency, and when you combine urgency with being rushed by life, you are much more likely to fall for the phishing link. Procrastination is a security strategy.
  • kitd 1y ago
    When we do the phishing awareness training at $WORK, we are told any sense of urgency is suspicious, especially from an established org. Most would give you at least a month before something as draconian as locking your account.
• Pomelolo 1y ago
  [flagged]
  • sethaurus 1y ago
    Furries tend to be high in curiosity, high in trait-openness, and lower in social conformance. It's a good recipe for learning, thinking and questioning.
    • Pomelolo 1y ago
      [dead]
• whiplash451 1y ago
  Not a security expert but I don’t think that requesting a reset of your 2FA credentials is reasonable. I would be very worried about my 2FA provider if they asked me to do this. And so I would not rate this phishing email a 10/10 at all.
  • brushfoot 1y ago
    Yes, the article's insistence that anyone would have fallen for the phish, and that anyone who disagrees is simply "wrong," is unfortunate. My old corporate phishing training drilled it into my head pretty effectively that you don't follow links in emails if the emails aren't direct responses to actions you've just taken: registering an account, resetting a password, and so forth. To this day, I don't follow links in other kinds of emails. I mouse over the link to view the domain as a first step in determining how seriously to take the email. If the domain appears to match the known-good one, I copy the link and examine the characters to see if any Unicode lookalikes have been employed. If the domain seems legitimate, or if I don't recognize it but the email is so convincing that I suspect the company truly is using a different domain (my bank has done this, frustratingly), I still don't click the link. I log in to my account on the known-good domain -- by typing it by hand into the browser's address bar -- and look for notifications. If there are no notifications, then I might contact the company about the email to verify its authenticity. If anyone reading thinks that seems like a lot of work, I agree with you! It stinks. But I humbly submit that it's necessary on today's Internet. And it's especially necessary if you're in charge of globally used software libraries. To adopt the tone of the article's author, if they aren't willing to do that, they're wrong, and they're going to keep getting phished.
    • hennell 1y ago
      Anyone is a literal stretch, but "almost anyone" seems pretty true. How many people do you think follow your very security minded, but quite long-winded practice? 1 in 1000?, 1 in 10,000? 1 in 100,000? Less? I think the vast vast majority of people would have fallen for it, it's a decent looking message, it has a sense of urgency and the domain doesn't look wildly wrong. Devs in theory might be more security aware, but also we work with a lot of different apps, systems and sites - mixed domains, weird deep-links, redirects we've all used (and possibly even deployed) such setups. Add in most of my email is now through a corporate outlook, so domains aren't very visible it's all nestled behind "safelinks", and personal email is often on a phone so mousing over a link just isn't muscle memory anymore. I think I'd be suspicious at the request, but possibly have clicked to see more, especially with the threat things might stop working soon. Maybe NPM/package platforms should be pushing security training to their biggest maintainers like your old corporation did, but for now they don't and the idea that people should be more aware of the risk is sort of the point. Almost anyone would have fallen for that, thats why almost all of us need to be reminded to think of this stuff more.
• mintaka5 1y ago
  [dead]
• Loudergood 1y ago
  Why is it always NPM?
• tempodox 1y ago
  Stuff like this is why I stay away from everything that touches NPM, but I guess not everyone has the freedom to make that decision.
• casey2 1y ago
  Not all of us