Il rootkit critico di MediaTek colpisce milioni di dispositivi Android

Il primo lunedì di ogni mese, Google pubblica il Bollettino sulla sicurezza Android, una pagina che rivela tutte le vulnerabilità della sicurezza e le relative patch inviate da Google stesso o da altre terze parti. La giornata di oggi non ha fatto eccezione: Google ha appena reso pubblico l'Android Security Bulletin di marzo 2020. Una delle vulnerabilità documentate nell'ultimo bollettino è CVE-2020-0069, un exploit di sicurezza critico, in particolare un rootkit, che colpisce milioni di dispositivi dotati di chipset MediaTek, la grande azienda taiwanese di progettazione di chip. Sebbene il Bollettino sulla sicurezza Android di marzo 2020 sia apparentemente la prima volta che CVE-2020-0069 viene divulgato pubblicamente, i dettagli dell'exploit sono stati pubblicati apertamente su Internet, più specificamente, sui forum XDA-Developers, da aprile del 2019. Nonostante MediaTek abbia reso disponibile una patch un mese dopo la scoperta, la vulnerabilità è ancora sfruttabile su decine di modelli di dispositivi.

Ancora peggio, la vulnerabilità viene sfruttata attivamente dagli hacker. Ora MediaTek si è rivolta a Google per colmare questa lacuna di patch e proteggere milioni di dispositivi da questo exploit critico per la sicurezza.

Per tutti i lettori che non hanno familiarità con Sviluppatori XDA, siamo un sito che ospita i più grandi forum per le modifiche del software Android. Di solito, queste modifiche sono incentrate sull'ottenimento dell'accesso root sui dispositivi per eliminare bloatware, installare software personalizzato o modificare i parametri di sistema predefiniti. I tablet Fire di Amazon sono obiettivi popolari per gli hacker hobbisti sui nostri forum: sono pieni di dispositivi non installabili bloatware, non hanno accesso ad applicazioni software di base come Google Play Store e, soprattutto, sono molto economico. La sfida con il rooting dei tablet Amazon Fire è che sono pesantemente bloccati per impedire agli utenti di uscire dal giardino recintato di Amazon; Amazon non fornisce un metodo ufficiale per sbloccare il bootloader dei tablet Fire, che di solito è il primo passo per eseguire il root di qualsiasi dispositivo Android. Pertanto, l'unico modo per eseguire il root di un tablet Amazon Fire (senza modifiche hardware) è trovare un exploit nel software che consenta all'utente di aggirare il modello di sicurezza di Android. Nel febbraio del 2019, cioè esattamente quello che ha fatto il diplomatico del membro senior di XDA quando ha pubblicato un thread sui nostri forum sui tablet Amazon Fire. Si è subito reso conto che questo exploit aveva una portata molto più ampia rispetto ai soli tablet Fire di Amazon.

Dopo alcuni test da parte dei diplomatici dei membri XDA e di altri membri della comunità, è stato confermato che questo exploit funziona su un gran numero di chip MediaTek. L'autore afferma che l'exploit funziona su "praticamente tutti i chip a 64 bit di MediaTek" e specificatamente menziona i seguenti come vulnerabili: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6 580, e MT6595. A causa del numero di chipset MediaTek interessati da questo exploit, all'exploit è stato dato il nome "MediaTek-su" o "MTK-su" in breve. Il 17 aprile 2019, diplomatic ha pubblicato un secondo thread intitolato "Incredibile root temporaneo per MediaTek ARMv8" sul nostro forum "Varie sviluppo Android". In questo thread, ha condiviso uno script che gli utenti possono eseguire per garantire loro l'accesso come superutente nella shell, oltre a set SELinux, il modulo del kernel Linux che fornisce il controllo degli accessi ai processi, al "permissivo" altamente insicuro stato. Per un utente ottenere l'accesso root e impostare SELinux su permissivo sul proprio dispositivo è incredibilmente facile da fare: tutto quello che devi fare è copiare il file script in una cartella temporanea, modificare le directory in cui è archiviato lo script, aggiungere autorizzazioni eseguibili allo script, quindi eseguire il comando sceneggiatura.

