Kit di sviluppo della suite di test per la sicurezza Android (SDK STS)

Security Test Suite Trade Federation (sts-tradefed) si basa sul test cablaggio di Android Trade Federation per testare tutti i dispositivi Android per test delle patch di sicurezza che non rientrano nella Compatibility Test Suite. Questi test riguardano esclusivamente le correzioni associate (o che saranno associate) a vulnerabilità ed esposizioni comuni (CVE).

L'SDK consente lo sviluppo di test STS all'esterno dell'albero dei sorgenti Android utilizzando Android Studio o l'SDK Android standard. Include tutte le utilità necessarie per creare ed eseguire un test STS.

Ottieni l'SDK STS più recente

Prerequisiti

  • PC Linux a 64 bit.
  • Android Studio (può essere installato anche dal gestore pacchetti della tua distribuzione.
  • Gli strumenti della piattaforma Android ( adb , fastboot ) devono essere installati ed essere presenti nel tuo $PATH (ovvero dovresti essere in grado di eseguire adb dalla riga di comando). Il modo più semplice per installare gli strumenti della piattaforma è tramite il gestore pacchetti della tua distribuzione.
    • Se utilizzi il gestore SDK di Android Studio anziché gli strumenti della piattaforma autonoma, ricorda di aggiungere la directory platform-tools dell'SDK al tuo $PATH.
  • aapt , che può essere installato anche tramite il gestore pacchetti della tua distribuzione.

Inizia a utilizzare Android Studio

Dopo aver estratto l'archivio, apri la directory in Android Studio come progetto esistente. Esegui la destinazione di build assembleSTSARM o assembleSTSx86 per creare il test skeleton, a seconda dell'architettura del dispositivo Android di destinazione. Eseguire il target di build runSTS per eseguire il test skeleton sul dispositivo connesso (ADB deve essere autorizzato).

Inizia a utilizzare Gradle

Dopo aver estratto l'archivio, imposta la proprietà sdk.dir nel file local.properties nella radice del progetto Gradle, quindi esegui l'attività assembleSTSARM Gradle per creare il test di struttura. Al termine della compilazione, il test può essere eseguito navigando ( cd ) in build/android-sts/tools ed eseguendo il wrapper 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

Scrivi un test STS

Ci sono tre parti in un test STS:

  1. Un test Tradefed lato host che interagisce con il dispositivo tramite adb, nella sottodirectory sts-test .
  2. Un attacco proof-of-concept nativo opzionale che viene inviato al dispositivo tramite adb push ed eseguito dal test lato host nella sottodirectory native-poc .
  3. Un'app facoltativa o un APK di servizio installato sul dispositivo tramite adb install e avviato anche dal test lato host. L'app o il servizio può contenere anche un proprio set di asserzioni JUnit segnalato al runner lato host. Questo è nella sottodirectory test-app .

Un tipico flusso di test STS segue solitamente uno dei due modelli seguenti:

  • Prova di concetto nativa:

    1. Il test lato host invia e avvia un eseguibile nativo sul dispositivo.
    2. Il programma nativo si blocca o restituisce un codice di uscita specifico.
    3. Il test lato host verifica la presenza di arresti anomali, esamina il backtrace del logcat o cerca il codice di uscita specifico per determinare se l'attacco ha avuto successo.
  • App di test strumentato:

    1. Il test lato host inserisce un APK costituito da un'app o un servizio nel dispositivo.
    2. Il test lato host avvia i test JUnit lato dispositivo forniti in bundle con l'APK tramite runDeviceTest()
    3. Il JUnit lato dispositivo testa i pulsanti e controlla l'app utilizzando UIAutomator o accede in altro modo al sistema Android in modi che rivelano vulnerabilità della sicurezza.
    4. Il successo o il fallimento dei test JUnit lato dispositivo viene restituito al test lato host, che può essere utilizzato per determinare se il test è stato superato o meno.

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

Il mio attacco proof-of-concept non necessita di un'app di prova e/o di un eseguibile nativo

La maggior parte dei test non richiederà né un'app sul dispositivo né un eseguibile nativo.

Se il test non prevede l'uso di un'app/servizio sul dispositivo, elimina semplicemente la sottodirectory test-app . Allo stesso modo, se il tuo test non utilizza un eseguibile nativo, elimina la sottodirectory native-poc quindi sincronizza il progetto con Gradle. Il progetto è impostato per ignorare automaticamente la creazione di tali moduli quando non esistono.

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

Innanzitutto, aggiungi un nuovo modulo al tuo progetto per la tua seconda app/servizio e scrivilo come faresti con qualsiasi altro APK.

Successivamente, modifica build.gradle nella radice di questa directory e aggiungi il tuo modulo seguendo le istruzioni in copyArtifacts , assembleStsARM e assembleStsx86 . Ciò garantirà che l'APK compilato venga copiato nella directory di output di STS e consenta l'installazione/richiamo della nuova app dal test.

Infine, sincronizza il progetto con Gradle.

Invio del test STS

Esegui l'attività zipForSubmission (con Android Studio o con Gradle sulla riga di comando). Un nuovo file, codesubmission.zip , dovrebbe essere creato nella directory build alla radice del progetto. Carica il file insieme al tuo contributo al programma Android Vulnerability Reward.