Android Security AutoRepro

Das AutoRepro-Gradle-Plug-in basiert auf dem Android Trade Federation-Testharness, um alle Android-Geräte mit Sicherheitspatch-Tests auf Sicherheitslücken im Android Security Bulletin zu testen. Diese Tests sind ausschließlich für Korrekturen vorgesehen, die mit einer CVE (Common Vulnerabilities and Exposures) verknüpft sind oder verknüpft werden.

Mit dem Plug-in können Tradefed-Tests außerhalb des Android-Quellbaums mit Android Studio oder dem Standard-Android-SDK entwickelt werden. Es enthält alle Dienstprogramme, die zum Erstellen und Ausführen eines Tradefed-Tests erforderlich sind.

Es wird hauptsächlich verwendet, um automatisch reproduzierbare Proof-of-Concepts für das Vulnerability Reward Program für Android einzureichen.

Beispiel für AutoRepro herunterladen 

Voraussetzungen

Die Anleitung bezieht sich auf einen 64-Bit-Linux-PC.

  • Android Studio Ladybug oder höher – kann auch über den Paketmanager Ihrer Distribution installiert werden.
  • Android SDK-Plattformtools (adb, fastboot): Müssen installiert sein und sich in Ihrem $PATH befinden. Das bedeutet, dass Sie adb über die Befehlszeile ausführen können. Am einfachsten installieren Sie die Plattformtools mit dem Paketmanager Ihrer Distribution.
    • Wenn Sie den SDK Manager von Android Studio anstelle von eigenständigen Plattformtools verwenden, müssen Sie das platform-tools-Verzeichnis des SDK in Ihren $PATH für die Befehlszeilenentwicklung einfügen.
  • AAPT2. – Kann auch mit dem Paketmanager Ihrer Distribution installiert werden.
  • Java JDK 21 oder höher – kompatibel mit dem Android SDK und Gradle.

Erste Schritte mit Android Studio

Nachdem Sie das Beispiel oder die Vorlage extrahiert haben, öffnen Sie das Verzeichnis in Android Studio als vorhandenes Projekt und warten Sie, bis die Gradle-Synchronisierung abgeschlossen ist. Es gibt mehrere vorkonfigurierte Android Studio-Ausführungskonfigurationen.

Gradle-Aufgaben:

  • assembleSubmissionSources – Quelldateien für die ZIP-Datei der Einreichung zusammenstellen.
  • assembleSubmissionZip: ZIP-Datei für die Einreichung zum Hochladen zusammenstellen.
  • copyInvocationResultsToSubmission: Kopieren Sie die Ergebnisse aus früheren Tradefed-Aufrufen in das Quellverzeichnis der AutoRepro-Einreichung, um den Überprüfungsprozess zu unterstützen. Diese Datei enthält Protokolle vom Host und vom Gerät. Sehen Sie sich die Inhalte vor oder nach dem Ausführen an.

AutoRepro-Aufruf in Android Studio-Ausführungskonfigurationen:

  • autorepro_nonroot_arm64
  • autorepro_nonroot_x86_64
  • autorepro_root_arm64
  • autorepro_root_x86_64

Die Launcher-Konfigurationen haben das Format autorepro_{device_root}_{device_arch}. Im Allgemeinen ist es besser, Non-Root zu verwenden, da Sicherheitslücken, die Root erfordern, weniger schwerwiegend sind. Die Verwendung von Root für die Einrichtung oder Bereinigung kann jedoch akzeptabel sein, sofern sie klar dokumentiert ist und allgemein als gültiger Nicht-Root-Status akzeptiert wird. Es ist beispielsweise zulässig, das Rooting zu verwenden, um das Senden von SMS an das Gerät zu simulieren, damit kein zweites Gerät und mehrere SIM-Karten erforderlich sind.

Dadurch wird Tradefed für Ihren Test gestartet. Tradefed wartet auf ein gültiges Gerät, das verbunden wird. Achten Sie also darauf, dass ein Gerät verbunden und das ADB-Debugging autorisiert ist.

AutoRepro-Test schreiben

