Stagefright: Exploit-ul care a schimbat Android

Unul dintre cele mai tari puncte ale Android a fost în primul rând natura sa open source, care permite părților interesate să schimbe, să modifice și să redistribuie sistemul de operare într-un mod care să se potrivească nevoilor lor specifice. Dar chiar acest avantaj de a fi open source acționează ca o sabie cu două tăișuri atunci când vine vorba de problemele de malware și securitate. Este mai ușor să găsiți și să corectați defecte atunci când aveți o mulțime de colaboratori capabili la un proiect al cărui cod sursă este disponibil gratuit. Cu toate acestea, rezolvarea problemei la nivel de sursă nu se traduce adesea prin rezolvarea problemei în mâinile consumatorului final. Ca atare, Android nu este alegerea principală atunci când vine vorba de alegerea unui sistem de operare pentru nevoile întreprinderilor sensibile la date.

La Google I/O 2014, Google a dat primul impuls către un ecosistem mai sigur și mai prietenos cu întreprinderile prin lansarea Programul Android For Work. Android For Work a adoptat o abordare cu profil dublu pentru nevoile întreprinderii, prin care administratorii IT puteau crea un profiluri de utilizator distincte pentru angajați - unul concentrat pe muncă, lăsând alte profiluri pentru personalul angajaților utilizare. Prin utilizarea criptării bazate pe hardware și a politicilor gestionate de administrator, datele personale și de lucru au rămas distincte și sigure. Ulterior, Android For Work a primit mai multă atenție în ultimele luni, cu un accent mare pus pe securitatea dispozitivului împotriva programelor malware. De asemenea, Google a plănuit activați criptarea completă a dispozitivului pentru toate dispozitivele care urmau să fie lansate cu Android Lollipop din cutie, dar acest lucru a fost abandonat din cauza problemelor de performanță, mutarea fiind opțională implementată de OEM.

Împingerea pentru un Android sigur nu este în întregime opera lui Google, deoarece Samsung a jucat un rol destul de important în acest sens prin intermediul său. Contribuții KNOX la AOSP, care în cele din urmă Android For Work consolidat. Cu toate acestea, exploatările recente de securitate și vulnerabilitățile din Android indică o sarcină dificilă când vine vorba de popularitate pentru adoptarea întreprinderilor. Un exemplu este recenta vulnerabilitate Stagefright.

Continut:

• Ce este Stagefright?
• Cât de grav este Stagefright?
• Ce face Stagefright diferit de alte „vulnerabilitati masive”?
• Dilema actualizării
• Android, Post-Stagefright
• Note de închidere

Ce este Stagefright?

În termeni simpli, Stagefright este un exploit care utilizează biblioteca de coduri pentru redarea media în Android numită libstagefright. Motorul libstagefright este folosit pentru a executa cod care este primit sub forma unui videoclip rău intenționat prin MMS, necesitând astfel doar numărul de telefon mobil al victimei pentru a efectua un atac cu succes.

Am contactat expertul nostru intern, dezvoltatorul principal recunoscut XDA și administratorul dezvoltatorului pulser_g2 pentru a oferi o explicație mai detaliată.

"În timp ce scriu asta, exploitul [Stagefright] trebuia să fie explicat la BlackHat [Legătură], deși nu există încă diapozitive sau detalii de hârtie albă disponibile.

Prin urmare, dau această explicație mai degrabă ca o idee aproximativă a ceea ce se întâmplă, mai degrabă decât ca o explicație foarte aprofundată, cu acuratețe deplină etc.

Există o serie de erori diferite care formează Stagefright, iar acestea au propriul lor CVE [Vulnerabilități și expuneri comune] numere pentru urmărire:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Din păcate, patch-urile disponibile nu sunt legate direct la fiecare CVE (cum ar trebui să fie), așa că va fi puțin dezordonat de explicat.

1. [CVE-2015-1538]

În codul de manipulare MPEG4, codul de gestionare a metadatelor 3GPP (lucrurile care descriu formatul și alte informații suplimentare, atunci când un videoclip este în format 3GPP) este greșit. Nu a respins metadatele, unde datele erau excesiv de mari, mai degrabă a verificat doar dacă erau prea mici. Acest lucru însemna că era posibil ca un atacator să creeze un fișier „modificat” sau „corupt”, care ar avea o porțiune de metadate mai lungă decât ar trebui.

