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

191–200 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#191

Post by feross »

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

Disclosure: I’m the founder of https://socket.dev

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#192

Post by feross »

bakugo wrote: post #4

> According to the npm statistics, nobody has downloaded these packages before they were deprecated 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?

Disclosure: I’m the founder of https://socket.dev

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#193

Post by kevinrineer »

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.

`curl URL | sudo sh` doesn't have a means of verification of what the contents of the URL points to.

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)

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#194

Post by bobbylarrybobby »

0cf8612b2e1e wrote: post #168
hiccuphippo wrote: post #52

Earlier quoted context omitted.

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

You could run two password managers, with a fake one that's a clone of the real one but with fake passwords. Only the fake one is connected to the browser. If the browser suggests a password from the fake pw manager, you go to the real one and copy it in.

Not actually suggesting this as it sounds like quite a big headache, but it is an option.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#195

Post by JimDabell »

zokier wrote: post #165
JimDabell wrote: post #122

Earlier quoted context omitted.

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.

Unfortunately, it’s not that simple. It’s extremely common for the same organisation to send emails from different addresses, different domains, and different servers, for many different reasons.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#196

Post by feross »

ptrl600 wrote: post #123

Is there a way to configure npm that it only installs packages that are, like, a week old?

Disclosure: I’m the founder of https://socket.dev

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#197

Post by 0cf8612b2e1e »

bobbylarrybobby wrote: post #194
0cf8612b2e1e wrote: post #168

Earlier quoted context omitted.

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

You could run two password managers, with a fake one that's a clone of the real one but with fake passwords. Only the fake one is connected to the browser. If the browser suggests a password from the fake pw manager, you go to the real one and copy it in. Not actually suggesting this as it sounds like quite a big headache, but it is an option.

Honestly, that’s not a terrible idea. There are only a half dozen accounts which actually matter, so there is not even that much initial configuration burden. If I get phished for my HN account, oh well.

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#198

Post by IshKebab »

nightski wrote: post #92
jasode wrote: post #87

Earlier quoted context omitted.

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

This hasn't been my experience at all. I regularly check the bitwarden icon for example to make sure I am not on the wrong site (b/c my login count badge is there). In fact autofill has saved me before because it did not recognize the domain and did not fill.

Yeah nor mine. Chrome's password manager / autofill is very reliable and very few sites don't work with it or have multiple domains with the same auth. The only one I can think of is maybe Synopsys Solvnet, but you're probably not using that...

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#199

Post by IshKebab »

worble wrote: post #99
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…

> Normally they're full of spelling mistakes and unprofessional grammar. 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?

I don't see why you're surprised. It is a key identifier for scam emails. Or at least it was until recently. I don't think anyone was under the impression that scammers could never possibly learn good English.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#200

Post by 0cf8612b2e1e »

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.

Too many services will send you 2FA codes from different numbers per request.
Post reply on HN