Top
Best
New

Posted by tosh 4 days ago

DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware(github.com)
390 points | 283 commentspage 3
karel-3d 3 days ago||
npm actually does send these emails. They are about setting up 2FA though. And never have this sense of urgency.

"Hi, XXXX! It looks like you still do not have two-factor authentication (2FA) enabled on your npm account.

To enable 2FA, please follow the instructions found here."

ebfe1 4 days ago||
Is it just me who think this could have been prevented if npm admins put in some sort of cool off period to only allow new versions or packages to be downloaded after being published by "x" amount of hours? This way the npm maintainer would get notifications on their email and react immediately? And if it is urgent fix, perhaps there can be a process to allow npm admin to approve and bypass publication cool off period.

Disclaimer: I don't know enough of npm/nodejs community so I might be completely off the mark here

herpdyderp 4 days ago||
If I was forced to wait to download my own package updates I would simply stop using npm altogether and use something else.
kaelwd 4 days ago|||
It would be fine if you could still manually specify those versions eg. npm i duckdb@1.3.3 installs 1.3.3 but duckdb@latest or duckdb@^1.3 stays on 1.3.2 until 1.3.3 is ~a week old.

https://github.com/pnpm/pnpm/issues/9921

ApolloFortyNine 4 days ago|||
Except they'd have to have an override for when there's a zero day, at which point we're back where we started.
kaelwd 4 days ago||
Versions with a serious vulnerability should be deprecated by the maintainer which then warns you to use a newer version when installing. Yes if a npm account is compromised the attacker could deprecate everything except their malicious version but it would still significantly reduce the attack surface by requiring manual intervention vs the current npm install foo@latest -> you're fucked.
herpdyderp 4 days ago|||
Brilliantly simple, that would work for me!
balder1991 4 days ago|||
It could be done like a rollout in % over time like app stores do.
kaelwd 4 days ago|||
NPM could also flag releases that don't have a corresponding github tag (for packages that are hosted on github), most of these attacks are publishing directly to NPM without any git changes.
mdaniel 3 days ago||
I would love this for every dependency manager, and double extra bonus for "the tag NOW isn't the tag from when the dep was published"

But, this coming from GitHub, who believe that sliding "v1" tags on random action repos is how one ends up with https://news.ycombinator.com/item?id=43367987

robjan 4 days ago|||
They could definitely add a maker-checker process (similar to code review) for new versions and make it a requirement for public projects with x number of downloads per week.
hiccuphippo 4 days ago||
The could force release candidates that the package managers don't automatically update to, but let researchers analyse the packages before the real release.
skylurk 4 days ago||
I hate the janky password manager browser extensions but at least they make it hard to make this mistake.
smw 4 days ago|
And passkeys or hardware tokens (FIDO/yubikeys) make it impossible
hoppp 4 days ago||
Why the hell we use npm,

Every dependency is a backdoor, To make them malicious it only take s a small slip up

cefboud 4 days ago||
> malicious code to interfere with cryptocoin transactions

Any idea what the interference was?

jeswin 4 days ago||
Publishing could require clicking an email confirmation link, sent by npm.
petcat 4 days ago|
It's all pointless theater because people want less friction to do what they want, not more. They'll just automate away the friction points like clicking an email confirmation link.
jeswin 4 days ago||
If you're the author of ducklib, and you get an email asking "Did you just publish ducklib 2.4.1?" with a fair number of warnings in the mail text, will you click on the publish link?

I certainly wouldn't. And I don't see it as pointless theater. It requires deliberate action, and that's what's missing here.

polynomial 4 days ago||
Serious question, how did the attacking site (npmjs.help) know the victim's 2fa? ie. How did they know what phone number to send the 2fa request to?
feross 4 days ago||
It was a relay. The fake site forwarded actions to the real npm, so the legit 2FA challenge was triggered by npm and the victim entered the code into the phishing page. The attacker captured it and completed the session, then added an API token and pushed malware. Passkeys or FIDO2 would have failed here because the credential is bound to the real domain and will not sign for npmjs.help.
yawaramin 3 days ago||
And by 'fail' we mean that passkeys would have successfully prevented the attack.
feross 3 days ago||
Correct!
xx_ns 4 days ago|||
It acted as a proxy for the real npm site, which was the one to send the request, intercepting the code when the user inserted it.
mediumsmart 4 days ago||
Comes with the territory considering that npm is defacto the number one enshittification dependency by now. But no worries - this will scale beautifully.

