THE IoT AND SECURITY AND PRIVACY Toward Automated Firmware Analysis in the IoT Era Grant Hernandez and Farhaan Fowze | University of Florida Dave (Jing) Tian | Purdue University Tuba Yavuz, Patrick Traynor, and Kevin R.B. Butler | University of Florida Firmware for Internet of Things devices can contain malicious code or vulnerabilities, which have already been used in devastating attacks. In this article, we discuss the problems in analyzing firmware for security, offer case studies, and propose challenge tasks to improve firmware analysis. orn from traditional embedded systems, the devices Unfortunately, attacks targeting or residing in the B that comprise the Internet of Things (IoT) bring firmware have shown that “everything still works” is not with them both opportunities and new challenges. always the reality. For instance, the BadUSB attack12 Voice-controlled devices such as Google Home and allows attackers to add extra functionality to USB Amazon Echo allow users to easily control their appli- firmware, e.g., adding keyboard functionality to a USB ances at home. Thermostats and cameras from Nest thumb drive to automatically and rapidly inject mali- interface with the cloud to enable remote monitoring and cious keystrokes to the host as a way of compromis- control. Devices such as these are here to stay, with plenty ing it. BlueBorne3 and BleedingBit4 allow attackers to more to come. Between smart homes, intelligent build- inject shellcode into target systems due to vulnerabili- ings, and industrial and medical environments, the num- ties within Bluetooth and Bluetooth Low Energy soft- ber of IoT devices had already reached 7 billion as of early ware stacks in controller firmware. Smartphones with 2018.10 These embedded systems are often built using a Android firmware were found to have backdoors trig- variety of processors and microcontroller architectures, gered by ATtention (AT) commands,15 allowing local all programmed with custom firmware. Most of this firm- attackers to bypass Android security mechanisms. The ware is closed source and proprietary, leading to a deficit Mirai botnet2 was responsible for some of the most mas- of public scrutiny. Users often have no idea what is inside sive distributed denial-of-service attacks seen to date, their firmware and rarely perform firmware updates. If building an army of IoT devices by exploiting different they do, they often find themselves performing manual zero-days and weak credentials within device firmware. updates by flashing an opaque blob of binary code onto a Even automobiles, which represent traditionally closed device and hoping that everything still works. systems, might be stopped remotely on the highway due to a vulnerability in their telematics controller.1 Digital Object Identifier 10.1109/MSEC.2019.2926462 In short, firmware can contain malicious or vulner- Date of publication: 1 August 2019 able components that are effectively hidden from users 38 September/October 2019 Copublished by the IEEE Computer and Reliability Societies 1540-7993/19©2019IEEE www.computer.org/security as techniques these categorize broadly can We data. and thecode about son rea to techniques analysis well-known program apply researchers this objective, achieve To within firmware. vulnerabilitiescally discover ormalicious components security-focused is analysis theability automati to of agoal particular, In software analysis. traditional of those similar to are analysis offirmware goals The Firmware Analysis automated. more and accurate, more able, scal more broader, analysis such make to how about future for look guidelines and firmware Android and analyzing from USB learned our experience lessons and discuss We era. fortheIoT analysis offirmware lenges this examine article, we thechal In universe. the IoT thewide exists assess variety that to across offirmware way is nosystematic there yet critical urgent, more and devicesAs forthese is analysis getting firmware such, deficiencies.these of of society aspects the stakes raise devices inall ofIoT connectivitytous proliferation and ubiqui The actors. bad by beleveraged can that and it is forced to overapproximate. to it is forced overall and limitations, its has analysis Static methods. dynamically call lists of function to assigned pointers asC++inwhich use such classes forlanguages issue an This becomes accurately. targets thebranch sary track to neces state theprogram nothave does analysis Static problem. is apath-sensitive branches indirect through flow control interprocedural tracking example, For beundiscovered. may boundaries functions data and some is explicit an there call orjumpintheassembly, Unless limitations. which inherent has a binary image, afixed view have of approaches Static data?” represent tion X?” “Which and which and code, bytes represent as“Who such questions answer thecallers offunc are then can analysts other, each to theirconnections and alist With offunctions analysis. forlater a program of define helps and theskeleton procedures between edges which creates flow recovery, isbinaries control when disassembling technique analysis static ventional Acon is analysis possible. static extracted, and stood under be can data to instructionstheir relations and As astheunderlyingtion long assembly environment. devicea working oremula require not does It data. types boundaries. code and assource-level such code, befoundonlyinsource can that information valuable to access lose analysts since challenging, astheonlyoption. Thisanalysis is more binary leaving available, is code rarely source though, orbinary code firmware, With level. thesource either at beapplied may techniques three These analysis. ware offirm inthecontext together concepts these connects Static analysis relies solely on firmware’s code and and code onfirmware’s solely relies analysis Static static , dynamic , or , symbolic . Figure 1 Figure 1 . - - - - - - - - - - - Dynamic Analysis Debugging Structure Recovery Firmware Instrument Platform Dynamic Binary Inst. Coverage Tracing IR Emulation Automated Testing Extract/Program reg_a := 0 Source Code reg_a += 1 reg_b = reg_a STORE(addr) = Symbolic Analysis 10110111010 reg_a 1011011101001 Lift reg_r2 = // firmware.c Specification 1001110110010 LOAD(addr) int main() { Write 0010100001010 for(...) { Binary Type Recovery Code/Data Recovery 0010100001010 Design } Firmware 1110110101010 return 0; 0x66: inc R6 1000110101010 Requirements } 0x67: mov (0x5), R7 Value Set Analysis CFG Recovery Compile 1010110101010 0x69: mov A, R5 0x6a: dec A 0x6b: mov R7, A Disassemble 0x6c: jnz $-8 Alias Analysis Static Slicing Assembly Static Analysis Decompile Reassemble Figure 1. An overview of program analysis concepts in the context of firmware. CFG: control flow graph; Inst.: instrumentation. 39 THE IoT AND SECURITY AND PRIVACY In contrast, dynamic analysis is performed using a firmware image takes input from a known memory an actual execution environment. Whether this is a range, only that memory range can be made symbolic, physical platform, an emulated platform, or a combina- limiting path explosion. tion of both depends on the availability of hardware or the completeness of an emulator. For example, to per- Case Study: FirmUSB form hardware-based dynamic analysis, you will likely When the USB protocol was first released in 1996, need many copies of a device and a harness to moni- there were many competing peripheral standards. USB tor and control them. Emulation-based analysis executes has largely replaced previous interfaces such as serial, a programmed model of the target system. QEMU5 parallel, and FireWire ports. However, the ubiquity of is arguably the most famous emulation platform and USB and its lack of built-in security mechanisms have implements many allowed for simple architectures and attack vectors, such machine types. With as spreading mal- an accurate emulation ware from infected model, analysis scales With firmware, though, source code is devices and the previ- with the amount of ously discussed Bad - available computing rarely available, leaving binary analysis USB attack against resources instead of as the only option. device firmware. Un - device-specific hard- fortunately, while ware. However, if no host-based protection emulation model exists, suites aim to protect then creating one is USB devices at the a costly endeavor, especially if the target platform file system layer, they do not provide insight into the combines a significant amount of application-specific actual device functionality present within the firmware. hardware. Emulators vastly improve the process of To provide insight into the actual device behavior, we discovering vulnerabilities and debugging flaws, created FirmUSB,9 a system for analyzing USB-controller as they are easily instrumented as compared to firmware and performing behavioral firmware analysis. closed-source software running on locked-down FirmUSB is designed to allow an understanding of device hardware. If a partial model exists but additional functionality; rather than focusing on manual reverse engi- modeling would be too costly, we can use real hard- neering, we concentrate on automating our methods by ware for the missing components, an approach taken employing a combination of static and symbolic analysis. by the Avatar2 framework.11 Symbolic methods take an approach similar to that Supporting New Microcontroller Architectures of dynamic analysis, with the key difference being that We quickly ran into a major stumbling block: USB con- program memory can be