Attacker Modus operandi
When considering the possible security controls to implement for protection of a given system and operating environment, it can be very helpful to understand the likely approach, flow, and methods of a skilled and motivated attacker.
This approach and viewpoint provides useful context to the system's designer and protector alike given the possible threats and risk level identified for the system and operations.
A “high value target” in effect warrants more potential resources (complexity, time, cost) and risk being expended by the attacker in order to compromise the system. It is incumbent on the defenders to keenly understand current known, as well as possible, attack capabilities in terms of ease, duration, risk, and cost.
Below is a probable attack flow for a medium to high value embedded system – a.k.a. M2M/IoT device. This is a high-level breakdown, and a good starting point, but should not be considered comprehensive. It is for this reason that it is important to maintain a fair degree of visibility into hacker/espionage “modus operandi” (methods, tools, tactics) either through internal or third party support resources; or to bring in experts who do that can advise on such.
Tools of the Trade
The best way to understand the threat is to understand the capabilities; and this begins with tools and methods. The methods are illustrated above. Below is a comprehensive sampling of tools supporting the security testing and analysis, and the hacking, of embedded system hardware, software, and services. Most need to be purchased; and there are no descriptions or links provided - but Google is your friend. Take a look and try some out; and understand their capabilities for enabling mischief or analysis.
An Example To Illustrate
To help further illustrate the attacker methodology, below is an excellent description of attacker deconstruction of a complex embedded system. The excerpt is from the research published in 2011 by an academic team from the University of California, San Diego and University of Washington, titled Comprehensive Experimental Analysis of Automotive Attack Surfaces.
First, a couple of definitions might help in reading the below section if unfamiliar with vehicle computing systems:
ECU: the Engine/Electronic control Unit; otherwise known as an embedded control system that helps control and regulate one or more functions of a car, such as the engine. There are many different ECUs in today’s cars.
CAN Bus: the Controller Area Network bus is the common, wired communications system and message protocol that all of the car’s ECUs communicate with each other on in a multi-master, serial broadcast manner.
"For each ECU we consider, our experimental approach was to extract its firmware and then explicitly reverse engineering its I/O code and data flow using disassembly, interactive logging and debugging tools where appropriate. In most cases, extracting the firmware was possible directly via the CAN bus (this was especially convenient because in most ECUs we encountered, the flash chips are not socketed and while we were able to desolder and read such chips directly, the process was quite painful).
Having the firmware in hand, we performed three basic types of analysis: raw code analysis, in situ observations, and interactive debugging with controlled inputs on the bench. In the first case, we identified the microprocessor (e.g., different components described in this paper use System on Chip (SoC) variants of the PowerPC, ARM, Super-H and other architectures) and used the industry standard IDA Pro disassembler to map control flow and identify potential vulnerabilities, as well as debugging and logging options that could be enabled to aid in reverse engineering.6 In situ observation with logging enabled allowed us to understand normal operation of the ECU and let us concentrate on potential vulnerabilities near commonly used code paths. Finally, ECUs were removed from the car and placed into a test harness on the bench from which we could carefully control all inputs and monitor outputs. In this environment, interactive debuggers were used to examine memory and single step through vulnerable code under repeatable conditions. For one such device, the Super-H-based media player, we resorted to writing our own native debugger and exported a control and output interface through an unused serial UART interface we “broke out” off the circuit board. In general, we made use of any native debugging I/O we could identify. For example, like the media player, the telematics unit exposed an unused UART that we tapped to monitor internal debugging messages as we interactively probed its I/O channels. In other cases, we selectively rewrote ECU memory (via the CAN bus or by exploiting software vulnerabilities) or rewrote portions of the flash chips using the manufacturer-standard ECU programming tools. For the telematics unit, we wrote a new character driver that exported a command shell to its Unix-like operating system directly over the OBDII port to enable interactive debugging in a live vehicle. In the end, our experience was that although the ECU environment was somewhat more challenging than that of desktop operating systems, it was surmountable with dedicated effort."