Android Security AutoRepro

Das AutoRepro Gradle-Plug-in basiert auf dem Android Trade Federation-Test-Harness und testet alle Android-Geräte auf Sicherheitspatches gegen Sicherheitslücken im Sicherheitsbulletin für Android. Diese Tests sind ausschließlich für Korrekturen vorgesehen, die mit einer Common Vulnerabilities and Exposures (CVE) verknüpft sind oder verknüpft werden.

Mit dem Plug-in können Tradefed-Tests außerhalb der Android-Quellstruktur 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.

Direkter Download des AutoRepro-Beispiels

AutoRepro-Beispiel und -Vorlagen ansehen

Vorbereitung

Die Anleitung gilt für 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 heißt, Sie sollten adb über die Befehlszeile ausführen können. Die einfachste Möglichkeit, die Plattformtools zu installieren, ist der Paketmanager Ihrer Distribution.
    • Wenn Sie anstelle von eigenständigen Plattformtools den SDK-Manager von Android Studio verwenden, müssen Sie das Verzeichnis platform-tools des SDK zu Ihrem $PATH hinzufügen, um die Befehlszeile für die Entwicklung zu nutzen.
  • AAPT2. – kann auch über den 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 Einreichungs- ZIP-Datei zusammenstellen.
  • assembleSubmissionZip – Einreichungs-ZIP-Datei für den Upload zusammenstellen.
  • copyInvocationResultsToSubmission – Ergebnisse aus vorherigen Tradefed-Aufrufen in das Verzeichnis mit den AutoRepro-Einreichungsquellen kopieren, um den Überprüfungsprozess zu erleichtern. Dieses Verzeichnis enthält Logs vom Host und vom Gerät. Überprüfen Sie die Inhalte vor oder nach der Ausführung.

Android Studio-Ausführungskonfigurationen für AutoRepro-Aufrufe:

  • 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, „nonroot“ zu verwenden, da Sicherheitslücken, für die Root-Zugriff erforderlich ist, 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 Nonroot-Zustand gilt. Es ist beispielsweise akzeptabel, Root zu verwenden, um gefälschte SMS an das Gerät zu senden, damit kein zweites Gerät und mehrere SIM-Karten erforderlich sind.

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

Einbindung in Coding-Agents

Das Beispiel und die Vorlagen enthalten eine AGENTS.md-Kontextdatei, die mit Gemini in Android Studio, der Gemini CLI und anderen Coding-Agents kompatibel ist. Sie enthält Meinungen zur Strukturierung von Einreichungen und Anleitungen zur Verwendung von AutoRepro. Sie können sie für Folgendes verwenden:

  • AutoRepro automatisch für Ihr Gerät ausführen
  • Vorhandene Einreichung auf Änderungen überprüfen, die dazu beitragen können, dass Ihr Bericht schneller akzeptiert wird
  • Neuen PoC anhand von Informationen zur Sicherheitslücke strukturieren

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 es 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 hostseitigen Test gestartet wird. Die App oder der Dienst kann auch eigene JUnit-Assertions enthalten, die dem hostseitigen Runner gemeldet werden. Im Beispiel wird es in den Verzeichnissen submission/appTest/ und 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. Der hostseitige Test überträgt ein APK, das aus einer instrumentierten App oder einem instrumentierten Dienst besteht, auf das Gerät.
    2. Der hostseitige Test startet die geräteseitigen JUnit-Tests, die im APK enthalten sind, über runDeviceTest().
    3. Die geräteseitigen JUnit-Tests tippen auf Schaltflächen und beobachten die App mit UIAutomator oder greifen auf andere Weise auf die Android APIs zu, um Sicherheitslücken aufzudecken.
    4. Der Erfolg oder Misserfolg der geräteseitigen JUnit-Tests wird an den hostseitigen Test zurückgegeben, mit dem ermittelt werden kann, ob der Test erfolgreich war 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. Der hostseitige Test überträgt und startet eine ausführbare Linux-Datei auf dem Gerät.
    2. Das native Programm stürzt ab oder gibt einen bestimmten Exit-Code 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 zu ermitteln, ob der Angriff erfolgreich war. Die Fehlermeldung sollte detaillierte Informationen dazu enthalten, warum die Assertion fehlgeschlagen ist, sowie alle spezifischen Strukturen, Werte, Stacktraces oder andere 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 einige andere Instrumentierungs-Frameworks verfügbar, z. B. frida-inject. Weitere Informationen finden Sie in der Referenzdokumentation zur Security Test Suite und in der Referenzdokumentation zu Tradefed.

