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

241–250 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#241

Post by yawaramin »

cesarb wrote: post #177
frizlab wrote: post #108

Earlier quoted context omitted.

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

You can just create a new passkey on the new device after logging in. It's a non-issue.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#242

Post by mdaniel »

SoftTalker wrote: post #230
OkayPhysicist wrote: post #218

Earlier quoted context omitted.

I can answer why this is at the company I work at right now: It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will gene…

Are you arguing that it’s a good idea for random developers to be able to set up new subdomains on the company domain without any oversight?

Do they work there or not? I deeply appreciate that everyone's threat model is different, but I'd bet anyone that wants to create a new DNS record also has access to credentials that would do a ton more actual damage to the company if they so chose

Alternatively, yup, SOC2 is a thing: optionally create a ticket tracking the why, then open a PR against the IaC repo citing that ticket, have it ack-ed by someone other than the submitter, audit trail complete, change managed, the end

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#243

Post by mdaniel »

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.

No guessing required, DKIM was intact, but it was also sent via a transactional email service, so that's why https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#244

Post by mdaniel »

400thecat wrote: post #84
bluGill wrote: post #73

Earlier quoted context omitted.

Unicode means that domain names can be different and look the same unless you really look close. Even if you just stick to ascii l (letter) and 1 (number) look so close that I would expect many people to not see the difference if it isn't pointed out. (remember you don't control the font in use, some are more different than others)

I think, firefox allows you to display url without uncicode

Given a test of https:// news.ycombınator.com [1] it seems that no, hovering over the URL shows it in its rendered form

  data:text/html,login to news.ycombinator.com
and only by clicking it and getting an NXDOMAIN does one see the Punycode:

> We can’t connect to the server at news.xn--ycombnator-1ub.com.

1: Ironically HN actually mutated that link, I pasted the unicode version news.ycombınator.com (which it seems to leave intact so long as I don't qualify it with a protocol://)

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#245

Post by mdaniel »

0xbadcafebee wrote: post #214
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…

> Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right? They should only need http. You don't need https at all if your package is signed. The package/installer/app/etc could come from anywhere, modified by anyone, at any level. But if it's not signed by the dev's private key (which only exists on their laptop [or hardware…

  curl -f
I'm super sad they didn't make --fail the default, and people that don't care could opt-out with --no-fail

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#246

Post by mdaniel »

kaelwd wrote: post #155
ebfe1 wrote: post #19

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

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.

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#247

Post by feross »

yawaramin wrote: post #240
feross wrote: post #190

Earlier quoted context omitted.

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.

And by 'fail' we mean that passkeys would have successfully prevented the attack.

Correct!

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#248

Post by EE84M3i »

kaoD wrote: post #88
eviks wrote: post #67

Earlier quoted context omitted.

What's the most common example of an alternative attack with autofill?

The password manager's autofill browser extension gets compromised.

This used to happen with some frequency but I haven't heard of it happening in some time now.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#249

Post by 3eb7988a1663 »

yawaramin wrote: post #241
cesarb wrote: post #177

Earlier quoted context omitted.

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

You can just create a new passkey on the new device after logging in. It's a non-issue.

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

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#250

Post by chatmasta »

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…

DuckDB is not critical infrastructure and I don’t even think these billion-download packages are critical infrastructure. In software everything can be rolled back and that’s exactly what happened here. Yes we were lucky that someone caught this rather sloppy exploit early, and (you can verify via the wallet addresses) didn’t make any money from it. And it could certainly have been worse.

But I think calling DuckDB “critical infrastructure” is just a bit conceited. As an industry we really overestimate the importance of our software that can be deleted when it’s broken. We take ourselves way too seriously. In any worst case scenario, a technical problem can be solved with a people solution.

If you want to talk about critical infrastructure then the xz backdoor was the closest we’ve caught to affecting it. And what came of that backdoor? Nothing significant… I suppose you could say there might be 100 xz-like backdoors lurking in our “critical infrastructure” today, but at least as long as they’re idle, it’s not actually a problem. Maybe one day China will invade Taiwan and we’ll see just how compromised our critical infrastructure has actually been this whole time…

Post reply on HN