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 isoleer.
  • Die toepassing self, wat ontwikkelaars toelaat om sekere funksionaliteite bloot te stel en toepassingsvermoĂ«ns te konfigureer.

UID Separation

Elke toepassing word aan ’n spesifieke gebruikers-ID toegeken. Dit gebeur tydens die installasie van die app sodat die app slegs met lĂȘers wat aan sy gebruikers-ID behoort of gedeelde lĂȘers kan kommunikeer. Daarom kan slegs die app self, sekere komponente van die OS en die wortelgebruiker toegang tot die toepassingsdata 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 gecompromitteer word, sal die data van albei toepassings gecompromitteer wees. Dit is waarom hierdie gedrag afgeraadpleeg word.
Om dieselfde UID te deel, moet toepassings dieselfde android:sharedUserId waarde in hul manifes definieer.

Sandboxing

Die Android Toepassing Sandbox laat toe om elke toepassing as ’n afsonderlike proses onder ’n afsonderlike gebruikers-ID te laat loop. Elke proses het sy eie virtuele masjien, sodat ’n app se kode in isolasie van ander apps loop.
Vanaf Android 5.0(L) word SELinux afgedwing. Basies het SELinux alle prosesinteraksies ontken en toe beleide geskep om slegs die verwagte interaksies tussen hulle toe te laat.

Permissions

Wanneer jy ’n app installeer en dit vra om toestemming, vra die app vir die toestemmings wat in die uses-permission elemente in die AndroidManifest.xml lĂȘer geconfigureer is. Die uses-permission element dui die naam van die aangevraagde toestemming binne die naam attribuut aan. Dit het ook die maxSdkVersion attribuut wat stop om vir toestemmings te vra op weergawes hoĂ«r as die een wat gespesifiseer is.
Let daarop dat Android-toepassings nie al die toestemmings aan die begin hoef te vra nie, hulle kan ook dynamies om toestemmings vra, maar al die toestemmings moet verklaar word in die manifest.

Wanneer ’n app funksionaliteit blootstel, kan dit die toegang beperk tot slegs apps wat ’n gespesifiseerde toestemming het.
’n Toestemmingselement het drie attribiete:

  • Die naam van die toestemming
  • Die permission-group attribuut, wat toelaat om verwante toestemmings te groepeer.
  • Die protection-level wat aandui hoe die toestemmings toegeken word. Daar is vier tipes:
  • Normal: Gebruik wanneer daar geen bekende bedreigings vir die app is nie. Die gebruiker word nie vereis om dit goed te keur nie.
  • Dangerous: Dui aan dat die toestemming die aansoekende toepassing sekere verhoogde toegang gee. Gebruikers word gevra om dit goed te keur.
  • Signature: Slegs apps wat deur dieselfde sertifikaat as die een wat die komponent uitvoer, kan toestemming ontvang. Dit is die sterkste tipe beskerming.
  • SignatureOrSystem: Slegs apps wat deur dieselfde sertifikaat as die een wat die komponent uitvoer of apps wat met stelselniveau toegang loop, kan toestemming ontvang.

Pre-Installed Applications

Hierdie apps word gewoonlik in die /system/app of /system/priv-app gidse gevind en sommige van hulle is geoptimaliseer (jy mag dalk nie eers die classes.dex lĂȘer vind nie). Hierdie toepassings is die moeite werd om na te kyk omdat hulle soms met te veel toestemmings loop (as wortel).

  • Diegene wat saam met die AOSP (Android OpenSource Project) ROM verskaf word
  • Bygevoeg deur die toestel fabrikant
  • Bygevoeg deur die sel foonverskaffer (as dit van hulle gekoop is)

Rooting

Om worteltoegang tot ’n fisiese Android-toestel te verkry, moet jy gewoonlik 1 of 2 kwesbaarhede ontgin wat gewoonlik spesifiek vir die toestel en weergawe is.
Sodra die ontginning gewerk het, word gewoonlik die Linux su binĂȘre na ’n plek gekopieer wat in die gebruiker se PATH omgewing veranderlike gespesifiseer is, soos /system/xbin.

