Slashdot Mirror
The Trouble With Intel's Management Engine (hackaday.com)
szczys writes: You've used many devices that have Intel's Management Engine built into them, even if you haven't heard of it before. This is the lowest level of security, built directly into the chips. But obscurity is part of its security and part of its weakness. Nobody knows exactly how ME works, yet it includes a wide range of features that would be frightening if exploited. The ME is always listening, able to receive packets even when the device is asleep. And it has the lowest level of access to every part of the computer system.
Stopped reading the conspiracy rant after this delicious gem:
Yeah, so because they finally abandoned BIOS, modern computers are suddenly insecure. With the implication that BIOS was somehow secure. Yeah, bullshit.
I'm not even saying that the IME is necessarily perfect, but conspiracy-theory drivel doesn't do much for me. That goes double for when it seems to be directed at one vendor and one vendor only while pretending that everybody else out there (AMD [which flat-out embeds an ARM processor in its parts to copy the functionality of IME], anything running ARM, etc.) is all magically secure.
AntiFA: An abbreviation for Anti First Amendment.
Between lack of a useful setup routine, centralized management, etc.. it's a royal PITA to actually work with on an Enterprise level.. It's nice though.. I'll give them that.. onboard VNC for BIOS level control like a DRAC/BMC/ORA/iLO, etc and ability to send WOL to PC level hardware is nice for those pesky users that have totally messed things up.. It's also useful for remote rebuilding of machines since you can remote redirect ISOs and such..
But.. again.. royal PITA to setup and the documentation is scattered and horrible to read through.
I guess you use AMD.
What do you mean "if"?
https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulnerabilities_and_exploits
So the IME is in place in millions of desktops. Is anyone currently using any of the features? How does the software communicate with it?
Only the State obtains its revenue by coercion. - Murray Rothbard
This kind of stuff really gets the wheels turning in my head, but unfortunately the hamsters in those wheels are on the verge of death.
always listening, able to receive packets even when the device is asleep
When was the last time you saw a computer that didn't have "wake on lan", "wake on keyboard", and "wake on network"? It's not done by magic and pixie dust/
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
In my experience, on late model DDR3 and DDR4-based chipsets, the ME driver is unstable, does absolutely nothing, is now included in Windows Update so you can't ignore it unless you disable it. Some early model computers around 2009-ish will not boot if ME is turned off in the BIOS so why is there even an option in the BIOS to turn it off? NOBODY actually uses it for anything, even in most corporate IT environments. I also heard some computers can use it to turn on from a dead power off, allegedly. It's almost like Intel decided they had too much business and too much of an advantage over AMD and wanted to shot themselves in a foot a couple times.
It's a completely separate processor embedded in the PCH itself. It's leveraged for a wide range of functions, including things like out-of-band control of the machine itself, even when it's off, and even when it's non-bootable for some reason. It's also used for content protection and encryption of protected video and audio, and as such the ME software is integrated with the graphics and (I think) audio drivers. That's about all I know about it, if there are other functions the ME is leveraged for, I don't know about them. I do know it's not necessary for the ME to be running for the rest of the computer to be bootable, but if it's not then some functions may be disabled (like the playing of protected content).
AMD calls their version of the IME the "Platform Security Processor (PSP)".
One of the side effects is that open source BIOS projects are effectively dead for desktops.
I read the internet for the articles.
If you don't like this sort of thing, buy devices that support Coreboot.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Step 1. Purchase a legitimate certificate from CA trusted by ME
Step 2. Broadcast DHCP announcement with domain name matching your trusted certificate
Step 3. Root dance
You would still need Intel RST to pretend to be a browser and open the website though.
Even going to the website with evil javascript trusted would still require admin access and need another OS level exploit to execute and then another one through ME to execute the code
http://saveie6.com/
I'll give you an example of how ME is used on very common business-oriented cheap desktops like Dell OptiPlex or old HP dc series.
It all begun around the era of Core2Duo when manufacturers started to implement ME/AMT management solutions on their cheap office PCs. In the *default configuration* the access to ME's setup is unrestricted and protected by default credentials of admin/admin. Even if you have set a password on the BIOS itself you can still enter ME setup by just pressing a hotkey during boot.
Since ME has a full-blown TCP stack it can even listen on a separate IP that can be set in the ME setup. When configured you basically own the PC, you can control power, attach IDE/CD/FDD images and remotely boot from them. If the current graphics mode is ol'DOS you can even redirect that on the Serial-Over-LAN interface without even having the full AMT (which uses VNC to redirect any graphics mode). All that is done over super-secure SOAP with no encryption by default.
If your manufacturer was competent there probably is a burried update to make it DASH-compliant and to make it not accessible without the BIOS password.
What is more it's possible to attack ME/AMT remotely with broadcasts to make it configure itself to open wide up. All you need is a certificate that's trusted, which is really not that hard.
It also has pretty neat capabilities to even filter packets in hardware, without the OS control!
Now for the intended purpose: different versions of ME/AMT behave differently in the desktop world. Missing features between generations, bugged features, broken power management. The default behaviour of taking 2 TCP ports for hosting websites that can be used to remotely control the PC itself is bad enough.
The firmware itself was confirmed by Intel to have unrestricted DMA, which pretty much can defeat any protections in software. The only way to stop it for sure is to use a dedicated NIC...
Software and APIs are really bad as well, the SDK is a collection of bolted-on turds.
It's all pretty sad really. And don't get me started on how it's implemented on laptops...
Glad I bought a h170 chipset motherboard and therefore don't have this crap.
All of those exploits exist and are in the wild. Luckily they have not been cobbled together into an attack script that I am aware of, but I haven't looked for a usable version of the hacks. I mainly care that they exist, and they do. :(
The PSP is nothing like IME. IME is a dedicated chip for remote management, which you can't touch.
PSP is simply a separate ARM core that you can control, including running a separate OS. The PSP ARM core, in turn, has a common ARM feature called TrustZone, which provides very strong security guarantees for the software running inside the TrustZone. Again, you control how this is configured and what software runs in the TrustZone.
I don't know about the PSP specifically, but most ARM chips with TrustZone also support something called HAB (High Assurance Boot), which is basically a secure boot mechanism like TPM. It allows you to set a public key used to verify the boot image, and using e-fuses you can programmatically make the public key immutable.
But ARM chips almost always come without any firmware pre-configured. The whole thing is a clean slate. The intention is for people (usually companies) to build their own special-purpose applications using these capabilities, and usages very widely.
IME, by contrast, is just pure evil. If you're lucky, the IME controller is only tied into a particular NIC, in which case you should make sure to _never_ plug anything into that NIC--perhaps fill it with glue. That doesn't solve all the issues--theoretically an attacker could tickle bugs in the IME purely from running in user space on the main CPU--but it closes a huge security hole. Yes, attackers have remotely broken into servers via IME, in some cases just by using the default passwords.
http://www.slideshare.net/code...
If you're enabling IME with default password, you're doing it wrong. If you enable IME you should be installing your own certificates and using certificate-based authentication. If you aren't, you're stupid. I've never encountered hardware where IME is enabled by default (in fact my Dell Precision T3610 is buggy in such a way that it's impossible to enable, and there's no way to enable it on 13th-generation PowerEdge by design). There's a lot of FUD about IME, but it won't hurt you if you don't turn it on.
If IME or (AMD's PSP) gets exploited, you are completely screwed, throw the motherboard out. no amount of re-flashing can get you to known good state. The advantage of the stick, as a relatively passive device and preferably read-only to the managed device, is that it can be removed/reviewed/fixed on another device. Imagine it like using an SD-Card to store a BIOS, and having no firmware other than that. to upgrade the BIOS, you remove the stick, put it on a trusted computer (you have to find one of those) and use that to do the BIOS upgrade, then you put it back in the computer, where it is read-only. This works for fixing a corrupt BIOS as well. The only capability you give to the CPU is the ability to load it's microcode on boot from this stick.
Implemented properly, with co-operation from the chip vendors that has the potential to be much more secure, but how likely is that?
You would still need Intel RST to pretend to be a browser and open the website though.
No websites required. Computer does not even need to be turned on.
Even going to the website with evil javascript trusted would still require admin access and need another OS level exploit to execute and then another one through ME to execute the code
All you need is access to broadcast domain of wired or wireless network on which your victim is attached. As my attack strictly uses remote access facilities as intended to be used no exploits are required.