AutoRepro Keamanan Android

Plugin Gradle AutoRepro dibangun di atas platform pengujian Android Trade Federation untuk menguji semua perangkat Android terkait pengujian patch keamanan terhadap kerentanan dalam Buletin Keamanan Android. 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 hierarki sumber Android menggunakan Android Studio atau Android SDK standar. Ini mencakup semua utilitas yang diperlukan untuk mem-build dan menjalankan pengujian Tradefed.

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

Contoh AutoRepro Download Langsung

Jelajahi Contoh dan Template AutoRepro

Prasyarat

Petunjuk disediakan untuk PC Linux 64-bit.

• Android Studio Ladybug atau yang lebih baru - Dapat juga diinstal dari pengelola paket distro Anda.
• Alat platform Android SDK (adb, fastboot) - Harus diinstal dan ada di $PATH Anda (Artinya, Anda harus dapat menjalankan adb dari command line). Cara termudah untuk menginstal alat platform adalah dengan menggunakan pengelola paket distro Anda.
  • Jika menggunakan pengelola SDK Android Studio, bukan alat platform mandiri, jangan lupa untuk menambahkan direktori platform-tools SDK ke $PATH 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.

Catatan: Lihat panduan CTS untuk mengetahui detail selengkapnya tentang cara menyiapkan ADB dan AAPT2.

Perhatian: AutoRepro hanya mendukung mesin Linux 64-bit secara resmi. Meskipun pengujian yang ditulis dengan AutoRepro dapat di-build dan dijalankan di Windows atau macOS, pengujian tersebut juga harus kompatibel dengan Linux untuk pengiriman.

Mulai menggunakan Android Studio

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

Tugas Gradle:

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

Tips: Menjalankan copyInvocationResultsToSubmission dapat membantu pengajuan Anda ditinjau lebih cepat dengan memberikan log dan hasil langsung dari perangkat dan host Anda.

Konfigurasi eksekusi Android Studio pemanggilan AutoRepro:

• autorepro_nonroot_arm64
• autorepro_nonroot_x86_64
• autorepro_root_arm64
• autorepro_root_x86_64

Konfigurasi peluncur berbentuk autorepro_{device_root}_{device_arch}. Umumnya lebih baik menggunakan non-root karena kerentanan yang memerlukan akses root lebih tidak parah. Namun, penggunaan root untuk melakukan penyiapan atau pembersihan dapat diterima selama didokumentasikan dengan jelas dan secara umum diterima sebagai status non-root yang valid. Misalnya, Anda dapat menggunakan akses root untuk mengirim pesan teks palsu ke perangkat agar tidak memerlukan perangkat kedua dan beberapa kartu SIM.

Perintah ini akan meluncurkan Tradefed untuk pengujian Anda. Tradefed menunggu perangkat yang valid terhubung, jadi pastikan perangkat terhubung dan proses debug ADB diizinkan.

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. Di dalamnya terdapat konten dengan opini tentang penataan pengiriman dan petunjuk tentang cara menggunakan AutoRepro. Anda dapat menggunakannya untuk:

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

Menulis pengujian AutoRepro

Catatan: Pengujian AutoRepro gagal jika perangkat rentan dan lulus jika perangkat telah di-patch atau tidak rentan. Salah satu keunggulan utama pendekatan ini adalah pesan kegagalan akan berisi informasi mendetail tentang kerentanan dan artefak apa pun yang dihasilkan oleh PoC. Pengujian harus menampilkan ASSUMPTION_FAILURE (misalnya, dengan menggunakan Assume JUnit, bukan Assert) jika tidak dapat menentukan apakah perangkat rentan atau tidak.

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

1. Plugin Gradle id("com.android.security.autorepro.javahosttest") Satu-satunya pengujian Tradefed sisi host yang berinteraksi dengan perangkat melalui ADB. Contoh 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 serangkaian pernyataan JUnit sendiri yang dilaporkan ke peluncur sisi host. Contoh menggunakannya di direktori submission/appTest/ dan.
3. Plugin Gradle id("com.android.security.autorepro.ndktest") Serangan proof-of-concept berbasis NDK opsional yang didorong 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 berikut:

• Aplikasi pengujian berinstrumen:

  1. Pengujian sisi host mengirimkan APK yang terdiri dari aplikasi atau layanan yang diinstrumentasi 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 memantau 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 spesifik lainnya sebagai bukti kerentanan.

• Bukti konsep NDK:

  1. Pengujian sisi host mendorong 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 mengapa pernyataan gagal dan struktur, nilai, stacktrace, atau artefak spesifik lainnya sebagai bukti kerentanan.

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

Struktur pembuktian 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 melakukannya, 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 tepat sebelum eksploitasi. (Penggunaan root diizinkan untuk konfigurasi jika dapat dibenarkan 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 membaca 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. Pada perangkat yang rentan, tindakan ini akan berhasil. Untuk memverifikasi hal ini, Anda harus menggunakan pernyataan yang gagal pada perangkat rentan dengan pesan yang diawali dengan awalan AUTOREPRO_VULNERABILITY_PROVEN: yang sama persis. Pesan ini harus menyertakan deskripsi singkat tentang kerentanan dan artefak yang terekam (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 proof-of-concept saya tidak memerlukan aplikasi pengujian atau file yang dapat dieksekusi native

Sebagian besar pengujian tidak memerlukan aplikasi sisi perangkat dan executable native.

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

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

Tambahkan subproject Gradle dengan plugin AutoRepro sebanyak yang Anda inginkan.

Mengirimkan pengujian AutoRepro

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

• Jalankan tugas Gradle clean secara opsional untuk menghapus semua proses pengujian lama.
• Jalankan konfigurasi eksekusi AutoRepro yang sesuai untuk memanggil Tradefed untuk pengujian Anda dan mengumpulkan log dan 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 beserta kiriman Anda ke Program Penghargaan Kerentanan Android. Pastikan lampiran sesuai dengan pola *autorepro-submission*.zip dan diupload bersama laporan awal. Mengupload kiriman terlambat akan memengaruhi kemampuan kami untuk meninjau laporan Anda dengan benar.