セキュリティ テスト スイート Trade Federation (sts-tradefed) はAndroid Trade Federationテスト ハーネスの上に構築され、Compatibility Test Suite に分類されないセキュリティ パッチ テストについてすべての Android デバイスをテストします。これらのテストは、Common Vulnerabilities and Exposures (CVE) に関連付けられている (または関連付けられる予定の) 修正専用です。
SDK を使用すると、Android Studio または標準の Android SDK を使用して、Android ソース ツリーの外部で STS テストを開発できます。 STS テストのビルドと実行に必要なすべてのユーティリティが含まれています。
前提条件
- 64 ビット Linux PC。
- Android Studio (ディストリビューションのパッケージ マネージャーからインストールすることもできます。
- Android プラットフォーム ツール(
adb、fastboot) をインストールして$PATHに入れる必要があります (つまり、コマンド ラインからadbを実行できる必要があります)。プラットフォーム ツールをインストールする最も簡単な方法は、ディストリビューションのパッケージ マネージャーを使用することです。- スタンドアロン プラットフォーム ツールの代わりに Android Studio の SDK マネージャーを使用する場合は、SDK の
platform-toolsディレクトリを $PATH に追加することを忘れないでください。
- スタンドアロン プラットフォーム ツールの代わりに Android Studio の SDK マネージャーを使用する場合は、SDK の
- aaptは、ディストリビューションのパッケージ マネージャーからもインストールできます。
Android Studio を使ってみる
アーカイブを解凍したら、Android Studio でディレクトリを既存のプロジェクトとして開きます。ターゲット Android デバイスのアーキテクチャに応じて、 assembleSTSx86 assembleSTSARMターゲットを実行して、スケルトン テストをビルドします。 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 つの部分があります。
-
sts-testサブディレクトリにある、adb を介してデバイスとやり取りするホスト側の Tradefed テスト。 -
adb pushを介してデバイスにプッシュされ、native-pocサブディレクトリ内のホスト側テストによって実行されるオプションのネイティブ概念実証攻撃。 -
adb installによってデバイスにインストールされ、ホスト側のテストによって起動されるオプションのアプリまたはサービス APK。アプリまたはサービスには、ホスト側のランナーに報告される独自の JUnit アサーション セットを含めることもできます。これはtest-appサブディレクトリにあります。
典型的な STS テスト フローは通常、次の 2 つのパターンのいずれかに従います。
ネイティブの概念実証:
- ホスト側のテストは、ネイティブの実行可能ファイルをデバイスにプッシュして起動します。
- ネイティブ プログラムがクラッシュするか、特定の終了コードを返します。
- ホスト側のテストでは、クラッシュのチェック、logcat バックトレースの確認、または特定の終了コードの検索を行って、攻撃が成功したかどうかを判断します。
インストルメント化されたテスト アプリ:
- ホスト側のテストでは、アプリまたはサービスで構成される APK をデバイスにプッシュします。
- ホスト側のテストは、
runDeviceTest()を通じて APK にバンドルされているデバイス側の JUnit テストを開始します。 - デバイス側の JUnit は、ボタンのタップをテストし、UIAutomator を使用してアプリを監視するか、セキュリティの脆弱性を明らかにする方法で Android システムにアクセスします。
- デバイス側の JUnit テストの成功または失敗はホスト側のテストに返され、テストが成功したかどうかを判断するために使用できます。
2 つのパターンの組み合わせ (たとえば、デバイス側のテストと組み合わせてネイティブ プログラムを実行する) も可能です。 frida-injectなどの他の計測フレームワークも利用できます。詳細については、 Security Test Suite リファレンス ドキュメントとTradefed リファレンス ドキュメントを参照してください。
私の概念実証攻撃は、テスト アプリやネイティブ実行可能ファイルを必要としません。
ほとんどのテストでは、デバイス側のアプリとネイティブの実行可能ファイルの両方は必要ありません。
テストにデバイス上のアプリ/サービスの使用が含まれていない場合は、単にtest-appサブディレクトリを削除してください。同様に、テストでネイティブ実行可能ファイルを使用しない場合は、 native-pocサブディレクトリを削除してから、プロジェクトを Gradle 同期します。プロジェクトは、それらのモジュールが存在しない場合、それらのモジュールのビルドを自動的にスキップするように設定されています。
私の概念実証攻撃には、2 番目のアプリ/サービスが含まれます
まず、2 番目のアプリ/サービスのプロジェクトに新しいモジュールを追加し、他の APK と同じように記述します。
次に、このディレクトリのルートにあるbuild.gradleを編集し、 copyArtifacts 、 assembleStsARM 、およびassembleStsx86の指示に従ってモジュールを追加します。これにより、コンパイルされた APK が STS の出力ディレクトリにコピーされ、テストから新しいアプリをインストール/呼び出しできるようになります。
最後に、プロジェクトを Gradle 同期します。
STS テストの送信
zipForSubmissionタスクを実行します (コマンド ラインで Android Studio または Gradle を使用)。プロジェクトのルートにあるbuildディレクトリに新しいファイルcodesubmission.zipを作成する必要があります。 Android Vulnerability Reward Program への提出物と一緒にそのファイルをアップロードします。