Kritični rootkit MediaTek vpliva na milijone naprav Android

Vsak prvi ponedeljek v mesecu Google objavi Varnostni bilten za Android, stran, ki razkriva vse varnostne ranljivosti in njihove popravke, ki jih predloži Google sam ali druge tretje osebe. Današnji dan ni bil izjema: Google je pravkar objavil varnostni bilten Androida za marec 2020. Ena od ranljivosti, ki je dokumentirana v najnovejšem biltenu, je CVE-2020-0069, kritično varnostno izkoriščanje, zlasti rootkit, ki vpliva na milijone naprav z nabori čipov podjetja MediaTek, velikega tajvanskega podjetja za oblikovanje čipov. Čeprav je marec 2020 Android Security Bulletin očitno prvič, da je bil CVE-2020-0069 javno razkrit, podrobnosti o izkoriščanju so dejansko odprto na internetu – natančneje na forumih XDA-Developers – od aprila leta 2019. Kljub temu, da je MediaTek dal na voljo popravek mesec dni po odkritju, je ranljivost še vedno mogoče izkoristiti na desetinah modelov naprav.

Še huje, ranljivost aktivno izkoriščajo hekerji. Zdaj se je MediaTek obrnil na Google, da bi zapolnil to vrzel v popravku in zaščitil milijone naprav pred tem kritičnim varnostnim izkoriščanjem.

Za vse bralce, ki jih ne poznate XDA-razvijalci, smo spletno mesto, ki je dom največjih forumov za spremembe programske opreme Android. Običajno se te spremembe osredotočajo na pridobitev korenskega dostopa na napravah, da se izbriše razpokana programska oprema, namesti programska oprema po meri ali prilagodi privzete sistemske parametre. Amazonove tablice Fire so priljubljene tarče ljubiteljskih hekerjev na naših forumih – polne so nenamestljivih bloatware, nimajo dostopa do osnovnih programskih aplikacij, kot je trgovina Google Play, in, kar je najpomembneje, so zelo poceni. Izziv pri ukoreninjenju tabličnih računalnikov Amazon Fire je, da so močno zaklenjeni, da uporabnikom preprečijo, da bi stopili iz Amazonovega obzidanega vrta; Amazon ne nudi uradne metode za odklepanje zagonskega nalagalnika tabličnih računalnikov Fire, kar je običajno prvi korak pri rootanju katere koli naprave Android. Zato je edini način za rootanje tabličnega računalnika Amazon Fire (brez sprememb strojne opreme) iskanje izkoriščanja v programski opremi, ki uporabniku omogoča, da zaobide varnostni model Androida. Februarja 2019, tj točno to, kar je storil višji diplomatski član XDA ko je objavil nit na naših forumih za tablične računalnike Amazon Fire. Hitro je ugotovil, da je ta podvig veliko širši kot le Amazonove tablice Fire.

Po kratkem testiranju diplomatskih in drugih članov skupnosti članov XDA je bilo potrjeno, da ta izkoriščanje deluje na velikem številu čipov MediaTek. Avtor navaja, da izkoriščanje deluje na "skoraj vseh MediaTekovih 64-bitnih čipih," in kot ranljive posebej imenuje naslednje: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8 173, MT8176, MT8183, MT6580 in MT6595. Zaradi tega, koliko naborov čipov MediaTek je prizadelo to izkoriščanje, je bilo izkoriščenje na kratko imenovano "MediaTek-su" ali "MTK-su". 17. aprila 2019 je Diplomatic objavil drugo nit z naslovom "Neverjeten Temp Root za MediaTek ARMv8« na našem forumu »Razni razvoj za Android«. V tej temi je dal v skupno rabo skript, ki ga lahko uporabniki izvedejo, da jim omogoči dostop superuporabnika v lupini, in nastavi SELinux, jedrni modul Linuxa, ki zagotavlja nadzor dostopa za procese do zelo nevarnih "permisivnih" država. Za uporabnika, da pridobi korenski dostop in nastavi SELinux na permisiven na svoji napravi, je šokantno enostavno narediti: Vse kar morate storiti je, da kopirate skript v začasno mapo, spremenite imenike, kjer je shranjen skript, skriptu dodajte izvršljiva dovoljenja in nato izvedite scenarij.

