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à del 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 della struttura 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.

Direct Download AutoRepro Example

Sfoglia l'esempio e i modelli 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 da caricare.
  • 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 del launcher 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.

Integrazione con gli agenti di codifica

L'esempio e i modelli forniscono un file di contesto AGENTS.md compatibile con Gemini in Android Studio, Gemini CLI e altri agent di codifica. Contiene contenuti con opinioni sulla strutturazione degli invii e istruzioni sull'utilizzo di AutoRepro. Puoi utilizzarlo per:

  • Eseguire automaticamente AutoRepro per il dispositivo
  • Rivedi il codice di un invio esistente per individuare le modifiche che possono contribuire ad accelerare l'accettazione del report.
  • Aiutare a strutturare una nuova prova di concetto in base alle informazioni sulla vulnerabilità

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 app o 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. Plugin 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 instrumentata 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.

Strutturazione della dimostrabilità della proof of concept

Una PoC di alta qualità deve fare di più che attivare un bug: deve fornire una prova verificabile che un confine di sicurezza è stato superato. Per raggiungere questo obiettivo, i PoC possono seguire un modello specifico in tre passaggi "fallimento-successo":

  1. Configurazione:prepara il dispositivo installando le app necessarie, trasferendo i file e assicurandoti che il dispositivo si trovi nello stato specifico richiesto immediatamente prima dell'exploit. L'utilizzo della root è consentito per la configurazione se giustificato e rappresentativo di uno stato realistico dell'utente finale.
  2. Dimostra il limite:prima di attivare la vulnerabilità, tenta l'azione di destinazione e afferma che non va a buon fine. Ad esempio, se l'exploit consente la lettura di un file protetto, devi prima tentare di leggerlo e confermare di ricevere un errore "Autorizzazione negata".
  3. Attivazione e verifica:attiva la vulnerabilità, quindi ripeti immediatamente l'azione del passaggio 2. Su un dispositivo vulnerabile, questa azione ora dovrebbe riuscire. Per verificare questo, devi utilizzare un'asserzione che non viene superata su un dispositivo vulnerabile con un messaggio che inizia con il prefisso esatto AUTOREPRO_VULNERABILITY_PROVEN:. Questo messaggio deve includere una descrizione concisa della vulnerabilità e degli artefatti acquisiti (come dati trapelati o stati imprevisti) per dimostrare in modo definitivo che l'exploit è andato a buon fine.

Esempio:

@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);
    }
}

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

La maggior parte dei test non richiede 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 o un secondo servizio

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

Inviare il test AutoRepro

Per includere i risultati dei test dal 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 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 venga caricato con la segnalazione iniziale. Il caricamento tardivo delle richieste influirà sulla nostra capacità di esaminare correttamente la tua segnalazione.