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

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

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

reply
There are plenty of exfiltration examples out there that could go through known, commonly-greenlit domains. Even exfil via DNS requests has been demonstrated.
reply
But at least in that case, there’s a chance that the outbound requests are blocked. Malware isn’t perfect. Simple measures can block a significant proportion of attacks.
reply
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.

reply
the pop-ups fatigue is already an issue, and not an easy one to solve. Pretty much like SIEM/SOC alerts.

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

They'll get there, maybe. But the reality is that right now, everyone allows outbound requests blindly.

Instead of speculating, I suggest to actually investigate current IOCs and common tactics of malicious npm/pip/plugins/VS extensions. Something like this:

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

Or use OpenSnitch (or Lulu, Glasswire, ZoneAlarm anyone?:D etc) to actually analyze real VS malicious extensions or npm packages and see if it stops the exfiltration, and if not, suggest ways to improve it. For example:

https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...

reply
> If companies continue to not pay the ransom then we're going to get a lot more things published

Paying the ransom means your data still gets leaked and now you're out of money and embarrassed.

Why would they ever, ever, delete the data?

reply
If paying the ransom doesn't stop your data getting leaked, nobody will pay the ransom. There is a rational basis for the ransomers to follow through with the deletion. Even the mob did provide "protection" when they coerced you into paying for it.
reply
This sounds like a naive presumption. Are ransomware distributors well known for operating within strict hierarchies bound by culturally-ingrained traditions, or acting in the best interests of their own “greater good”?

Last I heard, teenagers can deploy ransomware with minimal technical knowledge or skill.

reply
[dead]
reply
Because if they leak then nobody will pay the ransom in the future?
reply
(responded to a similar response above)
reply
> The malware (be it a VSCode plugin, an npm package, or whatever is next)

Not the first time we've seen a developer get popped thanks to a malicious game mod either...

reply