Kritisk MediaTek rootkit påvirker millioner av Android-enheter

Den første mandagen i hver måned publiserer Google Android sikkerhetsbulletin, en side som avslører alle sikkerhetssvakhetene og deres oppdateringer sendt inn av Google selv eller andre tredjeparter. I dag var intet unntak: Google offentliggjorde nettopp Android Security Bulletin for mars 2020. En av sårbarhetene som er dokumentert i den siste bulletinen er CVE-2020-0069, en kritisk sikkerhetsutnyttelse, spesielt en rootkit, som påvirker millioner av enheter med brikkesett fra MediaTek, det store taiwanske brikkedesignselskapet. Selv om Android Security Bulletin fra mars 2020 tilsynelatende er første gang CVE-2020-0069 har blitt offentliggjort, detaljer om utnyttelsen har faktisk vært åpent på Internett – nærmere bestemt på XDA-Developers-foraene – siden april av 2019. Til tross for at MediaTek har gjort en oppdatering tilgjengelig en måned etter oppdagelsen, kan sårbarheten fortsatt utnyttes på dusinvis av enhetsmodeller.

Enda verre, sårbarheten blir aktivt utnyttet av hackere. Nå har MediaTek henvendt seg til Google for å lukke dette oppdateringsgapet og sikre millioner av enheter mot denne kritiske sikkerhetsutnyttelsen.

For alle lesere som ikke er kjent med XDA-utviklere, vi er et nettsted som er hjemmet til de største foraene for modifikasjoner av Android-programvare. Vanligvis dreier disse modifikasjonene seg om å oppnå root-tilgang på enheter for å slette bloatware, installere tilpasset programvare eller justere standard systemparametere. Amazons Fire-nettbrett er populære mål for hobbyhackere på forumene våre – de er fulle av avinstallerbare bloatware, mangler tilgang til grunnleggende programvareapplikasjoner som Google Play Store, og, viktigst av alt, er svært billig. Utfordringen med å roote Amazon Fire-nettbrett er at de er tungt låst for å hindre brukere i å gå utenfor Amazons inngjerdede hage; Amazon tilbyr ikke en offisiell metode for å låse opp bootloaderen til Fire-nettbrett, som vanligvis er det første trinnet i å roote en gitt Android-enhet. Derfor er den eneste måten å roote et Amazon Fire-nettbrett på (uten maskinvaremodifikasjoner) å finne en utnyttelse i programvaren som lar brukeren omgå Androids sikkerhetsmodell. I februar 2019, altså nøyaktig hva XDA Senior Member diplomatic gjorde da han publiserte en tråd på våre Amazon Fire-nettbrettfora. Han innså raskt at denne utnyttelsen var langt bredere enn bare Amazons Fire-nettbrett.

Etter litt testing fra XDA Member diplomatiske og andre fellesskapsmedlemmer, ble det bekreftet at denne utnyttelsen fungerer på et stort antall MediaTek-brikker. Forfatteren uttaler at utnyttelsen fungerer på "så godt som alle MediaTeks 64-bits brikker," og de navngir spesifikt følgende som sårbare: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779. 173, MT8176, MT8183, MT6580 og MT6595. På grunn av hvor mange MediaTek-brikkesett som ble påvirket av denne utnyttelsen, ble utnyttelsen gitt navnet "MediaTek-su," eller "MTK-su," for kort. Den 17. april 2019 publiserte diplomat en andre tråd med tittelen "Utrolig Temp Root for MediaTek ARMv8" på vårt "Diverse Android Development"-forum. I denne tråden delte han et skript som brukere kan kjøre for å gi dem superbrukertilgang i shell, samt sette SELinux, Linux-kjernemodulen som gir tilgangskontroll for prosesser, til den svært usikre "tillatende" stat. For en bruker å få root-tilgang og sette SELinux til permissive på sin egen enhet er det sjokkerende enkelt å gjøre: Alt du trenger å gjøre er å kopiere skript til en midlertidig mappe, endre kataloger til der skriptet er lagret, legg til kjørbare tillatelser til skriptet, og kjør deretter manus.

