Die Security Test Suite Trade Federation (sts-tradefed) baut auf der Testumgebung der Android Trade Federation auf, um alle Android-Geräte auf Sicherheitspatch-Tests zu prüfen, die nicht in die Kompatibilitätstest-Suite fallen. Diese Tests sind ausschließlich für Fehlerkorrekturen vorgesehen, die mit einer Common Vulnerabilities and Exposures (CVE) verknüpft sind oder verknüpft werden.
Mit dem SDK können STS-Tests außerhalb des Android-Quellbaums mit Android Studio oder dem standardmäßigen Android SDK entwickelt werden. Es enthält alle Dienstprogramme, die zum Erstellen und Ausführen eines STS-Tests erforderlich sind.
Neuestes STS SDK herunterladen
Voraussetzungen
- 64-Bit-Linux-PC.
- Android Studio (kann auch über den Paketmanager Ihrer Distribution installiert werden)
- Die Android-Plattformtools (
adb
,fastboot
) müssen installiert und sich in Ihrem$PATH
befinden. Sie sollten alsoadb
über die Befehlszeile ausführen können. Am einfachsten installieren Sie die Plattformtools über den Paketmanager Ihrer Distribution.- Wenn Sie den SDK-Manager von Android Studio anstelle von eigenständigen Plattformtools verwenden, denken Sie daran, das Verzeichnis
platform-tools
des SDK Ihrem $PATH hinzuzufügen.
- Wenn Sie den SDK-Manager von Android Studio anstelle von eigenständigen Plattformtools verwenden, denken Sie daran, das Verzeichnis
- aapt, das auch über den Paketmanager deiner Distribution installiert werden kann.
Erste Schritte mit Android Studio
Öffnen Sie nach dem Extrahieren des Archivs das Verzeichnis in Android Studio als vorhandenes Projekt. Führen Sie das Build-Ziel assembleSTSARM
oder assembleSTSx86
aus, um je nach Architektur des Android-Zielgeräts den Testgerüst zu erstellen. Führen Sie das Buildziel runSTS
aus, um den Skeletttest auf dem verbundenen Gerät auszuführen. ADB muss autorisiert sein.
Erste Schritte mit Gradle
Nachdem Sie das Archiv extrahiert haben, legen Sie die sdk.dir
-Property in der local.properties
-Datei im Stammverzeichnis des Gradle-Projekts fest und führen Sie dann die Gradle-Aufgabe assembleSTSARM
aus, um den Skeletttest zu erstellen. Nachdem der Build abgeschlossen ist, kann der Test ausgeführt werden. Rufen Sie dazu build/android-sts/tools
auf (cd
) und führen Sie den Wrapper sts-tradefed
aus.
$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest
STS-Test schreiben
Ein STS-Test besteht aus drei Teilen:
- Ein hostseitiger Tradefed-Test, der über ADB mit dem Gerät interagiert, im Unterverzeichnis
sts-test
. - Ein optionaler nativer Proof-of-Concept-Angriff, der über
adb push
auf das Gerät gepusht und vom hostseitigen Test im Unterverzeichnisnative-poc
ausgeführt wird. - Ein optionales App- oder Dienst-APK, das über
adb install
auf dem Gerät installiert und auch vom hostseitigen Test gestartet wird. Die App oder der Dienst kann auch eigene JUnit-Behauptungen enthalten, die an den hostseitigen Runner gesendet werden. Sie befindet sich im Unterverzeichnistest-app
.
Ein typischer STS-Testablauf folgt normalerweise einem von zwei Mustern:
Proof of Concept für native Anzeigen:
- Beim hostseitigen Test wird eine native ausführbare Datei auf das Gerät gesendet und dort gestartet.
- Das native Programm stürzt ab oder gibt einen bestimmten Exit-Code zurück.
- Der hostseitige Test prüft auf Abstürze, sieht sich den Logcat-Backtrace an oder sucht nach dem bestimmten Exit-Code, um festzustellen, ob der Angriff erfolgreich war.
Instrumentierte Test-App:
- Beim Host-seitigen Test wird ein APK, das aus einer App oder einem Dienst besteht, auf das Gerät übertragen.
- Der hostseitige Test startet die geräteseitigen JUnit-Tests, die mit dem APK gebündelt sind, über
runDeviceTest()
- Bei den geräteseitigen JUnit-Tests werden Schaltflächen angetippt und die App mit UIAutomator beobachtet oder auf andere Weise auf das Android-System zugegriffen, um Sicherheitslücken aufzudecken.
- Ob die geräteseitigen JUnit-Tests erfolgreich waren oder nicht, wird an den hostseitigen Test zurückgegeben. So kann ermittelt werden, ob der Test bestanden hat oder nicht.
Eine Kombination der beiden Muster (z. B. das Ausführen eines nativen Programms in Verbindung mit geräteseitigen Tests) ist ebenfalls möglich. Außerdem sind einige andere Instrumentierungs-Frameworks wie frida-inject
verfügbar.
Weitere Informationen finden Sie in den Referenzdokumenten zur Security Test Suite und in den Referenzdokumenten zu Tradefed.
Für meinen Proof-of-Concept-Angriff ist keine Test-App oder native ausführbare Datei erforderlich.
Für die meisten Tests sind weder eine geräteseitige App noch eine native ausführbare Datei erforderlich.
Wenn Ihr Test nicht die Verwendung einer App oder eines Dienstes auf dem Gerät umfasst, löschen Sie einfach das Unterverzeichnis test-app
. Wenn in Ihrem Test keine native ausführbare Datei verwendet wird, löschen Sie das Unterverzeichnis native-poc
und synchronisieren Sie das Projekt dann mit Gradle.
Das Projekt ist so eingerichtet, dass das Erstellen dieser Module automatisch übersprungen wird, wenn sie nicht vorhanden sind.
Mein Proof-of-Concept-Angriff umfasst eine zweite App/einen zweiten Dienst
Fügen Sie Ihrem Projekt zuerst ein neues Modul für Ihre zweite App/Ihren zweiten Dienst hinzu und erstellen Sie es wie jedes andere APK.
Bearbeiten Sie als Nächstes build.gradle
im Stammverzeichnis dieses Verzeichnisses und fügen Sie das Modul gemäß den Anleitungen unter copyArtifacts
, assembleStsARM
und assembleStsx86
hinzu. Dadurch wird sichergestellt, dass das kompilierte APK in das Ausgabeverzeichnis von STS kopiert wird, und ermöglicht die Installation/Aufruf der neuen App aus dem Test.
Synchronisieren Sie das Projekt abschließend mit Gradle.
STS-Test einreichen
Führen Sie die zipForSubmission
-Aufgabe aus (entweder mit Android Studio oder mit Gradle in der Befehlszeile). Im Stammverzeichnis des Projekts sollte im Verzeichnis build
eine neue Datei mit dem Namen codesubmission.zip
erstellt werden. Laden Sie diese Datei zusammen mit Ihrer Einreichung in das Android Vulnerability Reward Program hoch.