logoalt Hacker News

gus_yesterday at 10:19 AM4 repliesview on HN

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


Replies

array_key_firstyesterday at 6:37 PM

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

I don't know but it's very standard practice in most applications, because telemetry. But VS code is one of the worst: just check open snitch when running VS code, it's constantly phoning to a bunch of IPs.

pixl97yesterday at 12:51 PM

> but I still think that restricting outbound requests is a good measure

It is 100% necessary, but doesn't stop most attacks quick enough.

If you're posting to github.com/acmecompany then attackers love to do things like add their own user github.com/acemcompany and just upload your data to that. Generally it doesn't last very long, but with CI/CD they can get thousands of keys in a minute and be gone seconds later.

mmcwilliamsyesterday at 1:06 PM

There are plenty of exfiltration examples out there that could go through known, commonly-greenlit domains. Even exfil via DNS requests has been demonstrated.

show 1 reply
alexfooyesterday at 10:51 AM

Ah yes, sandboxing/limiting a VSCode plugin is not impossible. I was thinking in more general terms (such as post install scripts within npm/python packages). Random test code in golang packages. There's an awful lot that people don't vet because keeping up with the vetting is a huge burden which seems pointless until you're the one that gets hacked.

The trick is to infect a plugin that has a legitimate reason for accessing the internet or running certain commands, and then coming up with ways to abuse that to exfiltrate the data. Or exfiltrating via DNS queries, or some other vector that isn't so obvious as "allow TCP/UDP connections to the whole world".

That or just repeatedly pester a user for permissions until one user (and you only need one within the organisation) relents and grants it.

show 1 reply