IOActive recently published a whitepaper (https://ioac.tv/3N005Bn) covering the current security posture of the drone industry. IOActive has been researching the possibility of using non-invasive techniques, such as electromagnetic (EM) side-channel attacks or EM fault injection (EMFI), to achieve code execution on a commercially available drone with significant security features. For this work, we chose one of the most popular drone models, DJI’s Mavic Pro. DJI is a seasoned manufacturer that emphasizes security in their products with features such as signed and encrypted firmware, Trusted Execution Environment (TEE), and Secure Boot.
Attack Surface
Drones are used in variety of applications, including military, commercial, and recreational. Like any other technology, drones are vulnerable to various types of attacks that can compromise their functionality and safety.
As illustrated above, drones expose several attack surfaces: (1) backend, (2) mobile apps, (3) radio frequency (RF) communication, and (4) physical device.
As detailed in the whitepaper (https://ioac.tv/3N005Bn), IOActive used EM emanations and EMFI due to their non-invasive nature. We leveraged Riscure products as the main tools for this research.
The image below show the PCB under analysis after being removed from the drone; power has been connected to an external power supply.
First Approach
Our first approach was to attempt to retrieve the encryption key using EM emanations and decrypting the firmware. We started by finding an area on the drone’s PCB with a strong EM signal so we could place a probe and record enough traces to extract the key.
After identifying the location with strongest signal, we worked on understanding how to bypass the signature verification that takes place before the firmware is decrypted. After several days of testing and data analysis, we found that the probability of successful signature bypass was less than 0.5%. This rendered key recovery unfeasible, since it would have required us to collect the tens of thousands of traces.
Second Approach
Our second approach was to use EMFI based on the ideas published by Riscure (https://www.riscure.com/publication/controlling-pc-arm-using-fault-injection). Riscure proposes using a glitch to cause one instruction to transform into another and gain control of, for example, the PC register. The following image shows the setup we used for this approach, which included a laptop (used as a controller), a power supply, Riscure’s Spider (used to generate the trigger), an oscilloscope, an XYZ table, and the EMFI pulse-generator.
After identifying a small enough area on the PCB, we modified the glitch’s shape and timing until we observed a successful result. The targeted process crashed, as shown below:
Program received signal SIGSEGV, Segmentation fault.
0x2a002f44 in ?? ()
#0 0x2a002f44 in ?? ()
#1 0x2a000f5a in ?? ()
#2 0x2a0011de in ?? ()
#3 0x2a000b04 in ?? ()
#4 0xb6f9b42c in __libc_init () from /system/lib/libc.so
#5 0x2a00099c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
r0 0x41414141 1094795585
r1 0x41414141 1094795585
r2 0xbefff6dc 3204445916
r3 0x41414141 1094795585
r4 0x41414141 1094795585
r5 0xbefffbc4 3204447172
r6 0x85242d9a 2233740698
r7 0xbefff6f0 3204445936
r8 0xb6b4e008 3065307144
r9 0xb6b4e1e8 3065307624
r10 0xbefffad0 3204446928
r11 0x2d7160 2978144
r12 0xbefff6ec 3204445932
sp 0xbefff6c8 0xbefff6c8
lr 0xde 222
pc 0x2a002f44 0x2a002f44
cpsr 0x60000030 1610612784
Our payload appeared in several registers. After examining the code at the target address, we determined that we had hit a winning combination of timing, position, and glitch shape. The following capture shows the instruction where a segmentation error took place:
The capture clearly shows a load instruction copying our data to registers R0 and R1. In addition, the GDB output also shows that registers R3 and R4 ended up with controlled data. Further details can be found in the whitepaper (https://ioac.tv/3N005Bn).
Having successfully caused memory corruption, the next step would be to design a proper payload that achieves code execution. An attacker could use such an exploit to fully control one device, leak all sensitive content, enable ADB access, and potentially leak the encryption keys.
Disclosure Timeline
The DJI team response was excellent, fast and supportive.
2023-04-04: Initial Contact with DJI including sharing report.
2023-05-04: DJI agrees on publication date.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.