I membri della comunità XDA hanno confermato che l'exploit ha funzionato almeno sui seguenti dispositivi:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Serie di compresse Alba
4. Alcatel 1 serie 5033
5. Alcatel 1C
6. Alcatel 3L (2018) serie 5034
7. Alcatel3T8
8. Alcatel A5 LED serie 5085
9. Serie Alcatel A30 5049
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 - solo fino a Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 - solo fino a Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 - solo fino a Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018: solo fino a Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 - solo fino a Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019: solo fino a Fire OS 7.3.1.0
20. Amazon Fire TV 2: solo fino a Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUSZenPad3s10Z500M
23. ASUS ZenPad Z3xxM(F) serie basata su MT8163
24. Barnes & Noble NOOK Tablet 7" BNTV450 e BNTV460
25. Barnes & Noble NOOK Tablet 10.1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Vita massima
29. BLU Vita Uno X
30. Serie BLU R1
31. BLU R2 LTE
32. BLU S1
33. Serbatoio BLU Xtreme Pro
34. BLU Vivo 8L
35. BLU Vivo XI
36. BLU Vivo XL4
37. Bluboo S8
38. BQ Aquaris M8
39. GATTO S41
40. CoolpadCool Play 8 Lite
41. Tocco del drago K10
42. Sensazione di eco
43. Gionee M7
44. HiSense Infinity H12 Lite
45. HuaweiGR3TAG-L21
46. Huawei Y5II
47. Serie Huawei Y6II MT6735
48. Lava Iris 88S
49. Lenovo serie C2
50. Lenovo Tab E8
51. LenovoTab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tributo alla dinastia
55. Serie LG X power 2/M320 (MTK)
56. Serie LG Xpression Plus 2/K40 LMX420
57. Lumigon T3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro7 Plus
61. Nokia1
62. Nokia 1 Plus
63. Nokia3
64. Nokia3.1
65. Nokia 3.1 Plus
66. Nokia5.1
67. Nokia 5.1Plus/X5
68. Su tablet Android 7".
69. Serie di tablet Onn da 8" e 10" (MT8163)
70. OPPO A5
71. Serie OPPO F5/A73: solo Android 8.x
72. Serie OPPO F7: solo Android 8.x
73. Serie OPPO F9: solo Android 8.x
74. Oukitel K12
75. Veramente D7
76. Regno 1
77. SonyXperia C4
78. Serie Sony Xperia C5
79. SonyXperia L1
80. SonyXperia L3
81. Serie Sony Xperia XA
82. Serie Sony Xperia XA1
83. Telecomunicazioni del sud Smartab ST1009X (MT8167)
84. Serie TECNO Spark 3
85. Serie Umidigi F1
86. Potenza Umidigi
87. Wiko Giro
88. Wiko Soleggiato
89. Wiko View3
90. Serie Xiaomi Redmi 6/6A
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest5Z3351S

Per saperne di più

Ad eccezione dei telefoni basati su MediaTek di Vivo, Huawei/Honor (dopo Android 8.0+), OPPO (dopo Android 8.0+) e Samsung, i membri della comunità XDA hanno scoperto che MediaTek-su funziona il più delle volte quando viene tentato su dispositivi interessati chipset. Secondo un membro diplomatico di XDA, i dispositivi Vivo, Huawei/Honor, OPPO e Samsung "utilizzano modifiche al kernel per scoraggiare l'accesso root tramite exploit", il che significa che lo sviluppatore dovrebbe scavare nel codice sorgente del kernel di questi dispositivi per creare "versioni su misura" del impresa. Non ne è valsa la pena, quindi lo sviluppatore ha scelto di non aggiungere il supporto per questi dispositivi anche se, "in teoria", l'exploit potrebbe ancora funzionare.