Medlemmer av XDA-fellesskapet bekreftet at utnyttelsen fungerte på minst følgende enheter:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Alba nettbrettserie
4. Alcatel 1 5033-serien
5. Alcatel 1C
6. Alcatel 3L (2018) 5034-serien
7. Alcatel 3T 8
8. Alcatel A5 LED 5085-serien
9. Alcatel A30 5049-serien
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 -- kun opptil Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 -- kun opptil Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 -- kun opptil Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 -- kun opptil Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 -- kun opptil Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 – kun opptil Fire OS 7.3.1.0
20. Amazon Fire TV 2 -- kun opptil Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163-basert serie
24. Barnes & Noble NOOK nettbrett 7" BNTV450 & BNTV460
25. Barnes & Noble NOOK nettbrett 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Levetid Maks
29. BLU Life One X
30. BLU R1-serien
31. BLU R2 LTE
32. BLU 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. Ekko følelse
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Huawei Y6II MT6735-serien
48. Lava Iris 88S
49. Lenovo C2-serien
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tribute Dynasty
55. LG X power 2/M320-serien (MTK)
56. LG Xpression Plus 2/K40 LMX420-serien
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. Onn 7" Android-nettbrett
69. Onn 8" og 10" nettbrettserie (MT8163)
70. OPPO A5s
71. OPPO F5-serien/A73 – kun Android 8.x
72. OPPO F7-serien – kun Android 8.x
73. OPPO F9-serien – kun Android 8.x
74. Oukitel K12
75. Protruly D7
76. Realme 1
77. Sony Xperia C4
78. Sony Xperia C5-serien
79. Sony Xperia L1
80. Sony Xperia L3
81. Sony Xperia XA-serien
82. Sony Xperia XA1-serien
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3-serien
85. Umidigi F1-serien
86. Umidigi Power
87. Wiko Ride
88. Wiko Sunny
89. Wiko View3
90. Xiaomi Redmi 6/6A-serien
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

Les mer

Med unntak av MediaTek-baserte telefoner fra Vivo, Huawei/Honor (etter Android 8.0+), OPPO (etter Android 8.0+), og Samsung, XDA-fellesskapsmedlemmer fant ut at MediaTek-su fungerer oftere enn ikke når det ble forsøkt på enheter med berørte brikkesett. I følge XDA Member diplomatic, Vivo, Huawei/Honor, OPPO og Samsung-enheter "bruker kjernemodifikasjoner for å avskrekke rottilgang via utnytter," som betyr at utvikleren må grave inn i kjernekildekoden til disse enhetene for å lage "skreddersydde versjoner" av utnytte. Det var ikke verdt den ekstra innsatsen, så utvikleren valgte å ikke legge til støtte for disse enhetene, selv om utnyttelsen "i teorien" fortsatt kunne fungere.

Nå bør det være klart at denne utnyttelsen påvirker et stort antall enheter på markedet. MediaTek-brikker driver hundrevis av budsjett- og mellomstore smarttelefonmodeller, billige nettbrett og off-brand set-top-bokser, hvorav de fleste selges uten forventning om rettidige oppdateringer fra produsenten. Mange enheter som fortsatt er berørt av MediaTek-su vil derfor neppe få en løsning på uker eller måneder etter dagens avsløring, hvis de i det hele tatt får en. Så hva får MediaTek-su til å tjene sin "kritiske" alvorlighetsgrad med en CVSS v3.0 score på 9,3?

Hvorfor MTK-su er et kritisk sikkerhetssårbarhet

For å gjenta, den typiske måten å oppnå root-tilgang på en Android-enhet er å først låse opp oppstartslasteren, som deaktiverer verifisering av oppstartspartisjonen. Når oppstartslasteren er låst opp, kan brukeren introdusere en superbrukerbinær til systemet og også en superbrukeradministrasjonsapp for å kontrollere hvilke prosesser som har tilgang til root. Å låse opp bootloaderen deaktiverer med vilje en av de viktigste sikkerhetsfunksjonene på enheten, og det er grunnen til at brukeren må eksplisitt tillate det å skje ved vanligvis å aktivere en veksling i utvikleralternativer og deretter utstede en opplåsingskommando til bootloader. Med MediaTek-su trenger imidlertid ikke brukeren å låse opp bootloaderen for å få root-tilgang. I stedet trenger de bare å kopiere et skript til enheten og kjøre det i shell. Brukeren er imidlertid ikke den eneste som kan gjøre dette. Enhver app på telefonen din kan kopiere MediaTek-su-skriptet til deres private katalog og deretter kjøre det for å få root-tilgang i skallet. Faktisk, XDA-medlem diplomatisk fremhever denne muligheten i forumtråden deres når de foreslår et alternativt sett med instruksjoner ved å bruke enten Terminal Emulator for Android-appen eller Termux heller enn ADB.

