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

Security Test Suite Trade Federation (sts-tradefed) は、 Android Trade Federationテスト ハーネスの上に構築されており、互換性テスト スイートに該当しないセキュリティ パッチ テストのためにすべての Android デバイスをテストします。これらのテストは、Common Vulnerabilities and Exposures (CVE) に関連付けられた (または関連付けられる予定の) 修正専用です。

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

最新の STS SDK を入手

前提条件

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

Android Studio の使用を開始する

アーカイブを抽出した後、Android Studio でディレクトリを既存のプロジェクトとして開きます。ターゲット Android デバイスのアーキテクチャに応じて、 assembleSTSARMまたはassembleSTSx86ビルド ターゲットを実行してスケルトン テストをビルドします。 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. sts-testサブディレクトリ内の adb を介してデバイスと対話するホスト側の Tradefed テスト。
  2. オプションのネイティブ概念実証攻撃adb pushを通じてデバイスにプッシュされ、 native-pocサブディレクトリ内のホスト側のテストによって実行されます。
  3. adb installを通じてデバイスにインストールされ、ホスト側のテストによっても起動されるオプションのアプリまたはサービス APK。アプリまたはサービスには、ホスト側ランナーに報告される独自の 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編集し、 copyArtifacts 、 assembleStsARM 、およびassembleStsx86の手順に従ってモジュールを追加します。これにより、コンパイルされた APK が STS の出力ディレクトリに確実にコピーされ、テストから新しいアプリのインストール/呼び出しが可能になります。

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

STS テストの提出

zipForSubmissionタスクを実行します (Android Studio またはコマンド ラインの Gradle を使用)。新しいファイルcodesubmission.zipプロジェクトのルートのbuildディレクトリに作成される必要があります。 Android 脆弱性報奨プログラムへの提出物と一緒にそのファイルをアップロードします。