Zbog ovakvog pristupa bilo je potrebno definirati robusni sigurnosni model koji bi osiguravao sigurnost podataka, korisnika, aplikacija uređaja i mreže.

Prema (Android, 2014b): Android je izrađen s fokusom na developere, te su ugrađene različite sigurnosne kontrole kako bi smanjile teret prilikom razvoja softvera. No ovo nije unazadilo pristup naprednim sigurnosnim kontrolama, nego je sustav osmišljen u smislu početno dodijeljenih sigurnosnih kontrola tako da su svi developeri zaštićeni u određenom pogledu.

Osim fokusa na developere Android sustav sadrži ugrađene mehanizme za zaštitu korisnika; svakome korisniku priloženo je na uvid kako aplikacija koju instaliraju radi, odnosno kojim svojstvima i funkcionalnostima uređaja pristupa. Na ovaj način otežani su napadi uz pomoć socijalnog inženjeringa, instaliranja zloćudnih aplikacija, napade na aplikacije trećih strana i sl.

Alati korišteni u ovome istraživanju:

• Eclipse Kepler – integrirano razvojno okruženje sa Android Development Tool (ADT) pluginom
• Android SDK – razvojni alati Androida
• Android debugging bridge (ADB) – alat za komunikaciju i upravljanje emulatorima i fizičkim uređajem preko naredbene linije (eng. command line)
• Dalvik Debug Monitor Server – alat za debuggiranje integriran u ADT
• HTC Sensation – Android verzija 4.3.1, CyanogenMod 10.2

SIGURNOSNA ARHITEKTURA ANDROID PLATFORME

U svrhu ostvarivanja (Android, 2014b):

• zaštite korisničkih podataka
• zaštite sistemskih resursa
• izolacije aplikacija

android sustav pruža sljedeće ključna svojstva:

• robusna sigurnost na razini operacijskog sustava kroz Linux kernel
• obavezno izvršavanje aplikacija u sandbox^{Sandbox- sigurnosni mehanizam zatvaranja aplikacije u kontrolirano okruženje u kojemu ima ograničene resurse, dopuštenja i sl. (Goldberg, Wagner, Thomas, i Brewer, 1996, str. 4)} okruženju
• potpisivanje aplikacija
• Dopuštenja definirana aplikacijom i dopuštena od strane korisnika

Na Slika 2 može se vidjeti struktura Android softvera te sažete sigurnosne komponente kroz različite razine slojeva Android softvera.

Slika 2: Android software stack (Android, 2014b)

Linux jezgra

Na dnu Androidove softverske hrpe nalazi se jezgra operativnog sustava temeljena na Security-Enhanced Linux operativnom sustavu te je dodatno prilagođena za mobilne uređaje od strane Googlea, tijekom razvoja novijih platformi Google je inkrementalno poboljšavao vlastitu verziju jezgre Linuxa te je pridonio stvaranju raznih sigurnosnih mehanizama koji su danas prihvaćeni te implementirani u glavnu verziju Linux jezgre verzije 3.3 [Kernelnewbies, 2012]

Neka od svojstava Androida implementiranih u Linux 3.3 verziju jezgre:

• Binder – interprocesni komunikacijski mehanizam visoke performanse koji služi za omogućavanje komunikacije između procesa.
• Logger – dio sustava za logiranje određenih poruka nevezanih za poruke jezgre.
• Shrinker – implementacija Androida u pogledu upravljanja aplikacijama, na ovaj način aplikacije ostaju u memoriji dok ih jezgra ne odluči uništiti.
• Pmem – daje mogućnost alociranja fizički većeg neprekinutog spremnika kada je potrebno.

Kada sagledamo Linux jezgru sa perspektive sigurnosti postoje mnogi mehanizmi koji osiguravaju siguran rad sustava primjerice (Android, 2014b):

• Sustav dopuštenja temeljen na korisnicima
• Izolacija procesa
• Sigurni mehanizmi interprocesne komunikacije (IPC)
• Mogućnost uklanjanja nepotrebnih i nesigurnih dijelova jezgre

Dm-verity

„Android verzije 4.4 podržava verificirani boot kroz provjeri istinitosti uređaja (eng. device-mapper-verity) odnosno skraćeno dm-verity funkcionalnosti“ (Android, 2014c) gdje jezgra provjerava integritet uređaja odnosno blokova. Na ovaj način sprječava se pokretanje rootkit^{Zloćudan softver koji se skriva od sustava te omogućava privilegirani pristup uređaju od strane napadača} zloćudnog softvera koji se obično mogao skriti prilikom pokretanja samog uređaja bez dm-verity­ funkcionalnosti.

