Android セキュリティ AutoRepro

AutoRepro Gradle プラグインは、Android Trade Federation テストハーネスの上に構築されており、Android のセキュリティに関する公開情報の脆弱性に対するセキュリティ パッチテストですべての Android デバイスをテストします。これらのテストは、共通脆弱性識別子(CVE)に関連付けられている(または関連付けられる予定の)修正専用のテストです。

このプラグインにより、Android Studio または標準の Android SDK を使用して、Android ソースツリーの外部で Tradefed テストを開発できます。このプラグインには、Tradefed テストのビルドと実行に必要なすべてのユーティリティが含まれています。

主に、Android 脆弱性報奨金プログラムにおける再現可能な概念実証の自動送信に使用されます。

AutoRepro のサンプルをダウンロード

前提条件

64 ビット Linux PC 用の手順をご覧ください。

  • Android Studio Ladybug 以降 - ディストリビューションのパッケージ管理システムからインストールすることもできます。
  • Android SDK プラットフォーム ツールadbfastboot)- $PATH にインストールしておく必要があります(コマンドラインから adb を実行できるようにする)。プラットフォーム ツールをインストールする最も簡単な方法は、ディストリビューションのパッケージ管理システムを使用することです。
    • スタンドアロン プラットフォーム ツールではなく Android Studio の SDK Manager を使用している場合は、コマンドライン開発の $PATH に SDK の platform-tools ディレクトリを必ず追加してください。
  • AAPT2 - ディストリビューションのパッケージ管理システムを使用してインストールすることもできます。
  • Java JDK 21 以降 - Android SDK と Gradle に対応しています。

Android Studio の使用を開始する

サンプルまたはテンプレートの解凍後に、Android Studio でディレクトリを既存のプロジェクトとして開き、Gradle の同期が完了するまで待機します。事前に設定された Android Studio の実行構成がいくつかあります。

Gradle タスク:

  • assembleSubmissionSources - ソースファイルを提出物の zip 用にアセンブルします。
  • assembleSubmissionZip - 提出物の zip をアップロード用にアセンブルします。
  • copyInvocationResultsToSubmission - 審査プロセスをサポートするため、以前の Tradefed 呼び出しの結果を AutoRepro の提出物のソース ディレクトリにコピーします。ホストとデバイス両方のログが含まれ、このタスクの実行前後の内容が審査されます。

AutoRepro 呼び出しの Android Studio 実行構成は以下のとおりです。

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

ランチャー構成は、autorepro_{device_root}_{device_arch} 形式です。root を要求する脆弱性の方が重大度が低いため、一般的に非 root の使用が適しています。ただし、セットアップやクリーンアップへの root の使用が許容されるのは、それが明記され、一般に有効な非 root 状態として受け入れられている場合に限られます。たとえば、2 台目のデバイスや複数の SIM カードが必要とならないように、root を使用して偽のテキスト メッセージをデバイスに送信することは許容されます。

これらにより、テスト用の Tradefed が起動します。Tradefed は有効なデバイスが接続されるまで待機状態となるため、確実にデバイスを接続し、ADB デバッグが承認されるようにします。

AutoRepro テストを作成する

AutoRepro テストは次の 3 つの部分で構成されており、対応する 3 つの Gradle プラグインがあります。

  1. Gradle プラグイン id("com.android.security.autorepro.javahosttest") ホスト側の単一の Tradefed テストで、ADB を介してデバイスとやり取りします。サンプルでは submission/hostTest/ ディレクトリで使用されています。
  2. Gradle プラグイン id("com.android.security.autorepro.apptest") アプリまたはサービス APK で、adb install を介してデバイスにインストールされ、ホスト側のテストにより起動されます。アプリまたはサービスには、ホスト側のランナーに報告される JUnit アサーションの独自のセットを含めることもできます。サンプルでは、submission/appTest/ とディレクトリで使用されています。
  3. Gradle プラグイン id("com.android.security.autorepro.ndktest") NDK ベースの概念実証攻撃(任意)で、adb push を介してデバイスにプッシュされ、ホスト側のテストにより実行されます。サンプルでは submission/ndkTest/ ディレクトリで使用されています。

一般的な AutoRepro テストフローは、次の 2 つのパターンのいずれかで進行します。

  • インストルメンテーション テストアプリ:

    1. ホスト側のテストは、インストルメンテーション アプリまたはサービスで構成された APK をデバイスにプッシュします。
    2. ホスト側のテストは、runDeviceTest() を介して、APK にバンドルされているデバイス側の JUnit テストを開始します。
    3. デバイス側の JUnit テストは、ボタンをタップして UIAutomator によりアプリを監視するか、セキュリティの脆弱性を明らかにするような方法で Android API にアクセスします。
    4. デバイス側の JUnit テストの成功または失敗がホスト側のテストに返されます。これにより、テスト結果が合格かどうかを判断できます。失敗のメッセージには、アサーションの失敗理由に関する詳細情報と脆弱性の証明として特定のオブジェクト、値、例外、スタック トレース、または他のアーティファクトのいずれかが含まれます。
  • NDK 概念実証:

    1. ホスト側のテストは、デバイス上で Linux 実行可能ファイルをプッシュして起動します。
    2. ネイティブ プログラムがクラッシュするか、特定の終了コードを返します。
    3. ホスト側のテストは、クラッシュをチェックするか、logcat バックトレースを確認するか、特定の終了コードを調べて、攻撃が成功したかどうかを判定します。失敗のメッセージには、アサーションの失敗理由に関する詳細情報と、脆弱性の証明として特定の構造体、値、スタックトレース、または他のアーティファクトのいずれかが含まれます。

上記の 2 つのパターンを組み合わせる(たとえば、デバイス側のテストと同時にネイティブ プログラムを実行する)こともできます。他のなんらかのインストルメンテーション フレームワーク(frida-inject など)も使用できます。詳しくは、セキュリティ テストスイートのリファレンス ドキュメントTradefed のリファレンス ドキュメントをご覧ください。

概念実証攻撃にテストアプリやネイティブ実行可能ファイルは不要である

ほとんどのテストでは、デバイス側のアプリとネイティブ実行可能ファイルの両方は必要ありません。

テストで機能を使用しない場合、不要な Gradle サブプロジェクト ディレクトリは削除してください。

概念実証攻撃に 2 つ目のアプリやサービスが必要である

AutoRepro プラグインに Gradle サブプロジェクトを必要なだけ追加できます。

AutoRepro テストを送信する

提出物の一部としてデバイスのテスト結果を含めるには:

  • Gradle clean タスクを実行し、古いテスト実行を削除します(任意)。
  • 適切な AutoRepro 実行構成を実行し、テストの Tradefed を呼び出して、ログと結果を収集します。
  • copyInvocationResultsToSubmission タスクを実行して、ログと結果を提出物のソース ディレクトリにコピーします。

assembleSubmissionZip を実行して submission/build/autorepro-submission.zip ファイルを作成します。このファイルと提出物の両方を Android 脆弱性報奨金プログラムにアップロードします。添付ファイルはパターン *autorepro-submission*.zip に一致させ、最初のレポートでアップロードするようにしてください。後から提出物をアップロードすると、レポートの適正な審査に悪影響を与えることがあります。