Android Security Test Suite Development Kit (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) dibuat di atas harness pengujian Android Trade Federation untuk menguji semua perangkat Android untuk pengujian patch keamanan yang tidak termasuk dalam Compatibility Test Suite. Pengujian ini khusus untuk perbaikan yang terkait (atau akan dikaitkan) dengan Common Vulnerabilities and Exposures (CVE).

SDK memungkinkan pengembangan pengujian STS di luar hierarki sumber Android menggunakan Android Studio atau Android SDK standar. Paket ini mencakup semua utilitas yang diperlukan untuk mem-build dan menjalankan pengujian STS.

Dapatkan STS SDK Terbaru

Prasyarat

• PC Linux 64-bit.
• Android Studio (juga dapat diinstal dari pengelola paket distro Anda.
• Alat platform Android (adb, fastboot) harus diinstal dan berada di $PATH (artinya, Anda dapat menjalankan adb dari command line). Cara termudah untuk menginstal alat platform adalah melalui pengelola paket distro Anda.
  • Jika menggunakan SDK Manager Android Studio, bukan alat platform mandiri, jangan lupa menambahkan direktori platform-tools SDK ke $PATH Anda.
• aapt, yang juga dapat diinstal melalui pengelola paket distro Anda.

Catatan: Lihat panduan CTS jika Anda memerlukan bantuan untuk menyiapkan ADB dan AAPT.

Perhatian: STS secara resmi hanya mendukung mesin Linux 64-bit. Meskipun pengujian yang ditulis dengan STS SDK dapat dibuat dengan Android Studio di Windows atau MacOS, menjalankannya di platform tersebut tidaklah mudah dan berada di luar cakupan dokumen ini.

Mulai menggunakan Android Studio

Setelah mengekstrak arsip, buka direktori di Android Studio sebagai project yang sudah ada. Jalankan target build assembleSTSARM atau assembleSTSx86 untuk mem-build pengujian kerangka, bergantung pada arsitektur perangkat Android target. Jalankan target build runSTS untuk menjalankan pengujian kerangka pada perangkat yang terhubung (ADB harus diberi otorisasi).

Mulai menggunakan Gradle

Setelah mengekstrak arsip, tetapkan properti sdk.dir dalam file local.properties di root project Gradle, lalu jalankan tugas Gradle assembleSTSARM untuk mem-build pengujian kerangka. Setelah build selesai, pengujian dapat dijalankan dengan membuka (cd) ke build/android-sts/tools dan menjalankan wrapper 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

Menulis pengujian STS

Catatan: Pengujian STS lolos saat perangkat tidak rentan, dan gagal saat perangkat rentan, atau dengan kata lain, saat serangan berfungsi. Pengujian harus menampilkan ASSUMPTION_FAILURE (misalnya, dengan menggunakan Assume, bukan Assert) jika tidak dapat menentukan apakah perangkat rentan atau tidak.

Ada tiga bagian dalam pengujian STS:

1. Pengujian Tradefed sisi host yang berinteraksi dengan perangkat melalui adb, di subdirektori sts-test.
2. Serangan bukti konsep native opsional yang didorong ke perangkat melalui adb push dan dijalankan oleh pengujian sisi host di subdirektori native-poc.
3. APK aplikasi atau layanan opsional yang diinstal ke perangkat melalui adb install dan juga diluncurkan oleh pengujian sisi host. Aplikasi atau layanan juga dapat berisi kumpulan pernyataan JUnit-nya sendiri yang dilaporkan ke runner sisi host. Ini ada di subdirektori test-app.

Alur pengujian STS standar biasanya mengikuti salah satu dari dua pola:

• Bukti konsep native:

  1. Pengujian sisi host mendorong dan meluncurkan file yang dapat dieksekusi native di perangkat.
  2. Program native mengalami error atau menampilkan kode keluar tertentu.
  3. Pengujian sisi host memeriksa error, melihat pelacakan balik logcat, atau mencari kode keluar tertentu untuk menentukan apakah serangan berhasil.

• Aplikasi pengujian berinstrumen:

  1. Pengujian sisi host mengirim APK yang terdiri dari aplikasi atau layanan ke perangkat.
  2. Pengujian sisi host memulai pengujian JUnit sisi perangkat yang dipaketkan dengan APK melalui runDeviceTest()
  3. Pengujian JUnit sisi perangkat mengetuk tombol dan mengamati aplikasi menggunakan UIAutomator, atau mengakses sistem Android dengan cara yang mengungkapkan kerentanan keamanan.
  4. Keberhasilan atau kegagalan pengujian JUnit sisi perangkat ditampilkan ke pengujian sisi host, yang dapat digunakan untuk menentukan apakah pengujian berhasil atau tidak.

Kombinasi dari kedua pola tersebut (misalnya, menjalankan program native bersama pengujian sisi perangkat) juga dapat dilakukan. Beberapa framework instrumentasi lainnya, seperti frida-inject, juga tersedia. Untuk mengetahui detailnya, lihat dokumen referensi Security Test Suite dan Dokumen referensi Tradefed.

Serangan bukti konsep saya tidak memerlukan aplikasi pengujian atau native yang dapat dieksekusi

Sebagian besar pengujian tidak akan memerlukan aplikasi sisi perangkat dan file yang dapat dieksekusi secara native.

Jika pengujian Anda tidak melibatkan penggunaan aplikasi/layanan di perangkat, cukup hapus subdirektori test-app. Demikian pula, jika pengujian Anda tidak menggunakan file native yang dapat dieksekusi, hapus subdirektori native-poc, lalu sinkronkan project dengan Gradle. Project disiapkan untuk otomatis melewati pembuatan modul tersebut jika modul tidak ada.

Serangan bukti konsep saya melibatkan aplikasi/layanan kedua

Pertama, tambahkan Modul baru ke project untuk aplikasi/layanan kedua Anda dan tulis seperti yang Anda lakukan pada APK lainnya.

Selanjutnya, edit build.gradle di root direktori ini dan tambahkan modul Anda dengan mengikuti petunjuk di copyArtifacts, assembleStsARM, dan assembleStsx86. Tindakan ini akan memastikan APK yang dikompilasi disalin ke direktori output STS dan memungkinkan penginstalan/pemanggilan aplikasi baru dari pengujian.

Terakhir, sinkronkan project melalui Gradle.

Mengirim pengujian STS

Jalankan tugas zipForSubmission (dengan Android Studio atau dengan Gradle pada command line). File baru, codesubmission.zip, harus dibuat di direktori build di root project. Upload file tersebut beserta pengiriman Anda ke Android Vulnerability Reward Program.