Istinitost blokova se provjerava uz pomoć sažetka (eng. hash) SHA256. Svaki izračunati sažetak bloka se uspoređuje sa stablom sažetaka, gdje korijenski sažetak mora biti pouzdan, na ovaj način cijelo stablo i njegova pouzdanost tj. istinitost je povezana kroz sažetke svih blokova, te ako postoje i najmanja odstupanja sa stablom sažetaka došlo je do promjene na sustavu te dolazi do greške u čitanju i poruke o izmijenjenosti datotečnog sustava (Slika 3). Kako ne bi došlo do pada performansi prilikom učitavanja uređaja, provjera blokova radi se po principu prvog pristupa, odnosno kada sustav pristupa određenom bloku sustava, paralelno se izvršava provjera bloka naspram stabla sažetaka te se verificira traženi blok i ponaša se u skladu s prethodno navedenim pravilima.

Slika 3: Princip rada dm-verity funkcionalnosti (Android, 2014c)

Koncept korisnika i grupa

Koncept korisnika i korisničkih grupa omogućio je da korisnik A ne može čitati i utjecati na resurse korisnika B ako ne ide preko sigurnih provjerenih mehanizama. Korisnik u ovome slučaju ne predstavlja nužno čovjeka kao korisnika uređaja nego podrazumijeva i aplikacije odnosno procese koji se izvode u sustavu i sl.

Svaki korisnik odnosno aplikacija sadrži svoj korisnički ID (eng. user ID – UID), osim korisničkih ID, postoje i grupe kojima se svaki korisnik može dodijeliti eng. group ID – GID. Zbog ovakvoga modela te svojstva Linux sustava da je gotovo svaki resurs sustava pohranjen u obliku datoteke, svaka datoteka pripada određenom korisniku, grupi ili ostalim korisnicima odnosno svim ostalim korisnicima sustava. Ovo se primjerice može vidjeti na Slika 4: Struktura datoteka, korisnika i korisničkih grupa gdje je prikazana struktura memorije Android sustava uz pomoć ls naredbe. Kao što je već navedeno svaka datoteka i direktorij sadrži pripadajućeg korisnika i grupu koji je njegov vlasnik te može upravljati svojim pridodijeljenim resursima, te u ovome slučaju svaka aplikacija sadrži vlastiti direktorij te posjeduje prava na upravljanje samo resursima na koje ima prava.

Ako bi običan korisnik pokušao ispisati sadržaj direktorija koji mu ne pripada dobili bi poruku o nedovoljnim pravima za pristup resursu. Kao što se može vidjeti na Slika 5: Ispis strukture direktorija kao root korisnik nakon prijave kao administrator naredbom su moguće je pristupiti prethodno zabranjenom direktoriju /data te ispisati njegov sadržaj i dopuštenja. Na ovaj način postignut je sigurnosni mehanizam zaštite podataka aplikacija, resursa sustava i ostalih osjetljivih podataka kroz prava pristupa.

Ovim podacima moguće je pristupati na dva načina, kao administratori sustava (Slika 6) odnosno root korisnik, ili kroz mehanizme sustava koji se nazivaju pružatelji sadržaja (eng. Content Providers).

• 

  Slika 5: Ispis strukture direktorija kao root korisnik|300x300px

• 

  Slika 6: Pristup podacima kontakata kao root korisnik|300x300px

• 

  Slika 4: Struktura datoteka, korisnika i korisničkih grupa|300x300px

Sloj iznad jezgre sustava sadrži temeljne biblioteke Androida pisane u C i C++ programskom jeziku te služe za upravljanje uređajem i obradu različitih vrsta podataka. Uz ove biblioteke nalazi se Android Runtime koji sadrži temeljne biblioteke Java programskog jezika zajedno sa Dalvik virtualnim strojem (eng. Dalvik Virtual Machine, DVM). Dalvik virtualni stroj napravljen je po uzoru na virtualni stroj Jave skraćeno JVM, ali je optimiziran za mobilne uređaje različitim tehnikama minimalizacije korištenja memorije, brzog kreiranje novih procesa i sl. Na Android platformi izvorni Java kod se kompajlira u datoteke s nastavkom .class, te ih zatim poseban alat pod nazivom „dx“ pretvara u .dex datoteke koje se nazivaju Dalvik Executable file odnosno dalvik izvršne datoteke.(Brähler,2010, str. 17-19). Na Slika 7 Usporedba .class i .dex formata(Brähler, 2010, str. 4) može se vidjeti usporedba standardne Java arhive s nastavkom .jar koji sadrži .class Java datoteke; te Android paketa s nastavkom .apk, Format .dex se razlikuje od standardno kompajliranih Java .class datoteka po bazenu konstanti (eng. constant pool), odnosno lokaciji i načinu spremanja konstantnih vrijednosti prilikom izvršavanja aplikacije. Ovako je spriječeno ponavljanje konstanti kroz različite klase, te sve klase u .dex datoteci dijele ove prostore.