Ein AutoRepro-Test besteht aus drei Teilen und es gibt drei entsprechende Gradle-Plug-ins:

  1. Gradle-Plug-in id("com.android.security.autorepro.javahosttest") Der einzelne hostseitige Tradefed-Test, der über ADB mit dem Gerät interagiert. Im Beispiel wird sie im Verzeichnis submission/hostTest/ verwendet.
  2. Gradle-Plug-in id("com.android.security.autorepro.apptest") Ein App- oder Dienst-APK, das über adb install auf dem Gerät installiert und vom Hostseitentest gestartet wird. Die App oder der Dienst kann auch einen eigenen Satz von JUnit-Assertions enthalten, die dem Host-seitigen Runner gemeldet werden. Im Beispiel wird es im Verzeichnis submission/appTest/ verwendet.
  3. Gradle-Plug-in id("com.android.security.autorepro.ndktest"): Ein optionaler NDK-basierter Proof-of-Concept-Angriff, der über adb push auf das Gerät übertragen und vom hostseitigen Test ausgeführt wird. Im Beispiel wird es im Verzeichnis submission/ndkTest/ verwendet.

Ein typischer AutoRepro-Testablauf folgt in der Regel einem von zwei Mustern:

  • Instrumentierte Test-App:

    1. Beim Host-seitigen Test wird ein APK, das aus einer instrumentierten App oder einem instrumentierten Dienst besteht, auf das Gerät übertragen.
    2. Der Host-seitige Test startet die geräteseitigen JUnit-Tests, die über runDeviceTest() mit dem APK gebündelt werden.
    3. Die JUnit-Tests auf dem Gerät tippen auf Schaltflächen und beobachten die App mit UIAutomator oder greifen auf andere Weise auf die Android-APIs zu, wodurch Sicherheitslücken aufgedeckt werden.
    4. Der Erfolg oder Misserfolg der JUnit-Tests auf dem Gerät wird an den Hostseitentest zurückgegeben, mit dem ermittelt werden kann, ob der Test bestanden wurde oder nicht. Die Fehlermeldung sollte detaillierte Informationen dazu enthalten, warum die Assertion fehlgeschlagen ist, sowie alle spezifischen Objekte, Werte, Ausnahmen, Stacktraces oder andere Artefakte als Beweis für die Sicherheitslücke.

  • NDK-Proof of Concept:

    1. Beim Hostseitentest wird eine ausführbare Linux-Datei auf das Gerät übertragen und gestartet.
    2. Das native Programm stürzt ab oder gibt einen bestimmten Exitcode zurück.
    3. Der hostseitige Test prüft auf Abstürze, sieht sich den Logcat-Backtrace an oder sucht nach dem spezifischen Exit-Code, um festzustellen, ob der Angriff erfolgreich war. Die Fehlermeldung sollte detaillierte Informationen dazu enthalten, warum die Assertion fehlgeschlagen ist, sowie alle spezifischen Strukturen, Werte, Stacktraces oder anderen Artefakte als Beweis für die Sicherheitslücke.

Eine Kombination der beiden Muster (z. B. Ausführung eines nativen Programms in Verbindung mit geräteseitigen Tests) ist ebenfalls möglich. Es sind auch andere Instrumentierungs-Frameworks wie frida-inject verfügbar. Weitere Informationen finden Sie in der Referenzdokumentation zur Security Test Suite und in der Tradefed-Referenzdokumentation.

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 für Ihren Test keine Funktion erforderlich ist, löschen Sie die unnötigen Gradle-Unterprojektverzeichnisse.

Für meinen Proof-of-Concept-Angriff ist eine zweite App/ein zweiter Dienst erforderlich

Sie können beliebig viele Gradle-Unterprojekte mit AutoRepro-Plug-ins hinzufügen.

AutoRepro-Test einreichen

So fügen Sie Testergebnisse von Ihrem Gerät in den Antrag ein:

  • Führen Sie optional den Gradle-Task clean aus, um alte Testläufe zu löschen.
  • Führen Sie die entsprechende AutoRepro-Laufzeitkonfiguration aus, um Tradefed für Ihren Test aufzurufen und Logs und Ergebnisse zu erfassen.
  • Führen Sie die Aufgabe copyInvocationResultsToSubmission aus, um die Logs und Ergebnisse in das Quellverzeichnis für die Einreichung zu kopieren.

Führen Sie assembleSubmissionZip aus, um die Datei submission/build/autorepro-submission.zip zu erstellen. Laden Sie diese Datei zusammen mit Ihrem Beitrag zum Vulnerability Reward Program für Android hoch. Achten Sie darauf, dass der Anhang dem Muster *autorepro-submission*.zip entspricht und mit dem ursprünglichen Bericht hochgeladen wird. Wenn Sie Einsendungen zu spät hochladen, können wir Ihren Bericht nicht richtig prüfen.