A Network Allow-List Won't Stop Exfiltration
2 points by dergraf
2 points by dergraf
I'm confused by the premise of this post. It starts with "If you let sandboxed code reach one domain, it can leak your secrets through that domain" and then promptly pivots to an example where more than one domain is involved via DNS exfiltration.
If I have an allow list for host.example.com, then my hosts file contains the IP for host.example.com, why would that host get unfetted DNS access?
I don't disagree with the idea of adding an additional layer of monitoring, adding more depth to defense in depth is great. But the examples seem contrived from poor network allow-list implementations, not a secured development environment.
For most of these examples, simply denying outbound connections when they are unexpected should work. Shai-Hulud logged secrets back to Github directly, if you're not running an intentional push right now, there shouldn't be git traffic back towards Github right now. Basically implement nethogs with approval of new flows required.
That said, I do appreciate the use of canaries, I think they are extremely underutilized and would suggest a better honeypot approach: Before pulling a new package (or even syncing existing ones) on your main development system, do it on a container elsewhere with live canary tokens. Watch that boxes' network connections via nethogs and watch for activity on the canary accounts.
It would be phenomenal if GitHub and NPM actively allowed you to create canary tokens for your account that they could detect at their end to automatically pause activity on your account when used and trigger an email alert. This way all the canaries die in the coalmine and the miners get out alive.
Your network policy allows DNS... Your SSH private key, base64-encoded, flows to an endpoint..
It really depends on the underlying sandbox model. With Wasmtime and the WASM Component Model, the isolation story is pretty robust: the guest declares dependency interfaces and the host must explicitly expose them.
I am building a runtime where DNS and FS are not exposed to WASM guests at all. Outbound HTTP is exposed through a controlled host interface where the runtime applies policy based on URL/method, injects secrets into headers, etc. So the guest never gets raw network or disk access, only constrained capabilities exposed by the host.
Encoding chains: The scanner recursively decodes base64, hexadecimal, and percent-encoding up to 32 layers deep
This seems fragile. Once an attacker can execute code that can read your secrets, it is just a matter of time until these heuristics are bypassed.
WASM sandboxes serve IMO a different use case. But I agree, if you can compile your usecase (whatever it might be) to WASM you can increase security tremendously. Where can i find your project?
It is https://obeli.sk . The exfiltration problem can actually be solved at the runtime level (in 90% of the cases): the sandbox only receives placeholders which are transparently replaced with actual secrets by the host/proxy. Not sure if Canister does that.
No it doesn't, yet. I was actually thinking about this and came to the conclusion that at this point it's more important to try to score credentials, e.g. a github pat will only be allowed in requested to Github related endpoints. But the replacement would actually make a lot of sense for exfils where the sensitive data gets e.g. encrypted.