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?
DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
231–240 of 296 posts
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#232Is 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
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#233This 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
#234Earlier 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?
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
#235Just 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…
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#236Earlier 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).
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#237This 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...
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#238Earlier 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…
> 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
#239Earlier 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…
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#240Serious 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.