Dovrebbe ormai essere chiaro che questo exploit colpisce un gran numero di dispositivi sul mercato. I chip MediaTek alimentano centinaia di modelli di smartphone economici e di fascia media, tablet economici e fuori marca set-top box, la maggior parte dei quali viene venduta senza l'aspettativa di aggiornamenti tempestivi da parte del produttore. È quindi improbabile che molti dispositivi ancora interessati da MediaTek-su ottengano una correzione per settimane o mesi dopo la divulgazione di oggi, sempre che ne ottengano una. Quindi, cosa fa sì che MediaTek-su guadagni la sua gravità "Critica" con a CVSS v3.0 punteggio di 9,3?

Perché MTK-su è una vulnerabilità critica della sicurezza

Per ribadire, il modo tipico per ottenere l'accesso root su un dispositivo Android è prima sbloccare il bootloader, che disabilita la verifica della partizione di avvio. Una volta sbloccato il bootloader, l'utente può introdurre nel sistema un binario superutente e anche un'app di gestione superutente per controllare quali processi hanno accesso a root. Lo sblocco del bootloader disabilita intenzionalmente una delle principali funzionalità di sicurezza del dispositivo, motivo per cui l'utente deve farlo consentire esplicitamente che ciò accada abilitando in genere un interruttore in Opzioni sviluppatore e quindi emettendo un comando di sblocco al boot loader. Con MediaTek-su, invece, l'utente non deve sbloccare il bootloader per ottenere l'accesso root. Invece, tutto ciò che devono fare è copiare uno script sul proprio dispositivo ed eseguirlo nella shell. Tuttavia, l'utente non è l'unico che può farlo. Qualsiasi app sul telefono può copiare lo script MediaTek-su nella propria directory privata e quindi eseguirlo per ottenere l'accesso root nella shell. In effetti, membro XDA diplomatico evidenzia questa possibilità nel thread del forum quando suggeriscono una serie alternativa di istruzioni utilizzando il file Emulatore di terminale per app Android O Termux piuttosto che ADB.

Con l'accesso root, il modello di sicurezza di Android praticamente crolla. Ad esempio, le autorizzazioni diventano prive di significato nel contesto di root poiché un'app con accesso a una shell root può concedersi qualsiasi autorizzazione desideri. Inoltre, con una shell root, l'intera partizione dei dati, inclusi i file archiviati nelle directory dei dati privati ​​delle applicazioni, solitamente inaccessibili, è accessibile. Un'app con root può anche installare silenziosamente qualsiasi altra app che desidera in background e quindi concederle tutte le autorizzazioni necessarie per violare la tua privacy. Secondo lo sviluppatore riconosciuto XDA topjohnwu, un'app dannosa può persino "iniettare codice direttamente in Zygote utilizzando ptrace", il che significa che una normale app sul tuo dispositivo potrebbe essere dirottata per eseguire gli ordini dell'aggressore. Questi esempi toccano solo alcuni modi in cui un'app può violare la tua fiducia in background a tua insaputa. Tuttavia, le app dannose possono causare danni al tuo dispositivo senza nascondere ciò che stanno facendo. Il ransomware, ad esempio, lo è estremamente potente con accesso root; se non paghi, potrebbe farlo un'ipotetica app ransomware totalmente ed irreversibilmente rendere il dispositivo inutilizzabile pulendo l'intero dispositivo.

