4 ms·
Would love to learn more about their internal behavioural detection program. > One of the first things our security team did was confirm that our existing endp
by skinfaxi 6mo ago
Would love to learn more about their internal behavioural detection program.
> One of the first things our security team did was confirm that our existing endpoint detection would catch this exploit. Our servers run behavioral detection that continuously monitors process execution patterns. It doesn't rely on knowing about specific vulnerabilities; it watches for anomalous behavior across the fleet.
- CGamesPlay 6mo agoWould certainly be interesting to learn more about. A simple check: allowlist of known "processes that run as root". Any new process shows up, something happened.
- jeffbee 6mo agoBased on what? Proc title?
- CGamesPlay 6mo agoProc title is very easily forged (without root even). Obviously a real privileged process could modify the kernel and do whatever it wants, but if I were trying to detect this I would start with /proc/$id/exe.
- jeffbee 6mo agoMaybe, but there's a prctl to change that reference which a root process can use.
- Retr0id 6mo ago/proc/pid/exe is also easily forged, without root. For example you can do LD_PRELOAD=evil.so /bin/foo on any dynamic executable, or spawn /bin/foo unmodified and inject code via ptrace or /proc/pid/mem. I have a fileless, execless copyfail exploit that works by injecting shellcode directly into systemd's pid 1. (I should probably publish it at some point...)
- jeffbee 6mo agoYeah the whole system is based on the ability of one task to apparently become another task, that's how Unix works. So the indicators in /proc are just that: indicative at best. There's no reason the task should even be assumed to be executing code in a file. A process can map code into anonymous memory and continue executing there without even branching. Again this is considered a feature of the system rather than a flaw.
- parliament32 6mo agoIt's curious they're just "monitoring" rather than preventing. In a serious environment you'd run IPE with dm-verity/fs-verity to ensure binaries are whitelisted and integrity-checked at every execution.
- staticassertion 6mo agolol no one does that (edit: or, rather, that is extremely uncommon, even in "serious" environments, for a ton of reasons).
- parliament32 6mo agoLook at the FedRAMP requirements around integrity protection, then look at how massive the list of complaint products is. I promise, pretty much everyone in regulated environments is. It's so prevelant Azure is even pushing a turnkey solution for k8s https://learn.microsoft.com/en-us/azure/aks/use-azure-linux-os-guard https://learn.microsoft.com/en-us/azure/aks/use-azure-linux-...
- jeffbee 6mo agoIf you have much experience with fedramp, and it sounds like you do, perhaps you might agree that it is a huge list of things that superficially indicate doing something, without actually doing anything. As the documentation for IPE freely admits, it has no protective benefits because it is unaware of anonymous executable regions.
- parliament32 6mo agoIt sure has limitations, but "no protective benefits" is pretty wrong. In a real world example, if your containerized application has an RCE, you're preventing the attacker from executing binaries they tampered with or down/up-loaded. Combined with minimal distroless containers, it's a very effective attack surface reduction strategy, and works much better than the legacy scan-occasionally integrity-checking methods (rkhunter et al).
- dboreham 6mo agoThey might just compute a hash over the binary, or the code space in memory.
- mobeigi 6mo agoI'd very much like to learn more about this too, deserves its own blog post.
- staticassertion 6mo agoSyscalls and kernel module loading can both be logged, I assume that's sufficient here.
- skinfaxi 6mo agoYes but I am interested in hearing about cloudflare's implementation, how they scale it to their whole fleet, and what kinds of heuristics they are using to classifying behavior as anomalous.