Sodra die su binĂȘre geconfigureer is, word ’n ander Android-app gebruik om met die su binĂȘre te kommunikeer en versoeke vir worteltoegang soos Superuser en SuperSU (beskikbaar in die Google Play winkel) te verwerk.

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 pasgemaakte firmware te installeer. Deur dit te doen, is dit moontlik om die nuttigheid van ’n ou toestel uit te brei, sagtewarebeperkings te omseil of toegang tot die nuutste Android-kode te verkry.
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 om ’n pasgemaakte firmware te installeer nie. Sommige fabrikante laat die ontsluiting van hul bootloaders op ’n goed gedokumenteerde en veilige manier toe.

Implications

Sodra ’n toestel ge-root is, kan enige app toegang as wortel vra. As ’n kwaadwillige toepassing dit kry, kan dit toegang tot byna alles hĂȘ en dit sal in staat wees om die foon te beskadig.

Android Application Fundamentals

  • Die formaat van Android-toepassings word verwys na as APK lĂȘerformaat. Dit is essensieel ’n ZIP-lĂȘer (deur die lĂȘernaamuitbreiding na .zip te hernoem, kan die inhoud onttrek en besigtig word).
  • APK Inhoud (Nie uitputtend nie)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: bevat vooraf gecompileerde hulpbronne, soos binĂȘre XML.
  • res/xml/files_paths.xml
  • META-INF/
  • Dit is waar die Sertifikaat geleĂ« is!
  • classes.dex
  • Bevat Dalvik bytecode, wat die gecompileerde Java (of Kotlin) kode verteenwoordig wat die toepassing standaard uitvoer.
  • lib/
  • Huisves inheemse biblioteke, gesegregeer volgens CPU-argitektuur in subgidse.
  • armeabi: kode vir ARM-gebaseerde verwerkers
  • armeabi-v7a: kode vir ARMv7 en hoĂ«r gebaseerde verwerkers
  • x86: kode vir X86 verwerkers
  • mips: kode vir slegs MIPS verwerkers
  • assets/
  • Berg miscellaneous lĂȘers wat deur die app benodig word, moontlik insluitend addisionele inheemse biblioteke of DEX-lĂȘers, soms deur kwaadwillige outeurs gebruik om addisionele kode te verberg.
  • res/
  • Bevat hulpbronne wat nie in resources.arsc gecompileer is nie.

Dalvik & Smali

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

Vir omgekeerde ingenieurswese word Smali noodsaaklik. Dit is die menslike leesbare weergawe van DEX bytecode, wat soos assembly-taal optree deur bronkode in bytecode-instruksies te vertaal. Smali en baksmali verwys na die samestelling en ontbinding gereedskap in hierdie konteks.

Intents

Intents is die primĂȘre middel waardeur 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 oorgedra word. Intents kan gerig word aan spesifieke komponente of apps, of kan sonder ’n spesifieke ontvanger gestuur word.
Om dit eenvoudig te stel, kan ’n Intent gebruik word:

  • Om ’n Aktiwiteit te begin, wat tipies ’n gebruikerskoppelvlak vir ’n app oopmaak
  • As uitsendings om die stelsel en apps van veranderinge in kennis te stel
  • Om ’n agtergronddiens te begin, stop, en met dit te kommunikeer
  • Om toegang tot data via ContentProviders te verkry
  • As terugroep funksies om gebeurtenisse te hanteer

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

Intent-Filter

Intent Filters definieer hoe ’n aktiwiteit, diens, of Uitsend Receiver met verskillende tipes Intents kan interaksie hĂȘ. Essensieel beskryf hulle die vermoĂ«ns van hierdie komponente, soos watter aksies hulle kan uitvoer of die tipes uitsendings wat hulle kan verwerk. Die primĂȘre plek om hierdie filters te verklaar is binne die AndroidManifest.xml lĂȘer, hoewel dit ook ’n opsie is om dit vir Uitsend Receivers te kodeer.

Intent Filters bestaan uit kategorieë, 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 (aktiwiteite/dienste/inhoudverskaffers/uitsend receivers) is hul sigbaarheid of publieke status. ’n Komponent word as publiek beskou en kan met ander apps interaksie hĂȘ as dit exported is met ’n waarde van true of as ’n Intent Filter vir dit in die manifest verklaar is. Daar is egter ’n manier vir ontwikkelaars om hierdie komponente eksplisiet privaat te hou, wat verseker dat hulle nie onbedoeld met ander apps interaksie het nie. Dit word bereik deur die exported attribuut op false in hul manifest definisies in te stel.

