Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We all dodged a bullet

xeiaso.net

Post reply on HN
Print view View original

181–190 of 498 posts

Re: We all dodged a bullet

#181

Post by andrewstuart2 »

pluto_modadic wrote: post #89
com2kid wrote: post #58

Earlier quoted context omitted.

> You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit? Because the way this was pulled off, it was going to be found out right away. It wasn't a subtle insertion, it was a complete account take over. The attacker had only hours before discovery - so the logical thing to do is a hit and run. They asked what is the most money that can be extracted…

"found out right away"... by people with time to review security bulletins. There's loads of places I could see this slipping through the cracks for months.

I'm assuming they meant the account takeover was likely to be found out right away. You change your password on a major site like that and you're going to get an email about it. Login from a new location also triggers these emails, though I admit I haven't logged onto NPM in quite a long time so I don't know that they do this.

It might get missed, but I sure notice any time account emails come through even if it's not saying "your password was reset."

Re: We all dodged a bullet

#183

Post by kccqzy »

yencabulator wrote: post #134
fiatpandas wrote: post #110

His email client even puts a green check mark next to the fake NPM email. UX fail.

The claim is valid -- it is legit from npm.help If you think npm.help is something it isn't, that's not something DKIM et al can help with.

Do you remember a few years ago that browsers used to put a lock icon for all HTTPS connections? That lock icon signified that the connection is encrypted alright. To a tech geek that's a valid use of a lock icon. But browsers still removed it because it's a massive UX fail. You have to consider what the lock icon means to people who are minimally tech literate. I understand and have set up DKIM and SPF, but you cannot condense the intended security feature of DKIM/SPF/DMARC into a single icon and expect that to be good UX.

Re: We all dodged a bullet

#184

Post by charlieyu1 »

quectophoton wrote: post #62
_fat_santa wrote: post #13

I know this isn't really possible for smaller guys but larger players (like NPM) really should buy up all the TLD versions of "npm" (that is: npm.io, npm.sh, npm.help, etc). One of the reasons this was so effective is that the attacker managed to snap up "npm.help"

Then you have companies like AWS, they were sending invoices from `no-reply-aws@amazon.com` but last month they changed it to `no-reply@tax-and-invoicing.us-east-1.amazonaws.com`. That looks like a phishing attempt from someone using a random EC2 instance or something, but apparently it's legit. I think . Even the "heads-up" email they sent beforehand looked like phishing, so I was waiting for the actual invoice to s…

I thought facebookmail.com was fake. No, it is actually legit

Re: We all dodged a bullet

#185

Post by dirkc »

I had a minor scare some time ago with npm. Can't remember the exact details, something like I had a broken symlink in my homedir and nodemon printed an error about the symlink! My first thought was it's a supply chain attack looking for credentials!

Since then I've done all my dev in an isolated environment like a docker container. I know it's possible to escape the container, but at least that raises the bar to a level I'm comfortable with.

Re: We all dodged a bullet

#187

Post by mlinksva »

As the post mentions wallets like MetaMask being the targets, AFAIK MetaMask in particular might be one of the best protected (isolated) applications from this kind of attack due to their use of LavaMoat https://x.com/MetaMask/status/1965147403713196304 -- though I'd love to read a detailed analysis of whether they actually are protected. No affiliation with MetaMask, just curious about effectiveness of seemingly little adopted measures (relative to scariness of attacks).

Added: story dedicated to this topic more or less https://news.ycombinator.com/item?id=45179889

Re: We all dodged a bullet

#188

Post by jcelerier »

stickfigure wrote: post #43
dsff3f3f3f wrote: post #5

> These kinds of dependencies are everywhere and nobody would even think that they could be harmful. Tons of people think these kind of micro dependencies are harmful and many of them have been saying it for years.

It wouldn't be a problem if there wasn't a culture of "just upgrade everything all the time" in the javascript ecosystem. We generally don't have this problem with Java libraries, because people pick versions and don't upgrade unless there's good reason.

and then you get Log4Shell

Re: We all dodged a bullet

#189

Post by AlienRobot »

mxuribe wrote: post #160
AlienRobot wrote: post #90

Isn't it a bit crazy that phishing e-mails still exist? Like, couldn't this be solved by encrypting something in a header and using a public key in the DNS to unencrypt it?

I'm not a top-level expert in cybersecurity nor email infra....but the little that i know has taught me that i merely have to create a similar-looking domain name... Let's say there's a company named Awesome...and i register the domain name of AwesomeSupport.com. I could be a total dark hat/evil hacker/neverdoweller....and this domain may not be infringing on any trademark, etc. And, then i can start using all the en…

This honestly doesn't feel like it should be the case.

There aren't that many websites. The e-mail provider could have a list of "popular" domains, and the user could have their own list of trusted domains.

There is all sorts of ways to warn the user about it, e.g. "you have never interacted with this domain before." Even simply showing other e-mails from the same domain would be enough to prevent phishing in some cases.

There are practical ways to solve this problem. They aren't perfect but they are very feasible.

Re: We all dodged a bullet

#190

Post by ameliaquining »

bob1029 wrote: post #113

"Batteries included" ecosystems are the ultimate defense against the dark arts. Your F100 first party vendor might get it wrong every now and then, but they have so much more to lose than a random 3rd party asshole who decides to deploy malicious packages. The worst thing I can recall from the enterprisey ecosystems is the log4j exploit, which was easily one of the most attended to security problems I am aware of. Ev…

Log4Shell didn't light up all the beacons because Java is "enterprisey", it was because it was probably the worst security vulnerability in history; not only was the package extremely widely used, the vulnerability existed for nearly a decade and was straightforwardly wormable, so basically everybody running Java code anywhere had to make sure to update and check that they hadn't been compromised. Which is just a big project requiring an all-out response, since it's hard to know where you might have something running. By contrast, this set of backdoors only existed for a few hours, and the scope of the vulnerability is well-understood, so most developers can be pretty sure they weren't impacted and will have quite reasonably forgotten about it by next week. It's getting attention because it's a cautionary tale, not because it's causing a substantial amount of real damage.

I do think it's worth reducing the number of points of failure in an ecosystem, but relying entirely on a single library that's at risk of stagnating due to eternal backcompat obligations is not the way; see the standard complaints about Python's "dead batteries". The Debian or Stackage model seems like it could be a good one to follow, assuming the existence of funding to do it.

Post reply on HN