Slika 7: Usporedba .class i .dex formata(Brähler,2010, str. 19)

APLIKACIJSKA SIGURNOST

Kao što je već spomenuto Android aplikacije pisane su u Java programskom jeziku te se izvršavaju u Dalvik virtualnom stroju ( no važno je napomenuti da ih je moguće pisati i u nativnom jeziku). Sve aplikacije se instaliraju iz jedne datoteke sa .apk ekstenzijom.

Prema (Android, 2014b) osnovni elementi svake Android aplikacije su:

• AndroidManifest.xml – datoteka koja govori sustavu o sadržaju aplikacije, te dopuštenjima koja zahtjeva od sustava
• Aktivnosti – dio aplikacije koji se odnosi na jedan zadatak odnosno aktivnost, služe za prikaz korisničkog sučelja ali ne nužno.
• Servisi – programski kod koji se izvršava u pozadini aplikacije, moguće je dopustiti drugim komponentama povezivanje na servis uz pomoć poziva udaljenih procedura (eng. remote procedure calls)
• Broadcast reciever – objekt koji se kreira kada se IPC mehanizam poznat kao Intent, u prijevodu namjera, izda od strane sustava ili aplikacije. Uz pomoć ovih primatelja aplikacija može mijenjati svoja ponašanja na temelju vanjskih informacija koje prima preko Intenta.

Android Sandbox

Kao što je već navedeno Android sustav koristi sustav zaštite podržavan Linuxom tako da odvaja aplikacije i njihove resurse korisničkim ID-om, no za razliku od Linuxa Android svakoj aplikaciji pridružuje jedinstveni korisnički ID. Zbog ovakvog načina dizajna omogućeno je kreiranje aplikacijskog sandboxa na razini jezgre sustava. Jezgra sustava održava razinu sigurnosti između aplikacija te ograničava komunikacije i pristup resursa između svake aplikacije.

„Kako je aplikacijski sandbox na razini jezgre sigurnosni model se proširuje na nativni kod i aplikacije operacijskog sustava.“ (Android, 2014b) Zbog ovakvog pristupa sigurnosnom modelu sandboxa omogućena je zaštita čak i prilikom kompromitiranja sigurnosti uređaja, zato što se zloćudni kod tada izvršava samo u kontekstu aplikacije i njenih dopuštenja. Aplikacije koje imaju digitalni potpis od istog developera te im je pridodijeljen dijeljeni korisnički ID definiran u AndroidManifest.xml datoteci imaju dopuštenje za međusobno dijeljenje resursa.

Sustav dopuštenja

Kako je već navedeno sve aplikacije se izvršavaju u sandbox okruženju te zbog toga imaju ograničen pristup resursima sustava. Kako bi aplikacija mogla pristupiti raznim sustavnim resursima i određenom hardveru potrebno je zatražiti dopuštenja sustava kroz sigurnosni mehanizam Androida nazvan Permissions. Prema [Android, 2014b] zaštićena aplikacijska sučelja za koja su potrebna uključuju:

• Funkcionalnosti kamere
• Lokacijske podatke
• Bluetooth funkcije
• Telefonske funkcije
• SMS/MMS funkcije
• Mrežne i podatkovne veze

Kako bi aplikacija imala pristup ovim resursima mora zatražiti dopuštenja u prikladnoj datoteci AndroidManifest.xm, unutar ove datoteke developer definira koja dopuštenja aplikacija zahtjeva od sustava, te sustav prije instaliranja aplikacije traži korisnika za odobravanje ili odbijanje traženih dopuštenja Slika 8. U slučaju odobrenja zatraženih dopuštenja aplikacija se pridružuje grupi korisnika na sustavu koji imaju pravo pristupa traženim resursima. U slučaju da aplikacija pokuša pristupiti resursima za koje nije dobila dopuštenja kreira se sigurnosna iznimka i rad aplikacije se prekida od strane sustava.

Slika 8: Potvrda dopuštenja prilikom instalacije aplikacije Google Maps (Android, 2014b)

