Is this actually accurate? Packages with weekly downloads in the hundreds of thousands, yet in the 4+ hours that the malicious versions were up for, not a single person updated any of them to the latest patch release?
I also know projects who are reading the update feeds and kick off CI jobs after any dependencies are updated to automatically test version upgrades, surely at least one dependent of DuckDB is doing something similar.
Microsoft has been bravely saying "Security is top priority" since 2002 (https://www.cnet.com/tech/tech-industry/gates-security-is-to...) and every now and then reminds us that they put "security above all else" (latest in 2024: https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...), yet things like this persists.
For how long time do Microsoft need to leave wide-open holes for the government to crack down on their wilful ignorance? Unless people go to jail, literally nothing will happen.
npm stats lag. We observed installs while the malicious versions were live for hours before removal. Affected releases we saw: duckdb@1.3.3, @duckdb/duckdb-wasm@1.29.2, @duckdb/node-api@1.3.3, @duckdb/node-bindings@1.3.3. Same payload as yesterday’s Qix compromise. Recommend pinning and avoiding those versions, reviewing diffs, and considering a temporary policy not to auto-adopt fresh patch releases on critical packages until they age.
downvotes appreciated but also happy to see one or two urls that would prove me wrong
Second - an example for a javascript heavy npm utilizing tracking heavy / low content site has not much weight in proving me right - my view is an assumption - 2 examples of shitty tracking SEO AI garbage content blubber sites not using npm would substantially question my assumption... I am genuinely interested in the tech those sites would use instead.
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?
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 legit, no obfuscated massive subdomain, no uncanny login screen, etc.
All the talk of AI disrupting tech; this is an angle where generative AI can have a massive impact in democratizing the global phishing industry. I do agree with you that there's likely many more authors who have been tricked and we haven't seen the full fallout.
same with just copying email HTML
it's actually easier to make it looke exactly the same vs different in some ways
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?
That's what I'm guessing OP meant.
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 for site A manually into site B, and give you a "are you sure this isn't phishing" warning or something?
I don't quite understand how the chalk author fell for it though. They said
> This was mobile, I don't use browser extensions for the password manager there.
So are there mobile password managers that don't even check the URL? I dunno how that works...
Is there some middle ground where I can get the browser to automatically confirm I am on a previously trusted domain? My initial thought is that I could use Firefox Workspaces for trusted domains. Limited to the chosen set of urls. Which I already do for some sites, but I guess I could expand it to everything with a login.
Not actually suggesting this as it sounds like quite a big headache, but it is an option.
Think my only blocker would be if the browser extension fights me if I try to register a site using a broken/missing password.
Does feel like a bit of a browser gap. “You have previously visited this site N times”. If that number is zero, extra caution warranted. Even just a bit of extra sophistication on bookmarks if the root domain has previously been registered. Thinking out loud, I guess I could just lean on the browser Saved Passwords list. I’ve never been comfortable with the security, but I could just always try to get it to save a sentinel username, “YOUHAVEBEENHEREBEFORE”.
I don't get these arguments. Yeah, of course I was always surprised phishing emails give itself away with mistakes as maybe non-native speakers create it without any spellcheck or whatever and it was straight forward to improve that... but whatever the text, if I open a link from email the first thing I look at is domain. Not how the site looks. The DOMAIN NAME! Am I on trusted site? Well .help TLD would SURELY ring a bell and involve research as whether this domain is associated to npm in any way.
At some point my bank redirected me to some weird domain name... meh, that was annoying, had to research whether that domain is really associated to them.. it was. But they just put their users under risk if they want domain name not to mean trust and just feed whatever domains as acceptable. That is NOT acceptable.
There are more than a few instances when I’ve created an account for a service I know I’ve never interacted with before, but my password manager offered to log me in because another business I’ve used in the past used the same service (medical providers, schools, etc.).
Even as a technically competent person, I received a legitimate email from Google regarding old shadow accounts they were reconciling from YouTube and I spent several hours convinced it was a phishing scheme.it put me on edge for nearly a week that there was no way I could be sure critical accounts were safe, and worse yet, someone like my parents or in-laws could be safe.
>A huge red flag.
It won't be a red flag for people who often see auto-complete not working for legitimate websites. The usual cause is legitimate websites not working instead of actual phishing attempts.
This unintended behavior of password managers changes the Bayesian probabilities in the mind such that username/password fields that remain unfilled becomes normal and expected. It inadvertently trains sophisticated people to lower their guard. I wrote more on how this happens to really smart technical people: https://news.ycombinator.com/item?id=45179643
>So are there mobile password managers that don't even check the URL? I dunno how that works...
Strongbox pw manager on iOS by default doesn't autofill. You have to go settings to specifically enable that feature. If you don't, it's copy&paste.
Yeah, that's true, I hit this all the time with 1Password+Firefox+Linux (fun combo).
Just copying-pasting the username+password because it doesn't show up is the wrong approach. It gives you a chance to pause and reflect, since it isn't working, so in that case you lookup if it's actually the right domain, and if it is, add it to the allowed domains so it works fine in the future.
Maybe best would be if password managers defaulted to not showing a "copy" thing at all for browser logins, and not letting users select the password, instead prompting them to rely on the autofill, and fix the domains if the autofill doesn't work.
Half the reason I use password manager in the first place is specifically for this issue, the other half is because I'm lazy and don't like typing. It's really weird to hear people using password managers yet do the old copy-paste dance anyways.
Thankfully there are many reasons to use a password manager. Auto-fill is just one.
Unfortunately, as bad as phishing is, service providers have leaked more plain text passwords than a phisherman could ever catch.
But the domain binding just isn't possible without technical means, hence I see that as my own top reason, I suppose :)
Please people, build your login forms correctly! It’s not rocket science.
This is the case when you are doing mass phishing attacks trying to get the dumbest person you can. In these cases, they want the person that will jump through multiple loops one after another that keeps giving them money. A more technical audience you wouldn't want to do so, if you want one smart person to make one mistake.
Frankly I can't believe we've trained an entire generation of people that this is the key identifier for scam emails.
Because native English speakers never make a mistake, and all scammers are fundamentally unable to use proper grammar, right?
MyBank: "Don't click on emails from suspicious senders! Click here for more information" { somethingweirdmybank.com } -- Actual real email from my bank.
Like, wtf. Why are you using a totally different domain.
And the companies I've worked for do this kind of crap all the time. "Important company information" { learnaboutmycompany.com } -- Like, is this a random domain someone registered. Nope, actually belongs to the place I work for when we have a well known and trusted domain.
Oh, and it's the best when the legit sites have their own spelling mistakes.
Considering that today it'd add work for me today, and future work, with no additional security benefits compared to my current approach, it just don't seem worth it.
The idea is that if your password manager doesn't show the usual list of accounts (regardless if the actual autofill after clicking the account works or not), you double-check the domain.
> do you now need to maintain two keys for every service?
I do maintain multiple keys for every service. I wouldn't say it's a lot of maintenance, any more than a far more secure "remember me" box is "maintenance".
When I register for a new service, I add my hardware token on my keychain as a passkey. I sign in on my laptop for the first time for a service I'll use there more than once, I make a passkey. I sign in on my desktop for the first time, I make a passkey, maybe make a spare in my password manager. Maybe if it's something I use on my phone, I'll make a passkey there as well when I sign in for the first time. When I get around to it, I'll add the spare hardware token I keep in a drawer. But its not like "I just signed up for a new service, now I must go around to every device and make a new passkey immediately. As long as I've got a couple of passkeys at registration time, I'm probably fine.
Lose my laptop? Its ok, I've got other passkeys. Lose my keys? Its ok, I've got other passkeys. My laptop and keys get stolen at the same time? Its ok, I've got other passkeys.
Its really not that hard.
I cannot be bother to remember every hole name. They're all USB anyway, the difference is that some are A, C, or Lightning, I bought a new MacBook and it has that magnet hole, what is that called? I'm not following.
The stuff I deal with every day is centering divs
> it's too hard to keep track of the names of the three different ports
it's more than three ports.
Disclaimer: I don't know enough of npm/nodejs community so I might be completely off the mark here
Not sure how this emphasis is of any importance, you brain doesn't have a pixel perfect image of the website, so you wouldn't know whether it's a perfect replica or not.
Let the silicon dummies in the password manager do the matching, don't strain your brain with such games outside of entertainment
https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
Any idea what the interference was?
They already make links go through redirects (to avoid referrer headers?) so it's halfway there. Just make the redirect page show the link and a go button instead of redirecting automatically. And it would fix the annoyance that is not being able to see the real domain when you hover the link.
People who publish software packages tend to be at least somewhat technical people. Can package publishing platforms PLEASE start SIGNING emails. Publish GPG keys (or whatever, I don't care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform.
Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks.
And while we're at it, it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it, but it's clear that the actions in this example were suspicious: user logs in, changes 2FA settings, immediately adds a new API token, which immediately gets used to publish packages. Maybe there should be a 24 hour period where nothing can be published after changing any form of credentials. Accompanied by a bunch of signed notification emails. Of course that's all moot if the attacker also changes the email address.
Like Citroen sends software update notifications for their cars from mmy-customerportal.com. That URL looks and sounds like a phisher's paradise. But somehow, it's legit. How can we expect any user to make the right decision when we push this kind of garbage in their face?
"All legitimate npm emails are signed with GPG key X" and "All legitimate npm emails come from @npmjs.com" are equally strong statements.
I think there’s a fairly straightforward way of fixing this: contact requests for email. The first email anybody sends you has an attachment that requests a token. Mail clients sort these into a “friend request” queue. When the request is accepted, the sender gets the token, and the mail gets delivered to the inbox. From that point on, the sender uses the token. Emails that use tokens can skip all the spam filters because they are known to be sent by authorised senders.
This has the effect of separating inbound email into two collections: the inbox, containing trustworthy email where you explicitly granted authorisation to the sender; and the contact request queue.
If a phisher sends you email, then it will end up in the new request queue, not your inbox. That should be a big glaring warning that it’s not a normal email from somebody you know. You would have to accept their contact request in order to even read the phishing email.
I went into more detail about the benefits of this system and how it can be implemented in this comment:
I got a fraud alert email from my credit card the other day. It included links to view and confirm/deny the suspicious charge. It all looked OK, the email included my name and the last digits of my account number.
I logged in to the website instead. When I called to follow up I used the phone number printed on my card.
Turns out it was a legit email, but you can't really know. Most people don't understand public key signing well enough to rely on them only trusting signed emails.
Also, if you're sending emails like this to your users, stop including links. Instead, give them instructions on what to do on your website or app.
I have had people attempt fraud in my work with live calls as follow up to emails and texts. I only caught it because it didn't pass the smell test so I did quite a bit of research. Somebody else got caught in the exact same scam and I had to extricate them from it. They didn't believe me at first and I had to hit them over the head a bit with the truth before it sank in.
1. I genuinely don't understand why.
2. If it is true that people are the failing factor, then nothing is going to help. Hardware keys? No problem, a human will use the hardware key to sign a malicious action.
It's a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself.
There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.
You never make a mistake? Never ever? It's a question of numbers. If the likelihood of making a mistake is 1 in 10000 emails, send out links to 10.000 package maintainers, and you've got a 63% chance of someone making that mistake.
I trust the user did this calculation. I didn't.
The major difference between passkeys and hardware 2fa (FIDO2/yubikeys) and TOTP/SMS/Email solutions is that the passkey/yubikey _also_ securely validates the site it's communicating with before sending validation, making traditional phishing attacks all but impossible.
Nothing will reduce incidents to 0, but many things can move us closer to 0.
* signed packages
enforce it for the top x thousand most popular packages to start
some basic hygiene about detecting unique new user login sessions would help as well
People will inevitably set up their CI system to sign packages, no human intervention needed. If they're smart & the CI system is capable of it they'll set it up to only build when a tag signed by someone approved to make releases is pushed, but far too often they'll just build if a tag is pushed without enforcing signature verification or even checking which contributors can make releases. Someone with access to an approved contributor's GitHub account can very often trigger the CI system to make a signed release, even without access to that contributor's commit signing key.
One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your primary one?
It also annoys me when people see this happening and point out how the person who fell for the attack missed some obvious detail they would have noticed. That's completely irrelevant, because everyone is stupid sometimes. Everyone can be stressed out and make bad decisions. It's always a good idea to make it harder to make bad decisions.
I am skeptical this solves phising & not add to more woes (would you blindly click on links if the email was signed?), but if we are going to suggest public key cryptography, then: NPM could let package publishers choose if only signed packages must be released and consumers decide if they will only depend on signed packages.
I guess, for attackers, that moves the target from compromising a publisher account to getting hold of the keys, but that's going to be impossible... as private keys never leave the SSM/HSM, right?
> Get them to distrust any unsigned email, no matter how convincing it looks.
For shops of any important consequence, email security is table stakes, at this point: https://www.lse.ac.uk/research/research-for-the-world/societ...
Signing the packages seems like low hanging fruit as well, if that isn't already being done. But I'm skeptical that those keys are as safe as they should be; IIRC someone recently abused a big in a Github pipeline to execute arbitrary code and managed to publish packages in that way. Which seems like an insane vulnerability class to me, and probably an inevitable consequence of centralising so many things on github.
USE PASSKEYS. Passkeys are phishing-resistant MFA, which has been a US govt directive for agencies and suppliers for three years now[1]. There is no excuse for infrastructure as critical as NPM to still be allowing TOTP for MFA.
[1]https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...
We analyzed this DuckDB incident today. The attacker phished a maintainer on npmjs.help, proxied the real npm, reset 2FA, then immediately created a new API token and published four malicious versions. A short publish freeze after 2FA or token changes would have broken that chain. Signed emails help, but passkeys plus a publish freeze on auth changes is what would have stopped this specific attack.
There was a similar npm phishing attack back in July (https://socket.dev/blog/npm-phishing-email-targets-developer...). In that case, signed emails would not have helped. The phish used npmjs.org — a domain npm actually owns — but they never set DMARC there. DMARC is only set on npmjs.com, the domain they send email from. This is an example of the “lack of an affirmative indicator” problem. Humans are bad at noticing something missing. Browsers learned this years ago: instead of showing a lock icon to indicate safety, they flipped it to show warnings only when unsafe. Signed emails have the same issue — users often won’t notice the absence of the right signal. Passkeys and publish freezes solve this by removing the human from the decision point.
So, regrettably, we're back to "train users" and all the pitfalls that entails
A week waiting period would not be enough. On average, npm malware lingers on the registry for 209 days before it's finally reported and removed.
Source: https://arxiv.org/abs/2005.09535
Forget about phishing, it's a red herring. The actual solution to this is code signing and artifact signing.
You keep a private key on your local machine. You sign your code and artifacts with it. You push them. The packages are verified by the end-user with your public key. Even if your NPM account gets taken over, the attacker does not have your private key, so they cannot publish valid packages as you.
But because these platforms don't enforce code and artifact signing, and their tools aren't verifying those signatures, attackers just have to figure out a way to upload their own poison package (which can happen in multiple ways), and everyone is pwnd. There must be a validated chain of trust from the developer's desktop all the way to the end user. If the end user can't validate the code they were given was signed by the developer's private key, they can't trust it.
This is already implemented in many systems. You can go ahead and use GitHub and 1Password to sign all your commits today, and only authorize unsealing of your private key locally when it's needed (git commits, package creation, etc). Then your packages need to be signed too, public keys need to be distributed via multiple paths/mirrors, and tools need to verify signatures. Linux distributions do this, Mac packages do, etc. But it's not implemented/required in all package managers. We need Npm and other packaging tools to require it too.
After code signing is implemented, then the next thing you want is 1) sign-in heuristics that detect when unusual activity occurs and either notifies users or stops it entirely, 2) mandatory 2FA (with the option for things like passkeys with hardware tokens). This will help resist phishing, but it's no replacement for a secure software supply chain.
No, with the _requirement_ for passkeys or hardware tokens!
Strongly agree on artifact signing, but it has to be real end-to-end. If the attacker can trigger your CI to sign with a hot key, you still lose. What helps: 1) require offline or HSM-backed keys with human approval for release signing, 2) enforce that published npm artifacts match a signed Git tag from approved maintainers, 3) block publishes after auth changes until a second maintainer re-authorizes keys. In today’s incident the account was phished and a new token was used to publish a browser-side wallet-drainer. Proper signing plus release approvals would have raised several hard gates.
I certainly wouldn't. And I don't see it as pointless theater. It requires deliberate action, and that's what's missing here.
The single one method how to install DuckDB on laptop is to run
`curl https://install.duckdb.org | sh`
I've requested to deliver CLI as standard package, they have ignored it. Here is the thread https://github.com/duckdb/duckdb/issues/17091
As you can see that it isn't single slip due to "human factor", but DuckDB management consistently puts users at risk.
Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right?
Like, I don't see how it's different than going to their website, copying their recommended command to install via a standard repo, then pasting that command into your shell. Either way, you are depending entirely on the legitimacy of their domain right?
You're about to install and run their software. If they wanted to do something malicious, they wouldn't hide it in their plaintext install script.
A server can use this to maliciously give you malware only if you're not looking at the code.
Though your point about trust is valid.
Sure a binary can be swapped in other places, but they generally can be verified with hashes and signatures. Also, a plaintext install script often has this problem in another layer of recursion (where the script usually pulls from URLs that the runner of the script cannot verify with this method)
Tomorrow they will do it again, and attackers will replace binary files that users download with this random script. Or this script will steal crypto/etc.
To make attack vector difficult for hackers, it's preferable to download any software as packages. On linux it looks like `apt install python3`.
The benefits is
1. Repositories are immutable, so attacker can't replace binary for specific version, even if they will hack all infrastructure of DuckDB. Remote script may be replaced anytime to run any code
2. Some repositories have strict review process, so there are external reviewers who will require to pass security processes to upload new version
for MacOS they have it in brew, which is also you can use on linux, also it is available in nix.
I think the problem is that there are so many linux distros with their own package repositories, that it is very untrivial task to include package into most of them if maintainers are not proactively interested.
This should not be considered high effort or a sophisticated attack. The attacker probably used a mitm proxy which can easily replicate every part of your site, with very little initial configuration. Evilginx is the most popular one I could think of
A few concrete datapoints from our analysis of this incident that may help cut through the hand-waving:
1. This is the same campaign that hit Qix yesterday (https://socket.dev/blog/npm-author-qix-compromised-in-major-...). The injected payload is byte-for-byte behaviorally identical. It hooks fetch, XMLHttpRequest, and common wallet provider APIs and live-rewrites transaction payloads to attacker addresses across ETH, BTC, SOL, TRX, LTC, BCH. One tell: a bundle of very distinctive regexes for chain address formats, including multiple Solana and Litecoin variants.
2. Affected versions and timing (UTC) that we verified:
- duckdb@1.3.3 at 01:13
- @duckdb/duckdb-wasm@1.29.2 at 01:11
- @duckdb/node-api@1.3.3 at 01:12
- @duckdb/node-bindings@1.3.3 at 01:11
Plus low-reach test shots: prebid@10.9.1, 10.9.2 and @coveops/abi@2.0.1
3. Payout so far looks small. Tracked wallets sum to roughly $600 across chains. That suggests speed of discovery contained damage, not that the approach is harmless.
What would actually move the needle:
=== Registry controls ===
- Make passkeys or FIDO2 mandatory for high-impact publisher accounts. Kill TOTP for those tiers.
- Block publishing for 24 hours after 2FA reset or factor changes. Also block after adding a new automation token unless it is bound by OIDC provenance.
- Require signed provenance on upload for popular packages. Verify via Sigstore-style attestations. Reject if there is no matching VCS tag.
- Quarantine new versions from being treated as “latest” for automation for N hours. Exact-version installs still work. This alone cuts the blast radius of a hijack.
=== Team controls ===
- Do not copy-paste secrets or 2FA. Use autofill and origin-bound WebAuthn.
- Require maker-checker on publish for org-owned high-reach packages. CI must only build from a signed tag by an allowed releaser.
- Pin and lock. Use `npm ci`. Consider an internal proxy that quarantines new upstream versions for review.
=== Detection ===
- Static heuristics catch this family fast. Wallet address regex clusters and network shims inside non-crypto packages are a huge tell. If your tooling sees that in a data engine or UI lib, fail the build.
Lastly, yes, training helps, but the durable fix is making the easy path the safe path.
But never ever anyone was rooted because of malware that was snuck into an official .deb package.
That was the concept of "stable" in the good old time, when software was really an "engineering" field.
arewethereyeta•7h ago
How can anyone publish their packages?
pneff•7h ago
masfuerte•7h ago
https://news.ycombinator.com/item?id=45169657
OtherShrezzing•7h ago
This is the second high-profile instance of the technique this week.
arewethereyeta•7h ago
jsheard•6h ago
frizlab•6h ago
frizlab•4h ago
Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable.
cesarb•2h ago
From what I've heard, they're also unbackupable, and tied to the ecosystem used to create them (so if you started with an Apple desktop, you can't later migrate the passkeys to a Windows desktop, you have to go to every single site you've ever used and create new ones).
smw•2h ago
smw•2h ago
diggan•5h ago
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.
jsheard•5h ago
https://old.reddit.com/r/node/comments/xftu7i/comment/iooabn...
koakuma-chan•6h ago
skeeter2020•6h ago