L'unico "punto debole" di MediaTek-su è che garantisce a un'applicazione solo l'accesso root "temporaneo", il che significa che un processo perde l'accesso come superutente dopo il riavvio del dispositivo. Inoltre, sui dispositivi con Android 6.0 Marshmallow e versioni successive, è presente la presenza di Avvio verificato e dm-verity bloccare le modifiche alle partizioni di sola lettura come sistema e fornitore. Tuttavia, questi due fattori sono per lo più solo ostacoli per i modder sui nostri forum piuttosto che per malintenzionati. Per superare la limitazione del root temporaneo, un'app dannosa può semplicemente eseguire nuovamente lo script MediaTek-su ad ogni avvio. D'altra parte, non c'è bisogno di superare dm-verity poiché è improbabile che le modifiche permanenti al sistema o alle partizioni del fornitore interessino la maggior parte degli autori di malware; dopo tutto, ci sono già tonnellate di cose che un'app dannosa può fare con una shell root.

Se ti stai chiedendo a livello tecnico cosa sta sfruttando MediaTek-su, MediaTek ha condiviso con noi il grafico seguente che riassume il punto di ingresso. Apparentemente il difetto esiste in uno dei driver del kernel Linux di MediaTek chiamato "CMDQ". La descrizione afferma che "eseguendo IOCTL comandi [nel] nodo del dispositivo CMDQ", un utente malintenzionato locale può "leggere/scrivere arbitrariamente la memoria fisica, eseguire il dump [della] tabella dei simboli del kernel nel buffer DMA pre-allocato, [e] manipolare il buffer DMA per modificare le impostazioni del kernel per disabilitare SELinux ed eseguire l'escalation a 'root' privilegio."

Secondo il grafico che MediaTek ha condiviso con noi, questa vulnerabilità colpisce i dispositivi MediaTek con versioni Linux Kernel 3.18, 4.4, 4.9 o 4.14 con versioni Android 7 Nougat, 8 Oreo o 9 Pie. Apparentemente la vulnerabilità non è sfruttabile sui dispositivi MediaTek con Android 10 poiché "il permesso di accesso di CMDQ dei nodi del dispositivo viene applicato anche da SELinux." Questa mitigazione probabilmente deriva da un aggiornamento al BSP di MediaTek piuttosto che da Android si. L'unica mitigazione di Android 10 per questa vulnerabilità è la sua restrizione sulle app che eseguono file binari nella loro home directory; tuttavia, come osserva topjohnwu XDA Recognized Developer, un'app dannosa può semplicemente eseguire il codice MediaTek-su in una libreria dinamica.

Anche se MediaTek ha risolto questo problema in tutti i chipset interessati, non può obbligare i produttori di dispositivi a implementare le patch. MediaTek ci ha detto che avevano le patch pronte già nel maggio del 2019. Amazon, non sorprende che abbia immediatamente risolto il problema sui suoi dispositivi una volta che ne è stata informata. Tuttavia, sono trascorsi 10 mesi da quando MediaTek ha reso disponibile una soluzione ai suoi partner, ancora in vigore Nel marzo del 2020, decine di OEM non hanno riparato i propri dispositivi. La maggior parte dei dispositivi interessati si trova su versioni Android precedenti con livelli di patch di sicurezza Android (SPL) obsoleti e la situazione degli aggiornamenti è ancora peggiore se si considera centinaia di modelli di dispositivi meno conosciuti che utilizzano questi chip MediaTek. MediaTek ha un serio problema qui, quindi si sono rivolti a Google per chiedere aiuto.

A differenza di MediaTek, Google Potere obbligare gli OEM ad aggiornare i propri dispositivi tramite accordi di licenza o termini del programma (come Android One). Affinché un OEM possa dichiarare che un dispositivo è conforme al livello di patch di sicurezza (SPL) del 05-03-2020, il dispositivo deve includere tutti i framework, Kernel Linux e correzioni dei driver del fornitore applicabili nel Bollettino sulla sicurezza Android di marzo 2020, che include una correzione per CVE-2020-0069 o MediaTek-su. (Google in realtà non sembra imporlo Gli OEM effettivamente uniscono tutte le patch quando si dichiara un certo SPL, però.) Ora che è uscito il bollettino di marzo 2020, questa storia dovrebbe essere finita, giusto? Purtroppo dobbiamo tenere i piedi sul fuoco anche a Google per aver ritardato l'incorporazione delle patch.

