BlackHatでのトーク：SamsungのRoot of Trustを破壊 - Samsungのセキュアブートへの悪用

D39は脆弱性研究に注力しており、モバイル、IoTデバイス、LinuxおよびWindowsオペレーティングシステムへの技術的な悪用を含めた、重大なセキュリティ上の欠陥を複数特定しています。私たちが報告した脆弱性は何十種類におよび、SVE（Samsung Vulnerabilities and Exposures）とCVE（Common Vulnerabilities and Exposures）を専門としています。

今月の本題に入る前に、Black Hat USAにTeamT5が再び招待され、来る8月のBlack Hat情報説明会では、当社の脆弱性調査チームであるD39が講演することになりましたのでお知らせします。私たちの研究成果を世界中の研究者やセキュリティ専門家と共有できることを光栄に思うとともに、台湾の脆弱性研究者が世界でより高く評価されることを期待しています。

Black Hatセッション

本記事では、8月に開催されたBlack Hat USAでの講演の一部をご紹介します。

Samsungセキュアブートに複数の脆弱性が見つかり、Samsung Knoxの保護を突破できることが判明しました。ロックされたデバイスから、ユーザーの機密データを取り出すこともできます。影響を受けるSamsung製モバイルフォンGalaxy S8、S9、S10です。これらの脆弱性に対するパッチが、Samsung社から提供されています。

これらの脆弱性の1つでは、攻撃者がGalaxy S8のセキュアブートローダーで任意のコードを実行して、端末にアクセスすることができます。本記事では、USBデバイスを使用して、こういった脆弱性を悪用しS8のセキュアブートローダーを回避し、起動初期段階で任意のコードを実行させる方法について詳しく見ていきましょう。

備考：別のセキュリティ研究チームも同時にこの脆弱性を発見しており、Samsungに報告しています。 ID：SVE-2019-15230（詳細は以下を参照）。

画像のソース

スマートフォン市場のリーダーとして君臨するSamsungは、自社のデバイスのセキュリティを確保するため、Android上で様々な保護を実施しており、これはKnoxプラットフォームと呼ばれています。起動時にSamsungはS-boot（セキュアブート）を使用して、保管されている画像のみしか起動できないようにしています。デバイスがカスタムイメージを起動しようとすると、1回だけプログラムできるビットe-fuse（通称Knoxビット）がトリップします（0X0から0X1へと変化）。トラストゾーンアプリ（trustlet）はKnoxビットのトリップを検出次第、機密データの暗号キーを削除し、不正なデータがロックされたデバイスにアクセスできないようにします。

Samsung Exynosプロセッサを搭載したスマートフォンは、S-bootと呼ばれる独自のセキュアブートローダーを採用しています。S-bootにはODINモードがあり、ユーザーはこのモードを使うことで、手動でファームウェアをアップグレードすることができます。そのコード内に不備があることから、ODINモードのフラッシュコマンド（オペコード：0x66）は、フラッシュイメージのサイズを正しくチェックすることができず、それによりバッファオーバーフローへとつながります。

ODINモードのflashコマンドは、画像を保存するにあたり一時的なバッファを使用します。Galaxy S8では、バッファは0xC0000000にあり、これはsbootコードセグメント（0xC9000000）のすぐ前に位置しています。システムはサイズが0x1e0000より大きくならないように確認しますが、画像のサイズをチェックするにあたり符号付きで比較するため、ここに回避するためのスキが生まれます。そのため、0x80000000より大きなサイズを指定してバッファをオーバーフローさせれば、最終的にコード、スタック、ヒープなどの後続のセグメントが上書きされます。

S-Bootのコードセグメントをオーバーフローさせることはできますが、実行フローをハイジャックすることはできません。USBレシーバーは受信したデータを直接物理メモリに保持するため、キャッシュラインが無効化されない限り、命令キャッシュに影響を与えることはできないからです。

幸い、MMUフラグがあることから、ヒープセグメントはキャッシュされていません。ヒープセグメントにはいくつかのポインターが格納されており、これらのポインターにはUSB処理中にアクセスすることができます。これらのポインターをNULLバイトで上書きすると、プロセッサは例外をトリガーし、NULLポインターへのアクセス中に例外ハンドラーにトラップされます。ハンドラーは一度も実行されていないため、命令キャッシュにはキャッシュされません。従って、例外ハンドラーも同時に上書きすることで、私たちが作成したシェルコードに引き込んで直接ハイジャックすることができます。

