Infected Hardware Myth or Reality?

Recently I stumbled across an interesting firmware – hardware contest hosted by the Polytechnic Institute of NYU. I’ve seen similar competitions run before - some promoting team work, some perhaps generating new ideas for hardware or firmware designs, some just wasting the participant’s efforts altogether. But not this time, this time it's different.

I’ll come to the rules of the actual contest a bit later. But first it is worth noting that history provides a number of examples of otherwise innocent technologies that can be used to embed malware deep in a computer system. Back in the old DOS days it was Terminate and Stay Resident (TSR) along with DOS system drivers. Windows introduced application level in-process hooks and system wide hooks in ring 0. Recently with the advent of virtualization technology it is hypervisor and so-called ring -1 supervision. All of these technologies, while conceived completely without malcious intent, can be used for system subversion and stealth. When examined with a malicious intent, these developments resemble an arms race where new ideas and innovations are harnessed for the sake of destruction.

But hey, is this enough? How about microcode alteration inside the actual microprocessor core?  After the infamous 1994 FPU (Float Point Unit) flaw in the early Pentium microprocessors, which in turn resulted in the costly recall of the entire batch, Intel introduced 'microprocessor microcode update'. This means that it's effectively possible to alter the microprocessor’s functionality. This can be done, say from BIOS, or through the Intel Microcode Update Driver for instance. Not stopping there, it became fairly common practice to ensure that peripheral devices (such as network, video or less common special function devices) have updatable firmware - either through in-circuit programming supported through software drivers, or alternatively through the JTAG (Joint Test Action Group) interface.

The JTAG interface was initially conceived of as a means to test outer chip connectivity to a printed circuit board and other chips. The release of a 486 processor with JTAG by Intel ultimately led to a quicker adoption of the standard and expanded its use to accessing the internal blocks of a chip and its debug module.  Not evil enough you might argue?  And perhaps you might be right. The microcode update is guarded by a somewhat obscure and never publicly-released protocol which relies on encrypted and signed blocks of data and the verification mechanism inside the processor itself. Although some claim that the protection is weak and exploitable and is only guarded by obscurity, we are yet to see the actual “break in”, working 'proof of concept' there.

What about firmware? Well the thing is, most firmware is piggy-backing on specialized controllers and chipsets, that in most instances require 'hard to come by' and hence, costly development tools. This trend is slowly changing though. For instance, as soon as Texas Instruments popularized its well-versed and now highly popular microcontroller, MSP430, making development tools and the hardware easily available - most probably hoping for wider adoption of its technology - the controller became the target of the undivided attention of hackers. (Attacks on MSP430 Microcontroller, Firmware Black Hat 2008).

Now, back to the contest...
Perhaps inspired by the Best Paper Award of the First USENIX Workshop on Large-Scale Exploits and Emergent Threats “Designing and implementing malicious hardware.”, the Polytechnic institute of NYU is running an embedded system challenge. The purpose of this challenge is to come up with the “best” trojan to fit into a reference design of an encrypting system based on the Digilent BASYS Spartan-3 FPGA board. The scenario being used for the challenge is that of industrial espionage, aimed at subverting an evil army encrypting device. And who said geeks are not romantic? They also provide convenient links to various resources with useful tips for malware developers, ranging from trojan creation to trojan detection and everything in between. To put the icing on the cake, the qualified teams get to keep the hardware board.

The submitted trojan implementations are expected to modify the functional specification of the device, provide information leakage, create a denial of service condition, or all or any of the above.

Teams competing in the challenge are expected to have or gain a working knowledge of Very High Speed Integrated Circuits (VHSIC) Hardware Description Language (HDL), or as it is commonly known VHDL. The competitors will need to become fairly proficient in the full cycle of the development process, including cross compiling, uploading and in-circuit debugging of the trojan code for a Field Programming Gate Array (FPGA) chip.

But you might argue that a challenge targeting FPGA’s is so farfetched - who cares about them anyway? Well the fact is that FPGA’s are used pretty much in every single special function circuit - routers, switches, network cards, specialized encrypting devices, wireless edge servers, monitoring and data processing and acquisition devices - including equipment for military and medical use.

Will this or similar competitions promote a shift from software to sophisticated hardware and firmware related malware? Perhaps not, but I certainly think that it’s not helpful to encourage the creation of such hardware related malware either.

-Oleg Petrovsky

Comments (0)

Skip to main content