Kritisk MediaTek rootkit påvirker millioner af Android-enheder

Den første mandag i hver måned udgiver Google Android sikkerhedsbulletin, en side, der afslører alle sikkerhedssårbarheder og deres patches indsendt af Google selv eller andre tredjeparter. I dag var ingen undtagelse: Google offentliggjorde netop Android Security Bulletin for marts 2020. En af de sårbarheder, der er dokumenteret i den seneste bulletin, er CVE-2020-0069, en kritisk sikkerhedsudnyttelse, specifikt en rootkit, der påvirker millioner af enheder med chipsæt fra MediaTek, det store taiwanske chipdesignfirma. Selvom Android Security Bulletin fra marts 2020 tilsyneladende er første gang, at CVE-2020-0069 er blevet offentliggjort, detaljer om udnyttelsen har faktisk stået åbent på internettet - mere specifikt på XDA-Developers fora - siden april af 2019. På trods af at MediaTek gør en patch tilgængelig en måned efter opdagelsen, kan sårbarheden stadig udnyttes på snesevis af enhedsmodeller.

Endnu værre, sårbarheden bliver aktivt udnyttet af hackere. Nu har MediaTek henvendt sig til Google for at lukke dette patchgab og sikre millioner af enheder mod denne kritiske sikkerhedsudnyttelse.

For alle læsere, der ikke er bekendt med XDA-udviklere, vi er et websted, der er hjemsted for de største fora for Android-softwareændringer. Normalt er disse ændringer centreret omkring at opnå root-adgang på enheder for at slette bloatware, installere brugerdefineret software eller justere standard systemparametre. Amazons Fire-tablets er populære mål for hobbyhackere på vores fora - de er fulde af afinstallerbare bloatware, mangler adgang til grundlæggende softwareapplikationer som Google Play Butik, og, vigtigst af alt, er meget billig. Udfordringen med at rodfæste Amazon Fire-tablets er, at de er stærkt låst for at forhindre brugere i at træde udenfor Amazons murede have; Amazon tilbyder ikke en officiel metode til at låse op for opstartsindlæseren af ​​Fire-tablets, hvilket normalt er det første trin i at roote enhver given Android-enhed. Derfor er den eneste måde at roote en Amazon Fire-tablet på (uden hardware-modifikationer) at finde en udnyttelse i softwaren, der tillader brugeren at omgå Androids sikkerhedsmodel. I februar 2019, det er præcis, hvad XDA Senior Member diplomatic gjorde da han udgav en tråd på vores Amazon Fire tablet-fora. Han indså hurtigt, at denne udnyttelse var langt bredere i omfang end bare Amazons Fire-tablets.

Efter lidt test fra XDA Member diplomatiske og andre community-medlemmer, blev det bekræftet, at denne udnyttelse virker på et stort antal MediaTek-chips. Forfatteren udtaler, at udnyttelsen virker på "stort set alle MediaTeks 64-bit chips," og de nævner specifikt følgende som værende sårbare: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795. 173, MT8176, MT8183, MT6580 og MT6595. På grund af hvor mange MediaTek-chipsæt, der blev påvirket af denne udnyttelse, fik udnyttelsen navnet "MediaTek-su" eller "MTK-su" for kort. Den 17. april 2019 udgav diplomatic en anden tråd med titlen "Fantastisk Temp Root til MediaTek ARMv8" på vores "Diverse Android-udvikling"-forum. I denne tråd delte han et script, som brugere kan udføre for at give dem superbrugeradgang i shell, samt indstille SELinux, Linux-kernemodulet, der giver adgangskontrol til processer, til den meget usikre "permissive" stat. Det er chokerende nemt for en bruger at få root-adgang og indstille SELinux til eftergivende på deres egen enhed: Alt du skal gøre er at kopiere script til en midlertidig mappe, skift mapper til det sted, hvor scriptet er gemt, tilføj eksekverbare tilladelser til scriptet, og kør derefter manuskript.

