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

351–360 of 498 posts

Re: We all dodged a bullet

#351

Post by 0xDEAFBEAD »

cjalmeida wrote: post #108
gmueckl wrote: post #65

Earlier quoted context omitted.

Java went down that road with the applet sandboxing. They thought that this would go well because the JVM can be a perfect gatekeeper on the code that gets to run and can see and stop all calls to forbidden methods. It didn't go well. The JVM did it's part well, but they couldn't harden the library APIs. They ended up playing whack-a-mole with a steady stream of library bugs in privileged parts of the system librarie…

It was too complex. Just making system calls require white listing libraries goes a long way of preventing a whole class of exploits. There’s no reason a color parser, or a date library should require network or file system access.

The simplest approach to whitelisting libraries won't work, since the malicious color parser can just call the whitelisted library.

A different idea: Special stack frames such that while that frame is on the stack, certain syscalls are prohibited. These "sandbox frames" could be enabled by default for most library calls, or even used by developers to handle untrusted user input.

Re: We all dodged a bullet

#352

Post by nurettin »

com2kid wrote: post #58
sebstefan wrote: post #48

Dodged a bullet indeed I find it insane that someone would get access to a package like this, then just push a shitty crypto stealer. You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit? You can exfiltrate API keys, add your SSH public key to the server then exfiltrate the server's IP address so you can snoop in there manually, if you're on a dev…

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

> They asked what is the most money that can be extracted in just a few hours in an automated fashion (no time to investigate targets manually one at a time) and crypto is the obvious answer.

A decade ago my root/123456 ssh password got pwned in 3-4 days. (I was gonna change to certificate!)

Hetzner alerted me saying that I filled my entire 1TB/mo download quota.

Apparently, the attacker (automation?) took over and used it to scrape alibaba, or did something with their cloud on port 443. It took a few hours to eat up every last byte. It felt like this was part of a huge operation. They also left a non-functional crypto miner in there that I simply couldn't remove.

So while they could cryptolock, they just used it for something insidious and left it alone.

Re: We all dodged a bullet

#353

Post by 0xDEAFBEAD »

ilvez wrote: post #131
stickfigure wrote: post #43

Earlier quoted context omitted.

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.

From maintenance perspective both never and always seem like extremes though. Upgrading when falling off the train is serious drawback on moving fast..

Maybe we need two upgrade paths: An expedited auto-upgrade path which requires multi-key signoff from various trusted developers, and a standard upgrade path which is low-pressure.

Re: We all dodged a bullet

#354

Post by galaxy_gas »

karmakaze wrote: post #296
_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"

First thing I do is check any domain that I don't recognize as official. Domain: NPMJS.HELP (85 similar domains) Registrar: Porkbun, LLC (4.84 million domains) Query Time: 8 Sep 2025 - 4:14 PM UTC [1 DAY BACK] [REFRESH] Registered: 5th September 2025 [4 days back] Expiry: 5th September 2026 [11 months, 25 days left] I'd be suspicious of anything registered with Porkbun discount registrar. 4 days ago, means it's fake.…

while other is reasonable, Porkbun is not "discount" registrar. They often more expensive, and on addition of that, they run quite a number of TLDs

Re: We all dodged a bullet

#355

Post by danenania »

zaik wrote: post #204

We need a permission system for packages just like with Android apps. The text coloring package suddenly needs a file access permission for the new version? Seems strange.

Deno has taken steps in this direction. It’s probably doable for pure js packages, but nearly impossible for packages with native extensions.

Re: We all dodged a bullet

#356

Post by Aeolun »

brazzy wrote: post #291
benoau wrote: post #142

Earlier quoted context omitted.

There's probably already hundreds of thousands of Jira tickets to fix it with no sprint assigned....

I feel attacked. And very, very happy that we're proxying all access to npm through Artifactory, which allowed us to block the affected versions and verify that they were in fact never pulled by any of our builds.

