Die Security Test Suite Trade Federation (sts-tradefed) basiert auf der Testumgebung der Android Trade Federation , um alle Android-Geräte auf Sicherheitspatchtests zu testen, die nicht in die Compatibility Test Suite fallen. Diese Tests beziehen sich ausschließlich auf Korrekturen, die mit einem Common Vulnerabilities and Exposures (CVE) verbunden sind (oder verbunden sein werden).
Das SDK ermöglicht die Entwicklung von STS-Tests außerhalb des Android-Quellbaums mit Android Studio oder dem Standard-Android-SDK. Es enthält alle Dienstprogramme, die zum Erstellen und Ausführen eines STS-Tests erforderlich sind.
Holen Sie sich das neueste STS SDK
Voraussetzungen
- 64-Bit-Linux-PC.
- Android Studio (kann auch über den Paketmanager Ihrer Distribution installiert werden.
- Android-Plattform-Tools (
adb
,fastboot
) müssen installiert sein und sich in Ihrem$PATH
befinden (dh Sie solltenadb
über die Befehlszeile ausführen können). Der einfachste Weg, die Plattform-Tools zu installieren, ist über den Paketmanager Ihrer Distribution.- Wenn Sie den SDK-Manager von Android Studio anstelle eigenständiger Plattform-Tools verwenden, denken Sie daran, das
platform-tools
Verzeichnis des SDK zu Ihrem $PATH hinzuzufügen.
- Wenn Sie den SDK-Manager von Android Studio anstelle eigenständiger Plattform-Tools verwenden, denken Sie daran, das
- aapt , das auch über den Paketmanager Ihrer Distribution installiert werden kann.
Beginnen Sie mit der Verwendung von 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 den Skeletttest zu erstellen, abhängig von der Architektur des Ziel-Android-Geräts. Führen Sie das Build-Ziel runSTS
aus, um den Skeletttest auf dem verbundenen Gerät auszuführen (ADB muss autorisiert sein).
Beginnen Sie mit der Verwendung von Gradle
Legen Sie nach dem Extrahieren des Archivs die Eigenschaft sdk.dir
in der Datei „ local.properties
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, indem Sie ( cd
) zu build/android-sts/tools
navigieren und den sts-tradefed
-Wrapper ausführen.
$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest
Schreiben Sie einen STS-Test
Ein STS-Test besteht aus drei Teilen:
- Ein hostseitiger Tradefed-Test, der über adb im Unterverzeichnis
sts-test
mit dem Gerät interagiert. - Ein optionaler nativer Proof-of-Concept-Angriff, der über
adb push
auf das Gerät übertragen und vom hostseitigen Test im Unterverzeichnisnative-poc
ausgeführt wird. - Eine optionale App- oder Dienst-APK, die über
adb install
auf dem Gerät installiert und auch durch den hostseitigen Test gestartet wird. Die App oder der Dienst kann auch einen eigenen Satz von JUnit-Assertionen enthalten, die dem hostseitigen Läufer gemeldet werden. Dies befindet sich im Unterverzeichnistest-app
.
Ein typischer STS-Testablauf folgt normalerweise einem von zwei Mustern:
Nativer Proof-of-Concept:
- Der hostseitige Test überträgt und startet eine native ausführbare Datei auf dem Gerät.
- Das native Programm stürzt ab oder gibt einen bestimmten Exit-Code zurück.
- Der hostseitige Test prüft auf Abstürze, schaut sich den Logcat-Backtrace an oder sucht nach dem spezifischen Exit-Code, um festzustellen, ob der Angriff erfolgreich war.
Instrumentierte Test-App:
- Der hostseitige Test überträgt ein APK, das aus einer App oder einem Dienst besteht, auf das Gerät.
- Der hostseitige Test startet die geräteseitigen JUnit-Tests, die über
runDeviceTest()
mit dem APK gebündelt sind. - Der geräteseitige JUnit testet das Tippen auf Schaltflächen und überwacht die App mithilfe von UIAutomator oder greift auf andere Weise auf das Android-System zu, um Sicherheitslücken aufzudecken.
- Der Erfolg oder Misserfolg der geräteseitigen JUnit-Tests wird an den hostseitigen Test zurückgegeben, der zur Bestimmung verwendet werden kann, ob der Test bestanden wurde oder nicht.
Auch eine Kombination beider Muster (zum Beispiel die Ausführung eines nativen Programms in Verbindung mit geräteseitigen Tests) ist möglich. Einige andere Instrumentierungs-Frameworks, wie zum Beispiel frida-inject
, sind ebenfalls verfügbar. Einzelheiten finden Sie in den Referenzdokumenten zur Security Test Suite und in den Referenzdokumenten von Tradefed .
Für meinen Proof-of-Concept-Angriff ist keine Test-App und/oder native ausführbare Datei erforderlich
Die meisten Tests benötigen nicht sowohl eine geräteseitige App als auch eine native ausführbare Datei.
Wenn Ihr Test nicht die Verwendung einer App/eines Dienstes auf dem Gerät beinhaltet, löschen Sie einfach das Unterverzeichnis test-app
. Wenn Ihr Test keine native ausführbare Datei verwendet, löschen Sie das Unterverzeichnis native-poc
und synchronisieren Sie das Projekt anschließend mit Gradle. Das Projekt ist so eingerichtet, dass die Erstellung 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 zunächst ein neues Modul für Ihre zweite App/Ihren zweiten Dienst hinzu und schreiben Sie es wie jedes andere APK.
Bearbeiten Sie als Nächstes build.gradle
im Stammverzeichnis dieses Verzeichnisses und fügen Sie Ihr Modul hinzu, indem Sie den Anweisungen in copyArtifacts
, assembleStsARM
assembleStsx86
folgen. Dadurch wird sichergestellt, dass das kompilierte APK in das Ausgabeverzeichnis von STS kopiert wird und die Installation/Aufrufung der neuen App aus dem Test ermöglicht wird.
Schließlich synchronisieren Sie das Projekt mit Gradle.
Einreichen des STS-Tests
Führen Sie die Aufgabe zipForSubmission
aus (entweder mit Android Studio oder mit Gradle in der Befehlszeile). Eine neue Datei, codesubmission.zip
, sollte im build
Verzeichnis im Stammverzeichnis des Projekts erstellt werden. Laden Sie diese Datei zusammen mit Ihrer Einreichung beim Android Vulnerability Reward Program hoch.