Potpisivanje i verifikacija aplikacija

Pomoću potpisivanja aplikacija i koda moguće je lakše identificirati autora aplikacije te mu omogućiti lakšu nadogradnju. Svaka aplikacija koja se izvršava na Android platformi mora biti potpisana od strane developera.(Android, 2014b)

Tijekom instalacije aplikacije na uređaj, rukovoditelj paketima (eng. Packet Manager) provjerava da li je aplikacija (APK) pravilno potpisana sa certifikatom uključenim u APK datoteku. Aplikacije mogu biti samostalno potpisane te nije potreban potpis centralnog autoriteta za izvršavanje aplikacija.

Od 4.2 verzije Androida pa nadalje sustav podržava verifikaciju aplikacija.(Android, 2014b) Korisnik može odabrati opciju „Provjeri aplikaciju“ te se aplikacije provjeravaju prije instalacije te sustav obavještava korisnika da li je aplikacija zloćudna.

Google Play

Google Play prethodno Android Market predstavlja servis Googlea uz pomoć kojeg korisnici mogu pronaći, instalirati ili kupiti aplikacije za svoj uređaj. Sustav je osmišljen na način da uređajima prikazuje aplikacije samo za koje ima prikladne hardverske funkcionalnosti. Ova politika je uspješno implementirana zbog korištenja AndroidManifest.xml datoteke, odnosno opisa aplikacije i hardverskih zahtjeva.

Svaka aplikacija prije instalacije prikazuje korisniku tražena dopuštenja od sustava te dozvolu korisnika za instalaciju, osim prikaza traženih dopuštenja korisnik također ima na uvid komentare drugih korisnika te njihove ocjene za aplikaciju koju instalira. Na ovaj način zajednica također doprinosi stabilnosti, kvaliteti i sigurnosti instaliranih aplikacija.

ZAŠTITA KORISNIKA

Android sustav održava razinu sigurnosti sa različitim ograničenjima pristupa i primjenom enkripcije, no za pravilno funkcioniranje određenih aplikacija sustav im može omogućiti pristup do određenih osjetljivih podataka kao što su kontakti, korisnički profili, certifikati i sl. Ovakvi pristupi osjetljivim podacima bez kršenja sigurnosnih mehanizama osiguravaju se uz pomoć API-ja odnosno aplikacijskog programskog sučelja (eng. application programming interface).

Content Providers

Content Provider u prijevodu pružatelj sadržaja je mehanizam uz pomoć kojega Android sustav aplikacijama pruža strukturirani skup podataka. (Android Developers, 2014b)

Uz pomoć pružatelja sadržaja aplikacije mogu pristupati osjetljivim ili zaštićenim podacima ako su za to prethodno dobili dopuštenje sustava odnosno korisnika. Moguće je izraditi vlastiti pružatelj sadržaja ako developer želi da njegova aplikacija dijeli podatke s drugim aplikacijama. Pružateljima sadržaja se pristupa uz pomoć content URIURI – skraćenica od uniformni identifikator resursa (eng. Uniform Resource Identifier) niz znakova koji služi za identifikaciju i interakciju s resursima (Thompson, H. S., 2010) , gdje se uz unos pružatelja podataka te imena koji pokazuje na određeni tablicu podataka može pristupiti određenim podacima sustava. Primjerice ako korisnik ili developer želi pristupiti rječniku koji se nalazi na sustavu koristit će sljedeći URI: content://user_dictionary/words, na ovaj način aplikacija pristupa pružatelju sadržaja pod nazivom user_dictionary u prijevodu „korisnički rječnik“, te uz dodatak naziva tablice words odnosno „riječi“ moguće je pristupiti korisničkom rječniku koji se nalazi u sustavu.

U slučaju da aplikacija pokušava pristupiti pružatelju sadržaja bez prethodnog dopuštenja sustav odbija vratiti tražene podatke, te dolazi do sigurnosne iznimke te se izvođenje aplikacije prekida.

Osobni podaci

Osobni podaci spremljeni su unutar lokalnog datotečnog sustava Androida u obliku SQLite baza podataka. Pristup ovim bazama ograničen prethodno opisanim sigurnosnim mehanizmima. Na Slika 9 Popis pružatelja sadržaja mogu se vidjeti sve baze osobnih podataka korisnika i osjetljivih podataka uređaja uz pomoć root korisnika. Kao što se može zamijetiti svaka baza podataka ima drugog korisnika odnosno različitog pružatelja sadržaja. Iz ovog razloga do navedenih podataka moguće je doći samo kroz sigurnosne mehanizme definirane sustavom uz prethodnu provjeru prava aplikacije (Slika 4.1 Aplikacijski pristup osjetljivim podacima).