Una dintre marile provocări în scrierea codului pentru a gestiona datele „neîncrezătoare” (adică de la un utilizator sau din orice alt tip de loc extern codului dvs.) este gestionarea datelor cu lungime variabilă. Videoclipurile sunt un exemplu perfect în acest sens. Software-ul trebuie să aloce memorie dinamic, în funcție de ceea ce se întâmplă.

În acest caz, un buffer este creat ca un pointer către o anumită memorie, dar lungimea matricei către care indică a fost un element prea scurtă. Metadatele au fost apoi citite în această matrice și a fost posibil ca ultima intrare din această matrice să nu fie „nulă” (sau zero). Este important că ultimul element din matrice este zero, deoarece așa software-ul spune că matricea este terminată. Prin posibilitatea de a face ca ultima valoare să fie diferită de zero (deoarece matricea era potențial un element prea mic), codul rău intenționat ar putea fi citit de o altă parte a codului și poate fi citit în prea multe date. În loc să se oprească la sfârșitul acestei valori, ar putea continua să citească alte date pe care nu ar trebui să le citească.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

Cea mai scurtă „dimensiune” posibilă a metadatelor ar trebui să fie de 6 octeți, deoarece este un șir UTF-16. Codul ia dimensiunea valorii întregi și scade 6 din ea. Dacă această valoare ar fi mai mică de 6, scăderea s-ar „încărca” și s-ar încheia și am ajunge la un număr foarte mare. Imaginează-ți dacă poți număra doar de la 0 la 65535, de exemplu. Dacă iei numărul 4 și scazi 6, nu poți coborî sub zero. Deci te întorci la 65535 și numări de acolo. Asta se întâmplă aici!

Dacă a fost primită o lungime mai mică de 6, ar putea duce la decodificarea incorect a cadrelor, deoarece Procesul byteswap folosește variabila len16, a cărei valoare se obține dintr-un calcul care începe cu (mărimea-6). Acest lucru ar putea duce la o operațiune de schimb mult mai mare decât s-a dorit, ceea ce ar schimba valorile din datele cadru într-un mod neașteptat.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

Un mare! Acesta este urât. Există exact opusul acestei ultime probleme - o depășire a numărului întreg, în care un număr întreg poate deveni „prea mare”. Dacă ajungeți la 65535 (de exemplu) și nu puteți număra mai mult, veți trece la 0 în continuare!

Dacă alocați memorie pe baza acestui lucru (care este ceea ce face Stagefright!), veți ajunge cu mult prea puțină memorie alocată în matrice. Când datele au fost introduse în acest lucru, ar putea suprascrie datele fără legătură cu datele controlate de creatorul fișierelor rău intenționate.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Inca una nasoala! Foarte asemănător cu ultimul - un alt întreg overflow, unde o matrice (folosită ca buffer) ar fi prea mică. Acest lucru ar permite suprascrierea memoriei care nu au legătură, ceea ce este din nou rău. Cineva care poate scrie date în memorie poate corupe alte date care nu au legătură și poate să le folosească pentru ca un cod pe care îl controlează să fie rulat de telefonul dvs.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Destul de asemănătoare cu acestea din urmă. O variabilă este utilizată atunci când săriți peste o anumită memorie, iar acest lucru ar putea fi negativ în timpul unei scăderi (ca mai sus). Acest lucru ar duce la o lungime de „sărire” foarte mare, depășind un buffer, dând acces la memorie care nu ar trebui accesată.

(Ref: OmniROM Gerrit)

Există, de asemenea, unele remedieri (potențial) legate care par să fi ajuns și în [Android] 5.1.

(Ref: OmniROM Gerrit)