Boonop het ontwikkelaars die opsie om toegang tot hierdie komponente verder te beveilig deur spesifieke toestemmings te vereis. Die permission attribuut kan gestel word om af te dwing dat slegs apps met die aangewese toestemming toegang tot die komponent kan verkry, wat ’n ekstra laag van sekuriteit en beheer oor wie met dit kan interaksie hĂȘ, toevoeg.

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

Impliciete Intents

Intents word programmaties geskep met ’n Intent-konstruktors:

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

Die Aksie van die voorheen verklaarde intent is ACTION_SEND en die Ekstra is ’n mailto Uri (die Ekstra 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 aksie, data en kategorie ooreenstem om ’n boodskap te ontvang.

Die “Intent resolusie” proses bepaal watter app elke boodskap moet ontvang. Hierdie proses oorweeg die prioriteit eienskap, wat in die intent-filter verklaring 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 konflik ontstaan, verskyn ’n “chooser” venster sodat die gebruiker kan besluit.

Expliciete Intents

’n Expliciete intent spesifiseer die klasnaam wat dit teiken:

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

In ander toepassings om toegang te verkry tot die voorheen verklaarde intent kan jy gebruik maak van:

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

Pending Intents

Hierdie laat ander toepassings toe om optrede namens jou toepassing te neem, met jou app se identiteit en toestemmings. Om ’n Pending Intent te konstrueer, moet ’n intent en die aksie wat uitgevoer moet word, gespesifiseer word. As die verklaarde intent nie Eksplisiet is nie (nie verklaar watter intent dit kan oproep nie), kan ’n kwaadwillige toepassing die verklaarde aksie namens die slagoffer-app uitvoer. Boonop, as ’n aksie nie gespesifiseer is nie, sal die kwaadwillige app in staat wees om enige aksie namens die slagoffer te doen.

Broadcast Intents

Anders as die vorige intents, wat slegs deur een app ontvang word, kan broadcast intents deur meerdere apps ontvang word. Dit is egter vanaf API weergawe 14 moontlik om die app wat die boodskap moet ontvang, te spesifiseer met behulp van Intent.setPackage.

Alternatiewelik is dit ook moontlik om ’n toestemming te spesifiseer wanneer die broadcast gestuur word. Die ontvangende app sal daardie toestemming moet hĂȘ.

Daar is twee tipes Uitsendings: Normaal (asynchrone) en Geordende (sinchrone). Die volgorde is gebaseer op die geconfigureerde prioriteit binne die ontvanger element. Elke app kan die Broadcast verwerk, oordra of laat val.

Dit is moontlik om ’n broadcast te stuur met die funksie sendBroadcast(intent, receiverPermission) van die Context klas.
Jy kan ook die funksie sendBroadcast van die LocalBroadCastManager gebruik wat verseker dat die boodskap nooit die app verlaat nie. Deur dit te gebruik, sal jy selfs nie ’n ontvanger komponent hoef te eksporteer nie.

Sticky Broadcasts

Hierdie tipe Uitsendings kan lank nadat hulle gestuur is, toeganklik wees.
Hierdie is in API vlak 21 verouderd en dit word aanbeveel om nie hulle te gebruik nie.
Hulle laat enige toepassing toe om die data te snuffel, maar ook om dit te wysig.

As jy funksies vind wat die woord “sticky” bevat soos sendStickyBroadcast of sendStickyBroadcastAsUser, kontroleer die impak en probeer om hulle te verwyder.

Deep links / URL schemes

In Android-toepassings, deep links word gebruik om ’n aksie (Intent) direk deur ’n URL te begin. Dit word gedoen deur ’n spesifieke URL skema binne ’n aktiwiteit te verklaar. Wanneer ’n Android-toestel probeer om ’n URL met hierdie skema te benader, word die gespesifiseerde aktiwiteit binne die toepassing gelaai.

Die skema moet in die AndroidManifest.xml lĂȘer verklaar word:

[...]
<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 ’n web te benader, is dit moontlik om ’n skakel soos te stel:

<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 aktiwiteit wat deur die deeplink aangeroep word en soek die funksie onNewIntent.

Leer hoe om deep links te bel sonder om HTML-bladsye te gebruik.

AIDL - Android Interface Definition Language

Die Android Interface Definition Language (AIDL) is ontwerp om kommunikasie tussen kliĂ«nt en diens in Android-toepassings te fasiliteer deur middel van interprocess communication (IPC). Aangesien dit nie toegelaat word om direk toegang tot ’n ander proses se geheue te verkry nie, vereenvoudig AIDL die proses deur voorwerpe in ’n formaat te marshall wat deur die bedryfstelsel verstaan word, wat kommunikasie oor verskillende prosesse vergemaklik.

Sleutelkonsepte

  • Gekoppelde Dienste: Hierdie dienste gebruik AIDL vir IPC, wat aktiwiteite of komponente in staat stel om aan ’n diens te bind, versoeke te maak en antwoorde te ontvang. Die onBind metode in die diens se klas is krities vir die inisiering van interaksie, wat dit ’n belangrike area maak vir sekuriteitsherziening in die soeke na kwesbaarhede.

  • Messenger: As ’n gekoppelde diens, fasiliteer Messenger IPC met ’n fokus op die verwerking van data deur die onBind metode. Dit is noodsaaklik om hierdie metode noukeurig te ondersoek vir enige onveilige datahantering of uitvoering van sensitiewe funksies.

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

Komponente

Hierdie sluit in: Aktiwiteite, Dienste, Uitsendingsontvangers en Verskaffers.

Laaieraktiwiteit en ander aktiwiteite

In Android-apps is aktiwiteite soos skerms, wat verskillende dele van die app se gebruikerskoppelvlak vertoon. ’n App kan baie aktiwiteite hĂȘ, elkeen wat ’n unieke skerm aan die gebruiker aanbied.

Die laaieraktiwiteit is die hooftoegangspunt tot ’n app, wat gelaai word wanneer jy op die app se ikoon tik. Dit is gedefinieer in die app se manifeslĂȘer 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 toepassings benodig ’n lanseeraktiwiteit nie, veral diĂ© sonder ’n gebruikerskoppelvlak, soos agtergronddienste.

Aktiwiteite kan beskikbaar gestel word aan ander toepassings of prosesse deur dit as “geĂ«ksporteer” in die manifest te merk. Hierdie instelling laat ander toepassings toe om hierdie aktiwiteit te begin:

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

However, toegang tot ’n aktiwiteit van ’n ander app is nie altyd ’n sekuriteitsrisiko nie. Die bekommernis ontstaan as sensitiewe data onregmatig gedeel word, wat kan lei tot inligtingslekke.

’n Aktiwiteit se lewensiklus begin met die onCreate metode, wat die UI opstel en die aktiwiteit voorberei vir interaksie met die gebruiker.

Aansoek 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 metode, indien geĂŻmplementeer in hierdie subklas, word uitgevoer voordat die onCreate metode. Hierdie opstelling stel vroeĂ« inisialisering in staat voordat die res van die aansoek 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

Dienste is agtergrond operateurs 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 noodsaaklik maak vir langdurige operasies.

Dienste is veelsydig; hulle kan op verskeie maniere geaktiveer word, met Intents as die primĂȘre metode om hulle as ’n toepassing se toegangspunt te begin. Sodra ’n diens begin is met die startService metode, begin sy onStart metode in aksie en hou aan om te loop totdat die stopService metode eksplisiet aangeroep word. Alternatiewelik, as ’n diens se rol afhanklik is van ’n aktiewe kliĂ«ntverbinding, word die bindService metode gebruik om die kliĂ«nt aan die diens te bind, wat die onBind metode aktiveer vir dataversending.

’n Interessante toepassing van dienste sluit agtergrondmusiekafspeel of netwerkdata-opeising in sonder om die gebruiker se interaksie met ’n toepassing te hindern. Boonop kan dienste beskikbaar gemaak word vir ander prosesse op dieselfde toestel deur uitvoer. Dit is nie die standaardgedrag nie en vereis eksplisiete konfigurasie in die Android Manifest-lĂȘer:

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

Uitsendingsontvangers

Uitsendingsontvangers dien as luisteraars in ’n boodskapstelsel, wat verskeie toepassings toelaat om op dieselfde boodskappe van die stelsel te reageer. ’n App kan ’n ontvanger registreer op twee primĂȘre maniere: deur die app se Manifest of dynamies binne die app se kode via die registerReceiver API. In die Manifest word uitsendings gefiltreer met toestemmings, terwyl dinamies geregistreerde ontvangers ook toestemmings kan spesifiseer tydens registrasie.

Intent filters is van kardinale belang in beide registrasiewyse, wat bepaal watter uitsendings die ontvanger aktiveer. Sodra ’n ooreenstemmende uitsending gestuur word, word die ontvanger se onReceive metode aangeroep, wat die app in staat stel om ooreenkomstig te reageer, soos om gedrag aan te pas in reaksie op ’n lae battery waarskuwing.

Uitsendings kan asynchrone wees, wat alle ontvangers sonder volgorde bereik, of synchronies, waar ontvangers die uitsending ontvang op grond van ingestelde prioriteite. Dit is egter belangrik om die potensiĂ«le sekuriteitsrisiko te noem, aangesien enige app homself kan prioriteer om ’n uitsending te onderskep.

Om ’n ontvanger se funksionaliteit te verstaan, soek na die onReceive metode binne sy klas. Die kode van hierdie metode kan die ontvangde Intent manipuleer, wat die behoefte aan datavalidatie deur ontvangers beklemtoon, veral in Geregelde Uitsendings, wat die Intent kan wysig of laat val.

Inhoudverskaffer

Inhoudverskaffers is noodsaaklik vir die deel van gestruktureerde data tussen toepassings, wat die belangrikheid van die implementering van toestemmings beklemtoon om datasekuriteit te verseker. Hulle laat toepassings toe om toegang te verkry tot data van verskeie bronne, insluitend databasisse, lĂȘerstelsels of die web. Spesifieke toestemmings, soos readPermission en writePermission, is van kardinale belang om toegang te beheer. Boonop kan tydelike toegang verleen word deur grantUriPermission instellings in die app se manifest, wat eienskappe soos path, pathPrefix, en pathPattern benut vir gedetailleerde toegangbeheer.

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

FileProvider, ’n gespesialiseerde Inhoudverskaffer, fokus op die veilige deel van lĂȘers. Dit word in die app se manifest gedefinieer met spesifieke eienskappe om toegang tot vouers te beheer, aangedui deur android:exported en android:resource wat na vouer konfigurasies verwys. Versigtigheid word aanbeveel wanneer daar direkteure gedeel word om te voorkom dat sensitiewe data per ongeluk blootgestel word.

Voorbeeld manifest verklaring vir 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 vouers in filepaths.xml:

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

For further information check:

WebViews

WebViews is soos mini webblaaiers binne Android-apps, wat inhoud trek of van die web of van plaaslike lĂȘers. Hulle ondervind 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 uitstekend vir basiese HTML, maar ondersteun nie die JavaScript waarskuwing funksie nie, wat die toetsing van XSS-aanvalle beĂŻnvloed.
  • WebChromeClient funksioneer meer soos die volle Chrome-blaaierervaring.

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

Vir die laai van inhoud is metodes soos loadUrl, loadData, en loadDataWithBaseURL beskikbaar. Dit is van kardinale belang 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 toe om met JavaScript te kommunikeer, wat vereis dat metodes gemerk moet word met @JavascriptInterface vir sekuriteit vanaf Android 4.2.

Om toegang tot inhoud toe te laat (setAllowContentAccess(true)) laat WebViews toe om toegang te verkry tot Content Providers, wat ’n risiko kan wees tensy die inhoud URL’s as veilig geverifieer word.

Om lĂȘertoegang te beheer:

  • Deaktiveer lĂȘertoegang (setAllowFileAccess(false)) beperk toegang tot die lĂȘerstelsel, met uitsonderings vir sekere bates, wat verseker dat hulle slegs vir nie-sensitiewe inhoud gebruik word.

Other App Components and Mobile Device Management

Digital Signing of Applications

  • Digitale ondertekening is ’n moet vir Android-apps, wat verseker dat hulle egte oorsprong het voor installasie. Hierdie proses gebruik ’n sertifikaat vir app-identifikasie en moet deur die toestel se pakketbestuurder geverifieer word tydens installasie. Apps kan self-onderteken of gesertifiseer deur ’n eksterne CA wees, wat beskerming bied teen ongemagtigde toegang en verseker dat die app ongeskonde bly tydens sy aflewering aan die toestel.

App Verification for Enhanced Security

  • Begin vanaf Android 4.2, ’n funksie genaamd Verify Apps laat gebruikers toe om apps vir veiligheid te laat nagaan voor installasie. Hierdie verifikasieproses kan gebruikers waarsku teen potensieel skadelike apps, of selfs die installasie van veral kwaadwillige apps voorkom, wat gebruikers se sekuriteit verbeter.

Mobile Device Management (MDM)

  • MDM-oplossings bied toesig en sekuriteit vir mobiele toestelle deur middel van Device Administration API. Hulle vereis die installasie van ’n Android-app om mobiele toestelle effektief te bestuur en te beveilig. Sleutelfunksies sluit in afdwing van wagwoordbeleide, verpligte stoor-enkripsie, en toestemming vir afstandsdata-wipe, 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);
}