Il difetto nel processo delle patch di sicurezza

Nel caso in cui non fosse già chiaro, non tutte le vulnerabilità della sicurezza devono finire in un bollettino sulla sicurezza di Android. Molte vulnerabilità vengono scoperte e risolte dai fornitori senza che vengano mai visualizzate nel bollettino mensile. MediaTek-su avrebbe dovuto essere uno di questi, ma per molteplici ragioni diversi OEM non sono riusciti a integrare le patch offerte da MediaTek. (Ci sono molte potenziali ragioni per cui, che vanno dalla mancanza di risorse alle decisioni aziendali fino a un fallimento nella comunicazione.) Quando in precedenza ha affermato che MediaTek "si è rivolta a Google" per chiedere aiuto, ciò implica che MediaTek abbia attivamente cercato aiuto da Google per convincere gli OEM a risolvere finalmente i loro problemi dispositivi. Tuttavia, in realtà potrebbe non essere stato così. Mi risulta che Google non fosse a conoscenza di MediaTek-su finché non è stato incidentalmente menzionato in un rapporto sulla sicurezza TrendMicro pubblicato il 6 gennaio 2020. Nel rapporto, TrendMicro si stava documentando un altro vulnerabilità della sicurezza, soprannominata "use-after-free nel driver del raccoglitore"vulnerabilità, che veniva attivamente sfruttata in natura. TrendMicro ha notato come tre app dannose abbiano ottenuto l'accesso root utilizzando uno dei due metodi, la vulnerabilità "use-after-free in binder driver" o MediaTek-su.

Nel codice quello TrendMicro condiviso, possiamo vedere chiaramente come le app dannose prendessero di mira modelli di dispositivi specifici (ad es. Nokia 3, OPPO F9 e Redmi 6A) e utilizzando MediaTek-su su di essi.

Non posso parlare TrendMicro, ma sembra che non fossero a conoscenza del fatto che MediaTek-su fosse un exploit non ancora patchato. Dopotutto, la loro attenzione era rivolta all'exploit "use-after-free in binder driver", e la scoperta dell'uso di MediaTek-su sembra essere stata un ripensamento. (Sono sicuro che se TrendMicro fossero a conoscenza della situazione relativa a MediaTek-su, avrebbero coordinato i loro sforzi di divulgazione con Google.) Siamo stati informati solo noi stessi abbiamo commesso questo exploit il 5 febbraio 2020 e, dopo aver accertato personalmente la gravità dell'accaduto, abbiamo contattato Google al riguardo il 7 febbraio, 2020. Google era così preoccupato per le ripercussioni della pubblicità di MediaTek-su che ci ha chiesto di rimandare la pubblicazione di questa storia fino ad oggi. Dopo aver considerato il danno irreparabile che può essere inflitto agli utenti presi di mira dall'utilizzo di malware MediaTek-su, abbiamo deciso di sospendere questa storia fino all'annuncio di Android di marzo 2020 Bollettino sulla sicurezza. Tuttavia, considerando quanto tempo impiegheranno molti dispositivi per ottenere l'ultimo aggiornamento di sicurezza, se mai lo riceveranno capito, ci saranno sicuramente un sacco di dispositivi ancora vulnerabili a MediaTek-su tra pochi mesi Ora. Dovrebbe essere terrificante per chiunque abbia un dispositivo vulnerabile.