Acest lucru adaugă verificări pentru a opri problemele cu o remediere de securitate anterioară pentru a adăuga verificări ale limitelor, care pot fi depășite. În C, numerele care pot fi reprezentate ca int semnat sunt stocate ca int semnat. În caz contrar, acestea rămân neschimbate în timpul operațiunilor. În aceste verificări, unele numere întregi ar fi putut fi făcute semnate (mai degrabă decât nesemnate), ceea ce ar reduce valoarea lor maximă mai târziu și ar permite să aibă loc o depășire.

(Ref: OmniROM Gerrit)

Mai multe depășiri de numere întregi (unde numerele sunt prea mici, iar apoi se efectuează scăderea acestor numere, permițându-le să devină negative). Acest lucru duce din nou la un număr mare, mai degrabă decât unul mic, și care provoacă aceleași probleme ca mai sus.

(Ref: OmniROM Gerrit)

Și, în sfârșit, un alt depășire întreg. La fel ca și înainte, este pe cale să fie folosit în altă parte și s-ar putea deborda.

(Ref: OmniROM Gerrit)"

Cât de grav este Stagefright?

Conform postare pe blog publicat de compania-mamă de cercetare, Zimperium Research Labs, exploitul Stagefright expune potențial 95% dintre dispozitivele Android - aproximativ 950 de milioane - la această vulnerabilitate, deoarece afectează dispozitivele care rulează Android 2.2 și sus. Pentru a înrăutăți lucrurile, dispozitivele anterioare Jelly Bean 4.3 sunt expuse „cel mai mare risc”, deoarece acestea nu conțin măsuri de atenuare adecvate împotriva acestui exploit.

În ceea ce privește daunele pe care Stagefright le-ar putea provoca, pulser_g2 a remarcat:

[blockquote author="pulser_g2"]"În sine, Stagefright ar oferi acces utilizatorului sistemului de pe telefon. Ar trebui să ocoliți ASLR (randomizarea aspectului spațiului de adrese) pentru a abuza de el. În acest moment, nu se știe dacă acest lucru a fost realizat sau nu. Acest exploit permite rularea „codului arbitrar” pe dispozitivul dvs. ca utilizator de sistem sau media. Aceștia au acces la sunetul și camera de pe dispozitiv, iar utilizatorul de sistem este un loc grozav pentru a lansa un exploit root. Îți amintești toate exploit-urile uimitoare de root pe care le-ai folosit pentru a-ți roota telefonul?

Acestea ar putea fi utilizate în tăcere pentru a obține root pe dispozitivul dvs.! Cel care are root detine telefonul. Ar trebui să ocolească SELinux, dar TowelRoot a reușit asta, iar PingPong a reușit și el. Odată ce obțin root, totul de pe telefonul tău este deschis pentru ei. Mesaje, chei etc.”[/blockquote]Vorbind despre cele mai defavorizate scenarii, este necesar doar un MMS pentru a livra cod și a declanșa acest exploit. Utilizatorul nici nu este nevoie să deschidă mesajul deoarece multe aplicații de mesagerie preprocesează MMS-ul înainte ca utilizatorul să interacționeze cu acesta. Acest lucru este diferit de atacurile spear-phishing, deoarece utilizatorul ar putea fi complet ignorant la un atac de succes, compromițând toate datele prezente și viitoare din telefon.

Ce face Stagefright diferit de alte „vulnerabilitati masive”?

„Toate vulnerabilitățile prezintă un anumit risc pentru utilizatori. Acesta este deosebit de riscant, deoarece dacă cineva găsește o modalitate de a-l ataca de la distanță (adică posibil, dacă s-a găsit o cale de ocolire a ASLR), ar putea fi declanșată chiar înainte de a realiza că ești sub atac"

Exploatările mai vechi precum Android Installer Hijacking, FakeID, precum și exploit-urile root precum TowelRoot și PingPong necesită interacțiunea utilizatorului la un moment dat pentru a fi executate. Deși sunt încă „exploatări” prin faptul că multe daune pot apărea dacă sunt folosite cu răutate, rămâne faptul că Stagefright teoretic are nevoie doar de numărul de mobil al victimei pentru a-și transforma telefonul într-un troian și, prin urmare, i se acordă atât de multă atenție în ultimul timp. zile.

Cu toate acestea, Android nu este în totalitate la cheremul acestui exploit. Inginerul principal al securității Android, Adrian Ludwig a abordat unele preocupări într-un postare pe Google+:

