Live data from Hacker News

DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

github.com

231–240 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#231

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?

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?

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#232
post #196

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

OK, a week for popular packages, anything else I'd manually review each update. It'd be a nice feature.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#233
> ... One of the maintainers read through this text and found it somewhat reasonable. He followed the link (now defunct) to a website hosted under the domain npmjs.help. This website contained a pixel-perfect copy of the npmjs.com website. He logged in using the duckdb_admin user and password, followed by 2FA. Again, the user profile, settings etc. were a perfect copy of the npmjs.com website including all user data. As requested by the email, he then re-set the 2FA setup.

This is absolutely wild that this did not raise _any_ red flags to this person.

red flag: random reset for 2FA ??? red flag: npmjs.help ??? red flag: user name and password not autofilled by browser ??? red flag: copy and pasting u/p combo into phishing site

If _developers_ can't even get this right. Why do we expect dumb users to get this right? We are so cooked.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#234

Earlier quoted context omitted.

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?

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.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#235

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…

Do you know about other security issues? If it's only about curl | sh it really isn't a problem, if the same website showed you a hash to check the file then the hash would be compromised at the same time as the file, and with a package manager you still end up executing code from the author that is free to download and execute anything else. Most package managers don't add security.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#236

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…

Nothing is plausible about this phishing mail - writing "update your password now" would be understandable but "update your 2FA now"? Never EVER seen this on any real site and it doesn't make sense (rotating passwords doesn't make sense either but not everyone got the memo).

I literally, just a couple of days ago, got an email from Microsoft Azure asking me to update my 2FA. And I had already set up a passkey, so 2FA shouldn't even have been needed!

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

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

Yes, use FIDO, you'll be better off, but no, passkeys aren't immune to account takeover. E.g. not only does GitHub support OAuth apps, it supports device code flow, and thus: https://www.praetorian.com/blog/introducing-github-device-co....

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#238

Earlier quoted context omitted.

> I always have to manually copy/paste the credentials. 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)

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

> If you're talking about a malicious desktop app running on the same system, it's game over anyway because it can read process memory, read keystrokes, etc.

The app does not have to be overtly malicious, AccuWeather (among others) was caught exfiltrating users' clipboard data for over 4 years to an analytics company who may or may not have gotten compromised. Even if the direct application you are using is non-malicious, you are left hoping wherever your data ends up isn't a giant treasure trove/honeypot waiting to be compromised by attackers.

The same reasoning can be used for pretty much anything really, why protect anything locally since they could just keylog you or intercept requests you make.

In that case it would be safer for everyone to run Qubes OS and stringently check any application added to their system.

In the end it's a balancing act between convenience and security with which striving for absolute perfection ends up being an enemy of good.

> Sidenote: Most password managers I've used automatically clear the clipboard 10-15s after you copy a credential.

That is true, good password managers took these steps precisely to reduce the clipboard attack surface.

Firefox also took steps in 2021 to also limit leaking secrets via the clipboard.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#239
post #178

Earlier quoted context omitted.

As mentioned elsewhere in this thread, the password manager failing to autofill is hardly unheard of.

As also mentioned elsewhere in this submission, it doesn't matter how often autofill breaks/works. There are two cases where it breaks: The accounts not showing up in the password manager modal, and the website autofill not working. The first is what prevents phishing, the second doesn't really matter to prevent phishing or not. The idea is that if your password manager doesn't show the usual list of accounts (regard…

Yes, the idea you are presenting is that the human being must manually check for mistakes. As should be clear by now, this idea does not work at scale. Passkeys will automate and enforce the check, removing human error from the equation.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#240
post #190

Serious question, how did the attacking site (npmjs.help) know the victim's 2fa? ie. How did they know what phone number to send the 2fa request to?

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.
Post reply on HN