|
BaDSeED: Backdoor Detection Systems for Embedded Devices
|
Research Project
We live surrounded by an increasing number of embedded devices with
computing and (wireless) networking capabilities. We rely on these
embedded devices for many critical applications and infrastructure.
In most cases, the manufacturing and programming of
microcontrollers and field programmable gate arrays (FPGAs) used in
embedded devices is outsourced. Indeed, most of these devices are
made in factories on the other side of the planet--well beyond our
control. But can we trust them?
A key problem is that detecting the presence of a backdoor on a
chip is an extremely challenging, expensive and time consuming
task.
This PhD project will address the problem of detecting backdoors in
embedded devices. Specifically, building on methods we have
recently developed to extract the firmware from embedded devices,
we will develop novel techniques to test the software and firmware
of embedded devices for the presence of backdoors.
Technical Approach
An important contribution of this PhD will be to develop methods to help indicate when firmware may
contain a backdoor. Rather than trying to test if firmware matches its specification exactly (which we do
not believe would be practical), we will adapt and develop state of the art software analysis methods to
look for indicators of the presence of a backdoor in embedded devices.
The most common type of backdoor found so far are hardcoded login accounts. These have been found
in many embedded systems of which smart meters [San12] and routers1 are just two examples. More
advanced backdoors might add substantial extra functionality to a device, which could be exploited by an
attacker. For instance, the ProASIC3 chip which was found to have a backdoor which could be accessed via
an on chip web server [SW12] and TURCK BL20 gateway2 had a backdoor accessible via an ftp server. If
these chips had no legitimate reason to run a web and ftp server, and the existence of this functionality was
not mentioned in their documentation, then the presence of these protocols in the firmware may indicate
a backdoor. To detect such backdoors we will develop heuristics that indicate what a particular region of
code may be doing, for instance, does it contain strings or sequences of commands that are known to relate
to particular encryption algorithms, or network protocols? In the case of particular network protocols, we
will also develop techniques that scan the code for possible hardcoded passwords and usernames and try to
use them to log in.
Another type of backdoor we will search for is a backdoor that allows the expected control flow or
information flow to be interfered with. Continuing with the example of an iris scanner gate, if this gate was
only suppose to open on the presentation of a correct iris scan, or in a particular emergency mode, then any
control flow through the program that opens the gate, without going via the code that tests the iris scan or
emergency mode, would be suspect and may indicate the presence of a backdoor. Likewise, there should
be a clear information flow from the data from the iris scanner along all possible paths: if the details of the
key input can be ignored by the device then there is likely a backdoor. We will adapt existing techniques
on both static and dynamic information flow analysis e.g. [CBP+13, CKNP13] to look for such flows.
In summary: over the course of the studentship we will address the challenge of detecting backdoors in
embedded devices in three main steps:
- Finding methods of recovering the firmware from embedded devices.
- Identifying the functionality of different parts of the firmware.
- Applying control flow and information flow analysis to identify possible backdoors.
People Involved