Live data from Hacker News

DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

github.com

71–80 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

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

The could force release candidates that the package managers don't automatically update to, but let researchers analyse the packages before the real release.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#72

Earlier quoted context omitted.

How is that different?

Passkeys are unphishable because there is nothing to type in. And they are locked to an origin by design, so you can’t accidentally use one on the wrong domain because the browser simply won’t do it.

... and they are not transferrable, tied to BigCorp & Friends.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#73
post #70

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. The domain was also plausible. I don't get these arguments. Yeah, of course I was always surprised phishing emails give itself away with mistakes as maybe non-native speakers create it without any spellcheck or whatever and it was straight forward to improve that... but whatever the text, if I open a link from email the first thing I look at is…

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)

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#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 care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform.

Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks.

And while we're at it, it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it, but it's clear that the actions in this example were suspicious: user logs in, changes 2FA settings, immediately adds a new API token, which immediately gets used to publish packages. Maybe there should be a 24 hour period where nothing can be published after changing any form of credentials. Accompanied by a bunch of signed notification emails. Of course that's all moot if the attacker also changes the email address.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#75

Maybe email software should add an option to make links unclickable, or show a box with the clear link (and highlight the domain) before letting the user go through it. They already make links go through redirects (to avoid referrer headers?) so it's halfway there. Just make the redirect page show the link and a go button instead of redirecting automatically. And it would fix the annoyance that is not being able to s…

So many legit emails contain links that pass through some kind of URL shortener or tracker (like mailchimp does). People are being actively conditioned to ignore suspicious looking URLs.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#76

Comes with the territory considering that npm is defacto the number one enshittification dependency by now. But no worries - this will scale beautifully. downvotes appreciated but also happy to see one or two urls that would prove me wrong

I think the downvotes are because enshittification is a different thing, intentionally done by the developers themselves.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#77
post #72

Earlier quoted context omitted.

Passkeys are unphishable because there is nothing to type in. And they are locked to an origin by design, so you can’t accidentally use one on the wrong domain because the browser simply won’t do it.

... and they are not transferrable, tied to BigCorp & Friends.

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#78

Earlier quoted context omitted.

This is a joke right? Can’t say I’ve ever heard of USB ports referred to as “holes”.

No I'm serious. I used to work on a PC and I had the correct hole, but I never figured out how to make yubikey useful and of course I couldn't use it with my phone. Maybe I'm missing something?

If it supports NFC, you can use that (mine do, I use them on my phone), otherwise you’d need an adapter, which is clunky but workable.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

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

They could definitely add a maker-checker process (similar to code review) for new versions and make it a requirement for public projects with x number of downloads per week.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

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

TRUE! A simple self defined word in an email and you will see, if the mail is fake or not.
Post reply on HN