Android Security AutoRepro

Il plug-in Gradle AutoRepro è basato sul framework di test Android Trade Federation per testare tutti i dispositivi Android per i test delle patch di sicurezza rispetto alle vulnerabilità nel Bollettino sulla sicurezza di Android. Questi test riguardano esclusivamente le correzioni associate o che verranno associate a una vulnerabilità ed esposizione comune (CVE).

Il plug-in consente lo sviluppo di test Tradefed al di fuori dell'albero di origine Android utilizzando Android Studio o l'SDK Android standard. Include tutte le utilità necessarie per creare ed eseguire un test Tradefed.

Viene utilizzato principalmente per inviare prove di concetto riproducibili automaticamente per il Vulnerability Reward Program di Android.

Scarica l'esempio di AutoRepro

Prerequisiti

Le istruzioni sono fornite per un PC Linux a 64 bit.

  • Android Studio Ladybug o versioni successive: può essere installato anche dal gestore dei pacchetti della tua distribuzione.
  • Strumenti della piattaforma Android SDK (adb, fastboot) - Devono essere installati e trovarsi in $PATH (ovvero devi essere in grado di eseguire adb dalla riga di comando). Il modo più semplice per installare gli strumenti della piattaforma è utilizzare il gestore di pacchetti della tua distribuzione.
    • Se utilizzi SDK Manager di Android Studio anziché gli strumenti della piattaforma autonomi, ricordati di aggiungere la directory platform-tools dell'SDK al tuo $PATH per lo sviluppo da riga di comando.
  • AAPT2. - Può anche essere installato utilizzando il gestore di pacchetti della tua distribuzione.
  • Java JDK 21 o versioni successive, compatibile con l'SDK Android e Gradle.

Iniziare a utilizzare Android Studio

Dopo aver estratto l'esempio o il modello, apri la directory in Android Studio come progetto esistente e attendi il completamento della sincronizzazione di Gradle. Esistono diverse configurazioni di esecuzione di Android Studio preconfigurate.

Attività Gradle:

  • assembleSubmissionSources - Assembla i file di origine per il file ZIP dell'invio.
  • assembleSubmissionZip - Assembla il file ZIP di invio per il caricamento.
  • copyInvocationResultsToSubmission: copia i risultati delle chiamate Tradefed precedenti nella directory delle origini di invio di AutoRepro per facilitare il processo di revisione. Tieni presente che questo file contiene log sia dell'host sia del dispositivo. Esamina i contenuti prima o dopo l'esecuzione.

Configurazioni di esecuzione di Android Studio per la chiamata di AutoRepro:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Le configurazioni dell'avvio app sono nel formato autorepro_{device_root}_{device_arch}. In genere è preferibile utilizzare nonroot perché le vulnerabilità che richiedono l'accesso root sono meno gravi. Tuttavia, l'utilizzo di root per eseguire la configurazione o la pulizia può essere accettabile a condizione che sia chiaramente documentato e sia generalmente accettato come stato non root valido. Ad esempio, è accettabile utilizzare il root per simulare l'invio di messaggi di testo al dispositivo per evitare di richiedere un secondo dispositivo e più schede SIM.

Questi avvieranno Tradefed per il test. Tradefed attende che venga connesso un dispositivo valido, quindi assicurati che uno sia connesso e che il debug ADB sia autorizzato.

Scrivere un test AutoRepro

Un test AutoRepro è composto da tre parti e da tre plug-in Gradle corrispondenti:

  1. Plug-in Gradle id("com.android.security.autorepro.javahosttest") Il singolo test Tradefed lato host che interagisce con il dispositivo tramite ADB. L'esempio lo utilizza nella directory submission/hostTest/.
  2. Plug-in Gradle id("com.android.security.autorepro.apptest") Un APK di un'app o di un servizio installato sul dispositivo tramite adb install e avviato dal test lato host. L'app o il servizio può anche contenere un proprio insieme di asserzioni JUnit che viene segnalato al runner lato host. L'esempio lo utilizza in submission/appTest/ e nella directory.
  3. Plug-in Gradle id("com.android.security.autorepro.ndktest") Un attacco proof-of-concept facoltativo basato su NDK che viene trasferito sul dispositivo tramite adb push ed eseguito dal test lato host. L'esempio lo utilizza nella directory submission/ndkTest/.

Un tipico flusso di test AutoRepro di solito segue uno dei due pattern:

  • App di test strumentato:

    1. Il test lato host esegue il push di un APK costituito da un servizio o da un'app strumentata sul dispositivo.
    2. Il test lato host avvia i test JUnit lato dispositivo inclusi nell'APK tramite runDeviceTest().
    3. I test JUnit lato dispositivo toccano i pulsanti e osservano l'app utilizzando UIAutomator o accedono alle API Android in modi che rivelano vulnerabilità della sicurezza.
    4. L'esito positivo o negativo dei test JUnit lato dispositivo viene restituito al test lato host, che può essere utilizzato per determinare se il test è stato superato o meno. Il messaggio di errore deve contenere informazioni dettagliate sul motivo per cui l'asserzione non è riuscita e su eventuali oggetti, valori, eccezioni, stacktrace o altri artefatti specifici come prova della vulnerabilità.

  • Proof of concept dell'NDK:

    1. Il test lato host esegue il push e avvia un eseguibile Linux sul dispositivo.
    2. Il programma nativo ha un arresto anomalo o restituisce un codice di uscita specifico.
    3. Il test lato host verifica la presenza di arresti anomali, esamina la traccia stack logcat o cerca il codice di uscita specifico per determinare se l'attacco è andato a buon fine. Il messaggio di errore deve contenere informazioni dettagliate sul motivo per cui l'asserzione non è riuscita e su eventuali struct, valori, stacktrace o altri artefatti specifici come prova della vulnerabilità.

È possibile anche una combinazione dei due pattern (ad esempio, l'esecuzione di un programma nativo in combinazione con test lato dispositivo). Sono disponibili anche altri framework di strumentazione, come frida-inject. Per maggiori dettagli, consulta la documentazione di riferimento di Security Test Suite e la documentazione di riferimento di Tradefed.

Il mio attacco proof-of-concept non richiede un'app di test o un eseguibile nativo

Per la maggior parte dei test non sono necessari sia un'app lato dispositivo sia un eseguibile nativo.

Se il test non prevede l'utilizzo di una funzionalità, elimina le directory dei sottoprogetti gradle non necessarie.

Il mio attacco proof-of-concept coinvolge una seconda app/servizio

Aggiungi tutti i sottoprogetti Gradle con i plug-in AutoRepro che preferisci.

Inviare il test AutoRepro

Per includere i risultati dei test del tuo dispositivo nell'invio:

  • (Facoltativo) Esegui il task Gradle clean per eliminare le vecchie esecuzioni di test.
  • Esegui la configurazione di esecuzione AutoRepro appropriata per richiamare Tradefed per il tuo test e raccogliere log e risultati.
  • Esegui l'attività copyInvocationResultsToSubmission per copiare i log e i risultati nella directory delle origini dell'invio.

Esegui assembleSubmissionZip per creare il file submission/build/autorepro-submission.zip. Carica il file insieme alla tua richiesta al Vulnerability Reward Program di Android. Assicurati che l'allegato corrisponda al pattern *autorepro-submission*.zip e che sia caricato con la segnalazione iniziale. Il caricamento in ritardo delle richieste influirà sulla nostra capacità di esaminare correttamente la tua segnalazione.