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

注意事項

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

• SSP は（HCI ソケット fd を作成する際に）リモートターゲットでのタイムアウトを防ぐためにオフにされています：

• 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 で説明されています