In the previous article: Software and hardware means of attacking AUTOSAR (Part 1) 
https://blog.csdn.net/NewCarRen/article/details/129368365?spm=1001.2014.3001.5501
introduced AUTOSAR and described the Software attacks and hardware attacks. This article will describe a case study of a fault injection attack to control an AUTOSAR-based ECU through a fault injection attack. The ECU is a development board developed based on STM32F4, and the development board runs the Arctic Core of AUTOSAR v3.1. In the new version of AUTOSAR, the implemented communication protocol stack is the same. Furthermore, we assume that the attacker has physical access to the ECU and ECU firmware.
01Case Study: FION AUTOSAR
A. Failure Model: Instruction Corruption
In the attack, the instructions are modified by injecting faults into the MCU's power supply. This attack vector is not unique to the targeted MCU or the fault injection technique we use. Similar to the example shown in Listing 1, Listing 2 describes the effect of changing bits in an instruction due to a fault. Instead of modifying an ADD instruction, we modify an LDR instruction to load a register value into the PC. This way we can hijack the control flow of the process at the instant of failure. Load and store instructions are used to copy memory.
Listing 1: ADD instruction broken
Listing 2: LDR instruction broken
For ARM chips, copying memory is done using the LDR instruction or the more efficient LDM instruction, where there is a single instruction that copies multiple 4-byte fields. From an attacker's point of view, the LDM instruction is more worth investigating because the target register is configured with a single bit, which means that only one bit needs to be set from 0 to 1 to load the value of a register into the PC . This attack only works on the ARM AArch32 architecture. Most other architectures do not allow loading a value directly into the program counter register. But despite this, variants of this attack work on other architectures as well.
When developing a failure model, the characteristics of the target must be considered. The MCU used in the vehicle environment usually needs to pass the ASIL level certification and can meet the functional safety requirements. Even so, an attacker could still exploit a faulty MCU certified to the highest level of protection, ASIL-D, against the vehicle.
B. Fault Target: Communication Protocol Stack
In a car, sensor information, user input, and commands from different ECUs are generally exchanged through various system buses (such as CAN, FlexRay, LIN, etc.). Therefore, the communication protocol stack is a key element of every RTOS running on the ECU. In order to meet the requirements of most common vehicle system buses, the AUTOSAR communication protocol stack supports multiple bus protocols such as CAN, Ethernet, FlexRay and LIN.
Figure 2 depicts the current AUTOSAR communication protocol stack. The first is that MCAL detects a bus interruption and then forwards the PDU to the corresponding communication driver. For CAN, CAN ISO-TP or raw CAN frames can be received and processed. In order to bypass the length limitation of CAN's 8 data bytes, the ISO-TP protocol is adopted. The protocol still uses 8-byte frames. When the data sent reaches 4095 bytes, the ISO-TP driver assembles 8-byte frames on the ECU. The PDU router is responsible for routing the PDUs to the user application or diagnostic communication manager etc.
Figure 2. AUTOSAR communication protocol stack
The purpose of the attack is to load controlled data into the PC register of the processor. To do this, it is necessary to attack an interface that allows the injection of data. Assume this data is processed with the LDR instruction. Timing a failure in order to hit a single load instruction is not trivial. Fortunately, during the memcpy operation, multiple load and store instructions are executed consecutively in a loop. This makes the attack less dependent on time. As long as we can modify a load instruction, it doesn't matter which load instruction is modified.
Figure 3 shows the disassembled representation of the memcpy function used by the AUTOSAR communication protocol stack. Cycle through LDR and STR instructions to copy data from one cache to another. This function is used whenever data is sent to the ECU via the CAN bus (or any other bus). This data originating from the ECU is controlled by the attacker. It is actually copied multiple times by different AUTOSAR layers using the same memcpy function. This process provides an attacker with multiple opportunities to successfully inject a fault, allowing the attacker to load arbitrary values into the PC register. Verify our hypothetical attack by modifying the code of the communication protocol stack. We modified a load instruction in order to load a value originating from the CAN bus into the PC register. It turns out our hypothesis was correct: if we can modify an LDR instruction, we can also load an arbitrary value into the PC. This finding gives us confidence. We can proceed to demonstrate a real attack whose results are shown in Section V-C.
Figure 3. The moment of glitch injection during the memcpy function
C. Attacking AUTOSAR
In this hardware attack on AUTOSAR, we exploit voltage fault injection to gain arbitrary code execution of the control unit. In order to be independent of the user software implemented in the application layer, we target the communication protocol stack of AUTOSAR. Using this attack, we are able to inject our own code into the application layer as a separate task. The benefit of controlling tasks on the ECU is that we are able to add functionality that can be used maliciously. For example, we could add the ability to extract keys from the ECU, or rely on some form of control for subsequent attacks. For example, extracting keys from hardware security modules (HSMs) through side-channel analysis attacks.
AUTOSAR supports sending data up to 4095 bytes via CAN using the ISO-TP protocol. Since the CAN bus does not support authentication by default, any participant with physical access to the bus will be able to send and receive data. For the launched attack, it is assumed that the attacker is able to remove the ECU from a donated experimental vehicle. By analyzing the source code of the AUTOSAR communication protocol stack, it can be found that the PDU is transferred from the PDU router to the AUTOSARCOM or DCM module by using the memcpy function. An attacker would likely reverse engineer the firmware to achieve the same result. By rectifying memcpy after sending an address on the bus, we can redirect control flow to an arbitrary location. Since copying data is a very basic operation, this attack can be applied to most ECUs.
AUTOSAR is a static real-time operating system, which means that it is not possible to simply create a new task at runtime. The operating system manages tasks by using task control blocks (TCBs). In this entry, the task name, priority, stack pointer and other important attributes of the task are stored. The OSEK/VDX specification is the basis for the AUTOSAR kernel and requires an OS IDLE task. OS IDLE tasks are scheduled when no other tasks are requesting CPU time. For most ECUs, OS IDLE is an infinite loop task. In other words, AUTOSAR-based ECUs do not depend on the functionality provided by the OS IDLE task. This feature allows the OS IDLE task to be abused, making it easy to inject our own code. We can inject code by simply overwriting the OS IDLE task pointer stored in memory. This pointer is used whenever an OS IDLE task is scheduled. It should be noted that this method is also feasible for other tasks, but the advantage of using the IDLE task is that it does not affect the overall function of the system.
Figure 4. The payload is sent to the ECU via the CAN bus
Figure 4 shows the payload sent to the ECU input buffer using the ISO-TP protocol. The payload consists of three major parts:
1) TCB operation. This code overwrites the task pointer stored on the IDLE task stack. The value of the new address points to an area in SRAM where the malicious IDLE task is placed.
2) Copy the malicious IDLE task. Copy the new task's code to the selected address before using memcpy.
3) Buffer address. The start address of the input buffer is repeated multiple times to make the failure less time-dependent.
In order to place the malicious IDLE task in the memory and modify the task pointer of the IDLE task at the same time, we use fault injection to modify the control flow of the program. Since the input buffer is marked executable, the goal of this modified program is to load the program count register with the address of the input buffer. To reduce the complexity of fault injection attacks, the address of the input buffer is repeated multiple times. An attacker now only needs to hit one of the addresses with an induced fault. After the attack is successful, the next time the IDLE task is scheduled, the code of the malicious IDLE task will be executed.
Figure 5 is about the timing of the attack. First, the payload is transferred using the CAN bus. Then, after the last frame is sent, the trigger activates the glitch generator. Due to the complexity of finding the strength required for a successful glitch, we randomly modify the parameters of the glitch: such as glitch length, voltage, and delay. If the glitch injection is successful, the malicious IDLE task sends a message to the computer using the UART. With our setup we were able to get arbitrary code execution on the ECU about 2 times per hour. As Timmers et al. state in their paper, the success rate is highly dependent on the setup used and the device being attacked, requiring dozens of failed attempts to succeed.
Figure 5. Time moments after injecting the glitch
02Enhanced ECU
The insecure design of ECU based on AUTOSAR may lead attackers to exploit logic loopholes to destroy its security. When an exploitable vulnerability is found when using the functions of the ECU according to the design, the design can be judged to be an unsafe design. An example of this is the ECU's authentication mechanism with very small keys. If the design is large, an attacker can compromise the security of the ECU through software and/or hardware vulnerabilities. These unreliable places are usually introduced by developers when converting computer designs into actual products. Using attacks on software and/or hardware, attackers can exploit these vulnerabilities and compromise the security of the ECU. Generally speaking, it is impossible to turn a design into a product without bugs. Therefore, an important aspect of the design is to make it as difficult as possible for an attacker to exploit these vulnerabilities.
A. Make it harder to attack software
To stay safe, secure embedded devices such as smartphones rely on world-proven software attack mitigation techniques. For example, on modern smartphones, stack buffer overflow protection (such as stack cookies), heap/heap memory protection (such as W⊕X), and address space layout randomization (such as ASLR) are standard operations. Employing these software attack mitigation techniques can greatly increase the complexity of memory corruption-based software vulnerabilities. But unfortunately, these software technologies are basically not used or rarely used in modern ECUs.
B. Make hardware attacks more difficult
Damage caused by hardware attacks that rely on hardware vulnerabilities, such as fault injection, is difficult to repair. These attacks are capable of subverting the software security model on which ECUs depend. Most MCUs available to ECU designers are not hardened against hardware attacks such as fault injection. Therefore, ECU designers can only use the MCU's standard functions and executed software to try to harden the ECU for hardware attacks. Even though hardware attacks are difficult to prevent, attacking hardware is only the beginning of what an attacker can do to a vehicle. For example, hardware attacks can be used to extract firmware in order to find software vulnerabilities that can be exploited remotely. Keys present in the firmware are also exposed to attackers. The impact of hardware attacks can be minimized by reducing the number of stored keys in the firmware and making it difficult to exploit software vulnerabilities. To put it more simply, don't rely on concealment to ensure security. Code protection functions implemented by most MCUs are vulnerable to fault injection attacks.
03 last
Attackers can compromise the security of AUTOSAR through software and hardware attacks. While remote attacks are a top priority, local attacks can also affect the security of modern vehicles. Often, a local attack is the first step in performing a remote attack (such as extracting firmware), or the attacker intends to perform a local attack (such as destroying an asset). Therefore, it is necessary to minimize the impact of physical presence attacks. Security sensitive data should not be stored in firmware.
The case study demonstrates that it is possible to control (i.e. execute arbitrary code) AUTOSAR-based ECUs using fault injection attacks. To load an attacker-controlled value into the PC register of the MCU, we inject faults using the memcpy function in the AUTOSAR communication protocol stack. This solution allowed us to successfully hijack the control flow of the MCU and take full control of the vehicle's ECU. If an attacker is able to execute arbitrary code on the ECU, then multiple attacks that threaten the vehicle can be performed. For example, if the code of the ECU is not certified for secure boot, the attacker can continuously modify the functionality of the ECU.
If you want to learn about AUTOSAR related courses, please contact me on Weibo NewCarRen