Medlemmer af XDA-fællesskabet bekræftede, at udnyttelsen virkede på mindst følgende enheder:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Alba tablet serie
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 op til Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 -- kun op til Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 -- kun op til Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 -- kun op til Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 -- kun op til Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 -- kun op til Fire OS 7.3.1.0
20. Amazon Fire TV 2 -- kun op til Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163-baseret serie
24. Barnes & Noble NOOK Tablet 7" BNTV450 & BNTV460
25. Barnes & Noble NOOK Tablet 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Levetid Max
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 tablet
69. Onn 8" & 10" tablet-serien (MT8163)
70. OPPO A5s
71. OPPO F5 series/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

Læs mere

Med undtagelse af MediaTek-baserede telefoner fra Vivo, Huawei/Honor (efter Android 8.0+), OPPO (efter Android 8.0+) og Samsung, XDA-fællesskabsmedlemmer fandt ud af, at MediaTek-su fungerer oftere end ikke, når det forsøges på enheder med berørte chipsæt. Ifølge XDA Member diplomatic, Vivo, Huawei/Honor, OPPO og Samsung-enheder "bruger kernemodifikationer til at afskrække root-adgang via exploits," hvilket betyder, at udvikleren skal grave i kernekildekoden for disse enheder for at skabe "skræddersyede versioner" af udnytte. Det var ikke den ekstra indsats værd, så udvikleren valgte ikke at tilføje support til disse enheder, selvom udnyttelsen "i teorien" stadig kunne fungere.

Efterhånden burde det stå klart, at denne udnyttelse påvirker et stort antal enheder på markedet. MediaTek-chips driver hundredvis af budget- og mellemklasse smartphone-modeller, billige tablets og off-brand set-top-bokse, hvoraf de fleste sælges uden forventning om rettidige opdateringer fra producenten. Mange enheder, der stadig er påvirket af MediaTek-su, vil derfor næppe få en rettelse i uger eller måneder efter dagens offentliggørelse, hvis de overhovedet får en. Så hvad får MediaTek-su til at tjene sin "Kritiske" sværhedsgrad med en CVSS v3.0 score på 9,3?

Hvorfor MTK-su er en kritisk sikkerhedssårbarhed

For at gentage, den typiske måde at opnå root-adgang på en Android-enhed er først at låse bootloaderen op, hvilket deaktiverer verifikation af boot-partitionen. Når bootloaderen er låst op, kan brugeren introducere en superbruger-binær til systemet og også en superbruger-administrationsapp til at kontrollere, hvilke processer der har adgang til root. Oplåsning af bootloaderen er med vilje at deaktivere en af ​​de vigtigste sikkerhedsfunktioner på enheden, hvilket er grunden til, at brugeren skal tillade det udtrykkeligt at ske ved typisk at aktivere en skift i Udviklerindstillinger og derefter udstede en oplåsningskommando til bootloader. Med MediaTek-su behøver brugeren dog ikke at låse bootloaderen op for at få root-adgang. I stedet skal de blot kopiere et script til deres enhed og udføre det i shell. Brugeren er dog ikke den eneste, der kan gøre dette. Enhver app på din telefon kan kopiere MediaTek-su-scriptet til deres private mappe og derefter udføre det for at få root-adgang i shell. Faktisk XDA-medlem diplomatisk fremhæver denne mulighed i deres forumtråd, når de foreslår et alternativt sæt instruktioner ved at bruge enten Terminal Emulator til Android app eller Termux frem for ADB.

Med root-adgang falder Androids sikkerhedsmodel dybest set fra hinanden. For eksempel bliver tilladelser meningsløse i forbindelse med root, da en app med adgang til en root shell kan give sig selv enhver tilladelse, den ønsker. Ydermere, med en rodskal, er hele datapartitionen – inklusive filer gemt i de typisk utilgængelige private datamapper i applikationer – tilgængelig. En app med root kan også stille installere enhver anden app, den ønsker i baggrunden, og derefter give dem de tilladelser, de har brug for for at krænke dit privatliv. Ifølge XDA Recognized Developer topjohnwu, kan en ondsindet app endda "injicere kode direkte i Zygote ved at bruge ptrace", hvilket betyder, at en normal app på din enhed kan blive kapret for at udføre angriberens bud. Disse eksempler berører kun nogle få måder, hvorpå en app kan krænke din tillid i baggrunden uden din viden. Dog kan ondsindede apps skabe kaos på din enhed uden at skjule, hvad de laver. Ransomware er for eksempel ekstremt potent med root-adgang; hvis du ikke betaler, kan en hypotetisk ransomware-app totalt og irreversibelt gør din enhed ubrugelig ved at tørre hele enheden ren.