Člani skupnosti XDA so potrdili, da je izkoriščanje delovalo na vsaj naslednjih napravah:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Serija tabličnih računalnikov Alba
4. Serija Alcatel 1 5033
5. Alcatel 1C
6. Alcatel 3L (2018) serija 5034
7. Alcatel 3T 8
8. Alcatel A5 LED 5085 serija
9. Alcatel A30 serija 5049
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 -- samo do Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 -- samo do Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 -- samo do Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 -- samo do Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 -- samo do Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 -- samo do Fire OS 7.3.1.0
20. Amazon Fire TV 2 -- samo do Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. Serija ASUS ZenPad Z3xxM(F) MT8163
24. Tablični računalnik Barnes & Noble NOOK 7" BNTV450 & BNTV460
25. Tablični računalnik Barnes & Noble NOOK 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Max
29. BLU Life One X
30. Serija BLU R1
31. BLU R2 LTE
32. MODRI S1
33. BLU Tank Xtreme Pro
34. BLU Vivo 8L
35. BLU Vivo XI
36. BLU Vivo XL4
37. Bluboo S8
38. BQ Aquaris M8
39. CAT S41
40. Coolpad Cool Play 8 Lite
41. Dragon Touch K10
42. Občutek odmeva
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Serija Huawei Y6II MT6735
48. Lava Iris 88S
49. Serija Lenovo C2
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tribute Dynasty
55. Serija LG X power 2/M320 (MTK)
56. Serija LG Xpression Plus 2/K40 LMX420
57. Lumigon T3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro 7 Plus
61. Nokia 1
62. Nokia 1 Plus
63. Nokia 3
64. Nokia 3.1
65. Nokia 3.1 Plus
66. Nokia 5.1
67. Nokia 5.1 Plus/X5
68. Na 7" tablici Android
69. Serija tabličnih računalnikov Onn 8" in 10" (MT8163)
70. OPPO A5s
71. Serija OPPO F5/A73 -- samo Android 8.x
72. Serija OPPO F7 -- samo Android 8.x
73. Serija OPPO F9 -- samo Android 8.x
74. Oukitel K12
75. Protruly D7
76. Realme 1
77. Sony Xperia C4
78. Serija Sony Xperia C5
79. Sony Xperia L1
80. Sony Xperia L3
81. Serija Sony Xperia XA
82. Serija Sony Xperia XA1
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3 serije
85. Serija Umidigi F1
86. Umidigi Power
87. Wiko Ride
88. Wiko Sunny
89. Wiko View3
90. Serija Xiaomi Redmi 6/6A
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

Preberi več

Z izjemo telefonov na osnovi MediaTek proizvajalcev Vivo, Huawei/Honor (po Androidu 8.0+), OPPO (po Androidu 8.0+) in Samsung, člani skupnosti XDA so ugotovili, da MediaTek-su deluje pogosteje kot ne, ko ga poskušajo uporabiti v napravah s prizadetimi nabori čipov. Glede na diplomatski član XDA naprave Vivo, Huawei/Honor, OPPO in Samsung "uporabljajo spremembe jedra za odvračanje korenskega dostopa prek izkorišča,« kar pomeni, da bi se moral razvijalec poglobiti v izvorno kodo jedra teh naprav, da ustvari »prilagojene različice« izkoriščanje. To ni bilo vredno dodatnega truda, zato se je razvijalec odločil, da ne bo dodal podpore za te naprave, čeprav bi "teoretično" izkoriščanje še vedno lahko delovalo.

