3 ms·

how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the c

by wolfi1 5mo ago

how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding

mentalgear 5mo ago
For credential stealing, that is true, but at least it would protect your local machine. But I just read these worms also try container escape ...
- silon42 5mo ago
  We need to prevent direct connections to internet for containers... once you have a proxy, predefined credentials (api keys) can maybe be added there (per container/target).
  - cyanydeez 5mo ago
    the model most people are talking about is in the cloud. for the harness to do useful work, it needs to talk to the cloud the trouble is, we need protocols that are software determined that force AI interaxtions into limited scope but currently theyre all just bash adjacent and inherit your tools.
- fnoef 5mo ago
  You need to use full isolated VM with its own kernel. But then again, I've read somewhere that this malware is also trying to escape the VM isolation as well...
  - deleted 5mo ago
    [deleted]
jcgl 5mo ago
On my personal machine, I run OpenSnitch. Much better defense against data exfil if you reject outbound connections to unexpected/unwanted hosts.
- 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
TacticalCoder 5mo ago
Watertight subdivision in a ship doesn't promise: "there'll never ever be water in this ship". It says: "If there's water in this ship due to one hole, it'll stay in one compartment". Note that I said one hole: you have the titanic, many compartment gets holes, that one ship is still going to sink. (btw that the Titanic sunk is not an excuse not to secure other ships. And it did save a great many other ships to have watertight subdivision.) So... Although there are exploits escaping containers and VMs and then bad guys doing lateral moves across machines, you still want defense in depth.
- sitkack 5mo ago
  One thing could be more clear, is that the Titanic's bulkheads didn't go all the way to the top deck. They did not seal completely and were not watertight.
CGamesPlay 5mo ago
Things on my workstation that the container does not have access to: browser cookies, 1Password cli, SSH keys (even if I allow the SSH agent socket), cargo publish tokens (unless it’s a rust project), npm tokens (unless it’s an npm project), and not to mention anything relating to my other clients (don’t compromise my employer when I vibe install some dep for a random side project).

by wolfi1 5mo ago

how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding

mentalgear 5mo ago

For credential stealing, that is true, but at least it would protect your local machine. But I just read these worms also try container escape ...

silon42 5mo ago
We need to prevent direct connections to internet for containers... once you have a proxy, predefined credentials (api keys) can maybe be added there (per container/target).
- cyanydeez 5mo ago
  the model most people are talking about is in the cloud. for the harness to do useful work, it needs to talk to the cloud the trouble is, we need protocols that are software determined that force AI interaxtions into limited scope but currently theyre all just bash adjacent and inherit your tools.
fnoef 5mo ago
You need to use full isolated VM with its own kernel. But then again, I've read somewhere that this malware is also trying to escape the VM isolation as well...
- deleted 5mo ago
  [deleted]

jcgl 5mo ago

On my personal machine, I run OpenSnitch. Much better defense against data exfil if you reject outbound connections to unexpected/unwanted hosts.

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

TacticalCoder 5mo ago

Watertight subdivision in a ship doesn't promise: "there'll never ever be water in this ship". It says: "If there's water in this ship due to one hole, it'll stay in one compartment". Note that I said one hole: you have the titanic, many compartment gets holes, that one ship is still going to sink. (btw that the Titanic sunk is not an excuse not to secure other ships. And it did save a great many other ships to have watertight subdivision.) So... Although there are exploits escaping containers and VMs and then bad guys doing lateral moves across machines, you still want defense in depth.

sitkack 5mo ago
One thing could be more clear, is that the Titanic's bulkheads didn't go all the way to the top deck. They did not seal completely and were not watertight.

CGamesPlay 5mo ago

Things on my workstation that the container does not have access to: browser cookies, 1Password cli, SSH keys (even if I allow the SSH agent socket), cargo publish tokens (unless it’s a rust project), npm tokens (unless it’s an npm project), and not to mention anything relating to my other clients (don’t compromise my employer when I vibe install some dep for a random side project).