AutoRepro Keamanan Android

Plugin AutoRepro Gradle dibuat berdasarkan test harness Android Trade Federation untuk menguji semua perangkat Android untuk pengujian patch keamanan terhadap kerentanan dalam Android Security Bulletin. Pengujian ini secara eksklusif ditujukan untuk perbaikan yang terkait atau akan dikaitkan dengan Common Vulnerabilities and Exposures (CVE).

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

Plugin ini terutama digunakan untuk mengirimkan bukti konsep yang dapat direproduksi secara otomatis untuk Program Hadiah Kerentanan Android.

Download Langsung Contoh AutoRepro

Jelajahi Contoh dan Template AutoRepro

Prasyarat

Petunjuk disediakan untuk PC Linux 64-bit.

  • Android Studio Ladybug atau yang lebih baru - Juga dapat diinstal dari pengelola paket distro Anda.
  • Alat platform Android SDK (adb, fastboot) - Harus diinstal dan berada di $PATH Anda (Artinya, Anda harus dapat menjalankan adb dari command line). Cara termudah untuk menginstal alat platform adalah menggunakan pengelola paket distro Anda.
    • Jika menggunakan pengelola SDK Android Studio, bukan alat platform mandiri, ingatlah untuk menambahkan direktori platform-tools SDK ke $PATH Anda untuk pengembangan command line.
  • AAPT2. - Juga dapat diinstal menggunakan pengelola paket distro Anda.
  • Java JDK 21 atau yang lebih baru - kompatibel dengan Android SDK dan Gradle.

Mulai menggunakan Android Studio

Setelah mengekstrak contoh atau template, buka direktori di Android Studio sebagai project yang ada dan tunggu sinkronisasi Gradle selesai. Ada beberapa konfigurasi run Android Studio yang telah dikonfigurasi sebelumnya.

Tugas Gradle:

  • assembleSubmissionSources - Mengumpulkan file sumber untuk pengiriman zip.
  • assembleSubmissionZip - Mengumpulkan zip pengiriman untuk diupload.
  • copyInvocationResultsToSubmission - Menyalin hasil dari pemanggilan Tradefed sebelumnya ke direktori sumber pengiriman AutoRepro untuk membantu proses peninjauan. Perhatikan bahwa direktori ini berisi log dari host dan perangkat; tinjau konten sebelum atau setelah menjalankan direktori ini.

Konfigurasi run Android Studio pemanggilan AutoRepro:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Konfigurasi peluncur berada dalam bentuk autorepro_{device_root}_{device_arch}. Umumnya, lebih baik menggunakan nonroot karena kerentanan yang memerlukan root tidak terlalu parah. Namun, penggunaan root untuk melakukan penyiapan atau pembersihan dapat diterima selama didokumentasikan dengan jelas dan umumnya diterima sebagai status nonroot yang valid. Misalnya, penggunaan root untuk mengirim pesan teks palsu ke perangkat dapat diterima untuk menghindari kebutuhan akan perangkat kedua dan beberapa kartu SIM.

Tindakan ini akan meluncurkan Tradefed untuk pengujian Anda. Tradefed menunggu perangkat yang valid terhubung. Jadi, pastikan perangkat terhubung dan proses debug ADB diotorisasi.

Integrasi dengan agen coding

Contoh dan template menyediakan file konteks AGENTS.md yang kompatibel dengan Gemini di Android Studio, Gemini CLI, dan agen coding lainnya. File ini memiliki konten dengan opini tentang penataan pengiriman dan petunjuk tentang cara menggunakan AutoRepro. Anda dapat menggunakannya untuk:

  • Menjalankan AutoRepro secara otomatis untuk perangkat Anda
  • Melakukan peninjauan kode pengiriman yang ada untuk perubahan yang dapat membantu laporan Anda diterima lebih cepat
  • Membantu menyusun PoC baru berdasarkan informasi tentang kerentanan

Menulis pengujian AutoRepro

Ada tiga bagian dalam pengujian AutoRepro dan tiga plugin Gradle yang sesuai:

  1. Plugin Gradle id("com.android.security.autorepro.javahosttest") Pengujian Tradefed sisi host tunggal yang berinteraksi dengan perangkat melalui ADB. Contoh ini menggunakannya di direktori submission/hostTest/.
  2. Plugin Gradle id("com.android.security.autorepro.apptest") APK aplikasi atau layanan yang diinstal ke perangkat melalui adb install dan diluncurkan oleh pengujian sisi host. Aplikasi atau layanan juga dapat berisi kumpulan pernyataan JUnit-nya sendiri yang dilaporkan ke runner sisi host. Contoh ini menggunakannya di direktori submission/appTest/ dan.
  3. Plugin Gradle id("com.android.security.autorepro.ndktest") Serangan bukti konsep berbasis NDK opsional yang dikirim ke perangkat melalui adb push dan dieksekusi oleh pengujian sisi host. Contoh ini menggunakannya di direktori submission/ndkTest/.

