Stagefright je jedan od najgorih iskorištavanja koje je Android u posljednje vrijeme vidio. Kliknite kako biste pročitali više o pojedinostima i saznali kako se zaštititi!
Jedna od najjačih strana Androida prvenstveno je bila njegova priroda otvorenog koda, koja dionicima omogućuje račvanje, modificiranje i redistribuciju OS-a na način koji odgovara njihovim posebnim potrebama. Ali sama ta prednost otvorenog izvornog koda djeluje poput dvosjeklog mača kada je riječ o problemima zlonamjernog softvera i sigurnosti. Lakše je pronaći i popraviti nedostatke kada imate mnogo sposobnih suradnika na projektu čiji je izvorni kod besplatno dostupan. Međutim, rješavanje problema na razini izvora često se ne pretvara u rješavanje problema u rukama krajnjeg korisnika. Kao takav, Android nije glavni izbor kada se radi o odabiru OS-a za poslovne potrebe osjetljive na podatke.
Na Google I/O 2014. Google je dao svoj prvi poticaj ka sigurnijem ekosustavu prilagođenom poduzećima pokretanjem Program Android For Work
. Android For Work usvojio je pristup dvostrukog profila za potrebe poduzeća, pri čemu IT administratori mogu stvoriti različiti korisnički profili za zaposlenike - jedan usmjeren na posao, ostavljajući druge profile za osobne profile zaposlenika koristiti. Upotrebom hardverske enkripcije i pravila kojima upravlja administrator, radni i osobni podaci ostali su različiti i sigurni. Nakon toga, Android For Work dobio je više pažnje u kasnijim mjesecima, s velikim fokusom na sigurnost uređaja od zlonamjernog softvera. Google je također planirao omogućiti punu enkripciju uređaja za sve uređaje koji su trebali biti objavljeni s Androidom Lollipop odmah po izlasku iz kutije, ali je to odbačeno zbog problema s performansama, pa je ovaj potez postao opcionalan za implementaciju OEM-a.Poticanje sigurnog Androida nije u potpunosti djelo Googlea, budući da je Samsung odigrao značajnu ulogu u tome putem svojih KNOX doprinosi AOSP-u, što u konačnici ojačani Android For Work. Međutim, nedavna sigurnosna iskorištavanja i ranjivosti u Androidu ukazuju na težak zadatak kada je riječ o popularnosti za prihvaćanje u poduzećima. Primjer je nedavna ranjivost Stagefrighta.
Sadržaj:
- Što je Stagefright?
- Koliko je Stagefright ozbiljan?
- Po čemu se Stagefright razlikuje od ostalih "masovnih ranjivosti"?
- Dilema ažuriranja
- Android, Post-Stagefright
- Završne bilješke
Što je Stagefright?
Jednostavno rečeno, Stagefright je eksploatacija koja koristi biblioteku koda za reprodukciju medija u Androidu tzv libstagefright. Motor libstagefright koristi se za izvršavanje koda koji se prima u obliku zlonamjernog videa putem MMS-a, stoga je za uspješan napad potreban samo broj mobilnog telefona žrtve.
Obratili smo se našem internom stručnjaku, XDA Senior Recognised Developeru i Developer Admin-u pulser_g2 dati detaljnije objašnjenje.
"Dok ovo pišem, [Stagefright] exploit je trebao biti objašnjen u BlackHatu [Veza], iako još nema dostupnih slajdova ili pojedinosti o bijelom papiru.
Stoga ovo objašnjenje dajem više kao grubu ideju o tome što se događa, a ne kao vrlo detaljno objašnjenje s punom točnošću itd.
Postoji niz različitih grešaka koje čine Stagefright, a one imaju vlastiti CVE [Uobičajene ranjivosti i izloženosti] brojevi za praćenje:
- CVE-2015-1538
- CVE-2015-1539
- CVE-2015-3824
- CVE-2015-3826
- CVE-2015-3827
- CVE-2015-3828
- CVE-2015-3829
Nažalost, zakrpe koje su dostupne nisu izravno povezane sa svakim CVE-om (kao što bi trebale biti), tako da će ovo biti malo neuredno za objašnjavanje.
1. [CVE-2015-1538]
U kodu za rukovanje MPEG4, kod za rukovanje 3GPP metapodacima (stvari koje opisuju format i druge dodatne informacije, kada je video u 3GPP formatu) ima pogreške. Nije odbijao metapodatke, gdje su podaci bili pretjerano veliki, nego je samo provjeravao jesu li premali. To je značilo da napadač može izraditi "modificiranu" ili "oštećenu" datoteku, koja bi imala duži dio metapodataka nego što bi trebao.
Jedan od velikih izazova u pisanju koda za rukovanje "nepouzdanim" podacima (tj. od korisnika ili s bilo koje druge vrste mjesta izvan vašeg koda) je rukovanje podacima varijabilne duljine. Videozapisi su savršen primjer za to. Softver treba dinamički dodijeliti memoriju, ovisno o tome što se događa.
U ovom slučaju, međuspremnik je kreiran kao pokazivač na neku memoriju, ali je duljina niza na koji pokazuje bila jedan element prekratka. Metapodaci su tada učitani u ovaj niz i bilo je moguće da zadnji unos u ovom nizu ne bude "nula" (ili nula). Važno je da je posljednja stavka u nizu nula, jer tako softver govori da je niz završen. Mogućnost da posljednja vrijednost bude različita od nule (budući da je niz potencijalno bio jedan element premalen), zlonamjerni kôd mogao bi pročitati drugi dio koda i učitati previše podataka. Umjesto da se zaustavi na kraju ove vrijednosti, mogao bi nastaviti čitati druge podatke koje ne bi trebao čitati.
(Ref: OmniROM Gerrit)
2. [CVE-2015-1539]
Najkraća moguća "veličina" metapodataka trebala bi biti 6 bajtova, jer se radi o nizu UTF-16. Kod uzima veličinu cjelobrojne vrijednosti i od nje oduzima 6. Ako je ta vrijednost manja od 6, oduzimanje bi se "ispustilo" i završilo, a mi bismo završili s vrlo velikim brojem. Zamislite da možete brojati samo od 0 do 65535, na primjer. Ako uzmete broj 4 i oduzmete 6, ne možete ići ispod nule. Dakle, vratite se na 65535 i brojite od tamo. To se ovdje događa!
Ako je primljena duljina manja od 6, to bi moglo dovesti do netočnog dekodiranja okvira, jer byteswap proces koristi varijablu len16, čija se vrijednost dobiva iz izračuna koji počinje s (veličina-6). To bi moglo uzrokovati mnogo veću operaciju zamjene od planirane, što bi promijenilo vrijednosti u podacima okvira na neočekivani način.
(Ref: OmniROM Gerrit)
3. [CVE-2015-3824]
velika stvar! Ovaj je gadan. Postoji upravo suprotno od ovog posljednjeg problema - prekoračenje cijelog broja, gdje cijeli broj može postati "prevelik". Ako dosegnete 65535 (na primjer) i ne možete brojati više, otkotrljat ćete se i prijeći na 0 sljedeći!
Ako memoriju dodjeljujete na temelju toga (što Stagefright radi!), završili biste s premalo memorije dodijeljene u nizu. Kada se podaci stave u ovo, potencijalno bi prebrisali nepovezane podatke s podacima koje kontrolira kreator zlonamjerne datoteke.
(Ref: OmniROM Gerrit)
4. [CVE-2015-3826]
Još jedan gadan! Vrlo slično prethodnom - još jedno prekoračenje cijelog broja, gdje bi niz (koji se koristi kao međuspremnik) bio premalen. To bi omogućilo prebrisanje nepovezane memorije, što je opet loše. Netko tko može zapisivati podatke u memoriju može pokvariti druge nepovezane podatke i potencijalno to iskoristiti da vaš telefon pokrene neki kod koji kontrolira.
(Ref: OmniROM Gerrit)
5. [CVE-2015-3827]
Dosta slično ovim zadnjima. Varijabla se koristi kada se preskače neka memorija, a to može biti negativno tijekom oduzimanja (kao gore). To bi rezultiralo vrlo velikom duljinom "preskakanja", prekoračenjem međuspremnika, dajući pristup memoriji kojoj se ne bi trebalo pristupati.
(Ref: OmniROM Gerrit)
Postoje i neki (potencijalno) povezani popravci za koje se čini da su također ušli u [Android] 5.1.
(Ref: OmniROM Gerrit)
Ovo dodaje provjere za zaustavljanje problema s prošlim sigurnosnim popravkom kako bi se dodale provjere granica, koje se same mogu prekoračiti. U C-u, brojevi koji se mogu predstaviti kao int s predznakom pohranjuju se kao int s predznakom. Inače ostaju nepromijenjeni tijekom rada. U tim provjerama, neki cijeli brojevi su mogli biti označeni (umjesto nepredpisani), što bi kasnije smanjilo njihovu maksimalnu vrijednost i omogućilo prekoračenje.
(Ref: OmniROM Gerrit)
Još neki cjelobrojni podljevi (gdje su brojevi preniski, a zatim se na tim brojevima provodi oduzimanje, dopuštajući im da postanu negativni). Ovo opet dovodi do velikog broja, a ne malog, a to uzrokuje iste probleme kao gore.
(Ref: OmniROM Gerrit)
I na kraju, još jedan cjelobrojni overflow. Kao i prije, uskoro će se koristiti negdje drugdje i moglo bi se preliti.
(Ref: OmniROM Gerrit)"
Koliko je Stagefright ozbiljan?
Prema post na blogu koje je objavila matična istraživačka tvrtka, Zimperium Research Labs, eksploatacija Stagefright potencijalno otkriva 95% Android uređaja - otprilike 950 milijuna - izloženo je ovoj ranjivosti jer utječe na uređaje s Androidom 2.2 i gore. Da stvar bude gora, uređaji prije Jelly Bean 4.3 su u "najgorem riziku" jer ne sadrže odgovarajuća sredstva za ublažavanje ovog iskorištavanja.
Što se tiče štete koju bi Stagefright mogao nanijeti, pulser_g2 je primijetio:
[blockquote author="pulser_g2"]"Sama po sebi, Stagefright bi omogućila pristup korisniku sustava na telefonu. Morali biste zaobići ASLR (randomizacija rasporeda adresnog prostora) da biste ga zapravo zlorabili. Za sada nije poznato je li to postignuto. Ovaj exploit omogućuje pokretanje "proizvoljnog koda" na vašem uređaju kao korisniku sustava ili medija. Oni imaju pristup zvuku i kameri na uređaju, a korisnik sustava je odlično mjesto za pokretanje root exploita. Sjećate li se svih nevjerojatnih root-a koje ste koristili za rootanje telefona?
One bi se potencijalno mogle tiho koristiti za dobivanje roota na vašem uređaju! Tko ima root, posjeduje telefon. Morali bi zaobići SELinux, ali TowelRoot je to uspio, a PingPong je također uspio. Nakon što dobiju root, sve na vašem telefonu im je otvoreno. Poruke, ključevi itd."[/blockquote]Govoreći o najgorem scenariju, samo je MMS potreban za isporuku koda i pokretanje ovog iskorištavanja. Korisnik ne mora niti otvoriti poruku budući da mnoge aplikacije za razmjenu poruka unaprijed obrađuju MMS prije nego korisnik stupi u interakciju s njim. Ovo se razlikuje od spear-phishing napada jer korisnik može biti potpuno nesvjestan uspješnog napada, ugrožavajući sve sadašnje i buduće podatke u telefonu.
Po čemu se Stagefright razlikuje od ostalih "masovnih ranjivosti"?
"Sve ranjivosti predstavljaju određeni rizik za korisnike. Ovaj je posebno riskantan, jer ako netko pronađe način da ga napadne daljinski (što je moguće, ako je pronađen način zaobilaženja ASLR-a), mogao bi se pokrenuti prije nego što uopće shvatite da ste ispod napad"
Starije eksploatacije kao što su Android Installer Hijacking, FakeID kao i root eksploatacije kao što su TowelRoot i PingPong zahtijevaju interakciju korisnika u nekom trenutku kako bi se izvršile. Iako su još uvijek "iskorištavanje" u činjenici da mnogo štete može nastati ako se koristi zlonamjerno, ostaje činjenica da Stagefright teoretski treba samo broj mobilnog telefona žrtve da pretvori njihov telefon u trojanca i stoga mu se u posljednje vrijeme pridaje toliko pozornosti dana.
Međutim, Android nije u potpunosti prepušten na milost i nemilost ovom iskorištavanju. Vodeći inženjer sigurnosti Androida, Adrian Ludwig iznio je neke nedoumice u a Google+ post:
[blockquote author="Adrian Ludwig"]"Postoji uobičajena, pogrešna pretpostavka da se svaka softverska greška može pretvoriti u sigurnosnu eksploataciju. Zapravo, većinu grešaka nije moguće iskoristiti i postoji mnogo stvari koje je Android učinio da poboljša te šanse...
Naveden je popis nekih od tih tehnologija koje su uvedene od Ice Cream Sandwicha (Android 4.0) ovdje. Najpoznatiji od njih zove se Randomizacija rasporeda adresnog prostora (ASLR), koji je u potpunosti dovršen u Androidu 4.1 s podrškom za PIE (Position Independent Executables) i sada je na više od 85% Androida uređaja. Ova tehnologija otežava napadaču da pogodi lokaciju koda, što je potrebno za izgradnju uspješne eksploatacije...
Nismo stali s ASLR-om, dodali smo i NX, FortifySource, Read-Only-Relocations, Stack Canaries i još mnogo toga."[/blockquote]
Međutim, i dalje se ne može poreći da je Stagefright ozbiljna stvar za budućnost Androida i da ga kao takvog ozbiljno shvaćaju uključeni dionici. Stagefright je također istaknuo bijele slonove u prostoriji - problem fragmentacije i ažuriranja koja konačno dolaze do korisnika.
Dilema ažuriranja
Govoreći o ažuriranjima, dobro je vidjeti da OEM-ovi preuzimaju odgovornost za sigurnost korisnika, kao što su mnogi obećali poboljšati proces ažuriranja posebno za ugradnju sigurnosnih popravaka i zakrpa za eksploatacije kao što je Stagefright.
Google je obećao da će među prvima objaviti službenu izjavu mjesečna sigurnosna ažuriranja (uz planirana ažuriranja OS-a i platforme) za većinu svojih Nexus uređaja, uključujući gotovo 3 godine star Nexus 4. Samsung je također slijedio taj primjer najavivši da će surađivati s operaterima i partnerima na implementaciji a mjesečni program sigurnosnog ažuriranja ali nije uspio navesti pojedinosti o uređajima i vremenskom slijedu ove implementacije. Ovo je zanimljivo jer spominje "brzi" pristup sigurnosnim ažuriranjima u suradnji s operaterima, tako da možemo očekujte češća ažuriranja (iako temeljena na sigurnosti, ali nadamo se da će ubrzati i nadogradnje firmvera) na operateru uređaja.
Ostali OEM-ovi koji se pridružuju paketu uključuju LG koji će se pridružiti mjesečna sigurnosna ažuriranja. Motorola je također najavila popis uređaja koji će se ažurirati sa Stagefright popravcima, a popis uključuje gotovo sve uređaje koje je tvrtka napravila od 2013. godine. Sony je također to rekao njegovi će uređaji uskoro dobiti zakrpe isto.
Jednom, operateri također dolaze s ažuriranjima. Sprint ima izdao priopćenje da su neki uređaji već primili zakrpu za Stagefright, a ažuriranje je planirano za više uređaja. AT&T je također slijedio primjer izdavanjem zakrpe za neke uređaje. Verizon je također izdao zakrpe, iako je ovo sporo uvođenje koje daje prioritet vrhunskim pametnim telefonima kao što su Galaxy S6 Edge i Note 4. T-Mobile Note 4 također je dobio ažuriranu zakrpu za Stagefright.
Kao krajnji korisnik, postoji nekoliko mjera opreza koje možete poduzeti kako biste smanjili svoje šanse za napad. Za početak, onemogućite automatsko dohvaćanje MMS poruka u aplikacijama za razmjenu poruka na vašem telefonu. Ovo bi trebalo držati pod kontrolom slučajeve u kojima nije bila potrebna interakcija korisnika da bi eksploatacija funkcionirala. Nakon toga pripazite da izbjegnete preuzimanje medija iz MMS poruka iz nepoznatih i nepouzdanih izvora.
Kao napredni korisnik XDA, također možete uredite svoj rekvizit za izgradnju kako biste onemogućili Stagefright. Ovo nije potpun i siguran način da se spasite od Stagefrighta, ali možete iskoristiti svoje šanse i smanjiti vjerojatnost uspješnog napada ako ste zapeli na starijoj verziji Androida. Postoje i prilagođena ROM rješenja, od kojih većina redovito sinkronizira izvore s AOSP-om i stoga će imati ugrađene popravke za Stagefright. Ako koristite ROM koji se temelji na AOSP-u, preporučuje se ažuriranje na novije izdanje ROM-a koje uključuje zakrpe za Stagefright. Možeš koristiti ovu aplikaciju kako biste provjerili utječe li Stagefright na vaš trenutni dnevni vozač.
Android, Post-Stagefright
Stagefright nije ništa drugo nego poziv na buđenje prema Androidu i njegovom problemu fragmentacije, kao i ažuriranja. Naglašava kako ne postoji jasan mehanizam putem kojeg bi se takvi kritični popravci mogli pravodobno uvesti na brojne uređaje. Dok OEM-ovi pokušavaju izbaciti zakrpe za uređaje, surova je istina da će većina tih popravaka biti ograničena samo na najnovije vodeće uređaje. Drugi ne-vodeći i stariji uređaji, a još manje od manjih OEM-a, i dalje će biti izloženi Stagefrightu.
Ovo podvig ima dobre strane: Ponovno je skrenuo pozornost na proces ažuriranja Androida i predstavio ga u svjetlu koje neće privući toliko budućih korporativnih tvrtki da usvoje Android za poslovne potrebe. Dok Google radi na većem prihvaćanju za poduzeća, bit će prisiljen ponovno razmisliti o svojoj strategiji ažuriranja i količini kontrole koju dopušta OEM-ovima.
Budući da se Android M svakim danom približava tržišnom izdanju, ne bi bilo iznenađenje da Google odluči odvojiti sve više komponenti AOSP-a u korist svog paketa usluga Play. Uostalom, to je jedno područje nad kojim Google još uvijek ima potpunu kontrolu ako se uređaj isporučuje uz Google Play Store. Ovaj ima svoje loše strane u obliku zamjene otvorenih područja s zatvorenim zidovima.
Kada se nagađa o budućnosti Androida, postoji (vrlo mala) mogućnost da Google također može ograničiti promjene koje OEM-ovi mogu napraviti na AOSP-u. s RRO okvir Budući da je prisutan u funkcionalnom stanju u Androidu M, Google bi mogao ograničiti OEM-ove na samo kozmetičke promjene u obliku RRO skinova. To bi trebalo omogućiti bržu implementaciju ažuriranja, ali bi bilo po cijenu da OEM-ovi budu uskraćeni za priliku da u potpunosti prilagode Android.
Još jedan put koji bi mogao biti moguć bio bi da bude obavezan za sve uređaje koji se isporučuju s njima Google Play Store za primanje zajamčenih sigurnosnih ažuriranja na određeno vremensko razdoblje, moguće dva godine. Okvir Play Services mogao bi se koristiti za provjeru prisutnosti važnih sigurnosnih ažuriranja i zakrpa, pri čemu bi se pristup Trgovini Play poništio u slučaju neusklađenosti.
Završne bilješke
To su u najboljem slučaju još uvijek nagađanja jer ne postoji elegantan način za rješavanje ovog problema. Osim vrlo totalitarnog pristupa, uvijek će postojati neki nedostaci u dosegu popravaka. Zbog ogromnog broja Android uređaja, praćenje statusa sigurnosti svakog uređaja bio bi vrlo velik zadatak. Trenutačna potreba je preispitivanje načina ažuriranja Androida budući da trenutni način sigurno nije najbolji. Mi u XDA Developersu nadamo se da će Android i dalje ostati vjeran svojim korijenima otvorenog koda dok radi u skladu s Googleovim planovima zatvorenog koda.
Je li vaš telefon osjetljiv na Stagefright? Mislite li da će vaš telefon ikada dobiti zakrpu za Stagefright? Javite nam u komentarima ispod!