Anche se questa vulnerabilità molto seria e di gravità "critica" viene attivamente sfruttata in natura, solo da Google inserito la correzione di questo problema nel bollettino di marzo 2020, ovvero circa 2 mesi dopo essere stati informati del problema problema. Mentre Google informa i suoi partner Android sull'ultimo bollettino sulla sicurezza Android ben 30 giorni prima che il bollettino venga reso pubblico (ad es. Gli OEM sono stati informati del contenuto del bollettino di marzo 2020 all'inizio di febbraio 2020), Google può, e spesso lo fa, aggiornare il bollettino con modifiche o nuove correzioni. Perché Google non abbia scelto di accelerare l'inclusione di una patch per un problema così serio non riesco a capirlo, soprattutto quando MediaTek ha trovato una soluzione 10 mesi fa. Se un bug del genere fosse stato scoperto nei dispositivi Apple, non ho dubbi che avrebbero rilasciato una correzione molto, molto più velocemente. Google ha scommesso essenzialmente sulla rischiosa scommessa che MediaTek-su sarebbe rimasto apparentemente di basso profilo come lo era già fino al bollettino di marzo 2020. Anche se Google sembra essere stato fortunato in questo senso, non abbiamo idea di quanti autori di malware siano già a conoscenza dell’exploit. Dopotutto, è rimasto in un thread casuale del forum XDA per quasi un anno intero.

C'è un'altra parte in questa debacle di cui non ho parlato molto, ed è l'autore dell'exploit, membro diplomatico di XDA. A suo merito, non credo che avesse alcun intento malevolo nel pubblicare MediaTek-su. Possiamo chiaramente far risalire l'origine dell'exploit al desiderio del diplomatico di modificare i tablet Amazon Fire. Diplomatic mi dice che il suo obiettivo principale nello sviluppo di questo metodo root era aiutare la comunità. Personalizzare il tuo dispositivo è ciò che fa XDA e gli sforzi diplomatici nella comunità sono ciò che le persone apprezzano nei forum. Sebbene il rifiuto di Diplomatic di rendere open source il progetto sollevi alcune preoccupazioni, spiega che voleva che la comunità godesse di questo accesso root il più a lungo possibile. Quando ho contattato diplomatico per la prima volta, ha anche affermato di collaborare con alcuni partner che gli hanno impedito di condividere il codice sorgente e la ricerca del progetto. Anche se non sono riuscito a ottenere maggiori dettagli su questa collaborazione, mi chiedo se la diplomazia avrebbe scelto di rendere pubblico questo exploit se MediaTek avesse offerto un programma di bug bounty. Non riesco a immaginare che una vulnerabilità di questa portata non pagherebbe una grossa somma di denaro se MediaTek avesse effettivamente un programma del genere. Diplomatic afferma che questo exploit è stato possibile dal chipset MediaTek MT6580 della fine del 2015, quindi c'è da chiedersi se Diplomatic sia addirittura la prima persona a scoprire questo exploit. Mi dice che non aveva idea che MediaTek-su fosse attivamente sfruttato fino alla pubblicazione di questo articolo.

Se desideri verificare se il tuo dispositivo è vulnerabile a MediaTek-su, esegui manualmente lo script pubblicato dal membro diplomatico XDA in questo thread del forum XDA. Se inserisci una shell di root (saprai quando il simbolo cambia da $ a #), allora saprai che l'exploit funziona. Se funziona, dovrai attendere che il produttore del tuo dispositivo rilasci un aggiornamento che corregga MediaTek-su. Se il tuo dispositivo riporta il livello patch di sicurezza del 2020-03-05, che è l'ultimo SPL di marzo 2020, è quasi certamente protetto da MediaTek-su. Altrimenti, dovrai semplicemente verificare se il tuo dispositivo è vulnerabile.

---

Aggiornamento 1 (02/03/2020, 21:45 EST): Questo articolo è stato aggiornato per chiarire che il membro diplomatico di XDA era effettivamente consapevole della portata di questa vulnerabilità non appena lo ha scoperto l'ha scoperto nel febbraio del 2019, ma non era a conoscenza dell'uso in natura dell'exploit fino alla pubblicazione di questo articolo. Abbiamo anche corretto la nostra formulazione riguardante uno dei motivi per cui diplomatic ha rifiutato di condividere il codice sorgente del progetto.