DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
101–110 of 296 posts
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#102This 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…
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.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#103Serious 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?
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#104This 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…
> 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.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#105Earlier 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…
> 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/…
Yeah, that's true, I hit this all the time with 1Password+Firefox+Linux (fun combo).
Just copying-pasting the username+password because it doesn't show up is the wrong approach. It gives you a chance to pause and reflect, since it isn't working, so in that case you lookup if it's actually the right domain, and if it is, add it to the allowed domains so it works fine in the future.
Maybe best would be if password managers defaulted to not showing a "copy" thing at all for browser logins, and not letting users select the password, instead prompting them to rely on the autofill, and fix the domains if the autofill doesn't work.
Half the reason I use password manager in the first place is specifically for this issue, the other half is because I'm lazy and don't like typing. It's really weird to hear people using password managers yet do the old copy-paste dance anyways.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#106Earlier 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.
Removing humans will help
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#107This 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…
* signed packages
enforce it for the top x thousand most popular packages to start
some basic hygiene about detecting unique new user login sessions would help as well
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#108Earlier quoted context omitted.
It is, if your packages are popular enough then npm will force you to enable 2FA. They started doing that a few years ago. It clearly doesn't stop everything though, the big attack yesterday went through 2FA by tricking the author into doing a "2FA reset".
Passkeys should be enforced
Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#109Earlier quoted context omitted.
... 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
#110This 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…
> 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.
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 by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.