Kit di sviluppo Android Security Test Suite (SDK STS)

La Security Test Suite Trade Federation (sts-tradefed) si basa su Federazione commerciale di Android Testa il cablaggio per testare tutti i dispositivi Android per verificare la sicurezza patch che non rientrano nella suite di test di compatibilità. Questi test esclusivamente per le correzioni associate (o che saranno associate) a un Vulnerabilità ed esposizioni comuni (CVE).

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

Scarica l'SDK STS più recente

Prerequisiti

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

Inizia 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 sviluppare lo scheletro di prova, a seconda dell'architettura dell'Android di destinazione dispositivo. Esegui il target di build runSTS per eseguire il test dello scheletro sulla connessione dispositivo (ADB deve essere autorizzato).

Inizia a utilizzare Gradle

Dopo aver estratto l'archivio, imposta la proprietà sdk.dir nel local.properties nella directory principale del progetto Gradle, quindi esegui assembleSTSARM Attività Gradle per creare il test dello scheletro. Dopo la compilazione completato, il test può essere eseguito spostando (cd) in build/android-sts/tools ed esecuzione del 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

Scrittura di un test STS

Il test STS prevede tre parti:

  1. Un test scambiato lato host che interagisce con il dispositivo tramite adb, nella Sottodirectory sts-test.
  2. Un attacco nativo proof-of-concept facoltativo che viene inviato dispositivo tramite adb push ed eseguito dal test lato host in Sottodirectory native-poc.
  3. Un APK facoltativo di app o servizi installato sul dispositivo tramite adb install e anche avviato dal test lato host. L'app o il servizio può anche contenere il proprio insieme di asserzioni JUnit che vengono segnalate lato host. Si trova nella sottodirectory test-app.

Un tipico flusso di test STS di solito segue uno di due pattern:

  • proof-of-concept nativo:

    1. Il test lato host esegue il push e avvia un 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 il backtrace logcat, oppure cerca il codice di uscita specifico per determinare se l'attacco riuscito.

  • App di prova strumentata:

    1. Il test lato host invia un APK costituito da un'app o un servizio su del dispositivo.
    2. Il test lato host avvia i test di JUnit lato dispositivo associati al bundle con l'APK fino a runDeviceTest()
    3. La JUnit lato dispositivo prova toccando i pulsanti e guarda l'app utilizzando UIAutomator o accede in altro modo al sistema Android in modi che individuare vulnerabilità di sicurezza.
    4. L'esito positivo o negativo dei test JUnit lato dispositivo viene restituito a il test lato host, che può essere utilizzato per determinare se è stato superato o meno.

Una combinazione dei due pattern (ad esempio, l'esecuzione di un programma nativo in congiuntamente ai test lato dispositivo). Un'altra strumentazione come frida-inject. Per maggiori dettagli, consulta Documentazione di riferimento di Security Test Suite e il Documenti di riferimento scambiati.

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 nella sottodirectory test-app. Allo stesso modo, se il test non utilizza un eseguibile, elimina la sottodirectory native-poc, quindi sincronizza il progetto con Gradle. Il progetto è configurato in modo da saltare automaticamente la creazione di questi moduli quando non esistono.

Il mio attacco proof-of-concept riguarda una seconda app/un secondo servizio

Innanzitutto, aggiungi un nuovo modulo al progetto per la tua seconda app o servizio e scrivi come qualsiasi altro APK.

Poi modifica build.gradle nella directory principale di questa directory e aggiungi il tuo modulo seguendo le istruzioni in copyArtifacts, assembleStsARM e assembleStsx86. Questo assicura che l'APK compilato venga copiato nell'output directory di STS e consente l'installazione/la chiamata della nuova app dal test.

Infine, sincronizza Gradle il progetto.

Inviare il test STS

Esegui l'attività zipForSubmission (con Android Studio o con Gradle nella riga di comando). Un nuovo file, codesubmission.zip, deve essere creato in build nella directory principale del progetto. Carica il file insieme al programma Android Vulnerability Reward Program.