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.
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 eseguireadb
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.
- Se utilizzi il gestore SDK di Android Studio anziché gli strumenti della piattaforma autonoma, ricorda di aggiungere la directory
- 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:
- Un test Tradefed lato host che interagisce con il dispositivo tramite adb, nella sottodirectory
sts-test
. - Un attacco proof-of-concept nativo opzionale che viene inviato al dispositivo tramite
adb push
ed eseguito dal test lato host nella sottodirectorynative-poc
. - 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 sottodirectorytest-app
.
Un tipico flusso di test STS segue solitamente uno dei due modelli seguenti:
Prova di concetto nativa:
- Il test lato host invia e avvia un eseguibile nativo sul dispositivo.
- Il programma nativo si blocca o restituisce un codice di uscita specifico.
- 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:
- Il test lato host inserisce un APK costituito da un'app o un servizio nel dispositivo.
- Il test lato host avvia i test JUnit lato dispositivo forniti in bundle con l'APK tramite
runDeviceTest()
- 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.
- 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.