スタック、ヒープ、グローバル変数を含めたすべてのランタイムデータが上書きされたため、sbootはこれ以降の起動に失敗します。こういったデータは復旧が困難なため、起動プロセスを再実行する必要があります。

通常、S-bootは、0xC90C7350にある特定の関数テーブル内から複数の関数を呼び出します。s-bootを再実行するためには、これらの関数を再度順次に呼び出す必要があります。関数がヒープやスタックなどのメモリを初期化し、グローバル変数を設定して、最後にカーネルを起動します。しかしながら、これらの関数には2回実行できないSMC呼び出しも含まれています。EL1（例外レベル1）のみを侵害しているので、EL3（例外レベル3）のトラストゾーンを元に戻すことはできません。ですから、SMC呼び出しをNOP命令で上書きしながら、これらのSMC（System Management Controller）呼び出しを無視するために、コードセグメントをオーバーフローさせる必要があります。

すべてのランタイムデータがリセットされた後、オリジナルのカーネルをカスタムカーネルに置き換えます。その後、最後の関数を実行してカスタムカーネルを起動し、KNOXビットをブローさせることなくルート権限 を取得します。

2019年10月02日 脆弱性を報告
2019年10月08日 脆弱性を重複できたことを報告し、パッチノートをリリ

当社の分析によると、この脆弱性はGalaxy S9、Galaxy S10、Galaxy Note 10にも影響を及ぼします。これらの機種の中では、異なるアドレスであったとしても弱点の悪用がトリガーされる可能性があることがわかりました。例えば、Galaxy S10の0x890000000のように、一時バッファが異なるアドレスにある場合でも、悪用される可能性はあります。悪用の完全な流れを説明するために、ファームウェアであるG970FXXU1ASD5を一例として挙げています。

Galaxy S9以降のバージョンでは、セキュアブートにもう一つの機能であるcompressed_downloadが追加されています。この機能は、別のバッファを使用してフラッシュイメージを格納します。しかしながら、初期化中にcompressed_downloadが失敗した場合、通常のダウンロードにフォールバックし、フラッシュイメージの保存にはバッファ（0xC0000000）が使用されます。

S-bootを通常のダウンロードにフォールバックさせるためには、cd_v3_smp_register関数を失敗させる必要があります。入れ替えを行ったところ、起動できるコアがない場合に（booted_cores > 3）、関数cd_v3_smp_registerが失敗を返す可能性があることに気づきました。偶然にも、テストコマンドであるsmp_boot_testがUART（Universal Asynchronous Receiver/Transmitter）コンソールにあります。smp_boot_testコマンドはコアを起動し、booted_coresのカウント数を加算します。smp_boot_testは起動したコアをすぐにシャットダウンしますが、カウントは復元されませんでした。そのため、ダウンロードモードに入る前にsmp_boot_test コマンドを2回以上実行すれば、compressed_download_init が失敗する可能性があります。

UARTデバッグケーブルでUARTコンソールを取得していれば、smp_boot_testコマンドを3回呼び出して、usbコマンドでダウンロードモードに入ることができます。compressed_download_initは失敗し、一時バッファが0xC0000000にフォールバックします。そのため、Galaxy S8の場合と同様に、S10のブートローダ上で任意のコードを実行することが可能になります。

最初は、当社自身でTypeCデバッグケーブルを構築することに成功しました。しかしながら、レジスタ値、TypeCのアクセサリーモード、TypeCのVDMであらゆる値を試してみましたが、RID_523Kを検出するケーブルはまだ見つかっていません。最終的には、デバッグケーブルなしで、Galaxy S10セキュアブートローダーの任意のコード許可 を得ることができる別の方法を適用しました。

Black Hatで詳しく説明する予定です。お楽しみに。

D39が実施した最新の脆弱性調査については、以下を参照してください。

TeamT5公式ウェブサイト： https://teamt5.org/

ツイッター：
TeamT5
TeamT5 株式会社