Android Applications Basics
Last updated
Last updated
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)
Postoje dva sloja:
OS, koji drži instalirane aplikacije izolovane jedna od druge.
sama aplikacija, koja omogućava programerima da izlože određene funkcionalnosti i konfigurišu mogućnosti aplikacije.
Svakoj aplikaciji se dodeljuje specifični User ID. Ovo se dešava tokom instalacije aplikacije tako da aplikacija može da komunicira samo sa datotekama koje pripadaju njenom User ID-u ili deljenim datotekama. Stoga, samo sama aplikacija, određeni delovi OS-a i root korisnik mogu pristupiti podacima aplikacije.
Dve aplikacije mogu biti konfigurisane da koriste isti UID. Ovo može biti korisno za deljenje informacija, ali ako je jedna od njih kompromitovana, podaci obe aplikacije će biti kompromitovani. Zato se ovo ponašanje ne preporučuje.
Da bi delile isti UID, aplikacije moraju definisati istu android:sharedUserId vrednost u svojim manifestima.
Android Application Sandbox omogućava da se svaka aplikacija pokreće kao poseban proces pod posebnim korisničkim ID-om. Svaki proces ima svoju virtuelnu mašinu, tako da se kod aplikacije izvršava u izolaciji od drugih aplikacija. Od Android 5.0(L) SELinux se primenjuje. U suštini, SELinux je odbio sve interakcije procesa i zatim stvorio politike da dozvoli samo očekivane interakcije između njih.
Kada instalirate aplikaciju i ona traži dozvole, aplikacija traži dozvole konfigurisane u uses-permission elementima u AndroidManifest.xml datoteci. uses-permission element označava naziv tražene dozvole unutar name atributa. Takođe ima maxSdkVersion atribut koji prestaje da traži dozvole na verzijama višim od one koja je navedena.
Napomena da android aplikacije ne moraju tražiti sve dozvole na početku, mogu takođe tražiti dozvole dinamički, 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 dozvole ima tri atributa:
ime dozvole
permission-group atribut, koji omogućava grupisanje povezanih dozvola.
protection-level koji označava kako se dozvole dodeljuju. Postoje četiri vrste:
Normal: Koristi se kada nema poznatih pretnji za aplikaciju. Korisnik nije obavezan da je odobri.
Dangerous: Ukazuje da dozvola dodeljuje tražećoj aplikaciji neki povišeni pristup. Korisnici se traže da ih odobre.
Signature: Samo aplikacije potpisane istim sertifikatom kao onaj koji izvozi komponentu mogu dobiti dozvolu. Ovo je najjači tip zaštite.
SignatureOrSystem: Samo aplikacije potpisane istim sertifikatom kao onaj koji izvozi komponentu ili aplikacije koje rade sa pristupom na sistemskom nivou mogu dobiti dozvole.
Ove aplikacije se obično nalaze u /system/app ili /system/priv-app direktorijumima i neke od njih su optimizovane (možda čak nećete pronaći classes.dex datoteku). Ove aplikacije vredi proveriti jer ponekad rade sa previše dozvola (kao root).
One koje dolaze sa AOSP (Android OpenSource Project) ROM-om
Dodate od strane proizvođača uređaja
Dodate od strane provajdera mobilnih telefona (ako su kupljene od njih)
Da biste dobili root pristup na fizičkom android uređaju, obično morate iskoristiti 1 ili 2 ranjivosti koje su obično specifične za uređaj i verziju.
Kada eksploatacija uspe, obično se Linux su binarni fajl kopira na lokaciju koja je navedena u korisničkoj PATH env varijabli kao što je /system/xbin.
Kada je su binarni fajl konfiguran, koristi se druga Android aplikacija za interakciju sa su binarnim fajlom i obrađivanje zahteva za root pristup kao što su Superuser i SuperSU (dostupni u Google Play prodavnici).
Napomena da je proces rootovanja veoma opasan i može ozbiljno oštetiti uređaj.
Moguće je zameniti OS instaliranjem prilagođenog firmvera. Na ovaj način 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 firmvera za korišćenje.
Napomena da nije uvek potrebno rootovati uređaj da bi se instalirao prilagođeni firmver. Neki proizvođači dozvoljavaju otključavanje svojih bootloader-a na dobro dokumentovan i siguran način.
Kada je uređaj rootovan, svaka aplikacija može zatražiti pristup kao root. Ako zlonamerna aplikacija dobije taj pristup, moći će da pristupi gotovo svemu i moći će da ošteti telefon.
Format Android aplikacija se naziva APK format datoteke. To je u suštini ZIP datoteka (preimenovanjem ekstenzije datoteke u .zip, sadržaj se može izdvojiti i pregledati).
Sadržaj APK-a (nije iscrpan)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: sadrži prekompilirane resurse, poput binarnog XML-a.
res/xml/files_paths.xml
META-INF/
Ovde se nalazi sertifikat!
classes.dex
Sadrži Dalvik bajtkod, koji predstavlja kompajlirani Java (ili Kotlin) kod koji aplikacija izvršava po defaultu.
lib/
Sadrži nativne biblioteke, razdvojene po CPU arhitekturi u poddirektorijumima.
armeabi: kod za ARM procesore
armeabi-v7a: kod za ARMv7 i više procesore
x86: kod za X86 procesore
mips: kod samo za MIPS procesore
assets/
Čuva razne datoteke potrebne aplikaciji, potencijalno uključujući dodatne nativne biblioteke ili DEX datoteke, ponekad korišćene od strane autora malvera za prikrivanje dodatnog koda.
res/
Sadrži resurse koji nisu kompajlirani u resources.arsc
U Android razvoju, Java ili Kotlin se koriste za kreiranje aplikacija. Umesto korišćenja JVM-a kao u desktop aplikacijama, Android kompajlira ovaj kod u Dalvik Executable (DEX) bajtkod. Ranije je Dalvik virtuelna mašina upravljala ovim bajtkodom, ali sada, Android Runtime (ART) preuzima u novijim verzijama Androida.
Za obrnuto inženjerstvo, Smali postaje ključan. To je ljudski čitljiva verzija DEX bajtkoda, koja deluje kao asemberski jezik prevodeći izvorni kod u bajtkod instrukcije. Smali i baksmali se odnose na alate za asembler i disassembler u ovom kontekstu.
Intenti su primarni način na koji Android aplikacije komuniciraju između svojih komponenti ili sa drugim aplikacijama. Ovi objekti poruka takođe mogu nositi podatke između aplikacija ili komponenti, slično kako se koriste GET/POST zahtevi u HTTP komunikaciji.
Dakle, Intent je u suštini poruka koja se prenosi između komponenti. Intenti mogu biti usmereni ka specifičnim komponentama ili aplikacijama, ili se mogu slati bez specifičnog primaoca. Da pojednostavimo, Intent se može koristiti:
Da pokrene Aktivnost, obično otvarajući korisnički interfejs za aplikaciju
Kao emitovanja da obavesti sistem i aplikacije o promenama
Da pokrene, zaustavi i komunicira sa pozadinskom uslugom
Da pristupi podacima putem ContentProviders
Kao povratni pozivi za obradu događaja
Ako su ranjivi, Intenti se mogu koristiti za izvođenje raznih napada.
Intent Filteri definišu kako aktivnost, usluga ili Broadcast Receiver mogu interagovati sa različitim tipovima Intent-a. U suštini, oni opisuju mogućnosti ovih komponenti, kao što su koje akcije mogu izvršiti ili koje vrste emitovanja mogu obraditi. Primarno mesto za deklarisanje ovih filtera je unutar AndroidManifest.xml datoteke, iako je kodiranje za Broadcast Receivere takođe opcija.
Intent Filteri se sastoje od kategorija, akcija i filtera podataka, sa mogućnošću uključivanja dodatnih metapodataka. Ova postavka omogućava komponentama da obrađuju specifične Intente koji se poklapaju sa deklarisanim kriterijumima.
Kritičan aspekt Android komponenti (aktivnosti/usluge/content provideri/broadcast receiveri) je njihova vidljivost ili javnost. Komponenta se smatra javnom i može interagovati sa drugim aplikacijama ako je exported sa vrednošću true ili ako je za nju deklarisan Intent Filter u manifestu. Međutim, postoji način za programere da eksplicitno zadrže ove komponente privatnim, osiguravajući da ne interaguju sa drugim aplikacijama nenamerno. Ovo se postiže postavljanjem exported atributa na false u njihovim manifest definicijama.
Pored toga, programeri imaju opciju da dodatno osiguraju pristup ovim komponentama zahtevajući specifične dozvole. permission atribut može biti postavljen da osigura da samo aplikacije sa dodeljenom dozvolom mogu pristupiti komponenti, dodajući dodatni sloj sigurnosti i kontrole nad tim ko može da interaguje sa njom.
Intenti se programatski kreiraju koristeći Intent konstruktor:
The Action of the previously declared intent is ACTION_SEND and the Extra is a mailto Uri (the Extra if the extra information the intent is expecting).
Ova namera treba da bude deklarisana unutar manifest-a kao u sledećem primeru:
An intent-filter treba da odgovara akciji, podacima i kategoriji da bi primio poruku.
Proces "rezolucije intencija" određuje koja aplikacija treba da primi svaku poruku. Ovaj proces uzima u obzir atribut prioriteta, koji može biti postavljen u deklaraciji intent-filter-a, i onaj sa višim prioritetom će biti izabran. Ovaj prioritet može biti postavljen između -1000 i 1000, a aplikacije mogu koristiti SYSTEM_HIGH_PRIORITY vrednost. Ako dođe do konflikta, pojavljuje se "chooser" prozor kako bi korisnik mogao da odluči.
Eksplicitna intencija specificira naziv klase koju cilja:
U drugim aplikacijama, kako biste pristupili prethodno deklarisanom nameru, možete koristiti:
Oni omogućavaju drugim aplikacijama da preduzimaju akcije u ime vaše aplikacije, koristeći identitet i dozvole vaše aplikacije. Prilikom konstruisanja Pending Intent-a, treba navesti intent i akciju koja se izvršava. Ako deklarisani intent nije Eksplicitan (ne navodi koji intent može da ga pozove), zla aplikacija bi mogla da izvrši deklarisanu akciju u ime žrtvinske aplikacije. Štaviše, ako akcija nije navedena, zla aplikacija će moći da izvrši bilo koju akciju u ime žrtve.
Za razliku od prethodnih intent-a, koji se primaju samo od jedne aplikacije, broadcast intent-i mogu biti primljeni od više aplikacija. Međutim, od API verzije 14, moguće je odrediti aplikaciju koja treba da primi poruku koristeći Intent.setPackage.
Alternativno, takođe je moguće navesti dozvolu prilikom slanja broadcast-a. Aplikacija primaoc će morati da ima tu dozvolu.
Postoje dva tipa Broadcast-a: Normalni (asinkroni) i Poručeni (sinhroni). Redosled se zasniva na konfigurisanoj prioritetu unutar elementa primaoca. Svaka aplikacija može obraditi, preneti 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 osigurava da poruka nikada ne napusti aplikaciju. Koristeći ovo, nećete ni morati da izvozite komponentu primaoca.
Ova vrsta Broadcast-a može se pristupiti dugo nakon što su poslati. Oni su ukinuti u API nivou 21 i preporučuje se da ih ne koristite. Oni omogućavaju bilo kojoj aplikaciji da prisluškuje podatke, ali i da ih modifikuje.
Ako pronađete funkcije koje sadrže reč "sticky" kao što su sendStickyBroadcast ili sendStickyBroadcastAsUser, proverite uticaj i pokušajte da ih uklonite.
U Android aplikacijama, deep links se koriste za pokretanje akcije (Intent) direktno putem URL-a. To se postiže deklarisanjem specifičnog URL shema unutar aktivnosti. Kada Android uređaj pokuša da pristupi URL-u sa ovom shemom, određena aktivnost unutar aplikacije se pokreće.
Shema mora biti deklarisana u AndroidManifest.xml datoteci:
Šema iz prethodnog primera je examplescheme:// (obratite pažnju i na kategoriju BROWSABLE)
Zatim, u polju podataka, možete navesti host i path:
Da biste mu pristupili putem veba, moguće je postaviti link kao:
Da biste pronašli kod koji će biti izvršen u aplikaciji, idite na aktivnost koju poziva deeplink i potražite funkciju onNewIntent.
Saznajte kako da pozovete deep linkove bez korišćenja HTML stranica.
Android Interfejs Definicija Jezika (AIDL) je dizajniran za olakšavanje komunikacije između klijenta i servisa u Android aplikacijama putem interprocesne komunikacije (IPC). Pošto direktan pristup memoriji drugog procesa nije dozvoljen na Androidu, AIDL pojednostavljuje proces maršalizovanjem objekata u format koji operativni sistem razume, čime olakšava komunikaciju između različitih procesa.
Povezani Servisi: Ovi servisi koriste AIDL za IPC, omogućavajući aktivnostima ili komponentama da se povežu sa servisom, šalju zahteve i primaju odgovore. Metoda onBind u klasi servisa je ključna za započinjanje interakcije, označavajući je kao vitalno područje za bezbednosnu reviziju u potrazi za ranjivostima.
Messenger: Kao povezani servis, Messenger olakšava IPC sa fokusom na obradu podataka putem metode onBind. Bitno je pažljivo pregledati ovu metodu zbog bilo kakvog nesigurnog rukovanja podacima ili izvršavanja osetljivih funkcija.
Binder: Iako je direktna upotreba klase Binder ređa zbog AIDL-ove apstrakcije, korisno je razumeti da Binder deluje kao drajver na nivou jezgra koji olakšava prenos podataka između memorijskih prostora različitih procesa. Za dalju pomoć, resurs je dostupan na https://www.youtube.com/watch?v=O-UHvFjxwZ8.
Ove uključuju: Aktivnosti, Servise, Broadcast Receiver-e i Provajdere.
U Android aplikacijama, aktivnosti su poput ekrana, prikazujući različite delove korisničkog interfejsa aplikacije. Aplikacija može imati mnogo aktivnosti, od kojih svaka predstavlja jedinstveni ekran za korisnika.
Launcher aktivnost je glavni ulaz u aplikaciju, pokreće se kada dodirnete ikonu aplikacije. Definisana je u manifest fajlu aplikacije sa specifičnim MAIN i LAUNCHER intencijama:
Неће све апликације требати ланчер активност, посебно оне без корисничког интерфејса, као што су позадинске услуге.
Активности могу бити доступне другим апликацијама или процесима означавањем као "извозне" у манифесту. Ова подешавања омогућавају другим апликацијама да покрену ову активност:
Međutim, pristupanje aktivnosti iz druge aplikacije nije uvek bezbednosni rizik. Briga se javlja ako se osetljivi podaci dele nepravilno, što može dovesti do curenja informacija.
Životni ciklus aktivnosti počinje sa onCreate metodom, postavljajući UI i pripremajući aktivnost za interakciju sa korisnikom.
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. attachBaseContext metoda, ako je implementirana u ovoj podklasi, izvršava se pre onCreate metode. Ova postavka omogućava ranu inicijalizaciju pre nego što ostatak aplikacije počne.
Services su pozadinski operativci sposobni za izvršavanje zadataka bez korisničkog interfejsa. Ovi zadaci mogu nastaviti da se izvršavaju čak i kada korisnici pređu na različite aplikacije, što čini servise ključnim za dugotrajne operacije.
Servisi su svestrani; mogu se pokrenuti na različite načine, pri čemu su Intents primarna metoda za njihovo pokretanje kao ulaznu tačku aplikacije. Kada se servis pokrene koristeći metodu startService, njegova metoda onStart počinje da se izvršava i nastavlja da radi dok se metoda stopService eksplicitno ne pozove. Alternativno, ako je uloga servisa zavisna od aktivne klijentske veze, koristi se metoda bindService za povezivanje klijenta sa servisom, angažujući metodu onBind za prenos podataka.
Zanimljiva primena servisa uključuje reprodukciju muzike u pozadini ili preuzimanje mrežnih podataka bez ometanja interakcije korisnika sa aplikacijom. Štaviše, servisi se mogu učiniti dostupnim drugim procesima na istom uređaju putem izvoza. Ovo nije podrazumevano ponašanje i zahteva eksplicitnu konfiguraciju u Android Manifest datoteci:
Broadcast receivers deluju kao slušatelji u sistemu poruka, omogućavajući više aplikacija da reaguju na iste poruke iz sistema. Aplikacija može registrovati prijemnik na dva osnovna načina: kroz Manifest aplikacije ili dinamički unutar koda aplikacije putem registerReceiver API-ja. U Manifestu, emitovanja se filtriraju sa dozvolama, dok dinamički registrovani prijemnici takođe mogu specificirati dozvole prilikom registracije.
Intent filteri su ključni u obe metode registracije, određujući koja emitovanja aktiviraju prijemnik. Kada se pošalje odgovarajuće emitovanje, poziva se onReceive metoda prijemnika, omogućavajući aplikaciji da reaguje u skladu sa tim, kao što je prilagođavanje ponašanja u odgovoru na upozorenje o niskoj bateriji.
Emitovanja mogu biti asinhrona, dostižući sve prijemnike bez reda, ili sinhrona, gde prijemnici dobijaju emitovanje na osnovu postavljenih prioriteta. Međutim, važno je napomenuti potencijalni bezbednosni rizik, jer svaka aplikacija može dati prioritet sebi da presretne emitovanje.
Da biste razumeli funkcionalnost prijemnika, potražite onReceive metodu unutar njegove klase. Kod ove metode može manipulisati primljenim Intentom, naglašavajući potrebu za validacijom podataka od strane prijemnika, posebno u Ordered Broadcasts, koji mogu modifikovati ili odbaciti Intent.
Content Providers su ključni za deljenje strukturiranih podataka između aplikacija, naglašavajući važnost implementacije dozvola kako bi se osigurala bezbednost podataka. Oni omogućavaju aplikacijama da pristupaju podacima iz različitih izvora, uključujući baze podataka, datotečne sisteme ili web. Specifične dozvole, kao što su readPermission i writePermission, su ključne za kontrolu pristupa. Pored toga, privremeni pristup može biti odobren putem grantUriPermission podešavanja u manifestu aplikacije, koristeći atribute kao što su path, pathPrefix i pathPattern za detaljnu kontrolu pristupa.
Validacija unosa je od suštinskog značaja za sprečavanje ranjivosti, kao što je SQL injekcija. Content Providers podržavaju osnovne operacije: insert(), update(), delete(), i query(), olakšavajući manipulaciju i deljenje podataka među aplikacijama.
FileProvider, specijalizovani Content Provider, fokusira se na sigurno deljenje datoteka. Definisan je u manifestu aplikacije sa specifičnim atributima za kontrolu pristupa folderima, označenim sa android:exported i android:resource koji ukazuju na konfiguracije foldera. Preporučuje se oprez prilikom deljenja direktorijuma kako bi se izbeglo nenamerno izlaganje osetljivih podataka.
Primer deklaracije manifesta za FileProvider:
I primer specifikovanja deljenih foldera u filepaths.xml:
For further information check:
WebViews su kao mini web pregledači unutar Android aplikacija, koji preuzimaju sadržaj ili sa interneta ili iz lokalnih datoteka. Suočen su sa sličnim rizicima kao obični pregledači, ali postoje načini da se smanje ovi rizici kroz specifične postavke.
Android nudi dva glavna tipa WebView:
WebViewClient je odličan za osnovni HTML, ali ne podržava JavaScript alert funkciju, što utiče na to kako se XSS napadi mogu testirati.
WebChromeClient deluje više kao potpuno iskustvo Chrome pregledača.
Ključna tačka je da WebView pregledači ne dele kolačiće sa glavnim pregledačem uređaja.
Za učitavanje sadržaja, dostupne su metode kao što su loadUrl, loadData, i loadDataWithBaseURL. Ključno je osigurati da su ovi URL-ovi ili datoteke sigurni za korišćenje. Bezbednosne postavke mogu se upravljati putem WebSettings klase. Na primer, onemogućavanje JavaScripta sa setJavaScriptEnabled(false) može sprečiti XSS napade.
JavaScript "Bridge" omogućava Java objektima da komuniciraju sa JavaScript-om, zahtevajući da metode budu označene sa @JavascriptInterface radi bezbednosti od Android 4.2 nadalje.
Dozvoljavanje pristupa sadržaju (setAllowContentAccess(true)) omogućava WebView-ima pristup Content Providers, što može predstavljati rizik osim ako su URL-ovi sadržaja verifikovani kao sigurni.
Da biste kontrolisali pristup datotekama:
Onemogućavanje pristupa datotekama (setAllowFileAccess(false)) ograničava pristup datotečnom sistemu, sa izuzecima za određene resurse, osiguravajući da se koriste samo za nesenzitivni sadržaj.
Digitalno potpisivanje je obavezno za Android aplikacije, osiguravajući da su autentično napisane pre instalacije. Ovaj proces koristi sertifikat za identifikaciju aplikacije i mora biti verifikovan od strane menadžera paketa uređaja prilikom instalacije. Aplikacije mogu biti samo-potpisane ili sertifikovane od strane eksternog CA, štiteći od neovlašćenog pristupa i osiguravajući da aplikacija ostane neizmenjena tokom isporuke na uređaj.
Počevši od Android 4.2, funkcija pod nazivom Verifikacija aplikacija omogućava korisnicima da provere aplikacije za bezbednost pre instalacije. Ovaj proces verifikacije može upozoriti korisnike na potencijalno štetne aplikacije, ili čak sprečiti instalaciju posebno zlonamernih, poboljšavajući bezbednost korisnika.
MDM rešenja pružaju nadzor i bezbednost za mobilne uređaje putem Device Administration API. Oni zahtevaju instalaciju Android aplikacije za efikasno upravljanje i obezbeđivanje mobilnih uređaja. Ključne funkcije uključuju sprovođenje politika lozinki, obavezno šifrovanje skladišta, i dozvoljavanje daljinskog brisanja podataka, osiguravajući sveobuhvatan nadzor i bezbednost nad mobilnim uređajima.
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)
