Kit di sviluppo di Android Security Test Suite (SDK STS)

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

L'SDK consente lo sviluppo di test STS 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 STS.

Ottieni l'ultimo SDK STS

Prerequisiti

  • PC Linux a 64 bit.
  • Android Studio (può anche essere installato dal gestore pacchetti della tua distribuzione.
  • Gli strumenti della piattaforma Android ( adb , fastboot ) devono essere installati ed essere 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 autonomi, ricorda di aggiungere la directory platform-tools dell'SDK al tuo $PATH.
  • aapt , che può anche essere installato 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. Eseguire la destinazione di compilazione assembleSTSARM o assembleSTSx86 per creare il test di scheletro, a seconda dell'architettura del dispositivo Android di destinazione. Eseguire la destinazione di compilazione runSTS per eseguire il test scheletro sul dispositivo connesso (ADB deve essere autorizzato).

Inizia a utilizzare Gradle

Dopo aver estratto l'archivio, impostare la proprietà sdk.dir nel file local.properties nella radice del progetto Gradle, quindi eseguire l'attività Gradle assembleSTSARM per creare lo scheletro di test. 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 facoltativo 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 che viene installato sul dispositivo tramite adb install e avviato anche dal test lato host. L'app o il servizio può anche contenere il proprio set di asserzioni JUnit che viene segnalato all'host-side runner. Si trova nella sottodirectory test-app .

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

  • Prova di concetto nativa:

    1. Il test lato host esegue il push e avvia un eseguibile nativo nel dispositivo.
    2. Il programma nativo va in crash o restituisce un codice di uscita specifico.
    3. Il test lato host verifica la presenza di arresti anomali, esamina il backtrace logcat o cerca il codice di uscita specifico per determinare se l'attacco ha avuto successo.

  • App di prova strumentata:

    1. Il test lato host esegue il push di un APK costituito da un'app o un servizio sul dispositivo.
    2. Il test lato host avvia i test JUnit lato dispositivo forniti in bundle con l'APK tramite runDeviceTest()
    3. Il test JUnit lato dispositivo tocca i pulsanti e controlla l'app utilizzando UIAutomator o accede in altro modo al sistema Android in modi che rivelano vulnerabilità di 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.

È 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 i 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 test e/o di un eseguibile nativo

La maggior parte dei test non avrà bisogno sia di un'app lato dispositivo che di un eseguibile nativo.

Se il test non prevede l'uso di un'app/servizio sul dispositivo, è sufficiente eliminare la sottodirectory test-app . Allo stesso modo, se il tuo test non utilizza un eseguibile nativo, elimina la sottodirectory native-poc quindi Gradle-sync il progetto. Il progetto è impostato per saltare automaticamente la creazione di quei 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 alla radice di questa directory e aggiungi il tuo modulo seguendo le istruzioni in copyArtifacts , assembleStsARM e assembleStsx86 . Ciò assicurerà che l'APK compilato venga copiato nella directory di output di STS e consentirà l'installazione/chiamata della nuova app dal test.

Infine, Gradle sincronizza il progetto.

Invio del test STS

Esegui l'attività zipForSubmission (con Android Studio o con Gradle sulla riga di comando). Un nuovo file, codesubmission.zip , deve essere creato nella directory build nella radice del progetto. Carica quel file insieme al tuo invio al programma di ricompensa per la vulnerabilità di Android.