Malware injection
There are various methods to inject a piece of code inside the system. The size of the malware depends on the
target but may be very small (few tens of bytes). To be executed, the malware must be injected in the device
memory (RAM or flash memory). Once injected, the challenge is to have it executed by the CPU, which means
that the PC (program counter) must branch to it.
Methods of injecting malware can be categorized as follows:
• basics device access/"open doors”:
– Debug port: JTAG or SWD interface
– Bootloader: if accessible, can be used to read/write memory content through any available interface.
– Execution from external memory
These malware injections are easy to counter with simple hardware mechanisms that are described
in Section 4 Device protections .
• Application download:
– Firmware update procedure: a malware can be transferred instead of a new FW.
– OS with capability to download new applications
This category countermeasure is based on authentication between the device and the server or directly
with code authentication. Authentication relies on cryptography algorithms.
• Weaknesses of communication ports and bugs exploitation:
– Execution of data. Sometimes it is possible to sneak the malware in as data, and to exploit incorrect
boundary check to execute it.
– Stack-based buffer overflows, heap-based buffer overflows, jump-to-libc attacks, and data-only
attacks
This third category is by definition difficult to circumvent. Most embedded system applications are coded
using low-level languages such as C/C++. These languages are considered unsafe because they can
lead to memory management errors leveraged by attackers (such as stack, heap, or buffers overflow).
The general idea is to reduce as much as possible what is called the attack surface, by minimizing the
untrusted or unverified part of firmware. One solution consists in isolating the execution and the resources
of the different processes. For example, the TF-M includes such a mechanism.
• Use of untrusted libraries with device back door:
This last category is an intentional malware introduction that facilitates device corruption. Today, lot of
firmware developments rely on software shared on the web and complex ones can hide Trojan horses. As
in previous category, the way to countermeasure this threat is to reduce the surface attack by isolating as
much as possible the process execution and protecting the critical code and data.
Brute forcing
This type of attack targets the authentication based on a shared secret. A secure device may require a session
authentication before accessing services (in the cloud for example) and a human machine interface (HMI) can be
exploited with an automatic process in order to try successive passwords exhaustively.
Interesting countermeasures are listed below:
• Limit the number of login trials with a monotonic counter (implemented with a timer, or if possible, with a
backup domain).
• Increase the delay between consecutive login attempts.
• Add a challenge-response mechanism to break automatic trials.
3.3
Hardware attacks
Hardware attacks require a physical access to the device or, often, to several devices in parallel.
The two following types of attacks differ in cost, time, and necessary expertise:
• Non-invasive attacks have only external access to the device (board-level attack) and are moderately
expensive (thousands to tens of thousands US dollars in equipment).
• Invasive attacks have direct access to device silicon (after de-packing). They are carried out with advanced
equipment often found in specialized laboratories. They are very expensive (more than 100k dollars, and
often in the range of millions) and target very valuable data (Keys or IDs) or even the protection technology
itself.
AN5156
Hardware attacks
AN5156 - Rev 8
page 9/56
To Next Page
Loading...
Need help?
General
