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

121–130 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#121

Post by cosmic_cheese »

jasode wrote: post #87
IshKebab wrote: post #44

Earlier quoted context omitted.

Probably the differentiating factor here is that the phishing message was very plausible. Normally they're full of spelling mistakes and unprofessional grammar. The domain was also plausible. I think where they got lucky is > In hindsight, the fact that his browser did not auto-complete the login should have been a red flag. A huge red flag. I wonder if browsers should actually detect if you're putting login details…

> In hindsight, the fact that his browser did not auto-complete the login should have been a red flag. >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/…

Even standard autofill (as in that built into Safari, Firefox, Chrome etc) gets tripped up on 100% legit sites shockingly often. Usually the cause is the site being botched, with mislabeled fields or some unnecessarily convoluted form design that otherwise prevents autofill from doing its thing.

Please people, build your login forms correctly! It’s not rocket science.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#122

Post by JimDabell »

elric wrote: post #96
zokier wrote: post #86

Earlier quoted context omitted.

Spf/dkim already authenticates the sender. But it doesn't help if the user doesn't check who the email is from. But in that case gpg would not help that much either.

SPF & DKIM are all but worthless in practice, because so many companies send emails from garbage domains, or add large scale marketing platforms (like mailchimp) to their SPF records. 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 pus…

The problem is there is no continuity. An email from an organisation that has emailed you a hundred times before looks the same as an email from somebody who has never emailed you before. Your inbox is a collection of legitimate email floating in a vast ocean of email of dubious provenance.

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:

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#124

Post by vel0city »

wavemode wrote: post #109
Semaphor wrote: post #77

Earlier quoted context omitted.

I use a hardware key as passkey where supported, nothing ties me to anything but those keys. Also there are OSS software managers that support them, like KeePass and friends.

does your hardware key work on mobile? or do you now need to maintain two keys for every service?

Yes, my hardware keys work on my mobile devices as well.

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#126

Post by 0xbadcafebee »

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#127

Post by ignoramous »

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…

> Can package publishing platforms PLEASE start SIGNING emails

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#128

Post by vel0city »

diggan wrote: post #45
koakuma-chan wrote: post #33

Earlier quoted context omitted.

Npm can't force people to use password manager

Nor does TOTP+password lock you to one authentication provider indefinitely. Tradeoffs :)

I've got passkeys from multiple "authentication providers" available on all of my devices. This isn't a tradeoff.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#129

Post by diggan »

maltee wrote: post #51
diggan wrote: post #45

Earlier quoted context omitted.

Nor does TOTP+password lock you to one authentication provider indefinitely. Tradeoffs :)

You can always register a new passkey with the site if you want to switch authentication providers, can’t you?

Yeah, I guess that'd work if I had a couple of accounts, but since there a bunch of them, I really need proper import/export to feel comfortable with moving to it. I just know I'd punt the task of migrating everything if I have to go account-by-account to migrate away.

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.

Post reply on HN