Only problem is the artifactory instance is on the other side if the world instead of behind the convenient npmjs CDN, so installing packages takes 5x longer..

Re: We all dodged a bullet

#357

Post by ryukafalz »

homebrewer wrote: post #301
kardianos wrote: post #277

Earlier quoted context omitted.

> We need some deeper changes in the ecosystem. I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason. As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage. NPM will often have different source then the github repo so…

It's already solved by pnpm, which refuses to execute any postinstall scripts except those you whitelist manually. In most projects I don't enable any and everything works fine, in the worst case I had to enable two scripts (out of two dozen or so) that download prebuilt native components, although even those aren't really necessary and it could have been solved through other means (proven by typescript-go, swc, and…

> None of it will help you when you're executing the binaries you built

Lavamoat would, if you get to the point of running your program with lavamoat-node or built with the lavamoat webpack plugin: https://lavamoat.github.io/guides/getting-started/

Re: We all dodged a bullet

#358

Post by hdjrudni »

homebrewer wrote: post #301
kardianos wrote: post #277

Earlier quoted context omitted.

> We need some deeper changes in the ecosystem. I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason. As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage. NPM will often have different source then the github repo so…

It's already solved by pnpm, which refuses to execute any postinstall scripts except those you whitelist manually. In most projects I don't enable any and everything works fine, in the worst case I had to enable two scripts (out of two dozen or so) that download prebuilt native components, although even those aren't really necessary and it could have been solved through other means (proven by typescript-go, swc, and…

> None of it will help you when you're executing the binaries you built, regardless of which language they were written in.

Sure it would... isn't that the whole point of Deno? The binary can't exfiltrate anything if you don't let it connect to the net.

Re: We all dodged a bullet

#359

Post by lmm »

aspenmayer wrote: post #327
babypuncher wrote: post #172

Earlier quoted context omitted.

Ultimately, stolen cryptocurrency doesn't cause real world damage for real people, it just causes a bad day for people who gamble on questionable speculative investments. The damage from this hack could have been far worse if it was stealing real money people rely on to feed their kids.

You have the context sort of wrong. To do a comparable “real money” heist en masse, you would be stealing from the banks or from the customers of one, or via debit or credit cards. It’s real enough money, but those fraudulent transactions would be covered by existing protections, like FDIC insurance or chargebacks. I don’t think anyone could steal much cash from a single heist from a bank or other hard target, so you…

> It’s real enough money, but those fraudulent transactions would be covered by existing protections, like FDIC insurance or chargebacks.

Not always. Many banks will claim e.g. they don't have to cover losses from someone who opened a phishing email, never mind that the bank themselves sends out equally suspicious "real" emails on the regular.

Also even if it's covered that money comes from somewhere - ultimately out of the pockets of regular folks who were just using their bank accounts, even if the insurance mechasims mean it's spread out more widely.

Re: We all dodged a bullet

#360

Post by hdjrudni »

easterncalculus wrote: post #321
kevinrineer wrote: post #156

Earlier quoted context omitted.

Its also really ineffective defense against 0 days!

In the context of a single system, there is no such thing as an "effective defense against 0 days" - that's marketing babble. A zero day by definition is an exploit with no defense. That's literally what that means.

That doesn't sound right.

> A zero-day exploit is a cyberattack vector that takes advantage of an unknown or unaddressed security flaw in computer software, hardware or firmware. "Zero day" refers to the fact that the software or device vendor has zero days to fix the flaw because malicious actors can already use it to access vulnerable systems.

If I never install the infected software, I'm not vulnerable, even if no one knows of its existence.

That said, you could argue that because it's a zero day and no one caught it, it can lie dormant for >2 weeks so your "just wait awhile" strategy might not work if no one catches it in that period.

But if you're a hacker, sitting on a goldmine of infected computers... do you really want to wait it out to scoop up more victims before activating it? It might be caught.

Post reply on HN