Opname en Exploitering van AIDL / Binder Dienste

Android Binder IPC stel baie stelsels en verskaffer-gelewer dienste bloot. Daardie dienste word ’n aanvaloppervlak wanneer hulle sonder ’n behoorlike toestemmingskontrole uitgevoer word (die AIDL-laag self voer geen toegangbeheer uit nie).

1. Ontdek lopende dienste

# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper
  1. Android-toepassings is ’n belangrike deel van mobiele toestels en bied ’n verskeidenheid funksies en dienste.
  2. Die ontwikkeling van Android-toepassings vereis ’n begrip van die Android-argitektuur en die verskillende komponente.
  3. Veiligheid is ’n kritieke aspek van Android-toepassings, en dit is noodsaaklik om kwesbaarhede te identifiseer en aan te spreek.
  4. Pentesting van Android-toepassings behels die gebruik van verskeie tegnieke om die sekuriteit van die toepassing te toets.
  5. Dit is belangrik om ’n gestructureerde benadering te volg wanneer jy Android-toepassings toets, insluitend die gebruik van metodologieĂ« en hulpmiddels.
145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]
  • Die indeks (eerste kolom) word tydens uitvoering toegeken – moenie daarop staatmaak oor herlaai nie.
  • Die Binder naam (bv. mtkconnmetrics) is wat aan service call oorgedra sal word.
  • Die waarde binne die hakies is die volledig-gekwalifiseerde AIDL koppelvlak waarvan die stub gegenereer is.