Den eneste "svaghed" i MediaTek-su er, at den giver en applikation kun "midlertidig" root-adgang, hvilket betyder, at en proces mister superbrugeradgang efter en genstart af enheden. Desuden på enheder, der kører Android 6.0 Marshmallow og nyere, tilstedeværelsen af Verified Boot og dm-verity blokere ændringer til skrivebeskyttede partitioner som system og leverandør. Disse to faktorer er dog for det meste kun hindringer for modders på vores fora frem for ondsindede aktører. For at overvinde begrænsningen af ​​midlertidig rod kan en ondsindet app simpelthen køre MediaTek-su-scriptet igen ved hver opstart. På den anden side er der ikke meget behov for at overvinde dm-verity, da permanente ændringer af systemet eller leverandørpartitioner sandsynligvis ikke vil interessere de fleste malware-forfattere; det er der jo allerede tons ting en ondsindet app kan gøre med en rodskal.

Hvis du spekulerer på på et teknisk niveau, hvad MediaTek-su udnytter, delte MediaTek nedenstående diagram med os, der opsummerer indgangspunktet. Fejlen findes tilsyneladende i en af ​​MediaTeks Linux Kernel-drivere kaldet "CMDQ." Beskrivelsen siger, at "ved at udføre IOCTL kommandoer i [] CMDQ-enhedens node," kan en lokal angriber "vilkårligt læse/skrive fysisk hukommelse, dumpe [kerne] symboltabellen til forudallokeret DMA-buffer, [og] manipuler DMA-bufferen for at ændre kerneindstillingerne for at deaktivere SELinux og eskalere til 'root' privilegium."

Ifølge diagrammet, som MediaTek delte med os, påvirker denne sårbarhed MediaTek-enheder med Linux Kernel-versioner 3.18, 4.4, 4.9 eller 4.14, der kører Android-versioner 7 Nougat, 8 Oreo eller 9 Pie. Sårbarheden kan tilsyneladende ikke udnyttes på MediaTek-enheder, der kører Android 10, da "adgangstilladelsen fra CMDQ enhedsknuder håndhæves også af SELinux." Denne afbødning kommer sandsynligvis fra en opdatering til MediaTeks BSP snarere end fra Android sig selv. Android 10s eneste afbødning af denne sårbarhed er dens begrænsning på apps, der udfører binære filer i deres hjemmemappe; som XDA Recognized Developer topjohnwu bemærker, kan en ondsindet app dog blot køre MediaTek-su-koden i et dynamisk bibliotek.

Selvom MediaTek har rettet dette problem i alle de berørte chipsæt, kan de ikke tvinge enhedsproducenter til at implementere programrettelserne. MediaTek fortalte os, at de havde patches klar helt tilbage i maj 2019. Ikke overraskende fik Amazon straks rettet problemet på tværs af sine enheder, når de blev gjort opmærksomme på det. Der er dog gået 10 måneder, siden MediaTek stillede en rettelse til rådighed for sine partnere, men endnu i marts 2020 har snesevis af OEM'er ikke rettet deres enheder. De fleste af de berørte enheder er på ældre Android-udgivelser med forældede Android Security Patch Levels (SPL'er), og opdateringssituationen er endnu værre, når du tænker på hundredvis af mindre kendte enhedsmodeller, der bruger disse MediaTek-chips. MediaTek har en alvorlig problemet her, så de har henvendt sig til Google for at få hjælp.

