Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

github.com

Post reply on HN
Print view View original

171–180 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#171

Post by tripplyons »

kyle-rb wrote: post #163

I've been critical of blockchain in the past because of the lack of use cases, but I've gotta say crypto functions pretty well as an underlying bug bounty system. This probably could have been a much more insidious and well hidden attack if there wasn't a quick payoff route to take.

That argument only really makes sense if you assume the attackers aren't rational actors. If there was a better, more destructive way to profit from this kind of compromise, they would either do it or sell their access to someone who knew how to do it.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#172

Post by parliament32 »

elric wrote: post #74

This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time. 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 car…

> it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#173

Post by egorfine »

vel0city wrote: post #161
egorfine wrote: post #138

Earlier quoted context omitted.

Then see #2: there is no way to prevent humans from actually performing detrimental actions, hardware keys or not.

This specific attack (and many others like it) would have absoultey been foiled by U2F or passkeys. These authors would have been incapable of giving the adversary any useful credential to impersonate them by the very nature of how these systems work.

Fair.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#174

Post by tgv »

theanonymousone wrote: post #142
chrisweekly wrote: post #133

Earlier quoted context omitted.

Your point is completely valid. Tangent: in your example, what calculation led to "63%"?

1-(.9999)^10000 I trust the user did this calculation. I didn't.

That's indeed the formula. The .9999 is (1 - 1/10000), 1/10000 being the likelihood. It would perhaps have been clearer if I had chosen two different numbers...

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#175

Post by SAI_Peregrinus »

nikcub wrote: post #107
elric wrote: post #74

This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time. 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 car…

* passkeys * 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

Requiring signed packages isn't enough, you have to enforce that signing can only be done with the approval of a trusted person.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#176

Post by smw »

parliament32 wrote: post #172
elric wrote: post #74

This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time. 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 car…

> it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it 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...

This is the way! Passkeys or FIDO2 (yubikey) should be required for supply chain critical missions like this.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#177

Post by cesarb »

frizlab wrote: post #108
frizlab wrote: post #17

Earlier quoted context omitted.

Passkeys should be enforced

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.

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#178

Post by diggan »

ApolloFortyNine wrote: post #146
diggan wrote: post #30

Earlier quoted context omitted.

Use a password manager (that isn't too buggy and/or suck) and you get the same thing for both TOTP and passwords.

As mentioned elsewhere in this thread, the password manager failing to autofill is hardly unheard of.

As also mentioned elsewhere in this submission, it doesn't matter how often autofill breaks/works. There are two cases where it breaks: The accounts not showing up in the password manager modal, and the website autofill not working. The first is what prevents phishing, the second doesn't really matter to prevent phishing or not.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#179

Post by smw »

egorfine wrote: post #139
tgv wrote: post #111

Earlier quoted context omitted.

> 1. I genuinely don't understand why. 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.

Then hardware 2FA won't help.

This seems to be a common misunderstanding.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#180

Post by smw »

0xbadcafebee wrote: post #126

At least third major compromise in two weeks. (last comment: https://news.ycombinator.com/item?id=45172225 ) (before that: https://news.ycombinator.com/item?id=45039764 ) 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-…

"2) mandatory 2FA (with the option for things like passkeys with hardware tokens)."

No, with the _requirement_ for passkeys or hardware tokens!

Post reply on HN