Med root-tilgang faller Androids sikkerhetsmodell i utgangspunktet fra hverandre. For eksempel blir tillatelser meningsløse i sammenheng med root, da en app med tilgang til et rotskall kan gi seg selv hvilken som helst tillatelse den vil. Videre, med et rotskall, er hele datapartisjonen – inkludert filer som er lagret i de vanligvis utilgjengelige private datakatalogene til applikasjoner – tilgjengelig. En app med root kan også stille installering av hvilken som helst annen app den vil ha i bakgrunnen og deretter gi dem de tillatelsene de trenger for å krenke personvernet ditt. I følge XDA Recognized Developer topjohnwu, kan en ondsinnet app til og med "injisere kode direkte inn i Zygote ved å bruke ptrace," som betyr at en vanlig app på enheten din kan bli kapret for å gjøre angriperens bud. Disse eksemplene berører bare noen få måter en app kan krenke tilliten din på i bakgrunnen uten at du vet det. Skadelige apper kan imidlertid skape kaos på enheten din uten å skjule hva de gjør. Ransomware er for eksempel ekstremt potent med root-tilgang; hvis du ikke betaler, kan en hypotetisk løsepenge-app totalt og irreversibelt gjør enheten ubrukelig ved å tørke av hele enheten.

Den eneste "svakheten" i MediaTek-su er at den gir en applikasjon bare "midlertidig" root-tilgang, noe som betyr at en prosess mister superbrukertilgang etter en omstart av enheten. Videre, på enheter som kjører Android 6.0 Marshmallow og nyere, tilstedeværelsen av Verified Boot og dm-verity blokkere modifikasjoner til skrivebeskyttede partisjoner som system og leverandør. Imidlertid er disse to faktorene stort sett bare hindringer for moddere på forumene våre i stedet for ondsinnede aktører. For å overvinne begrensningen av midlertidig rot, kan en ondsinnet app ganske enkelt kjøre MediaTek-su-skriptet på nytt ved hver oppstart. På den annen side er det lite behov for å overvinne dm-verity ettersom permanente modifikasjoner av systemet eller leverandørpartisjoner neppe vil interessere de fleste skadevareforfattere; det er tross alt allerede tonn av ting en ondsinnet app kan gjøre med et rotskall.

Hvis du lurer på på et teknisk nivå hva MediaTek-su utnytter, delte MediaTek diagrammet nedenfor med oss ​​som oppsummerer inngangspunktet. Feilen eksisterer tilsynelatende i en av MediaTeks Linux Kernel-drivere kalt "CMDQ." Beskrivelsen sier at "ved å utføre IOCTL kommandoer i [den] CMDQ-enhetsnoden," kan en lokal angriper "vilkårlig lese/skrive fysisk minne, dumpe [kjernesymboltabellen] til forhåndstildelt DMA-buffer, [og] manipuler DMA-bufferen for å endre kjerneinnstillingene for å deaktivere SELinux og eskalere til 'root' privilegium."

I følge diagrammet som MediaTek delte med oss, påvirker dette sikkerhetsproblemet MediaTek-enheter med Linux Kernel-versjoner 3.18, 4.4, 4.9 eller 4.14 som kjører Android-versjoner 7 Nougat, 8 Oreo eller 9 Pie. Sårbarheten kan ikke utnyttes på MediaTek-enheter som kjører Android 10, tilsynelatende siden "tilgangstillatelsen til CMDQ enhetsnoder håndheves også av SELinux." Denne begrensningen kommer sannsynligvis fra en oppdatering til MediaTeks BSP i stedet for fra Android seg selv. Android 10s eneste redusering for denne sårbarheten er dens begrensning på apper som kjører binærfiler i hjemmekatalogen deres; som XDA Recognized Developer topjohnwu bemerker, kan imidlertid en ondsinnet app ganske enkelt kjøre MediaTek-su-koden i et dynamisk bibliotek.