Slika 9: Popis pružatelja sadržaja

Slika 10: Aplikacijski pristup osjetljivim podacima(Android, 2014b)

Osjetljive osobne hardverske komponente: geolociranje, kamera, mikrofon

Osjetljive komponente koje mogu prikupljati vanjske podatke zaštićene su sigurnosnim mehanizmima sustava te im je moguće pristupati uz pomoć Intenta ili aplikacijskog programskog sučelja (API). U slučaju da aplikacija koristi Intent, odnosno šalje namjeru sustavu da želi koristiti kameru, mikrofon, geolokaciju i sl; sustav pronalazi pravilnu aplikaciju za rad s traženim hardverom te odabranu aplikaciju prikazuje korisniku. Prilikom slanja Intenta nije potrebno eksplicitno tražiti korisničko dopuštenje davanja ovlasti nad traženim hardverom.

No ako aplikacija radi na način da direktno pristupa aplikacijskom programskom sučelju kamere, mikrofona ili geolokacije potrebno je zatražiti sigurnosno ovlaštenje od korisnika,odnosno sustava, prije rada sa ovim hardverskim komponentama.

U slučaju da korisnik ne želi otkriti trenutnu lokaciju svim aplikacijama može zabraniti odnosno isključiti lokacijske servise u postavkama Android pametnog telefona.

Device metadata

Svaki sustav može sadržavati podatke koji se ne smatraju dovoljno važnim da budu osjetljive naravi, ali indirektno mogu otkriti određene karakteristike i podatke koji se mogu iskoristiti u zloćudne svrhe. Iz ovog razloga sam sustav zabranjuje aplikacijama pristup sistemskim logovima, povijesti pregledavanja weba, postavki mreže, identifikacijske oznake softvera i hardvera i sl. U slučaju da aplikacija za vlastiti rad treba neke od meta podataka mora zatražiti eksplicitno dopuštenje korisnika za njihovo korištenje. Tek nakon što korisnik dopusti korištenje metapodataka uređaja aplikacija ima dopuštenja sustava za pristup ovakvim podacima, zbog ovakvih načina rada korisnik je više svjestan što se događa te kakve aplikacije instalira na vlastiti uređaj.

Enkripcija pametnog telefona

Prema (Android, 2014b) Android verzije 3.0 te nadalje sustav pruža potpunu enkripciju datotečnog sustava i korisničkih podataka unutar kernela koristeći dmcrypt implementaciju AES128 sa CBC i ESSIV:SHA256. Ključ za kriptiranje je zaštićen AES128 koristeći ključ koji je izveden iz korisničke lozinke te tako zabranjuje pristup uređaju važeće korisničke lozinke.

Dodatna zaštita protiv napada i pokušaja pogađanja lozinke je ostvarena slučajnim soljenjem (eng. random salt) lozinke uz postupak zaštite lozinki jednosmjernom kriptografskom funkcijom (eng. hashing) lozinke sa SHA1 koristeći standardni PBKDF2 algoritam. Moguće je postaviti osnovne zahtjeve kompleksnosti lozinke od strane administratora sustava. Korištenje kriptiranja Android pametnog telefona može se pronaći u Postavkama>Sigurnost>Kriptiranje telefona (Slika 11)

Slika 11: Sigurnosne postavke Android 4.3.1 uređaja

Sigurnosne postavke različitih sustava

U ovisnosti od korištenog tipa i verzije Android sustava mogu se pronaći različite postavke sigurnosti. Prema Electronic Frontier Foundation (2013) tijekom razvoja Google Android sustava u verziji 4.3 pojavila se funkcionalnost zrnatog upravljanja dopuštenjima aplikacija pod nazivom App ops (Slika 12). Tijekom redovnih nadogradnji sustava, ova funkcionalnost je uklonjena uz izjavu Googlea da je ova funkcionalnost bila eksperimentalna te da bi mogla slomiti određene aplikacije sa svojim politikama sigurnosti. Iz ovog razloga je App ops funkcionalnost uklonjena iz sljedećih verzija izvornog Android sustava do daljnjega.

• 

  Slika 12: App Ops funkcionalnost Androida (4.3) (Electronic Frontier Foundation, 2013)|300x300px

• 

  Slika 13: Privacy Guard postavke za Skype aplikaciju - CyanogenMod sustava|300x300px