[blockquote author="Adrian Ludwig"]"Există o presupunere greșită, comună, că orice eroare de software poate fi transformată într-un exploit de securitate. De fapt, majoritatea erorilor nu sunt exploatabile și există multe lucruri pe care Android le-a făcut pentru a îmbunătăți aceste șanse...

Sunt enumerate o listă cu unele dintre acele tehnologii care au fost introduse de la Ice Cream Sandwich (Android 4.0) Aici. Cea mai cunoscută dintre acestea se numește Address Space Layout Randomization (ASLR), care a fost complet finalizată în Android 4.1 cu suport pentru PIE (Position Independent Executables) și este acum pe peste 85% din Android dispozitive. Această tehnologie face mai dificil pentru un atacator să ghicească locația codului, care este necesar pentru a construi un exploit de succes...

Nu ne-am oprit cu ASLR, am adăugat și NX, FortifySource, Read-Only-Relocations, Stack Canaries și multe altele.”[/blockquote]

Cu toate acestea, nu se poate nega că Stagefright este o problemă serioasă pentru viitorul Android și, ca atare, este luată în serios de către părțile interesate implicate. Stagefright a scos în evidență și elefanții albi din cameră – problema fragmentării și a actualizărilor ajungând în sfârșit la consumator.

Dilema actualizării

Apropo de actualizări, este bine să vedem că OEM-urile își asumă responsabilitatea pentru securitatea utilizatorilor, așa cum mulți au promis că îmbunătățirea procesului de actualizare special pentru încorporarea de corecții de securitate și patch-uri pentru exploit-uri precum Stagefright.

Printre primii care au lansat o declarație oficială, Google a promis actualizări lunare de securitate (pe lângă actualizările planificate ale sistemului de operare și ale platformei) pentru majoritatea dispozitivelor sale Nexus, inclusiv Nexus 4, vechi de aproape 3 ani. De asemenea, Samsung a urmat exemplul anunțând că va colabora cu transportatorii și partenerii pentru a implementa un program lunar de actualizare de securitate dar nu a reușit să specifice dispozitivele și detaliile cronologice ale acestei implementări. Acest lucru este interesant, deoarece menționează o abordare „rapidă” a actualizărilor de securitate în colaborare cu transportatorii, astfel încât să putem așteptați-vă actualizări mai frecvente (deși bazate pe securitate, dar sperăm că va accelera și upgrade-urile firmware-ului) pentru operator dispozitive.

Alți OEM care se alătură pachetului includ LG, care se va alătura actualizări lunare de securitate. De asemenea, Motorola a anunțat lista de dispozitive care vor fi actualizate cu remedieri Stagefright, iar lista include aproape toate dispozitivele pe care compania le-a fabricat din 2013. Sony a mai spus asta dispozitivele sale vor primi în curând patch-urile de asemenea.

Pentru o dată, transportatorii sunt și ei la îndemână cu actualizări. Sprint are a emis o declarație că unele dispozitive au primit deja patch-ul Stagefright, cu mai multe dispozitive programate pentru actualizare. AT&T a urmat și el exemplul prin emiterea patch-ului pe unele dispozitive. Verizon a lansat, de asemenea, patch-uri, deși aceasta este o lansare lentă care dă prioritate smartphone-urilor de ultimă generație, cum ar fi Galaxy S6 Edge și Note 4. T-Mobile Note 4 a primit și o actualizare a patch-ului Stagefright.

În calitate de utilizator final, există câțiva pași de precauție care pot fi luati pentru a vă reduce șansele de a fi atacat. Pentru început, dezactivați preluarea automată a mesajelor MMS în aplicațiile de mesagerie prezente pe telefon. Acest lucru ar trebui să țină sub control cazurile în care nu a fost necesară nicio interacțiune a utilizatorului pentru ca exploitul să funcționeze. După aceasta, aveți grijă să evitați descărcarea conținutului media din mesajele MMS din surse necunoscute și de încredere.