Selv om MediaTek har rettet dette problemet i alle de berørte brikkesettene, kan de ikke tvinge enhetsprodusenter til å implementere oppdateringene. MediaTek fortalte oss at de hadde patcher klare helt tilbake i mai 2019. Amazon, ikke overraskende, korrigerte problemet umiddelbart på tvers av enhetene sine når de ble gjort oppmerksomme. Imidlertid har det gått 10 måneder siden MediaTek gjorde en løsning tilgjengelig for sine partnere, men likevel inne Mars 2020 har dusinvis av OEM-er ikke fikset enhetene sine. De fleste av de berørte enhetene er på eldre Android-utgivelser med utdaterte Android Security Patch Levels (SPLs), og oppdateringssituasjonen er enda verre når du vurderer hundrevis av mindre kjente enhetsmodeller som bruker disse MediaTek-brikkene. MediaTek har en seriøs problemet på hendene her, så de har henvendt seg til Google for å få hjelp.

I motsetning til MediaTek, Google kan tvinge OEM-er til å oppdatere enhetene sine gjennom lisensavtaler eller programvilkår (som Android One). For at en OEM skal erklære at en enhet er i samsvar med 2020-03-05 Security Patch Level (SPL), må enheten inkludere alt rammeverk, Linux-kjernen og gjeldende leverandørdriverrettinger i Android Security Bulletin for mars 2020, som inkluderer en rettelse for CVE-2020-0069, eller MediaTek-su. (Det ser ikke ut til at Google håndhever det OEM-er slår faktisk sammen alle patcher når du erklærer en viss SPL.) Nå som mars 2020-bulletinen er ute, burde denne historien være over, ikke sant? Dessverre må vi også holde Googles føtter mot ilden for å dra føttene deres på å innlemme lappene.

Feilen i sikkerhetsoppdateringsprosessen

I tilfelle det ikke allerede er klart, trenger ikke alle sikkerhetssårbarheter å havne i en Android Security Bulletin. Mange sårbarheter oppdages og lappes av leverandører uten at de noen gang dukker opp i den månedlige bulletinen. MediaTek-su burde vært en av dem, men av flere grunner klarte ikke flere OEM-er å integrere oppdateringene som tilbys av MediaTek. (Det er mange mulige årsaker til dette, alt fra mangel på ressurser til forretningsbeslutninger til kommunikasjonssvikt.) Da jeg tidligere uttalte at MediaTek "vendte seg til Google" for å få hjelp, antydet det at MediaTek aktivt søkte hjelp fra Google for å få OEM-er til å endelig fikse enheter. Imidlertid kan det faktisk ikke ha vært tilfelle. Det er min forståelse at Google var uvitende om MediaTek-su før det tilfeldigvis ble tatt opp i en sikkerhetsrapport fra TrendMicro publisert 6. januar 2020. I rapporten, TrendMicro dokumenterte en annen sikkerhetssårbarhet, kalt "bruk-etter-fri i permdriver"sårbarhet, som aktivt ble utnyttet i naturen. TrendMicro bemerket hvordan tre ondsinnede apper oppnådde root-tilgang ved å bruke en av to metoder, enten "bruk-etter-fri i binderdriver"-sårbarheten eller MediaTek-su.

I koden som TrendMicro delt, kan vi tydelig se hvordan de skadelige appene målrettet mot bestemte enhetsmodeller (f.eks. Nokia 3, OPPO F9 og Redmi 6A) og bruker MediaTek-su på dem.

Jeg kan ikke snakke for TrendMicro, men det ser ut til at de ikke var klar over at MediaTek-su var en uoppdatert utnyttelse. Deres fokus var tross alt på "bruk-etter-fri i binderdriver"-utnyttelsen, og oppdagelsen av bruken av MediaTek-su ser ut til å ha vært en ettertanke. (Jeg er sikker på at hvis TrendMicro var klar over situasjonen rundt MediaTek-su, ville de ha koordinert avsløringsarbeidet med Google.) Vi ble bare gjort oppmerksomme på denne utnyttelsen selv 5. februar 2020, og etter å ha undersøkt selv hvor ille det var, kontaktet vi Google om det 7. februar, 2020. Google var så bekymret for konsekvensene av å publisere MediaTek-su at de ba oss om å vente med å publisere denne historien til i dag. Etter å ha vurdert den uopprettelige skaden som kan påføres brukere målrettet av skadelig programvare som bruker MediaTek-su, vi ble enige om å sette en stopper for denne historien frem til kunngjøringen av Mars 2020 Android Sikkerhetsbulletin. Likevel, med tanke på hvor lang tid det vil ta mange enheter å få den siste sikkerhetsoppdateringen, hvis de noen gang får det i det hele tatt, det er garantert massevis av enheter som fortsatt er sårbare for MediaTek-su noen måneder fra nå. Det burde være grusomt for alle med en sårbar enhet.