Do zdaj bi moralo biti jasno, da to izkoriščanje vpliva na veliko število naprav na trgu. Čipi MediaTek poganjajo stotine nizkocenovnih in srednjerazrednih modelov pametnih telefonov, poceni tabličnih računalnikov in drugih blagovnih znamk set-top boxi, ki se večinoma prodajajo brez pričakovanja pravočasnih posodobitev proizvajalca. Številne naprave, na katere še vedno vpliva MediaTek-su, tako verjetno ne bodo dobile popravka še tedne ali mesece po današnjem razkritju, če ga sploh bodo. Torej, zakaj MediaTek-su zasluži svojo "kritično" resnost z a CVSS v3.0 ocena 9,3?

Zakaj je MTK-su kritična varnostna ranljivost

Ponavljam, tipičen način za doseganje korenskega dostopa v napravi Android je, da najprej odklenete zagonski nalagalnik, ki onemogoči preverjanje zagonske particije. Ko je zagonski nalagalnik odklenjen, lahko uporabnik v sistem uvede dvojiško datoteko superuporabnika in tudi aplikacijo za upravljanje superuporabnika za nadzor nad tem, kateri procesi imajo dostop do korena. Odklepanje zagonskega nalagalnika namerno onemogoči eno od ključnih varnostnih funkcij v napravi, zaradi česar mora uporabnik izrecno dovolite, da se to zgodi, tako da običajno omogočite preklop v možnostih za razvijalce in nato izdate ukaz za odklepanje zagonski nalagalnik. Pri MediaTek-su pa uporabniku ni treba odkleniti zagonskega nalagalnika, da bi dobil korenski dostop. Namesto tega morajo samo kopirati skript v svojo napravo in ga izvesti v lupini. Uporabnik pa ni edini, ki lahko to stori. Vsaka aplikacija v vašem telefonu lahko kopira skript MediaTek-su v svoj zasebni imenik in ga nato izvede, da pridobi korenski dostop v lupini. Pravzaprav član XDA diplomatski poudarja to možnost v njihovi temi na forumu, ko predlagajo alternativni niz navodil z uporabo bodisi Aplikacija Terminal Emulator za Android oz Termux namesto ADB.

S korenskim dostopom Androidov varnostni model v bistvu razpade. Na primer, dovoljenja postanejo nesmiselna v kontekstu korena, saj lahko aplikacija z dostopom do korenske lupine sama sebi podeli poljubna dovoljenja. Poleg tega je s korensko lupino dostopna celotna podatkovna particija - vključno z datotekami, shranjenimi v običajno nedostopnih zasebnih podatkovnih imenikih aplikacij. Aplikacija s root lahko tudi tiho namesti katero koli drugo aplikacijo, ki jo želi v ozadju, in ji nato dodeli vsa dovoljenja, ki jih potrebujejo za kršitev vaše zasebnosti. Glede na XDA Recognized Developer topjohnwu, lahko zlonamerna aplikacija celo »vbrizga kodo neposredno v Zygote z uporabo ptrace«, kar pomeni, da bi običajno aplikacijo v vaši napravi lahko ugrabili, da bi izpolnila ponudbe napadalca. Ti primeri se dotikajo le nekaj načinov, kako lahko aplikacija brez vaše vednosti krši vaše zaupanje v ozadju. Vendar lahko zlonamerne aplikacije povzročijo kaos v vaši napravi, ne da bi prikrile, kaj počnejo. Ransomware je na primer izjemno močan s korenskim dostopom; če ne plačate, bi lahko hipotetična izsiljevalska aplikacija popolnoma in nepovratno naredite svojo napravo neuporabno tako, da obrišete celotno napravo.