No zbog open source politike sustava određene verzije sustava zadržale su ovu funkcionalnost te su je dodatno unaprijedili primjerice CyanogenMod je open source verzija Android sustava održavana od strane zajednice developera, te je funkcionalnost App Ops funkcionalnosti implementirana pod nazivom Privacy Guard. Uz pomoć ove funkcionalnosti moguće je dopustiti ili zabraniti aplikacijama pristup određenim podacima i funkcionalnostima uređaja kao što se može vidjeti na Slika 13.

PRAKTIČNO ISTRAŽIVANJE SIGURNOSTI ANDROIDA

Prilikom praktičnoga istraživanja sigurnost Android sustava fokusirati će se na pokušaj nedopuštenog dohvata sljedećih podataka:

• Razne korisničke račune i lozinke
• Geolokacijske podatke
• Povijesti korištenja Interneta
• Poruke, slike, kontakti

Kako su sigurnosni mehanizmi zaštite Android sustava objašnjeni kroz ovaj rad, podrazumijeva se da je do ovih podataka moguće doći nekoliko načina:

• Root administratorska prava pristupa uređaju
• Dohvat sadržaja uz pomoć Content Provider mehanizama
• Curenje osjetljivih podataka kroz razne sistemske zapise (eng. log)
• Eskalacija privilegija kroz rupe u sustavu
• Iskorištenje rupa u drugim instaliranim aplikacijama
• Ostali propusti?

Testiranje sigurnosti provođeno je na HTC Sensation, Android 4.3.1 uređaju sa CyanogenMod 10.2 sustavom. Kreiranje aplikacije sa traženjem dopuštenja za pristup osjetljivim podacima je najjednostavniji način kako napasti određeni sustav, no većina korisnika neće instalirati ovakve aplikacije te su korisnici relativno zaštićeni funkcionalnostima sustava. Kako bi došli do određenih korisničkih podataka moramo znati nešto više o njihovim svojstvima: lokacija, struktura podataka, zaštitni mehanizmi. Uz pretpostavku da nemamo root pristup uređaju, pristup podacima možemo ostvariti uz druge aplikacije ili ugrađene mehanizme pružatelja sadržaja (Slika 9).

Prije vlastitih pokušaja dolaska do osjetljivih podataka te testiranja sigurnosti Androida istraženi su javni izvori sigurnosnih propusta Android sustava. Prema tim izvorima pronađen je propust u Androidu do verzije 2.3.4 gdje je moguće uz pomoć web preglednika preuzeti osjetljive podatke uređaja tako što bi zloćudna skripta pozivala pružatelj sadržaja preko URI adrese unutar samog preglednika. Na ovaj način moguće je pristupiti kontekstu uređaja te preuzeti osjetljive podatke u obliku datoteka. (Cannon, 2011).

Ovaj propust je testiran na sljedećim preglednicima:

• Mozilla Firefox 27.0
• Google Chrome 33.0.1750.136
• Android Browser 4.3.1

Mozilla Firefox

Sve verzije preglednika su uspješno odbile pokušaj pristupa pružatelju sadržaja, no daljnjim istraživanjem i pokušajima pristupa datotečnom sustavu dva preglednika (Google Chrome i Mozilla Firefox) su uspješno prikazale sadržaj memorijske SD kartice uređaja na lokaciji file:///mnt/sdcard/ prema ovome korisnik je mogao pregledavati i „šetati“ sadržajem SD kartice kao datotečnim preglednikom (Slika 15).

Slika 14: Datotečni sustav SD kartice

Proučavajući više file protokol Android preglednika zamijećeno je da Firefox preglednik može doći do korijenskog direktorija, te se „šetati“ po datotečnom sustavu (Slika 16). Ovakva funkcionalnost može predstavljati sigurnosni propust u slučaju da aplikacija može zapisivati i čitati iz osjetljivih datoteka. Primjerice napadač može dohvatiti verziju jezgre sustava, te na temelju dohvaćenih podataka iskoristiti ranjivosti te verzije sustava(Slika 17).

Slika 16: Pristup korijenskom direktoriju Mozilla Firefox

Slika 17: Pristup osjetljivoj datoteci „/proc/version“

Trenutne verzije preglednika zaštićene su sa Same Origin Policy (SOP) mehanizmom koji zabranjuje izvršavanje skripti te dohvat drugih datoteka ako se ne nalaze na istoj lokaciji i protokolu kao izvršavana skripta. Primjerice ako se skripta izvršava na lokaciji: https://www.foi.hr/skripta1.html znači da je skripta izvršavana unutar www.foi.hr domene sa https protokolom. Ovakva zaštita zabranjuje skripti koja se izvršava na stranici skripta1.html izvršavanje i dohvat bilo kojih datoteka ili vanjskih skripti.

