O defecțiune critică la procesoarele MediaTek a fost necorecţionată în dispozitive din cauza neglijării OEM. Google speră că Buletinul de securitate Android din martie 2020 va rezolva acest lucru.
În prima zi de luni a fiecărei luni, Google publică Buletin de securitate Android, o pagină care dezvăluie toate vulnerabilitățile de securitate și corecțiile acestora trimise de Google înșiși sau de alte terțe părți. Astăzi nu a făcut excepție: Google tocmai a făcut public Buletinul de securitate Android pentru martie 2020. Una dintre vulnerabilitățile care sunt documentate în cel mai recent buletin este CVE-2020-0069, un exploit critic de securitate, în special un rootkit, care afectează milioane de dispozitive cu chipset-uri de la MediaTek, marea companie taiwaneză de design de cipuri. Deși Buletinul de securitate Android din martie 2020 este aparent prima dată când CVE-2020-0069 a fost dezvăluit public, detaliile despre exploatare au fost de fapt deschise pe Internet - mai precis, pe forumurile XDA-Developers - din aprilie din 2019. În ciuda faptului că MediaTek a făcut disponibil un patch la o lună de la descoperire, vulnerabilitatea este încă exploatabilă pe zeci de modele de dispozitive.
Și mai rău, vulnerabilitatea este exploatată în mod activ de hackeri. Acum, MediaTek a apelat la Google pentru a închide această breșă de corecție și pentru a securiza milioane de dispozitive împotriva acestui exploit critic de securitate.Pentru toți cititorii care nu sunt familiarizați XDA-Developers, suntem un site care găzduiește cele mai mari forumuri pentru modificări ale software-ului Android. De obicei, aceste modificări se concentrează pe obținerea accesului root pe dispozitive pentru a șterge bloatware, a instala software personalizat sau a modifica parametrii impliciti de sistem. Tabletele Amazon Fire sunt ținte populare pentru hackerii amatori pe forumurile noastre - sunt pline de dezinstalabile bloatware, nu au acces la aplicații software de bază precum Google Play Store și, cel mai important, sunt foarte ieftin. Provocarea cu înrădăcinarea tabletelor Amazon Fire este că acestea sunt puternic blocate pentru a împiedica utilizatorii să iasă din grădina cu ziduri a Amazon; Amazon nu oferă o metodă oficială pentru a debloca bootloader-ul tabletelor Fire, care este de obicei primul pas în rootarea oricărui dispozitiv Android. Prin urmare, singura modalitate de a roota o tabletă Amazon Fire (fără modificări hardware) este să găsești un exploit în software care să permită utilizatorului să ocolească modelul de securitate al Android. În februarie 2019, asta este exact ceea ce a făcut diplomatul XDA Senior Member când a publicat un thread pe forumurile noastre pentru tablete Amazon Fire. El și-a dat repede seama că această exploatare era mult mai largă în domeniul de aplicare decât doar tabletele Amazon Fire.
După câteva teste de la membrii diplomatici XDA Member și alți membri ai comunității, a fost confirmat că acest exploit funcționează pe un număr mare de cipuri MediaTek. Autorul afirmă că exploitul funcționează pe „practic toate cipurile pe 64 de biți ale MediaTek” și le numesc în mod specific pe următoarele ca fiind vulnerabile: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT88163, MT88163, MT88163 580 și MT6595. Din cauza numărului de chipset-uri MediaTek afectate de acest exploit, exploit-ul a primit numele „MediaTek-su” sau „MTK-su”, pe scurt. Pe 17 aprilie 2019, diplomatic a publicat un al doilea subiect intitulat „Amazing Temp Root pentru MediaTek ARMv8" pe forumul nostru "Dezvoltare Android Diverse". În acest thread, el a împărtășit un script pe care utilizatorii îl pot executa pentru a le acorda acces superutilizator în shell, precum și pentru a seta SELinux, modulul nucleului Linux care oferă controlul accesului pentru procese, „permisivului” extrem de nesigur. stat. Pentru ca un utilizator să obțină acces root și să seteze SELinux la permisiv pe propriul dispozitiv este șocant de ușor de făcut: tot ce trebuie să faci este să copiați scriptul într-un folder temporar, schimbați directoarele în care este stocat scriptul, adăugați permisiuni executabile la script și apoi executați scenariu.
Membrii comunității XDA au confirmat că exploitul a funcționat pe cel puțin următoarele dispozitive:
- Acer Iconia One 10 B3-A30
- Acer Iconia One 10 B3-A40
- seria de tablete Alba
- Seria Alcatel 1 5033
- Alcatel 1C
- Seria Alcatel 3L (2018) 5034
- Alcatel 3T 8
- Seria Alcatel A5 LED 5085
- Seria Alcatel A30 5049
- Alcatel Idol 5
- Alcatel/TCL A1 A501DL
- Alcatel/TCL LX A502DL
- Alcatel Tetra 5041C
- Amazon Fire 7 2019 -- numai până la Fire OS 6.3.1.2 versiunea 0002517050244
- Amazon Fire HD 8 2016 -- numai până la Fire OS 5.3.6.4 versiunea 626533320
- Amazon Fire HD 8 2017 -- numai până la Fire OS 5.6.4.0 build 636558520
- Amazon Fire HD 8 2018 -- numai până la Fire OS 6.3.0.1
- Amazon Fire HD 10 2017 -- numai până la Fire OS 5.6.4.0 build 636558520
- Amazon Fire HD 10 2019 -- numai până la Fire OS 7.3.1.0
- Amazon Fire TV 2 -- numai până la Fire OS 5.2.6.9
- ASUS ZenFone Max Plus X018D
- ASUS ZenPad 3s 10 Z500M
- Seria bazată pe ASUS ZenPad Z3xxM(F) MT8163
- Barnes & Noble Tabletă NOOK 7" BNTV450 și BNTV460
- Tabletă Barnes & Noble NOOK 10.1" BNTV650
- Blackview A8 Max
- Blackview BV9600 Pro (Helio P60)
- BLU Life Max
- BLU Life One X
- Seria BLU R1
- BLU R2 LTE
- BLU S1
- BLU Tank Xtreme Pro
- BLU Vivo 8L
- BLU Vivo XI
- BLU Vivo XL4
- Bluboo S8
- BQ Aquaris M8
- CAT S41
- Coolpad Cool Play 8 Lite
- Dragon Touch K10
- Echo Feeling
- Gionee M7
- HiSense Infinity H12 Lite
- Huawei GR3 TAG-L21
- Huawei Y5II
- Seria Huawei Y6II MT6735
- Lava Iris 88S
- Seria Lenovo C2
- Lenovo Tab E8
- Lenovo Tab2 A10-70F
- LG K8+ (2018) X210ULMA (MTK)
- LG K10 (2017)
- LG Tribute Dynasty
- LG X power 2/Seria M320 (MTK)
- LG Xpression Plus 2/K40 seria LMX420
- Lumigon T3
- Meizu M5c
- Meizu M6
- Meizu Pro 7 Plus
- Nokia 1
- Nokia 1 Plus
- Nokia 3
- Nokia 3.1
- Nokia 3.1 Plus
- Nokia 5.1
- Nokia 5.1 Plus/X5
- Pe tabletă Android de 7 inchi
- Seria de tablete Onn de 8" și 10" (MT8163)
- OPPO A5s
- Seria OPPO F5/A73 -- numai Android 8.x
- Seria OPPO F7 -- numai Android 8.x
- Seria OPPO F9 -- numai Android 8.x
- Oukitel K12
- Protruly D7
- Realme 1
- Sony Xperia C4
- seria Sony Xperia C5
- Sony Xperia L1
- Sony Xperia L3
- seria Sony Xperia XA
- seria Sony Xperia XA1
- Southern Telecom Smartab ST1009X (MT8167)
- Seria TECNO Spark 3
- Seria Umidigi F1
- Puterea Umidigi
- Wiko Ride
- Wiko Sunny
- Wiko View3
- Seria Xiaomi Redmi 6/6A
- ZTE Blade A530
- ZTE Blade D6/V6
- ZTE Quest 5 Z3351S
citeşte mai mult
Cu excepția telefoanelor bazate pe MediaTek de la Vivo, Huawei/Honor (după Android 8.0+), OPPO (după Android 8.0+) și Membrii comunității Samsung, XDA au descoperit că MediaTek-su funcționează cel mai des atunci când este încercat pe dispozitive afectate chipset-uri. Potrivit diplomației membre XDA, dispozitivele Vivo, Huawei/Honor, OPPO și Samsung „utiliză modificări ale nucleului pentru a descuraja accesul la root prin exploatează", ceea ce înseamnă că dezvoltatorul ar trebui să cerceteze codul sursă al nucleului acestor dispozitive pentru a crea „versiuni personalizate” ale exploata. Nu a meritat efortul suplimentar, așa că dezvoltatorul a ales să nu adauge suport pentru aceste dispozitive, chiar dacă, „teoretic”, exploit-ul ar putea încă funcționa.
Până acum, ar trebui să fie clar că această exploatare afectează un număr mare de dispozitive de pe piață. Cipurile MediaTek alimentează sute de modele de smartphone-uri de buget și de gamă medie, tablete ieftine și în afara mărcii set-top box-uri, dintre care majoritatea sunt vândute fără a aștepta actualizări în timp util de la producător. Este puțin probabil ca multe dispozitive încă afectate de MediaTek-su să primească o remediere timp de săptămâni sau luni după dezvăluirea de astăzi, dacă primesc una. Deci, ce face MediaTek-su să câștige severitatea sa „critică” cu a CVSS v3.0 scor 9,3?
De ce MTK-su este o vulnerabilitate critică de securitate
Pentru a reitera, modalitatea tipică de a obține accesul root pe un dispozitiv Android este de a debloca mai întâi bootloader-ul, care dezactivează verificarea partiției de pornire. Odată ce bootloader-ul este deblocat, utilizatorul poate introduce în sistem un binar de superutilizator și, de asemenea, o aplicație de gestionare a superutilizatorului pentru a controla ce procese au acces la root. Deblocarea bootloader-ului înseamnă dezactivarea intenționată a uneia dintre caracteristicile cheie de securitate de pe dispozitiv, motiv pentru care utilizatorul trebuie să permite în mod explicit să se întâmple, activând de obicei o comutare în Opțiuni pentru dezvoltatori și apoi lansând o comandă de deblocare către bootloader. Cu MediaTek-su, totuși, utilizatorul nu trebuie să deblocheze bootloader-ul pentru a obține acces root. În schimb, tot ce trebuie să facă este să copieze un script pe dispozitivul lor și să-l execute în shell. Cu toate acestea, utilizatorul nu este singurul care poate face acest lucru. Orice aplicație de pe telefonul dvs. poate copia scriptul MediaTek-su în directorul lor privat și apoi îl poate executa pentru a obține acces root în shell. De fapt, XDA membru diplomatic evidențiază această posibilitate în firul lor de forum când sugerează un set alternativ de instrucțiuni folosind fie Terminal Emulator pentru aplicația Android sau Termux mai degrabă decât ADB.
Cu acces root, modelul de securitate al Android practic se destramă. De exemplu, permisiunile devin lipsite de sens în contextul root, deoarece o aplicație cu acces la un shell root își poate acorda orice permisiunea dorește. În plus, cu un shell rădăcină, întreaga partiție de date - inclusiv fișierele stocate în directoarele de date private de obicei inaccesibile ale aplicațiilor - este accesibilă. O aplicație cu root poate, de asemenea, să instaleze în tăcere orice altă aplicație pe care o dorește în fundal și apoi să le acorde toate permisiunile de care au nevoie pentru a vă încălca confidențialitatea. Potrivit dezvoltatorului recunoscut XDA topjohnwu, o aplicație rău intenționată poate chiar „injecta cod direct în Zygote folosind ptrace”, ceea ce înseamnă că o aplicație normală de pe dispozitivul tău ar putea fi deturnată pentru a face licitația atacatorului. Aceste exemple se referă doar la câteva moduri prin care o aplicație îți poate încălca încrederea în fundal fără știrea ta. Cu toate acestea, aplicațiile rău intenționate pot face ravagii pe dispozitivul dvs. fără a ascunde ceea ce fac. Ransomware-ul, de exemplu, este extrem puternic cu acces root; dacă nu plătiți, o aplicație ransomware ipotetică ar putea total și ireversibil faceți dispozitivul inoperabil ștergând întregul dispozitiv.
Singura „slăbiciune” din MediaTek-su este că acordă unei aplicații doar acces rădăcină „temporar”, ceea ce înseamnă că un proces pierde accesul superutilizatorului după repornirea dispozitivului. În plus, pe dispozitivele care rulează Android 6.0 Marshmallow și versiuni ulterioare, prezența Verified Boot și dm-verity blocați modificările la partițiile de numai citire, cum ar fi sistemul și furnizorul. Cu toate acestea, acești doi factori sunt în cea mai mare parte doar obstacole pentru modificatorii de pe forumurile noastre, mai degrabă decât pentru actori rău intenționați. Pentru a depăși limitarea rădăcinii temporare, o aplicație rău intenționată poate pur și simplu să re-ruleze scriptul MediaTek-su la fiecare pornire. Pe de altă parte, nu este nevoie să depășim dm-verity, deoarece modificările permanente ale sistemului sau ale partițiilor furnizorului sunt puțin probabil să intereseze majoritatea autorilor de programe malware; la urma urmei, există deja tone dintre lucrurile pe care o aplicație rău intenționată le poate face cu un shell rădăcină.
Dacă vă întrebați la nivel tehnic ce exploatează MediaTek-su, MediaTek ne-a împărtășit graficul de mai jos, care rezumă punctul de intrare. Defectul se pare că există într-unul dintre driverele Linux Kernel ale MediaTek numite „CMDQ”. Descrierea spune că, „prin executarea IOCTL comenzi în [nodul] dispozitivului CMDQ", un atacator local poate "să citească/scrie în mod arbitrar memoria fizică, să transfere [tabelul] simbol al nucleului în tampon DMA pre-alocat, [și] manipulați tamponul DMA pentru a modifica setările kernelului pentru a dezactiva SELinux și a escalada la „rădăcină” privilegiu."
Conform diagramei pe care MediaTek ni l-a distribuit, această vulnerabilitate afectează dispozitivele MediaTek cu versiunile Linux Kernel 3.18, 4.4, 4.9 sau 4.14 care rulează versiunile Android 7 Nougat, 8 Oreo sau 9 Pie. Vulnerabilitatea nu este exploatabilă pe dispozitivele MediaTek care rulează Android 10, aparent, din moment ce „permisiunea de acces a CMDQ nodurile dispozitivului sunt impuse și de SELinux.” Această atenuare vine probabil dintr-o actualizare a BSP-ului MediaTek, mai degrabă decât de la Android în sine. Singura atenuare de la Android 10 pentru această vulnerabilitate este ea restricție asupra aplicațiilor care execută binare în directorul lor principal; cu toate acestea, după cum notează Topjohnwu, dezvoltatorul recunoscut XDA, o aplicație rău intenționată poate rula pur și simplu codul MediaTek-su într-o bibliotecă dinamică.
Chiar dacă MediaTek a corectat această problemă în toate chipset-urile afectate, ei nu pot forța producătorii de dispozitive să implementeze patch-urile. MediaTek ne-a spus că aveau patch-uri pregătite până în mai 2019. Deloc surprinzător, Amazon a remediat imediat problema pe dispozitivele sale odată ce au fost informați. Cu toate acestea, au trecut 10 luni de când MediaTek a pus la dispoziția partenerilor săi o remediere, încă în În martie 2020, zeci de producători OEM nu și-au reparat dispozitivele. Cele mai multe dintre dispozitivele afectate sunt pe versiuni Android mai vechi, cu niveluri de corecție de securitate Android (SPL) învechite, iar situația actualizării este și mai gravă dacă luați în considerare sute a modelelor de dispozitive mai puțin cunoscute care utilizează aceste cipuri MediaTek. MediaTek are un serios problema pe mâinile sale aici, așa că au apelat la Google pentru ajutor.
Spre deosebire de MediaTek, Google poate sa obligă OEM-urile să-și actualizeze dispozitivele prin acorduri de licență sau termenii programului (cum ar fi Android One). Pentru ca un OEM să declare că un dispozitiv este în conformitate cu nivelul de corecție de securitate (SPL) din 2020-03-05, dispozitivul trebuie să includă toate cadrul, Nucleul Linux și remedierea driverelor aplicabile ale furnizorului din Buletinul de securitate Android din martie 2020, care include o remediere pentru CVE-2020-0069 sau MediaTek-su. (Google nu pare să impună acest lucru OEM-urile îmbină de fapt toate patch-urile atunci când declarați un anumit SPL, totuși.) Acum că buletinul din martie 2020 a ieșit, această poveste ar trebui să se termine, nu? Din păcate, trebuie să ținem și picioarele lui Google la foc pentru că le trage picioarele la încorporarea plasturilor.
Defectul în procesul de corecție de securitate
În cazul în care nu este deja clar, nu orice vulnerabilitate de securitate trebuie să ajungă într-un Buletin de securitate Android. Multe vulnerabilități sunt descoperite și corectate de furnizori fără ca acestea să apară vreodată în buletinul lunar. MediaTek-su ar fi trebuit să fie unul dintre ele, dar din multiple motive, mai mulți OEM nu au reușit să integreze patch-urile oferite de MediaTek. (Există o mulțime de motive potențiale pentru care, de la o lipsă de resurse la decizii de afaceri până la un eșec în comunicare.) Când am anterior a declarat că MediaTek „a apelat la Google” pentru ajutor, ceea ce a implicat că MediaTek a căutat în mod activ ajutor de la Google pentru a-i determina pe OEM să-și repare în cele din urmă dispozitive. Cu toate acestea, s-ar putea să nu fi fost chiar așa. Am înțeles că Google nu a avut cunoștință de MediaTek-su până când acesta a fost adus întâmplător într-un raport de securitate de la TrendMicro publicat pe 6 ianuarie 2020. În raport, TrendMicro se documenta o alta vulnerabilitate de securitate, numită „utilizare-după gratuit în driverul de liant„vulnerabilitatea, care a fost exploatată activ în sălbăticie. TrendMicro a remarcat modul în care trei aplicații rău intenționate au obținut acces la rădăcină folosind una dintre cele două metode, fie vulnerabilitatea „use-after-free în driverul de liant” sau MediaTek-su.
În codul care TrendMicro distribuite, putem vedea în mod clar modul în care aplicațiile rău intenționate vizează anumite modele de dispozitive (de ex. Nokia 3, OPPO F9 și Redmi 6A) și utilizând MediaTek-su pe ele.
Nu pot vorbi pentru TrendMicro, dar se pare că nu știau că MediaTek-su era o exploatare încă nepatchată. Accentul lor a fost pus pe exploatarea „use-after-free in binder driver”, la urma urmei, iar descoperirea utilizării MediaTek-su pare să fi fost o idee ulterioară. (Sunt sigur că dacă TrendMicro au fost conștienți de situația din jurul MediaTek-su, și-ar fi coordonat eforturile de dezvăluire cu Google.) Am fost informați doar despre aceasta ne exploatăm pe 5 februarie 2020 și, după ce am investigat singuri cât de rău a fost, am contactat Google în acest sens pe 7 februarie, 2020. Google a fost atât de îngrijorat de repercusiunile publicării MediaTek-su încât ne-a cerut să amânăm publicarea acestei povești până astăzi. După ce am luat în considerare prejudiciul ireparabil care poate fi cauzat utilizatorilor vizați de utilizarea malware-ului MediaTek-su, am fost de acord să suspendăm această poveste până la anunțul Android-ului din martie 2020 Buletin de securitate. Totuși, având în vedere cât timp va dura multor dispozitive să primească cea mai recentă actualizare de securitate, dacă vor avea vreodată înțelegi, probabil că vor exista o mulțime de dispozitive încă vulnerabile la MediaTek-su în câteva luni de la acum. Ar trebui să fie îngrozitor pentru oricine are un dispozitiv vulnerabil.
Chiar dacă această vulnerabilitate foarte gravă, „critică” este exploatată în mod activ în sălbăticie, numai Google introduse în remedierea acestei probleme în buletinul din martie 2020, care este la aproximativ 2 luni după ce au fost anunțați despre emisiune. Deși Google își informează partenerii Android despre cel mai recent Buletin de securitate Android cu 30 de zile înainte ca buletinul să fie făcut public (de ex. OEM au fost informați despre ceea ce este în buletinul din martie 2020 la începutul lunii februarie 2020), Google poate și face adesea să actualizeze buletinul cu modificări sau remedieri noi. De ce Google nu a ales să grăbească includerea unui patch pentru o problemă atât de gravă, mă depășește, mai ales când MediaTek a remediat acum 10 luni. Dacă un astfel de bug ar fi descoperit în dispozitivele Apple, nu am nicio îndoială că ar fi emis o remediere mult, mult mai repede. Google s-a bazat, în esență, pe pariul riscant că MediaTek-su va rămâne la fel de aparent de profil redus, cum era deja până la buletinul din martie 2020. În timp ce Google pare să fi avut noroc în acest sens, nu avem idee câți autori de programe malware știu deja despre exploit. La urma urmei, a fost așezat într-un fir aleatoriu de forum XDA pentru aproape un an întreg.
Mai este o parte în această dezamăgire căreia nu m-am adresat prea mult și este autorul exploatării, diplomat membru XDA. Spre meritul lui, nu cred că a avut vreo intenție rău intenționată în a publica MediaTek-su. Putem urmări în mod clar originea exploitului din dorința diplomatică de a modifica tabletele Amazon Fire. Diplomatic îmi spune că scopul său principal în dezvoltarea acestei metode rădăcină a fost să ajute comunitatea. Personalizarea dispozitivului este ceea ce înseamnă XDA, iar eforturile diplomatice în comunitate sunt ceea ce le place oamenilor la forumuri. Deși refuzul diplomaticului de a deschide proiectul ridică unele îngrijorări, el explică că a dorit ca comunitatea să se bucure de acest lucru având acces root cât mai mult timp posibil. Când am luat legătura pentru prima dată cu diplomația, el a mai spus că este într-o colaborare cu unii parteneri care l-a împiedicat să împărtășească codul sursă și cercetarea proiectului. Deși nu am putut obține mai multe detalii despre această colaborare, mă întreb dacă diplomatic ar fi ales să facă public acest exploit dacă MediaTek ar fi oferit un program de recompensă pentru erori. Nu îmi pot imagina că o vulnerabilitate de această amploare nu ar plăti o sumă mare de bani dacă MediaTek ar avea de fapt un astfel de program. Diplomatic susține că această exploatare a fost posibilă începând cu chipsetul MediaTek MT6580 de la sfârșitul anului 2015, așa că trebuie să ne întrebăm dacă diplomatic este chiar prima persoană care a găsit acest exploat. Îmi spune că nu avea idee că MediaTek-su este exploatat în mod activ până la publicarea acestui articol.
Dacă doriți să verificați dacă dispozitivul dvs. este vulnerabil la MediaTek-su, atunci rulați manual scriptul postat de diplomatul membru XDA în acest thread de forum XDA. Dacă introduceți un shell rădăcină (veți ști când simbolul se schimbă de la $ la #), atunci veți ști că exploit funcționează. Dacă funcționează, va trebui să așteptați ca producătorul dispozitivului dvs. să lanseze o actualizare care corectează MediaTek-su. Dacă dispozitivul dvs. raportează nivelul de corecție de securitate din 2020-03-05, care este cel mai recent SPL din martie 2020, atunci este aproape sigur protejat împotriva MediaTek-su. În caz contrar, va trebui doar să verificați dacă dispozitivul dvs. este vulnerabil.
Actualizare 1 (02/03/2020 la 21:45 EST): Acest articol a fost actualizat pentru a clarifica faptul că diplomatul membru XDA era de fapt conștient de amploarea acestei vulnerabilități de îndată ce a a descoperit-o în februarie 2019, dar că nu era conștient de utilizarea în sălbăticie a exploitului până la publicarea acestui articol. De asemenea, ne-am corectat formularea cu privire la un motiv pentru care diplomatic a refuzat să partajeze codul sursă al proiectului.