Edina "slabost" v MediaTek-su je, da aplikaciji dodeli le "začasen" korenski dostop, kar pomeni, da proces po ponovnem zagonu naprave izgubi dostop superuporabnika. Poleg tega je v napravah s sistemom Android 6.0 Marshmallow in novejšim prisotnost Preverjen zagon in dm-verity blokirajte spremembe particij samo za branje, kot sta sistem in prodajalec. Vendar ta dva dejavnika večinoma le ovirata moderje na naših forumih in ne zlonamerne akterje. Za premagovanje omejitve začasnega korena lahko zlonamerna aplikacija preprosto znova zažene skript MediaTek-su ob vsakem zagonu. Po drugi strani pa ni potrebe po premagovanju dm-verity, saj trajne spremembe sistema ali particij proizvajalca verjetno ne bodo zanimale večine avtorjev zlonamerne programske opreme; navsezadnje že obstajajo ton stvari, ki jih zlonamerna aplikacija lahko naredi s korensko lupino.

Če se na tehnični ravni sprašujete, kaj MediaTek-su izkorišča, je MediaTek z nami delil spodnjo tabelo, ki povzema vstopno točko. Napaka očitno obstaja v enem od MediaTekovih gonilnikov za jedro Linuxa, imenovanem "CMDQ." Opis navaja, da "z izvajanjem IOCTL ukazov v [vozlišču] naprave CMDQ,« lahko lokalni napadalec »poljubno bere/piše fizični pomnilnik, izpusti [] tabelo simbolov jedra v vnaprej dodeljen vmesni pomnilnik DMA, [in] manipulirajte z vmesnim pomnilnikom DMA, da spremenite nastavitve jedra, da onemogočite SELinux in povečate na 'root' privilegij."

Glede na tabelo, ki nam jo je posredoval MediaTek, ta ranljivost vpliva na naprave MediaTek z različicami jedra Linux 3.18, 4.4, 4.9 ali 4.14, ki uporabljajo Android različice 7 Nougat, 8 Oreo ali 9 Pie. Ranljivosti ni mogoče izkoristiti v napravah MediaTek z operacijskim sistemom Android 10, očitno, ker "dovoljenje za dostop CMDQ vozlišča naprav uveljavlja tudi SELinux." Ta ublažitev verjetno izhaja iz posodobitve BSP podjetja MediaTek in ne iz sistema Android sama. Edina ublažitev te ranljivosti v sistemu Android 10 je omejitev aplikacij, ki izvajajo binarne datoteke v domačem imeniku; vendar, kot ugotavlja priznani razvijalec XDA topjohnwu, lahko zlonamerna aplikacija preprosto zažene kodo MediaTek-su v dinamični knjižnici.

Čeprav je MediaTek to težavo popravil v vseh prizadetih naborih čipov, ne morejo prisiliti proizvajalcev naprav, da uvedejo popravke. MediaTek nam je povedal, da so imeli popravke pripravljene že maja 2019. Amazon je, kar ni presenetljivo, takoj popravil težavo v svojih napravah, ko so bili o tem obveščeni. Vendar je minilo 10 mesecev, odkar je MediaTek dal na voljo popravek svojim partnerjem, vendar v Marca 2020 več deset proizvajalcev originalne opreme ni popravilo svojih naprav. Večina prizadetih naprav uporablja starejše izdaje Androida z zastarelimi ravnmi varnostnih popravkov za Android (SPL), stanje posodobitve pa je še slabše, če upoštevate na stotine manj znanih modelov naprav, ki uporabljajo te čipe MediaTek. MediaTek ima resno težavo, zato so se za pomoč obrnili na Google.

Za razliko od MediaTeka, Google lahko prisili proizvajalce originalne opreme, da posodobijo svoje naprave licenčne pogodbe ali pogoji programa (kot je Android One). Da lahko proizvajalec originalne opreme izjavi, da je naprava v skladu s stopnjo varnostnega popravka 2020-03-05 (SPL), mora naprava vključevati vse okvire, Jedro Linuxa in ustrezni popravki gonilnikov prodajalca v varnostnem biltenu za Android marec 2020, ki vključuje popravek za CVE-2020-0069 ali MediaTek-su. (Zdi se, da Google tega dejansko ne uveljavlja Proizvajalci originalne opreme dejansko združijo vse popravke pri razglasitvi določenega SPL.) Zdaj, ko je izšel bilten za marec 2020, bi moralo biti te zgodbe konec, kajne? Na žalost moramo tudi Google držati za noge, ker je zavlačeval z vgradnjo popravkov.