În calitate de utilizator cu putere XDA, puteți, de asemenea faceți editări pe suportul de construcție pentru a dezactiva Stagefright. Aceasta nu este o modalitate completă și sigură de a vă salva de Stagefright, dar vă puteți profita de șansele de a reduce probabilitatea unui atac de succes dacă sunteți blocat pe o versiune Android mai veche. Există, de asemenea, soluții ROM personalizate, dintre care majoritatea sincronizează sursele cu AOSP în mod regulat și, prin urmare, vor avea remedierile Stagefright încorporate. Dacă rulați un rom bazat pe AOSP, este foarte recomandat să actualizați la o versiune mai nouă a ROM-ului care încorporează patch-urile Stagefright. Poți să folosești această aplicație pentru a verifica dacă actualul șofer zilnic este afectat de Stagefright.

Android, Post-Stagefright

Stagefright nu a fost altceva decât un semnal de alarmă față de Android și problema sa de fragmentare, precum și actualizări. Subliniază faptul că nu există un mecanism clar prin care astfel de remedieri critice să poată fi implementate în timp util pe numeroase dispozitive. În timp ce OEM-urile încearcă să lanseze corecții pentru dispozitive, adevărul dur este că majoritatea acestor remedieri se vor limita doar la produsele emblematice recente. Alte dispozitive care nu sunt emblematice și dispozitive mai vechi, cu atât mai puțin de la OEM-uri mai mici, vor continua să fie expuse la asemenea Stagefright.

Această exploatare are un motiv de argint: A atras din nou atenția asupra procesului de actualizare a Android și l-a prezentat într-o lumină care nu va atrage atât de multe companii corporative viitoare spre adoptarea Android pentru uzul întreprinderilor. Pe măsură ce Google lucrează pentru o mai mare adoptare a întreprinderilor, va fi forțat să-și regândească strategia de actualizare și nivelul de control pe care îl oferă OEM-urilor.

Având în vedere că Android M se apropie de lansarea pe piață pe zi ce trece, nu ar fi surprinzător dacă Google ar alege să desprindă din ce în ce mai multe componente ale AOSP în favoarea pachetului său de servicii Play. La urma urmei, acesta este un domeniu pe care Google încă păstrează controlul complet asupra dacă un dispozitiv urmează să fie livrat cu Google Play Store. Acest are propriile sale dezavantaje sub forma înlocuirii zonelor open source cu pereți close source.

Atunci când speculăm viitorul Android, există o posibilitate (foarte mică) ca Google să limiteze și modificările pe care OEM-urile le pot face AOSP. Cu cadru RRO fiind prezent într-o stare funcțională în Android M, Google ar putea restricționa OEM-urile să facă doar modificări cosmetice sub formă de skin-uri RRO. Acest lucru ar trebui să permită o implementare mai rapidă a actualizării, dar ar fi în detrimentul ca OEM-ului să li se refuze oportunitatea de a personaliza complet Android.

O altă rută care ar putea fi o posibilitate ar fi să fie obligatorie pentru toate dispozitivele cu care se expediază Magazin Google Play pentru a primi actualizări de securitate garantate pentru o perioadă de timp fixă, eventual două ani. Cadrul Play Services ar putea fi folosit pentru a verifica prezența unor actualizări și patch-uri importante de securitate, accesul Play Store fiind anulat în caz de neconformitate.

Note de închidere

Aceasta este încă o speculație în cel mai bun caz, deoarece nu există o modalitate elegantă de a rezolva această problemă. În lipsa unei abordări foarte totalitare, vor exista întotdeauna unele deficiențe în ceea ce privește soluțiile. Datorită numărului mare de dispozitive Android, urmărirea stării securității fiecărui dispozitiv ar fi o sarcină foarte gigantică. Necesitatea orei este o regândire a modului în care se actualizează Android, deoarece modul actual nu este cu siguranță cel mai bun. Noi, cei de la XDA Developers, sperăm că Android continuă să rămână fidel rădăcinilor sale Open-Source în timp ce lucrează împreună cu planurile de sursă închisă ale Google.

Este telefonul dumneavoastră vulnerabil la Stagefright? Crezi că telefonul tău va primi vreodată un patch Stagefright? Spune-ne în comentariile de mai jos!