Selv om dette svært alvorlige, "kritiske" alvorlighetsproblemet aktivt blir utnyttet i naturen, er det kun Google satte inn løsningen for dette problemet i mars 2020-bulletinen, som er omtrent 2 måneder etter at de ble gjort oppmerksomme på utgave. Mens Google informerer sine Android-partnere om den siste Android-sikkerhetsbulletinen hele 30 dager før bulletinen offentliggjøres (dvs. OEM-er ble gjort oppmerksomme på hva som står i mars 2020-bulletinen tidlig i februar 2020), Google kan, og gjør det ofte, oppdatere bulletinen med endringer eller nye rettelser. Hvorfor Google ikke valgte å fremskynde inkluderingen av en oppdatering for et så alvorlig problem er utenfor meg, spesielt da MediaTek hadde en løsning for det for 10 måneder siden. Hvis en slik feil ble oppdaget i Apples enheter, har jeg liten tvil om at de ville ha utstedt en reparasjon mye, mye raskere. Google satset i hovedsak på det risikable veddemålet om at MediaTek-su ville forbli like lavprofilert som det allerede var frem til mars 2020-bulletinen. Selv om Google ser ut til å ha vært heldig i den forbindelse, har vi ingen anelse om hvor mange skadevareforfattere som allerede vet om utnyttelsen. Tross alt har den sittet i en tilfeldig XDA-forumtråd for nesten et helt år.

Det er en part til i denne debakelen som jeg ikke har tatt opp så mye, og det er forfatteren av utnyttelsen, XDA Member diplomatic. Til hans ære, tror jeg ikke han hadde noen ondsinnet hensikt med å publisere MediaTek-su. Vi kan tydelig spore utnyttelsens opprinnelse til diplomatiskes ønske om å modifisere Amazon Fire-nettbrettene. Diplomatic forteller meg at hans primære mål med å utvikle denne rotmetoden var å hjelpe samfunnet. Å tilpasse enheten din er det XDA handler om, og diplomatisk innsats i samfunnet er det folk liker ved forumene. Selv om diplomatisk avslag på å åpne kildekode prosjektet vekker noen bekymringer, forklarer han at han ønsket at fellesskapet skulle glede seg over dette med root-tilgang så lenge som mulig. Da jeg først kontaktet diplomat, opplyste han også at han var i et samarbeid med noen partnere som hindret ham i å dele prosjektets kildekode og forskning. Selv om jeg ikke var i stand til å få flere detaljer om dette samarbeidet, lurer jeg på om diplomat ville ha valgt å offentliggjøre denne utnyttelsen hvis MediaTek tilbød et bug-bounty-program. Jeg kan ikke forestille meg at en sårbarhet av denne størrelsesorden ikke ville betale ut en heftig sum penger hvis MediaTek faktisk hadde et slikt program. Diplomatic hevder at denne utnyttelsen har vært mulig siden slutten av MediaTek MT6580-brikkesettet i 2015, så man må lure på om diplomatic i det hele tatt er den første personen som finner denne utnyttelsen. Han forteller meg at han ikke hadde noen anelse om at MediaTek-su ble aktivt utnyttet før publiseringen av denne artikkelen.

Hvis du vil sjekke om enheten din er sårbar for MediaTek-su, så kjør manuelt skriptet som er lagt ut av XDA Member diplomatic i denne XDA-forumtråden. Hvis du skriver inn et rotskall (du vil vite når symbolet endres fra $ til #), så vet du at utnyttelsen fungerer. Hvis det fungerer, må du vente på at produsenten av enheten din ruller ut en oppdatering som patcher MediaTek-su. Hvis enheten din rapporterer sikkerhetsoppdateringsnivået 2020-03-05, som er den siste mars 2020 SPL, så er den nesten helt sikkert beskyttet mot MediaTek-su. Ellers må du bare sjekke om enheten din er sårbar.

---

Oppdatering 1 (3/2/2020 @ 21:45 EST): Denne artikkelen ble oppdatert for å klargjøre at XDA Member diplomatic faktisk var klar over omfanget av denne sårbarheten så snart han oppdaget det tilbake i februar 2019, men at han ikke var klar over utnyttelsens i-the-wild bruk før publiseringen av denne artikkel. Vi korrigerte også ordlyden vår angående en grunn til at diplomatic nektet å dele prosjektets kildekode.