Napaka v postopku varnostnega popravka

Če še ni jasno, ni nujno, da vsaka varnostna ranljivost konča v varnostnem biltenu Androida. Številne ranljivosti odkrijejo in popravijo prodajalci, ne da bi se te kdaj pojavile v mesečnem biltenu. MediaTek-su bi moral biti eden izmed njih, vendar iz več razlogov več proizvajalcev originalne opreme ni uspelo integrirati popravkov, ki jih ponuja MediaTek. (Za to obstaja veliko možnih razlogov, od pomanjkanja sredstev do poslovnih odločitev do neuspešne komunikacije.) Ko sem prej izjavil, da se je MediaTek za pomoč "obrnil na Google", kar pomeni, da je MediaTek aktivno iskal pomoč pri Googlu, da bi proizvajalce originalne opreme končno popravil naprave. Vendar morda v resnici ni bilo tako. Kolikor razumem, Google ni vedel za MediaTek-su, dokler ni bil slučajno omenjen v varnostnem poročilu TrendMicro objavljeno 6. januarja 2020. V poročilu je TrendMicro je dokumentiral drugo varnostna ranljivost, imenovana "brezplačna uporaba v gonilniku vezave" ranljivost, ki se je aktivno izkoriščala v naravi. TrendMicro opazil, kako so tri zlonamerne aplikacije dosegle korenski dostop z uporabo ene od dveh metod, bodisi ranljivosti "use-after-free in binder driver" ali MediaTek-su.

V kodi, ki TrendMicro v skupni rabi, lahko jasno vidimo, kako so zlonamerne aplikacije ciljale na določene modele naprav (npr. Nokia 3, OPPO F9 in Redmi 6A) in na njih uporabljajo MediaTek-su.

Ne morem govoriti namesto TrendMicro, vendar se zdi, da se niso zavedali, da je MediaTek-su še nepopravljen podvig. Navsezadnje so se osredotočili na izkoriščanje "use-after-free in binder driver" in zdi se, da je bilo odkritje uporabe MediaTek-su naknadna misel. (Prepričan sem, da če TrendMicro vedeli za situacijo v zvezi z MediaTek-su, bi svoja prizadevanja za razkritje uskladili z Googlom.) Seznanjeni smo bili le z to izkoriščanje sami izkoristili 5. februarja 2020 in potem, ko smo sami raziskali, kako hudo je bilo, smo 7. februarja o tem stopili v stik z Googlom, 2020. Google je bil tako zaskrbljen zaradi posledic objave MediaTek-su, da so nas prosili, naj z objavo te zgodbe odložimo do danes. Po upoštevanju nepopravljive škode, ki jo lahko povzroči uporabnikom, ki so tarča zlonamerne programske opreme MediaTek-su, dogovorili smo se, da bomo to zgodbo zadržali do objave Androida marca 2020 Varnostni bilten. Kljub temu, glede na to, kako dolgo bo trajalo, da veliko naprav prejme najnovejšo varnostno posodobitev, če sploh kdaj če ga sploh dobite, bo nekaj mesecev od zdaj. To bi moralo biti grozljivo za vsakogar z ranljivo napravo.