Daljnjim istraživanjem propusta Android sustava, ranjivost unutar Firefox preglednika je već bila otkrivena prema ViaForensics (2013), bilo je moguće zaobići SOP mehanizam uz pomoć kreiranja simboličkog linka na datoteku koju skripta želi preuzeti. Ovo je bio ozbiljan propust te je bilo moguće dohvatiti bilo koju datoteku kojoj je Firefox preglednik imao pristup unutar korijenskog direktorija. Sigurnosni propust je pravilno prijavljen Mozzili te je prema ViaForensics (2013) datuma 18.09.2013 pravilno riješen.

Tijekom testiranja pronađenog propusta i koristeći metode kreiranja simboličkih linkova Mozzila Firefox 27.0 bila je otporna na navedeni napad, no to ne znači da postoji mogućnost drugačijih vrsta napada te dohvata osjetljivih podataka uz pomoć Firefox preglednika.

Google Chrome

Osim prethodno navedenih propusta i sigurnosnih zakrpa Firefox preglednika, ustanovljena je još jedna moguća ranjivost koju je moguće iskoristiti sa administratorskim pristupom uređaju ili ranjivosti eskalacije privilegija. Google Chrome browser sprema razne osjetljive korisničke podatke u obliku nekriptiranih SQLite baza na lokaciji /data/data/com.android.chrome/app_chrome/Default kao što se može vidjeti na Slika 18

Slika 18: Korisnički podaci i lozinke spremljene u običnome tekstu

U slučaju da zloćudan korisnik ili aplikacija eskalalira privilegije pristupa podacima ili administratorskog pristupa zloćudne aplikacije svi osjetljivi podaci korisnika su dostupni bez ikakve enkripcije, te bi bilo preporučeno napraviti obfuskaciju i enkripciju osjetljivih podataka kao preventivnu mjeru zaštite od zloćudnih napada.

Zloćudne skripte

Kako bi demonstrirali način rada zloćudnih skripti i krađe osjetljivih podataka kreirana je osnovna skripta koja datoteku s osjetljivim podacima uploada na komandni server (Slika 19). Skripta je kreirana po uzoru na prethodno pronađeni i popravljeni propust [Cannon, 2011]. Nakon što skripta dohvati ciljanu datoteku i pokrene upload na server, server prihvaća primljene podatke te ih sprema u obliku JSON polja unutar datoteke payload.txt na samome serveru (Slika 5.6).

komandi server Osjetljiva datoteka

Slika 19: Zloćudna payload skripta

Slika 20: Komandi server skripta

Ako bi zloćudni korisnik kreirao aplikaciju koja traži dopuštenja:

• Pisanje/čitanje na vanjsku memoriju
• Internet dopuštenja

mogao bi pretražiti vanjsku memoriju u svrhu pronalaska osjetljivih podataka; mnogi korisnici aplikacije prebacuju na SD karticu iz raznih razloga, najčešće je to ušteda interne memorije, no na ovaj način aplikacije izlažu osjetljive podatke koji nisu zaštićeni od raznih napada. Nakon što aplikacija pronađe datoteku s osjetljivim podacima primjerice: certifikati, backup kontakata, fotografije i sl. Aplikacija zloćudnu skriptu kreira u direktoriju ciljane datoteke, na ovaj način zaobilazi se Same Origin Policy zaštita te skripta može učitati i uploadati ciljane datoteke na udaljeni server. Primjerice na Slika 21 može se vidjeti krađa kontakata i sms poruka koja se nalazi u backup datoteci „sms_20131221191957.xml“. Datoteka je spremljena u XML formatu te je skripta učitava i šalje na udaljeni server; server zatim prima ukradenu datoteku i sprema je u novu datoteku s nazivom payload.txt u JSON formatu. Moguće je uplodati više datoteka odjednom te skripta uspješno radi na Google Chrome i Firefox pregledniku. Važno je napomenuti da je prethodno spomenute tehnike moguće izvršiti i samo s zloćudnom aplikacijom koja ima internet dopuštenja i dopuštenje za rad s memorijom. Na ovaj način aplikacija direktno čita i uploada osjetljive datoteke na komandni server, no primjer sa skriptom pokazuje kako je moguće uploadati različite datoteke i uz pomoć preglednika. Kako su određeni preglednici pokazali mogućnost „šetanja“ kroz osjetljive direktorije, postoji rizik izvršavanja skripti unutar konteksta samog preglednika te krađe osjetljivih podataka iz više zaštićenih direktorija u slučaju da se pronađe određeni propust unutar preglednika koji bi omogućavao upravljanje skriptama i zapisivanje datoteka zaobilaskom politike istog izvora (eng. Same Origin Policy) kao što je već prethodno pronađeno u propustu od strane ViaForensics (2013) kojeg je Mozilla ispravila.