2. Verkry die koppelvlak beskrywer (PING)

Elke Binder stub implementeer outomaties transaksie kode 0x5f4e5446 (1598968902 desimaal, ASCII “_NTF”).

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

’n Geldige antwoord keer die koppelvlaknaam terug as ’n UTF-16 string binne ’n Parcel.

3. Om ’n transaksie aan te roep

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

Gewone argument spesifiseerders:

  • i32 <int> – onderteken 32-bit waarde
  • i64 <long> – onderteken 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 headerlĂȘers nie beskikbaar is nie, kan jy die kode herhaal 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 met proguard gecompileer is, moet die kaartlegging geraai word – sien volgende stap.

5. Kaartkode ↔ metodes via onTransact()

Decompile die jar/odex wat die koppelvlak implementeer (vir AOSP stubs kyk /system/framework; OEMs gebruik dikwels /system_ext of /vendor). Soek vir 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. Identifisering van ontbrekende toestemmingskontroles

Die implementering (dikwels ’n interne Impl klas) is verantwoordelik vir outorisering:

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

Die afwesigheid van sulke logika of ’n witlys van bevoorregte UID’s (bv. uid == 1000 /*system*/) is ’n kwesbaarheid aanduiding.

Gevalstudie – MediaTek startMonitorProcessWithUid() (transaksie 8) voer ’n Netlink boodskap sonder enige toestemming hek volledig uit, wat ’n onbevoegde app toelaat om met die kern se Netfilter module te kommunikeer en die stelsellog te spam.

7. Outomatisering van die assessering

Gereedskap / skripte wat Binder verkenning versnel:

  • binderfs – stel /dev/binderfs met per-diens nodes bloot
  • binder-scanner.py – loop deur die binder tabel en druk ACL’s
  • Frida snelkoppeling: 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