Čeprav se ta zelo resna, "kritična" ranljivost resnosti aktivno izkorišča v naravi, Google le dodali popravek za to težavo v bilten marca 2020, kar je približno 2 meseca po tem, ko so bili seznanjeni z težava. Medtem ko Google svoje partnerje za Android obvesti o najnovejšem biltenu o varnosti Android polnih 30 dni, preden je bilten javno objavljen (tj. Proizvajalci originalne opreme so bili v začetku februarja 2020 obveščeni o tem, kaj je v biltenu za marec 2020), Google lahko in pogosto tudi posodobi bilten s spremembami ali novimi popravki. Zakaj se Google ni odločil pospešiti vključitve popravka za tako resno težavo, ne vem, še posebej, ko je MediaTek pred 10 meseci imel popravek. Če bi takšno napako odkrili v Applovih napravah, ne dvomim, da bi izdali popravek veliko, veliko hitreje. Google je v bistvu stavil na tvegano stavo, da bo MediaTek-su ostal tako navidez nizko odmeven, kot je bil do biltena marca 2020. Čeprav se zdi, da je imel Google v zvezi s tem srečo, ne vemo, koliko avtorjev zlonamerne programske opreme že ve za izkoriščanje. Konec koncev že nekaj časa stoji v naključni niti na forumu XDA skoraj celo leto.

V tem debaklu je še ena stran, ki je nisem veliko obravnaval, in to je avtor podviga, diplomatski član XDA. Po njegovem mnenju mislim, da pri objavi MediaTek-su ni imel nobenih zlonamernih namenov. Jasno lahko sledimo izvoru izkoriščanja v diplomatski želji po modificiranju tabličnih računalnikov Amazon Fire. Diplomatic mi je povedal, da je bil njegov glavni cilj pri razvoju te korenske metode pomagati skupnosti. Prilagajanje vaše naprave je bistvo XDA in diplomatska prizadevanja v skupnosti so tisto, v čemer ljudje uživajo na forumih. Čeprav diplomatova zavrnitev odprtokodnega projekta vzbuja nekaj pomislekov, pojasnjuje, da je želel, da skupnost čim dlje uživa v korenskem dostopu. Ko sem prvič stopil v stik z diplomatom, je tudi izjavil, da sodeluje z nekaterimi partnerji, ki mu preprečujejo, da bi delil izvorno kodo projekta in raziskave. Čeprav nisem mogel pridobiti več podrobnosti o tem sodelovanju, se sprašujem, ali bi se diplomati odločili javno objaviti ta podvig, če bi MediaTek ponudil program za nagrado za napake. Ne morem si predstavljati, da ranljivost takšnega obsega ne bi izplačala zajetne vsote denarja, če bi MediaTek dejansko imel tak program. Diplomatic trdi, da je to izkoriščanje možno že od nabora čipov MediaTek MT6580 konec leta 2015, zato se je treba vprašati, ali je diplomat sploh prva oseba, ki je našla to izkoriščanje. Povedal mi je, da do objave tega članka ni vedel, da se MediaTek-su aktivno izkorišča.

Če želite preveriti, ali je vaša naprava ranljiva za MediaTek-su, potem ročno zaženite skript, ki ga je objavil XDA Member diplomatic v tej temi foruma XDA. Če vnesete korensko lupino (vedeli boste, ko se simbol spremeni iz $ v #), boste vedeli, da izkoriščanje deluje. Če deluje, boste morali počakati, da proizvajalec vaše naprave uvede posodobitev, ki popravi MediaTek-su. Če vaša naprava sporoči raven varnostnega popravka 2020-03-05, ki je najnovejši SPL iz marca 2020, potem je skoraj zagotovo zaščitena pred MediaTek-su. V nasprotnem primeru boste morali samo preveriti, ali je vaša naprava ranljiva.

---

Posodobitev 1 (3/2/2020 ob ​​21:45 EST): Ta članek je bil posodobljen, da bi pojasnil, da se je diplomatski član XDA dejansko zavedal obsega te ranljivosti takoj, ko je ga je odkril že februarja 2019, vendar do objave tega ni vedel za njegovo uporabo v naravi. Članek. Prav tako smo popravili naše besedilo glede enega od razlogov, zakaj diplomati niso želeli deliti izvorne kode projekta.