Android セキュリティ テストスイート開発キット(STS SDK)

セキュリティ テストスイート Trade Federation(sts-tradefed)は、Android Trade Federation テストハーネスの上に構築されており、互換性テストスイートにフォールバックしないセキュリティ パッチテストですべての Android デバイスをテストします。これらのテストは、共通脆弱性識別子(CVE)に関連付けられている(または関連付けられる予定の)修正専用のテストです。

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

最新の STS SDK を入手する

前提条件

  • 64 ビット Linux PC。
  • Android Studio(ディストリビューションのパッケージ マネージャーからインストールすることもできます)。
  • Android プラットフォーム ツールadbfastboot)を $PATH にインストールしておく(コマンドラインから adb を実行する必要があります)。プラットフォーム ツールをインストールする最も簡単な方法は、ディストリビューションのパッケージ マネージャーを使用することです。
    • スタンドアロン プラットフォーム ツールではなく Android Studio の SDK Manager を使用している場合は、SDK の platform-tools ディレクトリを $PATH に必ず追加してください。
  • aapt(ディストリビューションのパッケージ マネージャーからインストールすることもできます)。

Android Studio の使用を開始する

アーカイブを展開した後、Android Studio で既存のプロジェクトとしてディレクトリを開きます。assembleSTSARM または assembleSTSx86 ビルド ターゲットを実行し、ターゲット Android デバイスのアーキテクチャに応じてスケルトン テストをビルドします。runSTS ビルド ターゲットを実行し、接続されたデバイスでスケルトン テストを実行します(ADB を承認する必要があります)。

Gradle の使用を開始する

アーカイブを展開した後、Gradle プロジェクトのルートにある local.properties ファイルで sdk.dir プロパティを設定し、assembleSTSARM Gradle タスクを実行してスケルトン テストをビルドします。ビルドが完了したら、build/android-sts/tools に移動(cd)して sts-tradefed ラッパーを実行することにより、テストを実行できます。

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

STS テストを作成する

STS テストには以下の 3 つの部分があります。

  1. ホスト側の Tradefed テスト。これは sts-test サブディレクトリで ADB を介してデバイスとやり取りします。
  2. ネイティブ概念実証攻撃(任意)。これは adb push を介してデバイスにプッシュされ、native-poc サブディレクトリでホスト側のテストにより実行されます。
  3. アプリまたはサービス APK(任意)。これは adb install を介してデバイスにインストールされ、さらにホスト側のテストにより起動されます。アプリまたはサービスには、ホスト側のランナーに報告される JUnit アサーションの独自のセットを含めることもできます。これは test-app サブディレクトリにあります。

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

  • ネイティブ概念実証:

    1. ホスト側のテストは、デバイス上でネイティブ実行可能ファイルをプッシュして起動します。
    2. ネイティブ プログラムがクラッシュするか、特定の終了コードを返します。
    3. ホスト側のテストは、クラッシュをチェックするか、logcat バックトレースを確認するか、特定の終了コードを調べて、攻撃が成功したかどうかを判定します。
  • インストルメンテーション テストアプリ:

    1. ホスト側のテストは、アプリまたはサービスで構成された APK をデバイスにプッシュします。
    2. ホスト側のテストは、runDeviceTest() を介して、APK にバンドルされているデバイス側の JUnit テストを開始します。
    3. デバイス側の JUnit テストは、ボタンをタップして UIAutomator によりアプリを監視するか、セキュリティの脆弱性を明らかにするような方法で Android システムにアクセスします。
    4. デバイス側の JUnit テストの成功または失敗がホスト側のテストに返されます。これにより、テスト結果が合格かどうかを判断できます。

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

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

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

デバイス上のアプリやサービスを使用しないテストの場合は、test-app サブディレクトリを削除します。同様に、ネイティブ実行可能ファイルを使用しないテストの場合は、native-poc サブディレクトリを削除してから、プロジェクトを Gradle 同期します。これらのモジュールが存在しない場合は、モジュールのビルドを自動的にスキップするようプロジェクトが設定されています。

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

まず、2 つ目のアプリまたはサービス用に新しいモジュールをプロジェクトに追加し、他の APK と同じように書き込みます。

次に、このディレクトリのルートで build.gradle を編集して、copyArtifactsassembleStsARMassembleStsx86 の手順に沿ってモジュールを追加します。これにより、コンパイルされた APK が STS の出力ディレクトリにコピーされ、テストで新しいアプリのインストールや呼び出しが可能になります。

最後に、プロジェクトを Gradle 同期します。

STS テストを送信する

zipForSubmission タスクを実行します(Android Studio を使用するか、コマンドラインで Gradle を使用する)。新しいファイル codesubmission.zip が、プロジェクトのルートの build ディレクトリに作成されます。このファイルと提出物の両方を Android 脆弱性報奨金プログラムにアップロードします。