Recent submissions

Comment · 12 days ago
Comment · 3 months ago
1. restrict outbound connections by binary.

2. restrict outbound connections to known malicious IPs or domains.

3. run untrusted code/apps:

   - under a different user
   - or inside a sandbox
   - or in a VM
4. remove exec permissions to temporary directories (/tmp, /var/tmp, /dev/shm)
Comment · 4 months ago
Unfortunately this order will probably be revoked in 2027/2028, we'll see.
Comment · 4 months ago
Comment · 4 months ago
Comment · 4 months ago
A year ago a similar attack was reported and I think that there have been similar campaigns reported this year: https://github.com/evilsocket/opensnitch/discussions/1290#di...

  - This is a new repository, not a fork
  - All repositories have different contributors and different names
  From the last two points, it becomes clear that even if we find one such repository, we won’t be able to find other similar repositories using it.
In previous campaigns the repositories were linked to a few users. But those users had starred other users, that at the same time had also cloned other repositories with the malware. Sometimes the malicious repository had been cloned from another malicious repo, and if you listed the repositories and "friends" of that user, all were part of the botnet.

Also, github doesn't delete repositories and accounts, they mark them as deleted. If you use their api you can still list them.

Comment · 4 months ago
Comment · 5 months ago
Comment · 5 months ago
Comment · 5 months ago
Comment · 5 months ago
Comment · 5 months ago
Comment · 5 months ago
> It's trivial to do this in a way to avoid detection

I'd love to see a real example/PoC.

Anyway, we discussed this issue in the other thread. For me, unrestricted outbound requests to any url, whether it's well known domains like api.github.com or any other domain, are a red flag.

Why does VS need to establish outbound requests to any domain, without authorization?

There's no magic solution, and these attacks will evolve, but I still think that restricting outbound requests is a good measure to mitigate these attacks.

> slurps up all of the users private keys/tokens/env-vars it can find and sends this off somewhere covertly.

Isolating applications can also mitigate the impact of these attacks. For example, you can restrict VS code to only share with the host .vscode/, .git/ and other directories. Even by project. Again, it's not bulletproof, but helps.

Comment · 5 months ago
absolutely. These attacks will evolve for sure, like the malware evolved on Microslop for years.

But for the time being, the common entry vector is clear:

https://github.com/evilsocket/opensnitch/discussions/1119

> 2) trigger a tab open to attacker's website

be sure not to use extra cli parameters like "firefox --new-tab <url>", because if the rule is filtering by process path + cmdline it'll trigger a pop-up to allow the outbound request.

Comment · 5 months ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton