Kit Pengembangan Uji Keamanan Android (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) dibangun di atas test harness Android Trade Federation untuk menguji semua perangkat Android untuk uji patch keamanan yang tidak termasuk dalam Compatibility Test Suite. Tes ini khusus untuk perbaikan yang terkait (atau akan dikaitkan) dengan Kerentanan Umum dan Eksposur (CVE).

SDK memungkinkan pengembangan pengujian STS di luar pohon sumber Android menggunakan Android Studio atau Android SDK standar. Ini mencakup semua utilitas yang diperlukan untuk membangun dan menjalankan tes 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 ) perlu diinstal dan berada di $PATH Anda (yaitu, Anda harus dapat menjalankan adb dari baris perintah). Cara termudah untuk menginstal alat platform adalah melalui manajer paket distro Anda.
  • Jika menggunakan pengelola SDK Android Studio alih-alih alat platform mandiri, ingatlah untuk menambahkan direktori platform-tools SDK ke $PATH Anda.
• aapt , yang juga dapat diinstal melalui manajer 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 bukanlah hal sepele dan di luar cakupan dokumen ini.

Mulailah menggunakan Android Studio

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

Mulailah menggunakan Gradle

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

Tulis tes STS

Catatan: Tes STS lolos saat perangkat tidak rentan, dan gagal saat perangkat rentan, atau dengan kata lain, saat serangan berhasil. Tes harus mengembalikan ASSUMPTION_FAILURE (misalnya, dengan menggunakan Assume alih-alih Assert ) saat tidak dapat menentukan apakah perangkat rentan atau tidak.

Ada tiga bagian untuk tes STS:

1. Pengujian Tradefed sisi host yang berinteraksi dengan perangkat melalui adb, di subdirektori sts-test .
2. Serangan proof-of-concept native opsional yang didorong ke perangkat melalui adb push dan dieksekusi 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 rangkaian pernyataan JUnitnya sendiri yang dilaporkan ke runner sisi host. Ini ada di subdirektori test-app .

Alur uji STS tipikal biasanya mengikuti salah satu dari dua pola:

• Bukti konsep asli:

  1. Tes sisi host mendorong dan meluncurkan executable asli pada perangkat.
  2. Program asli mogok atau mengembalikan kode keluar tertentu.
  3. Pengujian sisi host memeriksa error, melihat backtrace logcat, atau mencari kode keluar khusus untuk menentukan apakah serangan berhasil.

• Aplikasi pengujian berinstrumen:

  1. Pengujian sisi host mendorong 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. JUnit sisi perangkat menguji tombol ketuk dan menonton aplikasi menggunakan UIAutomator, atau mengakses sistem Android dengan cara yang mengungkapkan kerentanan keamanan.
  4. Keberhasilan atau kegagalan pengujian JUnit sisi perangkat dikembalikan ke pengujian sisi host, yang dapat digunakan untuk menentukan apakah pengujian lulus atau tidak.

Kombinasi dari dua pola (misalnya, menjalankan program asli bersamaan dengan pengujian sisi perangkat) juga dimungkinkan. Beberapa framework instrumentasi lainnya, seperti frida-inject , juga tersedia. Untuk detailnya, lihat dokumen referensi Security Test Suite dan dokumen referensi Tradefed .

Serangan proof-of-concept saya tidak memerlukan aplikasi uji dan/atau dapat dieksekusi asli

Sebagian besar pengujian tidak memerlukan aplikasi sisi perangkat dan eksekusi asli.

Jika pengujian Anda tidak melibatkan penggunaan aplikasi/layanan di perangkat, cukup hapus subdirektori test-app . Demikian pula, jika pengujian Anda tidak menggunakan native executable, hapus subdirektori native-poc lalu sinkronkan proyek secara Gradle. Proyek diatur untuk secara otomatis melewati pembuatan modul-modul itu ketika tidak ada.

Serangan proof-of-concept saya melibatkan aplikasi/layanan kedua

Pertama, tambahkan Modul baru ke proyek Anda 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 . Ini akan memastikan APK yang dikompilasi disalin ke direktori keluaran STS dan memungkinkan penginstalan/pemanggilan aplikasi baru dari pengujian.

Terakhir, sinkronkan proyek secara Gradle.

Menyerahkan tes STS

Jalankan tugas zipForSubmission (baik dengan Android Studio atau dengan Gradle pada baris perintah). File baru, codesubmission.zip , harus dibuat di direktori build di root proyek. Unggah file itu bersama dengan kiriman Anda ke Program Penghargaan Kerentanan Android.