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

251–260 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#251

Post by [deleted] »

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…

[deleted]

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#252

Post by galaxy_gas »

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…

The PHP primary package manager does this similar in what you write - https://getcomposer.org/download/

It is amazing that a duckdb could be worse than decade old PHP for something such as this.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#253

Post by kentm »

elric wrote: post #110
egorfine wrote: post #102

Earlier quoted context omitted.

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

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

> where one moment of inattention by one person

I'll get a lot of pushback for this, but the main problem are ecosystems that encourage using packages published by one person. I call these "some person with a github" packages, and I typically go through codebases to try to remove these dependencies specifically because of this threat vector.

Packages that are developed by a team with code multiple code reviewers and a process are still at risk, don't get me wrong. But the risk is much less if one person does not have the power to unilaterally merge a PR, and more-so if its backed by an organization that has multiple active devs and processes for reviews.

If you do need to depend on these one-person packages, I'd recommend forking and carefully merging in changes, or pinning versions and manually reviewing all commits before upgrading versions. Thats probably intractable for a lot of projects, but thats honestly something that we as developers need to fix by raising the bar for what dependencies we include.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#254

Post by cuu508 »

parliament32 wrote: post #172
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…

> it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it USE PASSKEYS. Passkeys are phishing-resistant MFA, which has been a US govt directive for agencies and suppliers for three years now[1]. There is no excuse for infrastructure as critical as NPM to still be allowing TOTP for MFA. [1] https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...

Use WebAuthn as the second factor. Passkeys are a single factor authentication, and a downgrade from password+WebAuthn.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#255

Post by cuu508 »

JimDabell wrote: post #234
artemisart wrote: post #231

Earlier quoted context omitted.

Why should we expect companies to be able to reuse the correct token if they can't coordinate on using a single domain in the first place?

Your assumption that they use more than one domain by accident due to a lack of coördination is not correct. Separating, e.g. your product email from your mailing list email from your corporate email has a number of benefits. Anyway, I already mentioned a solid incentive for them to use the correct token. Go back and read my earlier comment.

It is correct at least in some cases. https://news.ycombinator.com/item?id=45190323

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#256

Post by neilv »

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…

> This is critical infrastructure, and it gets compromised way too often.

Most times that I go to use some JS, Python, or (sometimes) Rust framework, I get a sinking feeling, as I see a huge list of dependencies scroll by.

I know that it's a big pile of security vulnerabilities and supply-chain attack risk.

Web development documentation that doesn't start with `npm install` seems rare now.

Then there's the 'open source' mobile app frameworks that push you to use the framework on your workstation with some vendor's Web platform tightly in the loop, which all your code flows through.

Children, who don't know how things work, will push any button. But experienced software engineers should understand the technology, the business context, and the real-world threats context, and at least have an uneasy, disapproving feeling every time they work on code like this.

And in some cases -- maybe in all cases that aren't a fly-by-night, or an investment scam, or a hobby project on scratch equipment -- software engineers should consider pushing back against engaging in irresponsible practices that they know will probably result in compromise.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#257

Post by karel-3d »

npm actually does send these emails. They are about setting up 2FA though. And never have this sense of urgency.

"Hi, XXXX! It looks like you still do not have two-factor authentication (2FA) enabled on your npm account.

To enable 2FA, please follow the instructions found here."

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#258

Post by karel-3d »

eviks wrote: post #67
stanac wrote: post #64

Earlier quoted context omitted.

My password manager is a separate app, I always have to manually copy/paste the credentials. That's because I believed that approach to be more secure, now I see it's replacing one attack vector for another.

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

just recently there was a clickjacking attack that affected most popular password manager extensions. It tricked the managers into filling passwords to random pages, worked on almost all extensions and all pages.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#259

Post by zahlman »

JimDabell wrote: post #228
waynesonfire wrote: post #225

Earlier quoted context omitted.

You can just filter emails based on their from addresses.

So if an organisation emails you from no-reply@notifications.example.com, mailing-list@examplemail.com, and bob.smith@examplecorp.com, and the phisher emails you from support@example.help, which filter based on their from addresses makes all the legitimate ones show up as the same sender while excluding the phishing email?

> which filter based on their from addresses makes all the legitimate ones show up as the same sender while excluding the phishing email?

This is the wrong question.

The right question is: what should we do about the fact that the organization has such terrible security practice?

And the answer is: call them on the phone, and tell them that you will not do business with them until they fix their shit.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#260

Post by zahlman »

behindsight wrote: post #238
mtlynch wrote: post #227

Earlier quoted context omitted.

> I really hope you clear your clipboard history entirely after doing your copy/paste method because your credentials would otherwise persist for any other application with clipboard perms to just exfiltrate (which has already been exploited in the wild before) How does that work? If a malicious website reads the clipboard, what good is knowing an arbitrary password with no other information? If the user is using a p…

Interesting questions, I can later provide more links to more indepth security resources that go over similar points if you would be interested but currently on my phone so I will just jot down some quick surface level points. > If a malicious website reads the clipboard, what good is knowing an arbitrary password with no other information? Even if assuming unique username+url pairings, clipboard history can store mu…

> Even if assuming unique username+url pairings, clipboard history can store multiple items including emails or usernames which could be linked to any data breach and service (or just shotgunned towards the most popular services). It's not really a "no other information" scenario and you drastically reduce the effort required for an attacker regardless.

I always manually type the emails and usernames for this reason.

(A keylogger is already game over, so.)

Post reply on HN