Cyber attackers use Rootkits to implant malware using Operating System internals. Bootkits are for more persistent implants, targeted toward UEFI firmware vulnerabilities. But, what if you go lower down, into the silicon? This is a Chipkit.
I was first introduced to the definitions of Rootkits and Bootkits by the book of the same name, written by Alex Matrosov, Eugene Rodionov, and Sergey Bratus:
I purchased it years ago, when I first started my journey to learn more about x86 architecture, OS internals and UEFI. I purchased it at No Starch Press, both the hardcopy and also the eBook. I see that it is also available on Amazon now, as well as presumably other outlets.
This book really opened my eyes about the different ways that cyberattacks could be conducted. Prior to that, I always thought that most attacks targeted applications that I might run on my computer; for example, double-clicking on a spam infected Word document in an email attachment was targeted at Word. I was much more naïve back then; I hadn’t separated in my mind the payload delivery mechanism versus the payload itself.
Cyberattacks are getting more sophisticated all the time. As defenses are put into place higher up in the operating system and kernel – witness all of the enhancements made within Windows 10 and 11, such as Virtualization-Based Security (VBS), to name one of numerous mitigations – attackers have turned to the UEFI firmware on PCs and servers as their next frontier. With Black Hat USA 2022 just having finished, you can read about 12 new high-impact CVEs (Common Vulnerabilities and Exposures): Breaking Firmware Trust From Pre-EFI: Exploiting Early Boot Phases. And as Alex Matrosov, CEO of Binarly, states:
Disclosing and fixing a vulnerability is one side of the problem. The other is to deliver this patch at scale to the entire industry. Furthermore, integrity checks doesn’t provide code visibility, and scoping dependencies based on a binary module’s hash is difficult.
This is particularly challenging for platform firmware. It’s flashed onto the board. And there is not one standard delivery mechanism for UEFI firmware updates, as there is for Microsoft Windows. That industry is fragmented. It is not surprising that this is the next frontier of attack.
While I was perusing the Black Hat materials, I noted a presentation by Intel that dealt with lower-level attacks here:
https://i.blackhat.com/USA-22/Wednesday/US-22-Nemiroff-Fault-Injection-Detection-Circuits.pdf
And the more detailed paper is available here:
Quoting the Abstract from the paper:
This paper details the design, calibration, and validation methodology for a fault-injection detection circuit that was first productized in Intel 12th gen Intel® Core™ processors. We will describe how fault-injection attacks can impact circuit timing, the high-level design of the Tunable Replica Circuit (TRC), data gathering phase that occurs in HVM (high volume manufacturing), the methodology to create a calibration recipe, false positive testing, fault-injection testing and the final HVM production calibration flow. Additionally, this paper wwill illustrate the feedack loop where the circuit is tuned from data gathered from the false positive and attack-lab testing.
These make for very worthwhile reading. I’m impressed that Intel is being so open with this technology. Since this is low-level logic that protects the chip, this should be reassuring to Intel’s customers. The focus of the paper is the Intel Converged Security Management Engine (CSME), more commonly known as the ME:
The Intel TRC was originally designed to mitigate silicon aging, and it was soon found to be useful in protecting against fault injection attacks.
Fault injection attacks commonly cause circuit timing to fail, without causing the system to crash. In the context of a CPU or microcontroller, when glitched at just the right time, an attack can cause a NOP to be latched, instead of a JMP. In fixed‐function crypto engines, real keys could be replaced. And in fabrics and busses, I/O devices could latch data or bus addresses too early/late. These are just some of possible examples.
Why is this important? Because the silicon is the final frontier. The hardware is considered to be at the Root of Trust. If the chips are compromised, all bets are off at the upper layers. If there is rogue logic in the silicon, introduced at either the design or supply chain phases, there is nothing that all the mitigation layers in UEFI or the OS hypervisor/kernel can do about it.
A fault injection attack that changes instruction execution flow within a CPU or microcontroller is just one scenario. Others include a worst-case scenario wherein there is trojan logic introduced into the chip by the design flow chain. These malware or trojans could present a huge vulnerability. We designate these intrusions as “Chipkits”, as they apply to the chips themselves, as opposed to firmware (bootkits) or OS kernel (rootkits).
Investigation of means to detect and mitigate malware or trojans in silicon has been the subject of much focus. In our partnership with Amida, ASSET has done research on using IEEE 1687 (IJTAG) based embedded instrumentation to detect and protect against malware at the silicon level; you can read a high-level description here: Using JTAG for Silicon Trojan Detection and Mitigation. The trojans that were modeled within an FPGA sandbox were:
The full paper can be found here: A Role for Embedded Instrumentation in Real-Time Hardware Assurance and Online Monitoring against Cybersecurity Threats.
To summarize, a visual may assist:
The privilege level of the attack increases, the deeper you go. Chipkits are at the lowest possible level of cyberattacks.
