Kit di sviluppo Android Security Test Suite (SDK STS)

Security Test Suite Trade Federation (sts-tradefed) è basato sull'ambiente di test 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 le correzioni associate (o saranno associate) a vulnerabilità ed esposizioni comuni (CVE).

L'SDK consente lo sviluppo di test STS al di fuori della struttura di origine di Android utilizzando Android Studio o l'SDK Android standard. Include tutte le utilità necessarie per creare ed eseguire un test STS.

Scaricare l'SDK STS più recente

Prerequisiti

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

Iniziare a utilizzare Android Studio

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

Iniziare a utilizzare Gradle

Dopo aver estratto l'archivio, imposta la proprietà sdk.dir nel local.properties file nella radice del progetto Gradle, quindi esegui il assembleSTSARM task Gradle per compilare il test dello scheletro. Al termine della build, per eseguire il test puoi accedere (cd) a 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

Scrivere un test STS

Il test STS prevede tre parti:

  1. Un test Tradefed lato host che interagisce con il dispositivo tramite adb, nella subdirectory sts-test.
  2. Un attacco nativo facoltativo che viene eseguito tramite push sul dispositivo tramite adb push ed eseguito dal test lato host nella sottodirectory native-poc.
  3. Un APK facoltativo di app o servizio installato sul dispositivo tramite adb install e avviato anche 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. Si trova nella sottodirectory test-app.

Un tipico flusso di test STS segue in genere uno dei due schemi:

  • proof-of-concept nativo:

    1. Il test lato host spinge e avvia un file eseguibile nativo sul dispositivo.
    2. Il programma nativo si arresta in modo anomalo o restituisce un codice di uscita specifico.
    3. Il test lato host verifica la presenza di arresti anomali, controlla la backtrace di logcat o cerca il codice di uscita specifico per determinare se l'attacco è riuscito.

  • 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 associati all'APK fino al giorno runDeviceTest()
    3. La JUnit lato dispositivo testa tocca i pulsanti e guarda l'app utilizzando UIAutomator oppure 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 pattern (ad esempio, l'esecuzione di un programma nativo congiuntamente a 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

La maggior parte dei test non richiede sia un'app lato dispositivo sia un eseguibile nativo.

Se il test non prevede l'utilizzo di un'app o un servizio sul dispositivo, elimina semplicemente la sottodirectory test-app. Analogamente, se il test non utilizza un programma eseguibile nativo, elimina la sottodirectory native-poc e sincronizza il progetto con Gradle. Il progetto è configurato per saltare automaticamente la compilazione di questi moduli se non esistono.

Il mio attacco di prova del concetto coinvolge una seconda app/un secondo servizio

Per prima cosa, aggiungi un nuovo modulo al progetto per la tua seconda app/servizio e scrivi come faresti con qualsiasi altro APK.

Poi modifica build.gradle nella directory principale di questa directory e aggiungi il modulo seguendo le istruzioni in copyArtifacts, assembleStsARM e assembleStsx86. In questo modo ti assicuri che l'APK compilato venga copiato nella directory di output di STS e consenta l'installazione/la chiamata della nuova app dal test.

Infine, esegui la sincronizzazione Gradle del progetto.

Inviare il test STS

Esegui il task zipForSubmission (con Android Studio o con Gradle sulla riga di comando). È necessario creare un nuovo file, codesubmission.zip, nella directory build all'interno del progetto. Carica questo file insieme alla tua segnalazione al Vulnerability Reward Program di Android.