CVE-2020-0022

Insinuator の素晴らしいブログ記事とコードに心から感謝します!

結果

insinuator の投稿に記載されているすべての手順を完了し、さらに追加の作業も行いました。これらの手順は README.md ファイルに記載するには数が多すぎるため、前述の Insinuator の投稿を参照してください。

エクスプロイトは以下の時点まで完全に完成しています:

1. 攻撃者が制御する十分に大きなメモリ領域のアドレスがリークされる
2. プログラムカウンタがカスタムアドレスを指すように変更される
3. 失敗の確率が大幅に低下するまで、自動的にリトライが行われる
4. 切断時間とメモリ検索速度の観点でコードが最適化され、これ以上の最適化はエクスプロイトの安定性を損なうレベルに達している

相違点と改善点

このエクスプロイトは、以下の点で Insinuator の実装とは異なります:

1. python ではなく C で書かれている(C が好きだからです)
2. 各モジュールが特定のタスクを担当するモジュール方式で書かれている
3. Android 9 (PQ3A.190801.002、セキュリティパッチレベル 2019-08-01) を実行している Pixel 3 XL でテストされた(手元にあったため)
4. libicuuc.so ではなく libandroid_runtime.so 内のアドレスをリークする。この電話機/ターゲットではそちらの方がうまく機能したため
5. 2 つの JOP チェーンの例が実装されている。1 つは execv を直接呼び出し、もう 1 つは fork を呼び出してから execv を呼び出す
6. libandroid_runtime.so ファイルを処理して関数とガジェットのオフセットを抽出するカスタム Ghidra スクリプトが付属している(エクスプロイトを他のターゲットへ移植しやすくするため)

デモ/スクリーンショット

これは、エクスプロイトが PC(プログラムカウンタ)を変更してカスタムアドレスを指すようにする様子を示すビデオデモです:

チェーンの最初のイテレーションは jop_experiment で確認できます。このチェーンは fork を呼び出さずに execv を直接呼び出します。コミット ca28fdf 内にあります。このチェーンを使用すると、次のようになります:

チェーンの 2 番目のイテレーションは、fork を呼び出してから execv を呼び出すものです。このチェーンの詳細はこちらにあります。このチェーンを使用すると、次のようになります:

幸いなことに、Pixel 3 XL には Bluetooth プロセスが fork や execv を呼び出すのを防ぐ保護機能があります。知識共有や成果の披露という観点では、私のここでの作業は完了です。これ以上高度なものを執筆・共有すると、ブラックハットにとって有用すぎるものになる可能性があります。

エクスプロイトの結論

このエクスプロイトは完成したと考えています。今後の改善点としては、以下のようなものが考えられます:

• dlsym を呼び出してから mprotect を呼び出し、カスタムシェルコードを実行する JOP チェーンを作成する
• さまざまなターゲットのオフセットのデータベースを収集して保存する
• 相対的な普遍性を目指して、複数のターゲットでエクスプロイトをテストする
• OS レベルのエクスプロイトと連鎖させて root 権限を取得する(私の以前の CVE-2019-2215 エクスプロイトのように)
• その他...

これらすべてのことは、このプロジェクトを楽しい知識共有プロジェクトから、武器化できるブラックハット向けエクスプロイトへと変えてしまいます。ですから、私の探求はひとまずここで終わりです.... ご質問があれば、お気軽にご連絡ください。

使用方法

エクスプロイトを実行するには、次のコマンドを実行するだけです:

make build run ARGS="00:00:00:00:00:00" 

ここで、00:00:00:00:00:00 はターゲット/被害者デバイスの MAC アドレスです。make clean 以外のビルドターゲットは、エクスプロイトを変更、改善、または再実装しようとする場合にのみ役立つため、それらを詳しく説明する必要はありません。

デバッグ

• android の gdbserver バイナリは NDK フォルダにあります
• これを使用してターゲットをデバッグします(推奨しません):

# On target
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# On host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Termux の gdb を介して端末上で直接デバッグする方法(推奨):

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

# On target
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# OR
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Bluetooth サービスが動作しなくなった場合は、攻撃者マシンでサービスを再起動できます:

sudo systemctl restart bluetooth.service

メモ

このセクションでは、このエクスプロイトの開発中に観察されたいくつかの現象について説明します:

• リモートターゲットでのタイムアウトを防ぐために、(HCI ソケット fd を作成する際に)SSP をオフにしています:

• get_message_loop を介して使用される base::MessageLoop オブジェクトの vtable を変更する意図しないオーバーフローによってターゲットがクラッシュする可能性を減らすために、ヒープクリーナーパケットをスプレーしています:

• これは insinuator の投稿では十分に説明されていませんでした。partial_packets の unordered_map の各項目に対して 1 つのリンクリスト項目を含む 32 バイトの malloc チャンクをターゲットにすることで、パケットのアドレスをリークしています。これは map_experiment を使用して解明しました map_experiment は実際のプログラムでリークされる内容と一致しないため、Insinuator のパターンに従い、別のパターン(これも実験によって見つけました)を使用しました。

• クラッシュと PC の上書きによって、chrome シグナルオブジェクトのクラッシュに成功します:

• JOP チェーンは jop_experiment を使用してシミュレーションされています。完全な(最初の execv のみの)JOP チェーンは JOP_PLAN.md で説明されています