Alur pengujian AutoRepro yang umum biasanya mengikuti salah satu dari dua pola:

  • Aplikasi pengujian berinstrumen:

    1. Pengujian sisi host mengirimkan APK yang terdiri dari aplikasi atau layanan berinstrumen ke perangkat.
    2. Pengujian sisi host memulai pengujian JUnit sisi perangkat yang di-bundle dengan APK melalui runDeviceTest().
    3. Pengujian JUnit sisi perangkat mengetuk tombol dan menonton aplikasi menggunakan UIAutomator, atau mengakses Android API 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 lulus atau tidak. Pesan kegagalan harus berisi informasi mendetail tentang alasan pernyataan gagal dan objek, nilai, pengecualian, stacktrace, atau artefak tertentu lainnya sebagai bukti kerentanan.

  • Bukti konsep NDK:

    1. Pengujian sisi host mengirim dan meluncurkan file yang dapat dieksekusi Linux di perangkat.
    2. Program native mengalami error atau menampilkan kode keluar tertentu.
    3. Pengujian sisi host memeriksa error, melihat backtrace logcat, atau mencari kode keluar tertentu untuk menentukan apakah serangan berhasil. Pesan kegagalan harus berisi informasi mendetail tentang alasan pernyataan gagal dan struct, nilai, stacktrace, atau artefak tertentu lainnya sebagai bukti kerentanan.

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

Penataan provabilitas bukti konsep

PoC berkualitas tinggi harus melakukan lebih dari sekadar memicu bug; PoC harus memberikan bukti yang dapat diverifikasi bahwa batas keamanan telah dilanggar. Untuk mencapai hal ini, PoC dapat mengikuti pola "gagal-lalu-berhasil" tiga langkah tertentu:

  1. Penyiapan: Siapkan perangkat dengan menginstal aplikasi yang diperlukan, mengirim file, dan memastikan perangkat berada dalam status tertentu yang diperlukan segera sebelum eksploitasi. (Penggunaan root diizinkan untuk konfigurasi jika dijustifikasi dan mewakili status pengguna akhir yang realistis).
  2. Buktikan Batas: Sebelum memicu kerentanan, coba tindakan target dan tegaskan bahwa tindakan tersebut gagal. Misalnya, jika eksploitasi memungkinkan pembacaan file yang dilindungi, Anda harus mencoba membacanya terlebih dahulu dan mengonfirmasi bahwa Anda menerima error "Izin Ditolak".
  3. Picu &Verifikasi: Picu kerentanan, lalu segera ulangi tindakan dari Langkah 2. Di perangkat yang rentan, tindakan ini sekarang akan berhasil. Untuk memverifikasi hal ini, Anda harus menggunakan pernyataan yang gagal di perangkat yang rentan dengan pesan yang diawali dengan awalan persis AUTOREPRO_VULNERABILITY_PROVEN:. Pesan ini harus menyertakan deskripsi singkat tentang kerentanan dan artefak yang diambil (seperti data yang bocor atau status yang tidak terduga) untuk membuktikan secara definitif bahwa eksploitasi berhasil.

Contoh:

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

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

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

Jika pengujian Anda tidak melibatkan penggunaan fitur, hapus direktori subproject gradle yang tidak diperlukan.

Serangan bukti konsep saya melibatkan aplikasi atau layanan kedua

Tambahkan subproject Gradle sebanyak yang Anda inginkan dengan plugin AutoRepro.

Mengirim pengujian AutoRepro

Untuk menyertakan hasil pengujian dari perangkat Anda sebagai bagian dari pengiriman:

  • Secara opsional, jalankan tugas Gradle clean untuk menghapus pengujian lama.
  • Jalankan konfigurasi run AutoRepro yang sesuai untuk memanggil Tradefed untuk pengujian Anda dan mengumpulkan log serta hasil.
  • Jalankan tugas copyInvocationResultsToSubmission untuk menyalin log dan hasil ke direktori sumber pengiriman.

Jalankan assembleSubmissionZip untuk membuat file submission/build/autorepro-submission.zip. Upload file tersebut bersama dengan pengiriman Anda ke Program Hadiah Kerentanan Android. Pastikan lampiran cocok dengan pola *autorepro-submission*.zip dan diupload dengan laporan awal. Mengupload pengiriman terlambat akan memengaruhi kemampuan kami untuk meninjau laporan Anda dengan benar.