DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

This does nothing for the case of receiving a fake coinbase sms with a fake contact phone number.

I have had people attempt fraud in my work with live calls as follow up to emails and texts. I only caught it because it didn't pass the smell test so I did quite a bit of research. Somebody else got caught in the exact same scam and I had to extricate them from it. They didn't believe me at first and I had to hit them over the head a bit with the truth before it sank in.

This exactly. It's actually wild how much valid emails can look like phishing emails, and how confusing it is that companies use different domains for critical things.

One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your primary one?

It also annoys me when people see this happening and point out how the person who fell for the attack missed some obvious detail they would have noticed. That's completely irrelevant, because everyone is stupid sometimes. Everyone can be stressed out and make bad decisions. It's always a good idea to make it harder to make bad decisions.

Too many services will send you 2FA codes from different numbers per request.

The problem is there is no continuity. An email from an organisation that has emailed you a hundred times before looks the same as an email from somebody who has never emailed you before. Your inbox is a collection of legitimate email floating in a vast ocean of email of dubious provenance.

I think there’s a fairly straightforward way of fixing this: contact requests for email. The first email anybody sends you has an attachment that requests a token. Mail clients sort these into a “friend request” queue. When the request is accepted, the sender gets the token, and the mail gets delivered to the inbox. From that point on, the sender uses the token. Emails that use tokens can skip all the spam filters because they are known to be sent by authorised senders.

This has the effect of separating inbound email into two collections: the inbox, containing trustworthy email where you explicitly granted authorisation to the sender; and the contact request queue.

If a phisher sends you email, then it will end up in the new request queue, not your inbox. That should be a big glaring warning that it’s not a normal email from somebody you know. You would have to accept their contact request in order to even read the phishing email.

I went into more detail about the benefits of this system and how it can be implemented in this comment:

https://news.ycombinator.com/item?id=44969726

The same problem applies to gpg. If companies can not manage to use consistent from addresses then do you really expect them to do any better with gpg key management?

"All legitimate npm emails are signed with GPG key X" and "All legitimate npm emails come from @npmjs.com" are equally strong statements.

But in the same vein the phishing email can easily be gpg signed too. The problem is to check if the gpg key used to sign the email is legitimate, but that is exactly the same problem as checking if the from address is legitimate.

`curl URL | sudo sh` doesn't have a means of verification of what the contents of the URL points to.

Sure a binary can be swapped in other places, but they generally can be verified with hashes and signatures. Also, a plaintext install script often has this problem in another layer of recursion (where the script usually pulls from URLs that the runner of the script cannot verify with this method)

It is sometimes possible to detect server-side whether the script is being run immediately with `| sh` or not. The reason is that `sh` only reads from its input as far as it got in the script, so it takes longer to get to the end than if you'd curl show the result in the terminal directly (or pipe it to a file).

A server can use this to maliciously give you malware only if you're not looking at the code.

Though your point about trust is valid.

Even standard autofill (as in that built into Safari, Firefox, Chrome etc) gets tripped up on 100% legit sites shockingly often. Usually the cause is the site being botched, with mislabeled fields or some unnecessarily convoluted form design that otherwise prevents autofill from doing its thing.

Please people, build your login forms correctly! It’s not rocket science.

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

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.

This hasn't been my experience at all. I regularly check the bitwarden icon for example to make sure I am not on the wrong site (b/c my login count badge is there). In fact autofill has saved me before because it did not recognize the domain and did not fill.

I use a separate app like this because I do not fully trust browser security. The browser is such a tempting hacking target (hardened, for sure) that I want to know my vault lives in an offline-only area to reduce chance of leaks.

Is there some middle ground where I can get the browser to automatically confirm I am on a previously trusted domain? My initial thought is that I could use Firefox Workspaces for trusted domains. Limited to the chosen set of urls. Which I already do for some sites, but I guess I could expand it to everything with a login.

You are probably right. Still browser vendors or even extension devs can create a system where username hash and password hash are stored and checked on submit to warn for phishing. Not sure if I would trust such extension, except in case it's FF recommended and verified extension.

Nearly every email link now goes through an analytics domain that looks like a jumble of random characters. In the best case they end up at the expected site, but a significant number go to B2B service provider of the week’s domain.

There are more than a few instances when I’ve created an account for a service I know I’ve never interacted with before, but my password manager offered to log me in because another business I’ve used in the past used the same service (medical providers, schools, etc.).

Even as a technically competent person, I received a legitimate email from Google regarding old shadow accounts they were reconciling from YouTube and I spent several hours convinced it was a phishing scheme.it put me on edge for nearly a week that there was no way I could be sure critical accounts were safe, and worse yet, someone like my parents or in-laws could be safe.

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)

more alarming than .help domain is the domain registration just few weeks ago. I got scammed just last week when paying with credit card online, and only later when investigating discovered several of identical eshops with different .shop domains registered just months ago if domain is less that year old, it should raise red flags

I don't see why you're surprised. It is a key identifier for scam emails. Or at least it was until recently. I don't think anyone was under the impression that scammers could never possibly learn good English.

I mean most of the time it's the companies themselves that teach people bad habits.

MyBank: "Don't click on emails from suspicious senders! Click here for more information" { somethingweirdmybank.com } -- Actual real email from my bank.

Like, wtf. Why are you using a totally different domain.

And the companies I've worked for do this kind of crap all the time. "Important company information" { learnaboutmycompany.com } -- Like, is this a random domain someone registered. Nope, actually belongs to the place I work for when we have a well known and trusted domain.

Oh, and it's the best when the legit sites have their own spelling mistakes.

If your someone who barely speaks English in a third world country running a phishing campaign, you can have chatgpt write you a professional sounding email in 10 seconds. If you convince it your running a phishing test you can probably even have a back and forth about the entire design and wording of the email and phishing site.

That's what I'm guessing OP meant.

You can make your phishing bot write tailor-made messages and even respond

The password manager's autofill browser extension gets compromised.

Yes we tried, but npm would not let us because of "dependencies". We've reached out to them and are waiting for a response. In the meantime, we re-published the packages with newer versions so people won't accidentally install the compromised version.