The more likely it is that your target will discover someone compromised them, yes. But finding a DLL injection exploit only says "hacked by someone", whereas finding a microcode-level rootkit in the CPU pretty much says "hacked by a state actor". Which, sometimes is what you want to say (see e.g. Stuxnet), but often not. If you know the first has a 99% chance of going undetected, and the second a 99.9% chance, do you always want to risk the one that pretty much acts like a calling card?
There's two ways microcode goes on Intel CPUs. The first is when it gets flashed in at the factory onto an OTP ROM. The second is when it gets uploaded to a block of internal RAM by your computer, every time it boots. That's why packages like this one (https://www.archlinux.org/packages/extra/any/intel-ucode/) exist.
One is set at the factory, one is set by your computer every time, once at boot, before the completion of boot. Also, it's very carefully signed, so even if you managed to put a bootkit before the OS boot, you would need to steal Intel's microcode key.
Microcode is not targetable. Few things at that level are. (A decent example of something that might be more targetable at that level is a hard drive controller. Less difficult but still not easy.) The amount of engineering needed to pull off an exploit that is "99.9% chance" unnoticeable, but still persistent, is much more than that of a "99% chance".
(I know nothing of AMD's CPUs and their microcode, but I'm guessing it's much of the same.)
First of all, thanks for writing this, since I did find the technical details quite interesting. But I don't think this puts microcode rootkits beyond the reach of a state actor. It puts them beyond the reach of a normal criminal attacker, which is actually my point.
Scenario 1: Supply chain interdiction. You don't need to target the CPU only after it has been manufactured and put into whatever you want to hack, you can start way earlier, including at the factory.
Scenario 2: Getting the signing keys from hardware manufacturers, including Intel, seems quite feasible for state actors. You don't even need hacking (I assume Intel's keys are kept air-gapped) or relying on secret court orders, plain old spycraft would probably do the trick.
That said, my argument can be rephrased to consider the hard-drive controller or other peripheral firmware rootkits instead, if you prefer and care only about scenarios where the rootkit must be delivered over the network to a clean system without attacking the CPU manufacturer.
The CIA took control of the SIM card manufacturer company through in-q-tel years before and willingly sold their shares just before the keys got stolen by NSA/GHCQ.
It was a big deal at the time known as "l'affaire gemplus" and it prompted the french government to set up the "Fonds stratégique d'investissement" or strategic investment fund, sort of a french in-q-tel.
Intel being a US company it is probable the US agencies have their ways with them.
I wouldn't be surprised if the NSA worked with Intel to design their microcode update mechanism (selecting algorithms with advisements against classified breaches; generating key material and sharing between themselves; etc.) That would serve the NSA's interests in both their SIGINT and COMSEC roles at once.
I would say what you did is to "neutralize" the ME firmware part in the flash BIOS. But this is only firmware that the ME loads additionally to load applications like e.g. AMT.
The ME has it's own internal ROM containing it's very own firmware which is inaccessible and can not be modified.
So what you have is libreboot running on top of a still functional IME. All you gained is, that you got your BIOS of choice installed, and to remove some ME apps from the flash image. Correct me if I am wrong.
In Ptacek's defense (heh), I'm willing to wager those hypothetical detection rates are far off the mark by orders of magnitude.
I'd expect a microcode-level rootkit to run a five-nines success rate evading detection unless used against someone who's paranoid enough to have _something_ in place to detect it, and I'd venture further that the 3LAs of the world are smart enough not to target the infosec-paranoids of the world.
I am sure the numbers are way off, but not sure only the microcode one is. My suspicion is that against most non-intelligence targets, the DLL injection approach is quite unlikely to be found out either, at least once the initial intrusion has been accomplished. In both cases, the implants will likely only be detected if the machine in question is used to stage another attack or exfiltrate data over the network, in which case the level of the rootkit running on the host will matter very little for detection.
Admittedly, the best rootkits probably target the network equipment as well as the host.
At the host level, most organizations wouldn't be able to detect an unmasked trojan running as its own separate user process unless its signature was already known or its behavior caught by a blacklist-based IDS.
The problem doing DLL injections is you are dropping things directly to the disk which is a great way to get AVs attention. Heuristics based detection can be a pain in the ass here and you want your rootkit to be able to be 'unique' for every installation if possible.
Also rootkits are way overrated. What you do when you compromise an organization is you open a connection to your C&C on a few machines to keep your foothold if any reboot. If you need to get in you just connect to one of those boxes and just continue on. You never have to drop anything on the hard disk which makes it much stealthier.
