Exploiting a debuggeable application

Reading time: 8 minutes

Om te verbygaan van root en debuggeable kontroles

Hierdie afdeling van die pos is 'n opsomming van die pos https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

Stappe om 'n Android App Debuggable te Maak en Kontroles te Omseil

Maak die App Debuggable

Inhoud gebaseer op https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

1. Decompile die APK:

• Gebruik die APK-GUI hulpmiddel om die APK te dekompileer.
• In die android-manifest lêer, voeg android:debuggable="true" in om die debugmodus te aktiveer.
• Hercompileer, teken en zipalign die gewysigde toepassing.

2. Installeer die Gewysigde Toepassing:

• Gebruik die opdrag: adb install <application_name>.

3. Herwin die Pakketnaam:

• Voer adb shell pm list packages –3 uit om derdeparty-toepassings te lys en die pakketnaam te vind.

4. Stel die App in om op Debugger Verbinding te Wacht:

• Opdrag: adb shell am setup-debug-app –w <package_name>.
• Let wel: Hierdie opdrag moet elke keer voor die begin van die toepassing uitgevoer word om te verseker dat dit vir die debugger wag.
• Vir volharding, gebruik adb shell am setup-debug-app –w ––persistent <package_name>.
• Om alle vlae te verwyder, gebruik adb shell am clear-debug-app <package_name>.

5. Bereid voor vir Debugging in Android Studio:

• Navigeer in Android Studio na File -> Open Profile or APK.
• Open die hergecompileerde APK.

6. Stel Breekpunte in Sleutel Java Lêers:

• Plaas breekpunte in MainActivity.java (spesifiek in die onCreate metode), b.java, en ContextWrapper.java.

Omseiling van Kontroles

Die toepassing sal op sekere punte verifieer of dit debuggable is en sal ook kontroleer vir binêre wat 'n ge-root toestel aandui. Die debugger kan gebruik word om app-inligting te wysig, die debuggable bit te verwyder, en die name van gesoekte binêre te verander om hierdie kontroles te omseil.

Vir die debuggable kontrole:

1. Wysig Vlag Instellings:

• In die debugger-konsol se veranderlike afdeling, navigeer na: this mLoadedAPK -> mApplicationInfo -> flags = 814267974.
• Let wel: Die binêre voorstelling van flags = 814267974 is 11000011100111011110, wat aandui dat die "Flag_debuggable" aktief is.

Hierdie stappe verseker dat die toepassing gedebug kan word en dat sekere sekuriteitskontroles met behulp van die debugger omgegaan kan word, wat 'n meer diepgaande analise of wysiging van die toepassing se gedrag moontlik maak.

Stap 2 behels die verandering van 'n vlagwaarde na 814267972, wat in binêr voorgestel word as 110000101101000000100010100.

Eksploitering van 'n Kwessie

'n Demonstrasie is verskaf met 'n kwesbare toepassing wat 'n knoppie en 'n teksview bevat. Aanvanklik vertoon die toepassing "Crack Me". Die doel is om die boodskap van "Try Again" na "Hacked" tydens uitvoering te verander, sonder om die bronkode te wysig.

Kontroleer vir Kwessie

• Die toepassing is gedekomplileer met behulp van apktool om toegang te verkry tot die AndroidManifest.xml lêer.
• Die teenwoordigheid van android_debuggable="true" in die AndroidManifest.xml dui aan dat die toepassing debuggable is en vatbaar is vir eksploitasie.
• Dit is die moeite werd om te noem dat apktool slegs gebruik word om die debuggable status te kontroleer sonder om enige kode te verander.

Voorbereiding van die Stel

• Die proses het behels om 'n emulator te begin, die kwesbare toepassing te installeer, en adb jdwp te gebruik om Dalvik VM-poorte te identifiseer wat luister.
• Die JDWP (Java Debug Wire Protocol) stel die debugging van 'n toepassing wat in 'n VM loop in deur 'n unieke poort bloot te stel.
• Poort forwarding was nodig vir afstand debugging, gevolg deur die aanhegting van JDB aan die teiken toepassing.