Slika 21: Prikaz ukradenih podataka

ZAKLJUČAK

Kao što se može vidjeti iz prethodno navedenih propusta i njihovih zakrpa, Android sustav je relativno zaštićen od raznih zloćudnih napada. Koristeći dugo ustanovljene standarde sigurnosti SELinux jezgre te dodatnih mehanizama zaštite pristupa osjetljivim podacima kao što su pružatelji sadržaja (eng. Content Provider) platforma je zaštićena od osnovnih napadačkih tehnika. No, u slučaju instalacije aplikacija koje su nesigurne te sadržavaju sigurnosne propuste, a posjeduju prava pristupa osjetljivim podacima, dovodi do nesigurnosti cijelog sustava.

Ove probleme i rizike sustav pokušava umanjiti prikazom sigurnosnih zahtjeva, odnosno prava pristupa aplikacije prije njene instalacije; na ovaj način korisnik ima veliku kontrolu nad aplikacijama koje instalira. Osim prikaza traženih dopuštenja aplikacije, Google Play sadrži i komentare zajednice na određenu aplikaciju te korisnik iz komentara drugih korisnika može uvidjeti kvalitetu, probleme i nesigurnost određenih aplikacija koje želi instalirati.

U ovisnosti o verziji Android sustava sigurnost se inkrementalno poboljšavala te uz pravilne postavke korisnik može imati visoku razinu zaštite, no razni proizvođači pametnih telefona ne prate trend nadogradnje softvera dovoljno brzo te na taj način izlažu vlastite korisnike sigurnosnim rupama koje napadači mogu iskoristiti. Iz ovih razloga obični korisnici imaju nižu razinu zaštite od naprednijih korisnika koji samostalno nadograđuju sustave.

LITERATURA

1. Android Developers. (2014a). Brand Guidelines. Dostupno 04.03.2014. na http://developer.android.com/distribute/googleplay/promote/brand.html
2. Android Developers. (2014b). Content Providers. Dostupno 12.03.2014. na http://developer.android.com/guide/topics/providers/content-providers.html
3. Android. (2014a). Licenses. Dostupno 04.03.2014. na http://source.android.com/source/licenses.html
4. Android. (2014b). Android Security Overview Guidelines. Dostupno 04.03.2014. na http://source.android.com/devices/tech/security/
5. Android. (2014c). dm-verity on boot. Dostupno 04.03.2014. na http://source.android.com/devices/tech/security/
6. Brähler, S. (2010). Analysis of the Android Architecture. Dostupno 11.03.2014. na http://os.ibds.kit.edu/downloads/sa_2010_braehler-stefan_android-architecture.pdf
7. Corbet, J. (2011). Bringing Android closer to the mainline [LWN.net]. Dostupno 06.03.2014. na https://lwn.net/Articles/472984/
8. Cannon, T. (2011). 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team. Dostupno 15.03.2014. na http://1337day.com/exploit/description/17194
9. Electronic Frontier Foundation (2013). Google Removes Vital Privacy Feature From Android, Claiming Its Release Was Accidental. Dostupno 12.03.2014. na https://www.eff.org/deeplinks/2013/12/google-removes-vital-privacy-features-android-shortly-after-adding-them
10. Goldberg I., Wagner D., Thomas R., i Brewer E. (1996). A Secure Environment for Untrusted Helper Applications (Confining the Wily Hacker). Proceedings of the Sixth USENIX UNIX Security Symposium. Dostupno 04.03.2014. na https://www.usenix.org/legacy/publications/library/proceedings/sec96/full_papers/goldberg/goldberg.pdf
11. Kernelnewbies (2012). Linux 3.3. Dostupno 06.03.2014. na http://kernelnewbies.org/Linux_3.3
12. Thompson, H. S. (2010). What's a URI and why does it matter? Dostupno 12.03.2014. na http://www.ltg.ed.ac.uk/~ht/WhatAreURIs/
13. ViaForensics (2013). How I met Firefox: A tale about chained vulnerabilities – viaForensics Dostupno 15.03.2014. na https://viaforensics.com/mobile-security/chained-vulnerabilities-firefox-android-pimp-browser.html