Intel Security Releases Detection Tool For EFI Rootkits After CIA Leak (pcworld.com)

After WikiLeaks revealed data exposing information about the CIA's arsenal of hacking tools, Intel Security has released a tool that allows users to check if their computer's low-level system firmware has been modified and contains unauthorized code. PCWorld reports: The release comes after CIA documents leaked Tuesday revealed that the agency has developed EFI (Extensible Firmware Interface) rootkits for Apple's Macbooks. The documents from CIA's Embedded Development Branch (EDB) mention an OS X "implant" called DerStarke that includes a kernel code injection module dubbed Bokor and an EFI persistence module called DarkMatter. In addition to DarkMatter, there is a second project in the CIA EDB documents called QuarkMatter that is also described as a "Mac OS X EFI implant which uses an EFI driver stored on the EFI system partition to provide persistence to an arbitrary kernel implant." The Advanced Threat Research team at Intel Security has created a new module for its existing CHIPSEC open-source framework to detect rogue EFI binaries. CHIPSEC consists of a set of command-line tools that use low-level interfaces to analyze a system's hardware, firmware, and platform components. It can be run from Windows, Linux, macOS, and even from an EFI shell. The new CHIPSEC module allows the user to take a clean EFI image from the computer manufacturer, extract its contents and build a whitelist of the binary files inside. It can then compare that list against the system's current EFI or against an EFI image previously extracted from a system.

Comments

Conundrum

[Dunbal]

I no longer trust Intel. Therefore why would I run this?

Re:Conundrum

[barc0001]

Because they were probably compelled by some sort of behind the scenes bullshit to do this on behalf of the CIA and now that the cat's out of the bag they (the CIA) figure it's probably better to be able to poison the ability for the exploit to work than to let the bad guys (different groups depending on who you are) have a go unhindered.

And they're right. They're utter bastards but they're right.

Mistake

[sexconker]

When will people admit that [U]EFI was a mistake?

It's too much code at too low a level, and it's too easy to manipulate. I for one would rather pay a nominal fee to have a new ROM chip sent to me. Remember when you could just pop those babies in and out? Remember when we had jumpers to protect and reset BIOS, boot sectors, etc.?

Yes, [U]EFI has good features and goes far beyond what BIOS can do, but so what? Outside of supporting hardware and booting to the point of OS handoff, the BIOS (either BIOS proper or [U]EFI) is supposed to be as minimal as possible. BIOS has been hacked to hell to support all sorts of shit like that at the behest of the various motheboard manufacturers. If we just had a newer BIOS developed by a central body that didn't try to completely reinvent the wheel as a helicopter, we'd be much better off.

Re:Mistake

[Proudrooster]

Yes, UEFI is a poorly implemented, bad idea, and full of never ending critical vendor security flaws. When you can extract the code, change it, compile it, and put it back, that is scaarrry! I have personally extracted the code from APCI table in the UEFI, tweaked it, compiled it, and put it back. UEFI is a security hole like no other. It can access all the hardware, including memory and the network without the host O/S having any idea.

To quote Linux: EFI is this other Intel brain-damage (the first one being ACPI).

Now root kits can hide after reboot and re-install. UEFI was supposed to make us secure, but all it accomplished was trying to lockout Linux from PC hardware.

Re:Mistake

[SuricouRaven]

Don't blame Intel for the constant problems of ACPI. It was a good design, as initially envisioned.

Blame Microsoft. The Windows ACPI support is really, really awful, but every non-server motherboard is designed and tested for windows - linux testing is an afterthought, if at all. Same for laptops. An ACPI implementation designed and tested for Windows is likely to go very wrong if confronted with an OS that actually does ACPI properly. A common problem is invalid values in those ACPI tables (Probably why the above poster was fiddling with them) - Windows ignores a few values, and just assumes defaults, so some mainboards and laptops pass testing on Windows even though the wrong values or just all-zeros are written in. When linux reads and tries to act on those tables, it usually hangs the system.

My own desktop has an issue something like that, which I got around by just putting 'acpi=off' on the kernel options.

So how do I install it?

[Snotnose]

Link leads to github, which I've never used. Reading the manual I need to install Python using pip. Never heard of pip. Google says it's a Python package manager. Whee.

Then I have to compile some C programs. OK.

Then I have to shutdown my system using funny flags I've never seen before. Before doing this I hope I've printed out a few pages of the manual, because the next few steps are wat do when the system won't boot.

Then I can run it.

OK, I'm technically competent. I'm kinda surprised I've had this laptop for 2 years and have yet to install Python. Oh well, not a problem. I've also got a C development system, that's easy enough. And I'm smart enough to print out the 2-3 pages of important info before shutting down my system in a funky way.

So yeah, I can install and run this. But how about grandma? She has no chance. Besides the fact she's been dead for 10 years or so, she would never be able to figure this stuff out.

What we need is a .msi file we can install that, when run, says yay or nay that the CIA/NSA/KGB/Chinese/whomever has infected your firmware.

Yeah right

[Anonymous Coward]

Intel already has a backdoor called "Intel Management Engine Interface" that can't be disabled, even if you disable Windows drivers or run Linux, it's built into the BIOS that cannot be disabled.

The UEFI/EFI itself is another layer of bullshit that makes it such a hassle to dual-boot or run non-windows OS. Try installing Linux Mint on an HP laptop and even the latest version requires you to log into the UEFI partition and rename/move the image file just so you can get grub to show up during boot (without hitting hot keys).

How do I know that Intel's utility's not going to replace it with the Microsoft version in the name of "security"?

How do I know your replacement image, if that's how it works - is not going to be Intel's compromised BS that allows even more access than the fucking Intel Management engine?