Strukturierung der Nachweisbarkeit von Proof of Concepts

Ein hochwertiger PoC muss mehr als nur einen Fehler auslösen. Er sollte einen überprüfbaren Beweis dafür liefern, dass eine Sicherheitsgrenze überschritten wurde. Dazu können PoCs einem bestimmten dreistufigen Muster folgen, bei dem der Test zuerst fehlschlägt und dann erfolgreich ist:

  1. Einrichtung:Bereiten Sie das Gerät vor, indem Sie die erforderlichen Apps installieren, Dateien übertragen und dafür sorgen, dass sich das Gerät unmittelbar vor dem Exploit im erforderlichen Zustand befindet. Die Verwendung von Root ist für die Konfiguration zulässig, wenn sie gerechtfertigt ist und einen realistischen Endnutzerzustand darstellt.
  2. Grenze nachweisen:Bevor Sie die Sicherheitslücke auslösen, versuchen Sie die Zielaktion und bestätigen Sie, dass sie fehlschlägt. Wenn der Exploit beispielsweise das Lesen einer geschützten Datei ermöglicht, müssen Sie zuerst versuchen, sie zu lesen, und bestätigen, dass Sie eine Fehlermeldung „Berechtigung verweigert“ erhalten.
  3. Auslösen und überprüfen:Lösen Sie die Sicherheitslücke aus und wiederholen Sie dann sofort die Aktion aus Schritt 2. Auf einem anfälligen Gerät sollte diese Aktion jetzt erfolgreich sein. Um dies zu überprüfen, müssen Sie eine Assertion verwenden, die auf einem anfälligen Gerät mit einer Nachricht fehlschlägt, die mit dem genauen Präfix AUTOREPRO_VULNERABILITY_PROVEN: beginnt. Diese Nachricht muss eine kurze Beschreibung der Sicherheitslücke und aller erfassten Artefakte (z. B. durchgesickerte Daten oder unerwartete Zustände) enthalten, um endgültig zu beweisen, dass der Exploit erfolgreich war.

Beispiel :

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

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

Für die meisten Tests sind weder eine geräteseitige App noch eine ausführbare Datei erforderlich.

Wenn Ihr Test keine Funktion verwendet, löschen Sie die unnötigen Gradle-Unterprojektverzeichnisse.

Mein Proof of Concept-Angriff umfasst eine zweite App oder einen zweiten Dienst

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 als Teil der Einreichung hinzu:

  • Optional können Sie die Gradle-Aufgabe clean ausführen, um alte Testläufe zu löschen.
  • Führen Sie die entsprechende AutoRepro-Ausführungskonfiguration 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 Verzeichnis mit den Einreichungsquellen zu kopieren.

Führen Sie assembleSubmissionZip aus, um die Datei submission/build/autorepro-submission.zip zu erstellen. Laden Sie diese Datei zusammen mit Ihrer Einreichung in das Vulnerability Reward Program für Android hoch. Achten Sie darauf, dass die Anlage dem Muster *autorepro-submission*.zip entspricht und mit dem ursprünglichen Bericht hochgeladen wird. Wenn Sie Einreichungen zu spät hochladen, können wir Ihren Bericht nicht ordnungsgemäß überprüfen.