Comment by javajosh
9 years ago
Little Snitch users are the kind of people who can and would expose CIA beacon signals. It's not so much that LS users are juicy targets, but rather that they are substantial exposure risks.
You might say, well, just piggy-back the signal on something else. Indeed, that is better. But that solution is far more complicated because you have to control (cooperatively, or coercively) a legitimate end-point.
Ergo, I don't think it's clownish at all for the CIA to target LS, it addresses a real threat (to them).
That's not what he was saying. Yes, it would of course be a good idea to try to hide the malware implants from tools like Little Snitch. It's just that the method they propose of going about it is really dumb.
What tptacek is saying is that instead of writing some hand-tailored userspace code to specifically fool Little Snitch, they should just be using a kernel module that will hide the network and process activity from all analysis tools. That's what most nation-state malware does (or tries to do).
Using kernel implants to hide signals from these kinds of network security tools is literally 1990s-grade hacker opsec. It's the actual, precise use case for which "amodload" was written, in 1996, by a 20-year-old, for a closed-source OS. I stand by my assessment.
...But what if you can implant into the kernel? Also, what if you don't want to use a full-featured zero-day kernel exploit if you can get your target with a somewhat lower tech exploit?
Clever to just recover all your data using a browser process which has (likely) already been fully authorized to exfiltrate data.
So, rather than targeting LS they would target the kernel with a patch to make LS (and all tools like it) blind to their traffic.
Clearly that's a neater and more complete approach, but there still might be reasons to target a specific app instead of the kernel. It might just be easier and less error prone. (Monkey-patching a running kernel's networking innards has got to pose serious risk to the underlying system's stability, increasing the likelihood that the target will simply reinstall the OS. That's fine for a DoS attack, but not for something like this).
Using kernel modules to do researchy things -- that nobody would care if they crashed and burned -- in the 90s just to prove that they were possible, has little in common with doing what you describe, today, in a way that is reliable and has to account for conditions that were not present 30 years ago.
Your comparison is therefore invalid.
You'd know all of that of course if you actually had written a single kernel implant in your life.
You got me. It turns out, there's no such thing as an xnu rootkit. That's why the elite hackers all backdoor Little Snitch.