I modsætning til MediaTek, Google kan tvinge OEM'er til at opdatere deres enheder igennem licensaftaler eller programvilkår (såsom Android One). For at en OEM kan erklære, at en enhed er i overensstemmelse med 2020-03-05 Security Patch Level (SPL), skal enheden omfatte alle rammer, Linux-kerne og relevante leverandørdriverrettelser i Android Security Bulletin marts 2020, som inkluderer en rettelse til CVE-2020-0069, eller MediaTek-su. (Google ser faktisk ikke ud til at håndhæve det OEM'er slår faktisk alle patches sammen når man erklærer en bestemt SPL.) Nu hvor marts 2020-bulletinen er ude, burde denne historie være slut, ikke? Desværre er vi også nødt til at holde Googles fødder mod ilden for at trække deres fødder med at inkorporere plastrene.

Fejlen i sikkerhedspatch-processen

Hvis det ikke allerede er klart, behøver ikke enhver sikkerhedssårbarhed at ende i en Android Security Bulletin. Mange sårbarheder bliver opdaget og rettet af leverandører, uden at de nogensinde dukker op i den månedlige bulletin. MediaTek-su burde have været en af ​​dem, men af ​​flere årsager undlod flere OEM'er at integrere de patches, som MediaTek tilbyder. (Der er mange potentielle årsager til, lige fra mangel på ressourcer til forretningsbeslutninger til en fejl i kommunikationen.) Da jeg tidligere udtalte, at MediaTek "vendte sig til Google" for at få hjælp, det antydede, at MediaTek aktivt søgte hjælp fra Google for at få OEM'er til endelig at rette deres enheder. Men det var måske ikke rigtigt tilfældet. Det er min forståelse, at Google var uvidende om MediaTek-su, indtil det i øvrigt blev bragt i en sikkerhedsrapport fra TrendMicro offentliggjort 6. januar 2020. I rapporten, TrendMicro dokumenterede en anden sikkerhedssårbarhed, kaldet "brug-efter-fri i binderdriver"sårbarhed, der aktivt blev udnyttet i naturen. TrendMicro bemærkede, hvordan tre ondsindede apps opnåede root-adgang ved hjælp af en af ​​to metoder, enten "brug-efter-fri i binder-driver"-sårbarheden eller MediaTek-su.

I koden, der TrendMicro delt, kan vi tydeligt se, hvordan de ondsindede apps var målrettet mod specifikke enhedsmodeller (f.eks. Nokia 3, OPPO F9 og Redmi 6A) og bruger MediaTek-su på dem.

Jeg kan ikke tale for TrendMicro, men det ser ud til, at de ikke var klar over, at MediaTek-su var en endnu ikke-patchet udnyttelse. Deres fokus var trods alt på udnyttelsen af ​​"brug-efter-fri i binder-driver", og opdagelsen af ​​brugen af ​​MediaTek-su ser ud til at have været en eftertanke. (Jeg er sikker på, at hvis TrendMicro var opmærksomme på situationen omkring MediaTek-su, ville de have koordineret deres afsløringsindsats med Google.) Vi blev kun gjort opmærksomme på denne udnyttelse selv den 5. februar 2020, og efter selv at have undersøgt, hvor slemt det var, kontaktede vi Google om det den 7. februar, 2020. Google var så bekymret over konsekvenserne af at offentliggøre MediaTek-su, at de bad os om at vente med at udgive denne historie indtil i dag. Efter at have overvejet den uoprettelige skade, der kan påføres brugere, der er målrettet af malware ved hjælp af MediaTek-su, vi blev enige om at sætte et hold på denne historie indtil meddelelsen af ​​marts 2020 Android Sikkerhedsbulletin. Alligevel i betragtning af, hvor lang tid det vil tage mange enheder at få den seneste sikkerhedsopdatering, hvis de nogensinde få det overhovedet, er der helt sikkert et væld af enheder, der stadig er sårbare over for MediaTek-su et par måneder fra nu. Det burde være rædselsfuldt for alle med en sårbar enhed.

