Android Security Test Suite Development Kit (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) basiert auf dem Android Trade Federation-Test-Harness, um alle Android-Geräte auf Sicherheits-Patches zu testen, die nicht in die Compatibility Test 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. Sie 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 deiner Distribution installiert werden.
  • Android-Plattformtools (adb, fastboot) müssen installiert sein und sich in Ihrem $PATH befinden. Sie sollten also adb ü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.
  • aapt, das auch über den Paketmanager deiner Distribution installiert werden kann.

Erste Schritte mit Android Studio

Öffnen Sie das Verzeichnis nach dem Entpacken des Archivs in Android Studio als vorhandenes Projekt. Führen Sie das Build-Ziel assembleSTSARM oder assembleSTSx86 aus, um den Skeletttest zu erstellen, je nach Architektur des Ziel-Android-Geräts. Führen Sie das Build-Ziel runSTS aus, um den Basistest 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:

  1. Ein hostseitiger Tradefed-Test, der über ADB im Unterverzeichnis sts-test mit dem Gerät interagiert.
  2. Ein optionaler nativer Proof-of-Concept-Angriff, der über adb push auf das Gerät übertragen und vom hostseitigen Test im Unterverzeichnis native-poc ausgeführt wird.
  3. Ein optionales App- oder Dienst-APK, das über adb install auf dem Gerät installiert und auch durch den hostseitigen Test gestartet wird. Die Anwendung oder der Dienst kann auch eigene JUnit-Assertions enthalten, die dem Runner auf Hostseite gemeldet werden. Sie befindet sich im Unterverzeichnis test-app.

Ein typischer STS-Testablauf folgt in der Regel einem der beiden Muster:

  • Natives Proof of Concept:

    1. Beim hostseitigen Test wird eine native ausführbare Datei auf das Gerät gesendet und dort gestartet.
    2. Das native Programm stürzt ab oder gibt einen bestimmten Exit-Code zurück.
    3. Der hostseitige Test sucht nach Abstürzen, prüft das Logcat-Backtrace oder sucht nach dem spezifischen Exit-Code, um festzustellen, ob der Angriff erfolgreich war.

  • Instrumentierte Test-App:

    1. Beim hostseitigen Test wird ein APK mit einer App oder einem Dienst auf das Gerät geschoben.
    2. Der hostseitige Test startet die geräteseitigen JUnit-Tests, die mit dem APK gebündelt sind, über runDeviceTest()
    3. Bei den geräteseitigen JUnit-Tests werden mit UIAutomator auf Schaltflächen geklickt und die App beobachtet oder es wird anderweitig auf das Android-System zugegriffen, um Sicherheitslücken aufzudecken.
    4. Der Erfolg oder Misserfolg der JUnit-Tests auf Geräteseite wird an den hostseitigen Test zurückgegeben, mit dem ermittelt werden kann, ob der Test bestanden wurde.

Eine Kombination der beiden Muster ist auch möglich, z. B. das Ausführen eines nativen Programms in Verbindung mit geräteseitigen Tests. Außerdem sind einige andere Instrumentierungs-Frameworks wie frida-inject verfügbar. Weitere Informationen finden Sie in der Referenzdokumentation zur Security Test Suite und in der Referenzdokumentation zu Trade-In.

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üge deinem Projekt zuerst ein neues Modul für deine zweite App bzw. deinen zweiten Dienst hinzu und schreibe das wie bei jedem anderen 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 senden

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. Lade diese Datei zusammen mit deiner Bewerbung für das Android Vulnerability Reward Program hoch.