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

161–170 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#161

Post by vel0city »

egorfine wrote: post #138
elric wrote: post #110

Earlier quoted context omitted.

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

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#162

Post by tomsmeding »

dansmith1919 wrote: post #150
throwaway127482 wrote: post #143

Earlier quoted context omitted.

Genuine question: why is `curl https://trusted-site.com | sh` a security 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…

I assume OP's point is "you're running a random script directly into your shell!!" 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.

It is sometimes possible to detect server-side whether the script is being run immediately with `| sh` or not. The reason is that `sh` only reads from its input as far as it got in the script, so it takes longer to get to the end than if you'd curl show the result in the terminal directly (or pipe it to a file).

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#163

Post by kyle-rb »

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#164

Post by 0cf8612b2e1e »

vitonsky wrote: post #137

Just for context. DuckDB team is consistently ignores any security practices. 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 pu…

They also publish binaries on their GitHub if you prefer that.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#165

Post by zokier »

JimDabell wrote: post #122
elric wrote: post #96

Earlier quoted context omitted.

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 a…

You don't need complex token arrangements for this. You can just filter emails based on their from addresses.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#166

Post by InsideOutSanta »

chrisweekly wrote: post #131
evantbyrne wrote: post #114

Earlier quoted context omitted.

The email was sent from the 'npmjs dot help' domain. I'm not saying you're wrong, but also basic due diligence would have prevented this. If not by email, the maintainer may have been able to be compromised over text or some other medium. And today maintainers of larger projects can avoid these problems by not importing and auto-updating a bunch of tiny packages that look like they could have been lifted from stack o…

Re: "npmjs dot help", way too many companies use random domains -- effectively training their users to fall for phishing attacks.

This exactly. It's actually wild how much valid emails can look like phishing emails, and how confusing it is that companies use different domains for critical things.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#167

Post by InsideOutSanta »

egorfine wrote: post #102
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…

> You can't rely on people not falling for phishing 100% of the time 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.

> If it is true that people are the failing factor, then nothing is going to help

Nothing will reduce incidents to 0, but many things can move us closer to 0.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#168

Post by 0cf8612b2e1e »

hiccuphippo wrote: post #52
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…

My guess is their password manager is a separate app and they use the clipboard (or maybe it's a keyboard app) to paste the password. No way for the password manager to check the url in that case.

I use a separate app like this because I do not fully trust browser security. The browser is such a tempting hacking target (hardened, for sure) that I want to know my vault lives in an offline-only area to reduce chance of leaks.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#169

Post by elric »

ignoramous wrote: post #127
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…

I don't think signed email would solve phishing in general. But for a service by-and-for programmers, I think it at least stands a chance.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#170

Post by zokier »

vel0city wrote: post #159
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.

There's little reason to think these emails didn't pass SPF/DKIM. They probably "legitimately" own their npmjs[.]help domain and whatever server they used to send the emails is probably approved by them to send for that domain.

But in the same vein the phishing email can easily be gpg signed too. The problem is to check if the gpg key used to sign the email is legitimate, but that is exactly the same problem as checking if the from address is legitimate.
Post reply on HN