Selvom denne meget alvorlige, "kritiske" alvorlighedssårbarhed aktivt bliver udnyttet i naturen, er det kun Google indsat rettelsen til dette problem i marts 2020 bulletinen, hvilket er omkring 2 måneder efter, at de blev gjort opmærksomme på problem. Mens Google informerer sine Android-partnere om den seneste Android Security Bulletin hele 30 dage før bulletinen offentliggøres (dvs. OEM'er blev gjort opmærksomme på, hvad der står i bulletinen fra marts 2020 i begyndelsen af ​​februar 2020), kan Google, og gør det ofte, opdatere bulletinen med ændringer eller nye rettelser. Hvorfor Google ikke valgte at fremskynde medtagelsen af ​​en patch til et så alvorligt problem er uden for mig, især da MediaTek havde en rettelse til det for 10 måneder siden. Hvis en sådan fejl blev opdaget i Apples enheder, er jeg ikke i tvivl om, at de ville have udstedt en rettelse meget, meget hurtigere. Google satsede i det væsentlige på det risikable væddemål om, at MediaTek-su ville forblive lige så lavprofileret, som det allerede var indtil marts 2020 bulletinen. Selvom Google ser ud til at have været heldig i den forbindelse, har vi ingen idé om, hvor mange malware-forfattere allerede kender til udnyttelsen. Det har jo stået i en tilfældig XDA-forumtråd for næsten et helt år.

Der er endnu en part i denne debacle, som jeg ikke har talt meget om, og det er ophavsmanden til udnyttelsen, XDA Member diplomatic. Til hans kredit tror jeg ikke, at han havde nogen ondsindet hensigt med at udgive MediaTek-su. Vi kan tydeligt spore udnyttelsens oprindelse til diplomatikkens ønske om at modificere Amazon Fire-tabletterne. Diplomatic fortæller mig, at hans primære mål med at udvikle denne rodmetode var at hjælpe samfundet. Tilpasning af din enhed er, hvad XDA handler om, og diplomatisk indsats i fællesskabet er, hvad folk nyder ved foraene. Selvom diplomatikkens afvisning af at åbne kilde-projektet vækker nogle bekymringer, forklarer han, at han ønskede, at samfundet skulle nyde dette med root-adgang så længe som muligt. Da jeg første gang kontaktede diplomat, oplyste han også, at han var i et samarbejde med nogle partnere, der forhindrede ham i at dele projektets kildekode og forskning. Selvom jeg ikke var i stand til at få flere detaljer om dette samarbejde, spekulerer jeg på, om diplomatisk ville have valgt at offentliggøre denne udnyttelse, hvis MediaTek tilbød et bug bounty-program. Jeg kan ikke forestille mig, at en sårbarhed af denne størrelsesorden ikke ville betale en stor sum penge, hvis MediaTek rent faktisk havde et sådant program. Diplomatic hævder, at denne udnyttelse har været mulig siden det sene MediaTek MT6580-chipsæt i 2015, så man må spekulere på, om diplomatic overhovedet er den første person, der finder denne udnyttelse. Han fortæller mig, at han ikke anede, at MediaTek-su blev aktivt udnyttet, indtil denne artikel blev offentliggjort.

Hvis du vil kontrollere, om din enhed er sårbar over for MediaTek-su, så kør manuelt scriptet udsendt af XDA Member diplomatic i denne XDA-forumtråd. Hvis du indtaster en rodskal (du ved, når symbolet ændres fra $ til #), så ved du, at udnyttelsen virker. Hvis det virker, skal du vente på, at producenten af ​​din enhed udruller en opdatering, der patcher MediaTek-su. Hvis din enhed rapporterer sikkerhedspatch-niveauet for 2020-03-05, som er den seneste marts 2020 SPL, så er den næsten helt sikkert beskyttet mod MediaTek-su. Ellers skal du bare tjekke, om din enhed er sårbar.

---

Opdatering 1 (2/3/2020 kl. 21:45 EST): Denne artikel blev opdateret for at præcisere, at XDA Member diplomatic faktisk var klar over omfanget af denne sårbarhed, så snart han opdagede det tilbage i februar 2019, men at han var uvidende om udnyttelsens in-the-wild brug indtil offentliggørelsen af ​​denne artikel. Vi korrigerede også vores ordlyd vedrørende en grund til, at diplomatisk afviste at dele projektets kildekode.