Android Security Test Suite Development Kit (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) baut auf Android-Handelsföderation Test-Harnisch zum Testen der Sicherheit aller Android-Geräte Patchtests, die nicht in die Kompatibilitätstest-Suite fallen. Diese Tests sind für Fehlerbehebungen, die mit einem Common Vulnerabilities and Exposures (CVEs).

Das SDK ermöglicht die Entwicklung von STS-Tests außerhalb der Android-Quellstruktur. mit Android Studio oder dem standardmäßigen Android SDK. Enthält alle Dienstprogramme die zum Erstellen und Ausführen eines STS-Tests erforderlich sind.

<ph type="x-smartling-placeholder"></ph> Neuestes STS SDK herunterladen

Voraussetzungen

  • 64-Bit-Linux-PC.
  • Android Studio (kann auch installiert werden) Paketmanager deiner Distribution.
  • Android-Plattformtools (adb, fastboot) müssen installiert sein und sich in deinem $PATH befinden (d.h. du adb über die Befehlszeile ausführen können. Der einfachste Weg, die Plattformtools über den Paketmanager Ihrer Distribution installieren können.
    • Bei Verwendung des SDK-Managers von Android Studio anstelle der eigenständigen Plattform müssen Sie $PATH das Verzeichnis platform-tools des SDK hinzufügen.
  • aapt das auch über den Paketmanager deiner Distribution installiert werden kann.

Erste Schritte mit Android Studio

Nachdem du das Archiv extrahiert hast, öffne das Verzeichnis in Android Studio als bestehenden Projekts. Führen Sie das Build-Ziel assembleSTSARM oder assembleSTSx86 aus, den grundlegenden Test abhängig von der Architektur des Ziel-Android-Geräts erstellen, . Führen Sie das Build-Ziel runSTS aus, um den Basistest auf der verbundenen Gerät (ADB muss autorisiert sein).

Erste Schritte mit Gradle

Legen Sie nach dem Extrahieren des Archivs das Attribut sdk.dir in der local.properties im Stammverzeichnis des Gradle-Projekts. Anschließend führen Sie den assembleSTSARM Gradle-Aufgabe zum Erstellen des Skeleton-Tests. Nachdem der Build abgeschlossen ist, können Sie den Test durchführen, indem Sie (cd) zu build/android-sts/tools und führt den sts-tradefed-Wrapper 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 Tradefed-Test auf Hostseite, der über ADB mit dem Gerät interagiert. sts-test-Unterverzeichnis.
  2. Ein optionaler nativer Proof-of-Concept-Angriff, der auf das über adb push und wird vom hostseitigen Test im Unterverzeichnis native-poc.
  3. Ein optionales App- oder Dienst-APK, das über adb install und auch durch den hostseitigen Test gestartet. App oder Dienst kann auch eigene JUnit-Assertions enthalten, die an die den Host-Side-Runner aus. Sie befindet sich im Unterverzeichnis test-app.

Ein typischer STS-Testablauf folgt normalerweise einem von zwei Mustern:

  • Proof of Concept für native Anzeigen:

    1. Der hostseitige Test überträgt eine native ausführbare Datei im .
    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 die Logcat-Rückverfolgung oder nach dem spezifischen Exit-Code sucht, um zu bestimmen, erfolgreich war.

  • Instrumentierte Test-App:

    1. Beim Host-seitigen Test wird ein APK, das aus einer App oder einem Dienst besteht, auf dem Gerät.
    2. Der Host-seitige Test startet die geräteseitigen JUnit-Tests, die im Bundle enthalten sind mit dem APK über runDeviceTest()
    3. Der geräteseitige JUnit-Test tippt Schaltflächen und beobachtet die App mit oder auf andere Weise auf das Android-System zugreift, Sicherheitslücken aufzudecken.
    4. Der Erfolg oder Misserfolg der geräteseitigen JUnit-Tests wird Host-seitiger Test, mit dem festgestellt werden kann, ob der Test bestanden wurde oder nicht.

Eine Kombination aus diesen beiden Mustern (z. B. das Ausführen eines nativen Programms in in Verbindung mit geräteseitigen Tests) ist ebenfalls möglich. Andere Instrumentierung Frameworks wie frida-inject stehen ebenfalls zur Verfügung. Weitere Informationen finden Sie in der Referenzdokumente der Security Test Suite und in den Tradefed Referenzdokumente

Für meinen Proof-of-Concept-Angriff ist keine Test-App oder native ausführbare Datei erforderlich.

Für die meisten Tests sind nicht gleichzeitig eine geräteseitige App und eine native ausführbare Datei erforderlich.

Wenn bei deinem Test keine App oder ein Dienst auf dem Gerät verwendet wird, lösche einfach im Unterverzeichnis test-app. Wenn in Ihrem Test keine native löschen Sie das Unterverzeichnis native-poc und führen Sie dann Gradle-sync für das Projekt durch. Das Projekt ist so eingerichtet, dass das Erstellen dieser Module automatisch übersprungen wird, wenn sie nicht existieren.

Mein Proof-of-Concept-Angriff beinhaltet eine zweite App bzw. einen zweiten Dienst.

Fügen Sie Ihrem Projekt zuerst ein neues Modul für Ihre zweite Anwendung bzw. Ihren zweiten Dienst hinzu und schreiben Sie genau wie jedes andere APK.

Bearbeiten Sie als Nächstes build.gradle im Stammverzeichnis dieses Verzeichnisses und fügen Sie Ihr Modul hinzu befolgen Sie die Anweisungen in copyArtifacts, assembleStsARM und assembleStsx86. Dadurch wird das kompilierte APK in die Ausgabe kopiert von STS und ermöglicht die Installation bzw. den Aufruf der neuen Anwendung aus dem Test.

Zum Schluss synchronisieren Sie das Projekt mit Gradle.

STS-Test senden

Führen Sie die Aufgabe zipForSubmission aus (entweder mit Android Studio oder mit Gradle auf der Befehlszeile). In build sollte eine neue Datei, codesubmission.zip, erstellt werden im Stammverzeichnis des Projekts. Laden Sie diese Datei zusammen mit Ihrem für das Belohnungsprogramm für Android-Sicherheitslücken eingereicht wurden.