downvotes appreciated but also happy to see one or two urls that would prove me wrong

eviks 4 days ago||
In the spirit of a substantive discussion could you likewise share a couple that would prove you right?
mediumsmart 4 days ago||
First of all I have a theory that nothing can be proven but I can't prove it.

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.

eviks 4 days ago||
If you have such a theory, how does it make sense to ask others to do the impossible and prove anything???
mediumsmart 4 days ago||
thats a fortune cookie - please stay on topic :)
hiccuphippo 4 days ago||
I think the downvotes are because enshittification is a different thing, intentionally done by the developers themselves.
mediumsmart 4 days ago||
granted but the motivation is payment I think and that originates elsewhere.
arewethereyeta 4 days ago|
> An attacker published new versions of four of duckdb’s packages that included malicious code to interfere with cryptocoin transactions

How can anyone publish their packages?

OtherShrezzing 4 days ago||
The attacker emailed a maintainer from a legitimate looking email address. The maintainer clicked the link and reset their credentials on a legitimate looking website. The attacker then signs into the legitimate duckdb account and publishes their new package.

This is the second high-profile instance of the technique this week.

arewethereyeta 4 days ago||
2FA for such high profile packages should be enforced
jsheard 4 days ago|||
It is, if your packages are popular enough then npm will force you to enable 2FA. They started doing that a few years ago. It clearly doesn't stop everything though, the big attack yesterday went through 2FA by tricking the author into doing a "2FA reset".
diggan 4 days ago|||
> It is, if your packages are popular enough then npm will force you to enable 2FA.

Are they actively forcing it? I've received the "Remember to enable 2FA" email notifications from NPM since 2022 I think, but haven't bothered since I'm not longer publishing packages/updates.

Besides, the email conveniently mentions their "automation" tokens as well, which when used for publishing updates, bypasses 2FA fully.

jsheard 4 days ago||
Did you ever get this email?

https://old.reddit.com/r/node/comments/xftu7i/comment/iooabn...

frizlab 4 days ago|||
Passkeys should be enforced
smw 4 days ago|||
Parent is exactly right! For critical infrastructure an un-phishable 2fa mechanism like passkeys or hardware token (FIDO2/yubikey) should be required! It would remove this category of attack completely.
frizlab 4 days ago|||
I take the downvote but I’d like to know why?

Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable.

cesarb 4 days ago||
> Among other things, they are completely unfishable.

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).

yawaramin 3 days ago|||
You can just create a new passkey on the new device after logging in. It's a non-issue.
3eb7988a1663 3 days ago||
It is not a given that multiple services let you enroll multiple keys. How many year did it take before Amazon allowed multiple Yubikeys? Which means you are in a real pickle if you ever lose your one hardware device with keys (lost, stolen, bricked, whatever).
yawaramin 3 days ago||
It's an incorrect implementation, the same as when eg an account provider truncates a long password to 8 characters.
smw 4 days ago||||
You can't really backup hardware tokens, either? It's quite possible to use something like bitwarden/vaultwarden/1password as a password manager, and you can "backup" tokens quite easily without being tied to a particular mobile/desktop ecosystem.
frizlab 4 days ago|||
That’s not true anymore; you can migrate passkeys to another password manager now.
skeeter2020 4 days ago||||
for popular packages - and in this case - they are. This attack (and yesterday's) are relay attacks, with the attacker in the middle between npm and the target.
koakuma-chan 4 days ago|||
He would have entered 2FA too
pneff 4 days ago|||
There is a detailed postmortem in the linked ticket explaining exactly how this happened.
masfuerte 4 days ago||
This is the same phishing attack that hit junon yesterday.

https://news.ycombinator.com/item?id=45169657