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.
I no longer trust Intel. Therefore why would I run this?
Seven puppies were harmed during the making of this post.
Then how can I trust Intel's code to detect rootkits?
Same applies for Motorola and AMD.
-- Tigger warning: This post may contain tiggers! --
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.
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.
.msi file we can install that, when run, says yay or nay that the CIA/NSA/KGB/Chinese/whomever has infected your firmware.
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
when Intel builds a separate computing environment into their processors and chipsets, designed to operate out of control or view of the user, and then offers this EFI rootkit detection tool? Can you trust Intel?
"What if this Intel program is the actual malware?"
You insensitive clods!
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?
My understanding (perhaps somewhat dated) is there is modifiable code inside Intel CPUs as well. Does the CIA/NSA/whoever have the capability of silently changing that microcode so as to make their task easier (perhaps as simple/complex as detecting when certain encryption code is running, and changing the results to be cryptographically weaker)? Or is this old stuff that no longer applies?
So obviously Intel makes popular CPUs, as well as other components, in computers. If you run a system with any of those, well then they could have a back door in them and there's nothing you could do. However it goes further than that: The Intel C Compiler is EXTREMELY popular for writing software (in Windows and Linux) because it generates really optimized code. It could, of course, insert back doors in to binaries without the knowledge of the person compiling it. So you'd have to scrap anything written using it.
Really, it isn't feasible. If you are so paranoid you think Intel is spying on you or helping others spy, your probably have to go hide in a cave because there is just nothing you can really do to eliminate all risk.
At some point, you have to stop being a member of the AFDB brigade and just accept that ya, there's some risk in trusting, well, anyone but you have to and just leave it be. You also have to accept that you aren't protecting nuclear secrets, the kind of attacks against you are not the spy-agency level.
This is part of the long slow march back to locked down shitty platforms and completely closed hardware. This is the phone/appliance-ification of your shit.
People don't understand the freedoms they're losing. By the time they realize it it will be far too late (it pretty much already is at this point). Even the term "walled garden" doesn't make it sound as bad as it is.
What really gets to me is it takes talented, highly educated people in niche fields to create this shit and they're selling out hardcore to some of the worst evils imaginable and giving no fucks (the over arching cultural imperative, at least in America, of "I got mines").
It's a shame there aren't more RMS style zealots; maybe even some with billions of dollars to throw at preserving and perpetuating freedom.
OS Manufacturers use UEFI to force users to upgrade their systems to the latest OS, like Microsoft SuckIt 10.
It is by design to make old OSes, like Windows XP, obsolete. They will do everything in their power to fuck you over and mke you buy a new computer.
Not some useless PC mag blurbage.
I have no problem buying a new computer. But I want control of my hardware. I replace shit whether its broken or not. Just to give me something to play with. But I remember the days when you didnt have to play the "Lets break this part to make the system work right" game..
What about UEFI's "secure boot"? Wasn't it designed to prevent this kind of boot exploits, while incidentally making it a pain in the backside to run non-Microsoft OSes? So, was the executable image of the CIA exploit signed? By whose key?
While the ME is a major security hole, and UEFI is a giant pile of shart (Great *IF* everything is fully standards compliant, which almost none of it is...), the issues with UEFI/SecureBoot usually come down to two problems:
Windows 10 (or possibly 8.1) requires SecureBoot enabled to validate itself as 'authentic' for purposes of a preinstalled Windows OS. And secondly, that your Non Win10/8.1 distro (even if it is windows!) is signed in order to load via SecureBoot, or that you disable SecureBoot by first setting an administrator password in the bios, which in turn is used to 'prime' the TPM with owner credentials in order to allow you to enable/disable SecureBoot without switching to Legacy Bios mode (which requires a second form of bootable media or reimaging each time you would want to switch from Win10/Signed Linux(Fedora, Ubuntu, etc.) to 'legacy' Linux/Windows for instance.)
With systemd deliberately mounting efivars writeable by default, is it finally clear that it is malware planted into the very core of a modern linux system and right in the plain sight and under the noses of millions of users?
Because the Intel malware binary blob sits outside the BIOS, is encrypted and signed by Intel, and only Intel/NSA/CIA has the golden key.
They can hack into your box through the ethernet port or builtin wireless display or wifi, and the OS won't be able to detect it.
They can send a magic packet to your ethernet port, or a signal to your wifi or the cpu built-in wireless display, the backdoor will respond with your CPU ID, the CIA/NSA then use that ID to lookup your backdoor encryption golden key, that only they have.
Then can then use the golden key it to get into your system, do whatever they want with zero evidence left behind, even if you catch them in the act, the packet would just look like some random packet due to encryption.
The ME is just the firmware, the actual bad stuff is in the hardware inside the CPU, which very few people has access to and also have the technical knowledge to understand it.
The FBI wants Apple to create an iPhone backdoor.
The CIA/NSA doesn't even have to ask, Intel is basically another arm of the cartel.
Just look at the long history of server IPMI backdoors, and know that Intel ME is a more advanced version of it that is tightly controlled by Intel/CIA/NSA, it is their aces in their sleeves reserved for high value targets.
Building backdoors is what they do, in the past the morons can use the tin foil hats excuse, but after snowden/wikileaks in recent years you can't seriously be that stupid and naive.
The answer is in the bold part:
The Trouble With Intelâ(TM)s Management Engine
Finding an exploit for the Intel ME will be difficult, though. While most of the firmware for the ME also resides in the Flash chip used by the BIOS, the firmware isnâ(TM)t readily readable; some common functions are in an on-chip ROM and cannot be found by simply dumping the data from the Flash chip.
This means that if youâ(TM)re trying to figure out the ME, a lot of the code is seemingly missing. Adding to the problem, a lot of the code itself is compressed with either LZMA or Huffman encoding. There are multiple versions of the Intel ME, as well, all using completely different instruction sets: ARC, ARCompact, and SPARC V8. In short, itâ(TM)s a reverse-engineerâ(TM)s worst nightmare.
Intel used custom compression and multiple instruction sets (ARC/ARCompact/SPARC V8/ARM) for their backdoor to make reverse engineering extremely difficult.
To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.
But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.
There are many researchers trying to unlock the secrets of Intel's Management Engine, and for good reason: it's a microcontroller that has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one, and if you're looking for the perfect vector for an attack, you won't find anything better than the ME. It is the scariest thing in your computer, and this fear is compounded by our ignorance: no one knows what the ME can actually do. And without being able to audit the code running on the ME, no one knows exactly what will happen when it is broken open.
The first person to find an exploit for Intel's Management Engine will become one of the greatest security researchers of the decade. Until that happens, we're all left in the dark, wondering what that exploit will be.
Intel used custom compression and multiple instruction sets (ARC/ARCompact/SPARC V8/ARM) for their backdoor to make reverse engineering extremely difficult.
The Trouble With Intelâ(TM)s Management Engine
To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.
But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.
There are many researchers trying to unlock the secrets of Intel's Management Engine, and for good reason: it's a microcontroller that has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one, and if you're looking for the perfect vector for an attack, you won't find anything better than the ME. It is the scariest thing in your computer, and this fear is compounded by our ignorance: no one knows what the ME can actually do. And without being able to audit the code running on the ME, no one knows exactly what will happen when it is broken open.
The first person to find an exploit for Intel's Management Engine will become one of the greatest security researchers of the decade. Until that happens, we're all left in the dark, wondering what that exploit will be.
Intel used custom compression and multiple instruction sets (ARC/ARCompact/SPARC V8/ARM) for their backdoor to make reverse engineering extremely difficult.
The Trouble With Intel's Management Engine
To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.
But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.
There are many researchers trying to unlock the secrets of Intel's Management Engine, and for good reason: it's a microcontroller that has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one, and if you're looking for the perfect vector for an attack, you won't find anything better than the ME. It is the scariest thing in your computer, and this fear is compounded by our ignorance: no one knows what the ME can actually do. And without being able to audit the code running on the ME, no one knows exactly what will happen when it is broken open.
The first person to find an exploit for Intel's Management Engine will become one of the greatest security researchers of the decade. Until that happens, we're all left in the dark, wondering what that exploit will be.
By tracking who and how many people download the "tool".
Do you think the Intel Wireless Display on the GPU will be backdoor/bug free? They don't even need to send you a packet through the network port.
They are way ahead of you and has already mastered cross device hacking, one mobile/wifi within 50 feet and your air gapped Intel box is owned.
You know things are bad when Intel used ARM for the backdoor chip just to make reverse-engineering difficult.
Intel used custom compression and multiple instruction sets (ARC/ARCompact/SPARC V8/ARM) for their backdoor. You can't be sure what's going on unless you decap the chip and look at the circuits, but how many people have that skill?
The Trouble With Intel's Management Engine
To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that's used in the firmware remains an unsolved problem.
But unsolved doesn't mean that people aren't working on it. There are efforts to break the ME's Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.
There are many researchers trying to unlock the secrets of Intel's Management Engine, and for good reason: it's a microcontroller that has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one, and if you're looking for the perfect vector for an attack, you won't find anything better than the ME. It is the scariest thing in your computer, and this fear is compounded by our ignorance: no one knows what the ME can actually do. And without being able to audit the code running on the ME, no one knows exactly what will happen when it is broken open.
The first person to find an exploit for Intel's Management Engine will become one of the greatest security researchers of the decade. Until that happens, we're all left in the dark, wondering what that exploit will be.
WikiLeaks says there's still a lot of CIA documents to come
WikiLeaks's "Year Zero," the first part of the "Vault 7" trove of alleged CIA documents, is 8,761 documents big, but it's just a tiny part of the entire stash.
According to WikiLeaks, the documents released Tuesday constitute "less than 1%" of the total Vault 7 files.
This is a scary proposition for the CIA, which weighed in on the leak with a pretty angry "no comment" statement.
WikiLeaks has released less than 1% of its #Vault7 series in its part one publication yesterday 'Year Zero'.
â" WikiLeaks (@wikileaks) March 8, 2017
I am a Linux advocate, but I have to say this is a ridiculous claim. Linux boots on UEFI just fine.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Rootkits can't talk back to C&C controlling 'em via APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
Ads/script & malware rob speed/security/privacy
Hosts add speed (via hardcodes/adblocks), security (vs. bad sites/malware/poisoned dns), reliability (vs. dns down), & anonymity (vs. dns requestlogs/trackers).
Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus + less security bugs/complexity & faster vs. addons/routers/remote dns!
Avoids DNSChangers in routers/IP settings & dns redirects (99.999% of ISP DNS != patched vs. it) + lightens DNS load & resolves faster from local system RAM!
* Via what u NATIVELY have built into the IP stack in FASTER kernelmode!
APK
P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/
You fail simple logic.
I might be stuck with Intel, but I don't have to accept it, I'll jump ship the moment there is a better choice.
By accepting it silently you're just encouraging them to make things even worse for future generations.
Even if you build it from source?
That doesn't even make sense
There is a warning.txt on Github (chipsec/chipsec/WARNING.txt). Here is the funny part from the file:
Chipsec should only be used on test systems!
It should not be installed/deployed on production end-user systems.
Fuck you Intel, fuck you very much.
Linux can boot on UEFI systems just fine, but very few distro have EFI support (ie Fedora, CentOS). Once you drop down to classic BIOS to install your favorite distro then all your PCI and USB peripherals like keyboard, mouse, all USB ports won't work! Believe me its a pain when I installed a Linux distro in an Acer machine after removing Win10. Lucky for me, I have burned around 30 DVD discs loaded with the latest top 30 Linux Distro, I tried one by one until one distro knew how to tame my systems UEFI.
You are confusing UEFI and Secure Boot
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Meanwhile, Intel still doesn't sign the crap in their download.intel.com service, so when Linux distros get microcode data files, or Windows users get driver updates from there, they can be MITM'd by *anyone* (not just the CIA or NSA), and have trojans inserted. Yeah, it is HTTPS, but you just need to mess with the unsecured DNS and pass yourself as a CDN node with a non intel.com node name to MITM someone whose DNS service is vulnerable to poisoning.
Can you imagine the damage if a Linux distro or an OEM with a few million users distribute trojanned crap? I *assume* Microsoft actually has a more trusted path that doesn't depend on bad jokes like HTTPS + the public CA system, but if they don't, it then the fear is valid there, too.
The CHIPSEC people have been doing a damn good job cleaning up the incompetent shit done by several other Intel (and Microsoft, etc) departments, this new module is just business as usual for them, and not even more relevant than their previous work.
Intel does _not_ deserve the good PR they're getting out of this CHIPSEC release, only the CHIPSEC team itself does -- and the CHIPSEC team deserves a lot more good PR for all the good work they've been doing for *years*.
When Intel stops pushing half-finished processors/microcode to market (due to their higher management decision to downplay QA since Westmere days), deploys DNSSEC for the entire intel.com domain so that it is not trivial to MITM it anymore, starts signing all their driver and firmware releases with widely-known keys both for Windows and Linux so that we get actually decent crypto attestation that the firmware/drivers were not trojaned somewhere down the supply chain or MITM'd when fetching it from intel.com servers, and gets the firmware ecosystem to actually take responsibility to keep their shit up-to-date (something not even Intel is stellar at, although they're not among the worst of the lot any more since their criminally negligent desktop motherboard unit has been disbanded)... THEN, Intel will deserve the good PR created by some of their "fix the other guy's mess" teams like CHIPSEC and BITS.
Are you kidding me? do you know how many checks and balances go into launching a nuke?
You are right, other counties just give their leaders full control over their nukes, no codes needed.
Since regular BIOS began to be phased out in the late 2000s I have seen numerous problems. One that cost me a customer was the inability of Proliant servers to boot to internal storage. Instead it would attempt to boot off a usb backup drive when present. HP's dispatched techs who offered no assistance.
Since then I've experienced numerous other technical issues surrounding the newer BIOS startup tech. I could tell from the start that this introduced security and reliability issues.
What I've never been able to determine is, aside from providing and easy exploit path for nosy governments, what benefit does EFI provide and/or what problem/s does it solve? I never had an issue with the old BIOS, while EFI continues to introduce expensive problems into my life.
Eventually you can get Linux to boot on UEFI just fine. But it is harder than before.
It used to be that you could just put a DVD in a computer and click OK to install Linux, and that was it.
Now people people ask me for help when Linux installation fails. Usually the installation seem to succeed, but the computer cannot boot. I usually install Boot-Repair on a live USB disk, boot the computer and fix it. Boot-Repair is a nice toot but really, it should not be necessary.
And sometimes it does not work. Early versions of the Intel NUC would fail starting Ubuntu because if expected the executable to be named uefi.exe, not grub.exe. Intel fixed it in a later firmware version. But it is telling that they created something so complex, that not even Intel could get it right.
It is really another tool developed by Intel for the CIA to make hacking even easier!
All this hype is to just get you to install it!
GOTCHA - AGAIN!!!
Self-importance and self-indulgence is the root of ALL evil.