Inspuiting van Kode tydens Uitvoering

• Die eksploitering is uitgevoer deur breekpunte in te stel en die toepassing se vloei te beheer.
• Opdragte soos classes en methods <class_name> is gebruik om die toepassing se struktuur te ontdek.
• 'n Breekpunt is gestel by die onClick metode, en sy uitvoering is beheer.
• Die locals, next, en set opdragte is gebruik om plaaslike veranderlikes te ondersoek en te wysig, veral om die "Try Again" boodskap na "Hacked" te verander.
• Die gewysigde kode is uitgevoer met behulp van die run opdrag, wat suksesvol die toepassing se uitvoer in werklike tyd verander het.

Hierdie voorbeeld het gedemonstreer hoe die gedrag van 'n debuggable toepassing gemanipuleer kan word, wat die potensiaal vir meer komplekse eksploite soos om toegang tot die shell op die toestel in die toepassing se konteks te verkry, beklemtoon.

2024 – Om enige toepassing in 'n debuggable proses te verander (CVE-2024-31317)

Selfs al is die teiken APK nie gestuur met die android:debuggable vlag nie, het onlangse navorsing getoon dat dit moontlik is om arbitraire toepassings te dwing om met die DEBUG_ENABLE_JDWP runtime vlag te begin deur die manier waarop Zygote opdraglynargumente ontleed, te misbruik.

• Kwessie: Onbehoorlike validasie van --runtime-flags wat deur Zygote se opdrag socket verskaf word, laat 'n aanvaller wat toegang kan verkry tot system_server (byvoorbeeld via die bevoorregte adb shell wat die WRITE_SECURE_SETTINGS toestemming besit) toe om ekstra parameters in te spuit. Wanneer die vervaardigde opdrag deur system_server herhaal word, word die slagoffer-toepassing as debuggable en met 'n JDWP-draad wat luister, gefork. Die probleem word as CVE-2024-31317 gevolg en is in die Junie 2024 Android Sekuriteitsbulletin reggestel.
• Impak: Volledige lees/skryf toegang tot die privaat datagids van enige app (insluitend bevoorregte soos com.android.settings), token-diefstal, MDM-omseiling, en in baie gevalle 'n direkte pad na voorreg-verhoging deur die uitgevoerde IPC eindpunte van die nou-debuggable proses te misbruik.
• Geaffekteerde weergawes: Android 9 tot 14 voor die Junie 2024 patch vlak.

Vinige 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

Die vervaardigde waarde in stap 1 breek die parser uit die “fast-path” en voeg 'n tweede sintetiese opdrag by waar --runtime-flags=0x104 (DEBUG_ENABLE_JDWP | DEBUG_JNI_DEBUGGABLE) aanvaar word asof dit deur die raamwerk verskaf is. Sodra die app geskep is, word 'n JDWP-soket geopen en gereelde dinamiese-debug truuks (metode vervanging, veranderlike patching, live Frida inspuiting, ens.) is moontlik sonder om die APK of die toestel se opstartbeeld te verander.

Detectie & Versagting

• Patch na 2024-06-01 (of later) sekuriteitsvlak – Google het ZygoteCommandBuffer versterk sodat daaropvolgende opdragte nie op hierdie manier gesmokkel kan word nie.
• Beperk WRITE_SECURE_SETTINGS / shell toegang op produksietoestelle. Die uitbuiting vereis hierdie toestemming, wat normaalweg net deur ADB of OEM-bevoorregte apps besit word.
• Op EMM/MDM-gemanagerde vloot, handhaaf ro.debuggable=0 en weier shell via adb disable-verifier.

Verwysings

• https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0
• https://resources.infosecinstitute.com/android-hacking-security-part-6-exploiting-debuggable-android-applications
• https://rtx.meta.security/exploitation/2024/06/03/Android-Zygote-injection.html
• https://blog.flanker017.me/cve-2024-31317/