Live data from Hacker News

We all dodged a bullet

xeiaso.net

171–180 of 498 posts

Re: We all dodged a bullet

#171
post #76

>Saved by procrastination! Seriously, this is one of my key survival mechanisms. By the time I became system administrator for a small services company, I had learned to let other people beta test things. We ran Microsoft Office 2000 for 12 years, and saved soooo many upgrade headaches. We had a decade without the need to retrain. That, and like other have said... never clicking links in emails.

Not in the "npm ecosystem". You're hopelessly behind there if you haven't updated in the last 54 seconds.

Sorry, the "npm ecosystem" command has been deprecated. You can instead use npm environment (or npm under-your-keyboard because we helpfully decided it should autocorrect and be an alias)

Re: We all dodged a bullet

#172

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…

Stolen cryptocurrency is a sure thing because fraudulent transactions can't be halted, reversed, or otherwise recovered. Things like a random dev's API and SSH keys are close to worthless unless you get extremely lucky, and even then you have to find some way to sell or otherwise make money from those credentials, the proceeds of which will certainly be denominated in cryptocurrency anyway.

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.

Re: We all dodged a bullet

#173

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…

API/SSH keys can easily be swapped, it's more hassle than it's worth. Be glad they didn't choose to spread the payload of one of the 100 ransomware groups with affiliate programs.

Re: We all dodged a bullet

#174

> Formatting text with colors for use in the terminal ... > These kinds of dependencies are everywhere and nobody would even think that they could be harmful. The first article I ever read discussing the possibility of npm supply chain attacks actually used coloured text in terminal as the example package to poison. And ever since then I have always been associated coloured terminal in text with supply chain attack

I used to share this article with students https://david-gilbertson.medium.com/im-harvesting-credit-car...

Re: We all dodged a bullet

#175
Is this not a good use case for AI in your email client (local-only to avoid more opportunities for data to leak)?

Have the client-embedded AI view the email to determine if it contains a link to a purported service. Remotely verify if the service URL domain is valid, by comparing to the domains known for that service

If unknown, show the user a suspected phishing message.

This will occasionally give a false positive when a service changes their sending domain, but the remote domainservice database can then be updated via an API call as a new `(domain, service)` pair for investigation and possible inclusion.

I feel like this would mitigate much of the risk of phishing emails slipping past defenses, and mainly just needs 2 or 3 API calls to service once the LLM has extracted the service name from the email.

Re: We all dodged a bullet

#176

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…

yeah a shitty crypto stealer is more lucrative, more quickly monetized, has less OPSEC issues for the thief if done right, easier to launder

nobody cares about your trade secrets, or some nation's nuclear program, just take the crypto

Re: We all dodged a bullet

#177

Earlier quoted context omitted.

Alternatively, I've long been wondering if automatic package management may have been a mistake. Its primary purpose seems to be to enable this kind of proliferation of micro-dependencies by effectively sweeping the management of these sprawling dependency graphs under the carpet. But the upshot of that is, most changes to your dependency graph, and by extension your primary vector for supply chain attacks, becomes s…

Unpopular opinion these days, but: It should be painful to pull in a dependency. It should require work. It should require scrutiny, and deep understanding of the code you're pulling in. Adding a dependency is such an important decision that can have far reaching effects over your code: performance, security, privacy, quality/defects. You shouldn't be able to casually do it with a single command line.

I wouldn’t go for painful that much. The main issue is transitive dependencies. The tree can be several layer deep.

In the C world, anything that is not direct is often a very stable library and can be brought in as a peer deps. Breaking changes happen less and you can resolve the tree manually.

In NPM, there are so many little packages that even renowned packages choose to rely one for no obvious reason. It’s a severe lack of discipline.

Re: We all dodged a bullet

#179

Earlier quoted context omitted.

Just because you buy them doesn't mean that you have to use them. Squatting on them is no more harmful (except financially) than leaving them available for potentially hostile 3rd parties.

Sure, I guess buying up every npm.* you can find and then having a message "never use this, only use npm.com" could work. I thought OP was saying have every npm.* site be a mirror of the canonical site

Looks like it costs ~$200,000 to get your own TLD. If a bunch of companies started doing the "register every TLD of our brand", I wonder what the breakeven point would be where just registering a TLD is profitable.

Re: We all dodged a bullet

#180

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

Yeah, there's an entire community dedicated to cleaning up the js ecosystem. https://e18e.dev/ Micro-dependencies are not the only thing that went wrong here, but hopefully this is a wakeup call to do some cleaning.

Discord server? Is it that much work to create a forum or a mailing list with anonymous access. Especially with a community you can vet that easily?
Post reply on HN