Le rootkit MediaTek critique affecte des millions d’appareils Android

Le premier lundi de chaque mois, Google publie le Bulletin de sécurité Android, une page qui divulgue toutes les failles de sécurité et leurs correctifs soumis par Google lui-même ou d'autres tiers. Aujourd'hui n'a pas fait exception: Google vient de rendre public le bulletin de sécurité Android de mars 2020. L'une des vulnérabilités documentées dans le dernier bulletin est CVE-2020-0069, un exploit de sécurité critique, en particulier un rootkit, qui affecte des millions d'appareils équipés de chipsets de MediaTek, la grande société taïwanaise de conception de puces. Bien que le bulletin de sécurité Android de mars 2020 soit apparemment la première fois que CVE-2020-0069 est divulgué publiquement, Les détails de l'exploit sont en fait publiés ouvertement sur Internet, plus précisément sur les forums XDA-Developers, depuis avril. de 2019. Bien que MediaTek ait mis à disposition un correctif un mois après sa découverte, la vulnérabilité est toujours exploitable sur des dizaines de modèles d'appareils.

Pire encore, la vulnérabilité est activement exploitée par les pirates. MediaTek s'est désormais tourné vers Google pour combler cette lacune et sécuriser des millions d'appareils contre cet exploit de sécurité critique.

Pour tous les lecteurs qui ne connaissent pas Développeurs XDA, nous sommes un site qui héberge les plus grands forums de modifications logicielles Android. Habituellement, ces modifications se concentrent sur l'obtention d'un accès root sur les appareils afin de supprimer les bloatwares, d'installer des logiciels personnalisés ou de modifier les paramètres système par défaut. Les tablettes Fire d'Amazon sont des cibles populaires pour les pirates amateurs sur nos forums: elles regorgent de produits désinstallables. bloatware, n'ont pas accès aux applications logicielles de base comme le Google Play Store et, surtout, sont très bon marché. Le défi avec l'enracinement des tablettes Amazon Fire est qu'elles sont fortement verrouillées pour empêcher les utilisateurs de sortir du jardin clos d'Amazon; Amazon ne fournit pas de méthode officielle pour déverrouiller le chargeur de démarrage des tablettes Fire, ce qui constitue généralement la première étape pour rooter un appareil Android donné. Par conséquent, la seule façon de rooter une tablette Amazon Fire (sans modifications matérielles) est de trouver un exploit dans le logiciel qui permet à l'utilisateur de contourner le modèle de sécurité d'Android. En février 2019, c'est exactement ce que le membre diplomatique senior de XDA a fait lorsqu'il a publié un fil de discussion sur nos forums sur les tablettes Amazon Fire. Il s'est vite rendu compte que cet exploit avait une portée bien plus large que les seules tablettes Fire d'Amazon.

Après quelques tests effectués par les diplomates membres de XDA et d'autres membres de la communauté, il a été confirmé que cet exploit fonctionne sur un grand nombre de puces MediaTek. L'auteur déclare que l'exploit fonctionne sur « pratiquement toutes les puces 64 bits de MediaTek » et désigne spécifiquement les éléments suivants comme étant vulnérables: 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, et MT6595. En raison du nombre de chipsets MediaTek affectés par cet exploit, celui-ci a reçu le nom « MediaTek-su » ou « MTK-su » en abrégé. Le 17 avril 2019, la diplomatie a publié un deuxième fil de discussion intitulé «Racine temporaire incroyable pour MediaTek ARMv8" sur notre forum "Divers développement Android". Dans ce fil de discussion, il a partagé un script que les utilisateurs peuvent exécuter pour leur accorder un accès superutilisateur dans le shell, ainsi que pour définir SELinux, le module du noyau Linux qui fournit un contrôle d'accès aux processus, au « permissif » hautement non sécurisé État. Pour qu'un utilisateur obtienne un accès root et définisse SELinux sur permissif sur son propre appareil, c'est incroyablement simple à faire: tout ce que vous avez à faire est de copier le script dans un dossier temporaire, modifiez les répertoires dans lesquels le script est stocké, ajoutez des autorisations exécutables au script, puis exécutez le scénario.

Les membres de la communauté XDA ont confirmé que l'exploit fonctionnait sur au moins les appareils suivants :

1. Acer Iconia Un 10 B3-A30
2. Acer Iconia Un 10 B3-A40
3. Série de tablettes Alba
4. Alcatel série 1 5033
5. Alcatel1C
6. Alcatel 3L (2018) série 5034
7. Alcatel3T 8
8. Alcatel A5 LED série 5085
9. Alcatel A30 série 5049
10. Alcatel Idole 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 - jusqu'à Fire OS 6.3.1.2 build 0002517050244 uniquement
15. Amazon Fire HD 8 2016 - jusqu'à Fire OS 5.3.6.4 build 626533320 uniquement
16. Amazon Fire HD 8 2017 - jusqu'à Fire OS 5.6.4.0 build 636558520 uniquement
17. Amazon Fire HD 8 2018 - jusqu'à Fire OS 6.3.0.1 uniquement
18. Amazon Fire HD 10 2017 - jusqu'à Fire OS 5.6.4.0 build 636558520 uniquement
19. Amazon Fire HD 10 2019 - jusqu'à Fire OS 7.3.1.0 uniquement
20. Amazon Fire TV 2 - jusqu'à Fire OS 5.2.6.9 uniquement
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. Série ASUS ZenPad Z3xxM(F) basée sur MT8163
24. Barnes & Noble Tablette NOOK 7" BNTV450 et BNTV460
25. Barnes & Noble Tablette NOOK 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Vie Max
29. BLU Vie Un X
30. Série BLU R1
31. BLU R2 LTE
32. BLU S1
33. Réservoir BLU Xtreme Pro
34. BLU Vivo 8L
35. BLU Vivo XI
36. BLU Vivo XL4
37. Bluboo S8
38. BQ Aquaris M8
39. CHAT S41
40. Coolpad Cool Play 8 Lite
41. Dragon Touch K10
42. Sentiment d'écho
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Série Huawei Y6II MT6735
48. Iris de lave 88S
49. Série Lenovo C2
50. Onglet Lenovo E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. Dynastie hommage LG
55. Série LG X Power 2/M320 (MTK)
56. Série LG Xpression Plus 2/K40 LMX420
57. Lumigon T3
58. MeizuM5c
59. Meizu M6
60. MeizuPro 7 Plus
61. Nokia1
62. Nokia1 Plus
63. Nokia3
64. Nokia3.1
65. Nokia3.1 Plus
66. Nokia5.1
67. Nokia5.1 Plus/X5
68. Sur une tablette Android 7"
69. Série de tablettes Onn 8" et 10" (MT8163)
70. OPPO A5
71. Série OPPO F5/A73 - Android 8.x uniquement
72. Série OPPO F7 - Android 8.x uniquement
73. Série OPPO F9 - Android 8.x uniquement
74. Oukitel K12
75. Protruly D7
76. Royaume moi 1
77. SonyXperia C4
78. Série Sony Xperia C5
79. SonyXperia L1
80. SonyXperia L3
81. Série Sony Xperia XA
82. Série Sony Xperia XA1
83. Southern Telecom Smartab ST1009X (MT8167)
84. Série TECNO Spark 3
85. Série Umidigi F1
86. Puissance Umidigi
87. Wiko Ride
88. Wiko Ensoleillé
89. Wiko View3
90. Série Xiaomi Redmi 6/6A
91. ZTE Lame A530
92. ZTE Lame D6/V6
93. ZTE Quest 5 Z3351S

En savoir plus

À l'exception des téléphones basés sur MediaTek de Vivo, Huawei/Honor (après Android 8.0+), OPPO (après Android 8.0+) et Les membres de la communauté Samsung et XDA ont constaté que MediaTek-su fonctionne le plus souvent lorsqu'il est essayé sur des appareils concernés. chipsets. Selon les membres diplomatiques de XDA, les appareils Vivo, Huawei/Honor, OPPO et Samsung « utilisent des modifications du noyau pour dissuader l'accès root via exploits", ce qui signifie que le développeur devra fouiller dans le code source du noyau de ces appareils pour créer des "version(s) sur mesure" du exploiter. Cela n’en valait pas la peine, c’est pourquoi le développeur a choisi de ne pas ajouter de support pour ces appareils même si, « en théorie », l’exploit pouvait toujours fonctionner.

Il devrait désormais être clair que cet exploit affecte un grand nombre d’appareils sur le marché. Les puces MediaTek alimentent des centaines de modèles de smartphones économiques et milieu de gamme, des tablettes bon marché et hors marque décodeurs, dont la plupart sont vendus sans attente de mises à jour en temps opportun de la part du fabricant. Il est donc peu probable que de nombreux appareils encore affectés par MediaTek-su obtiennent un correctif avant des semaines ou des mois après la divulgation d'aujourd'hui, voire pas du tout. Alors, qu'est-ce qui fait que MediaTek-su mérite sa gravité « Critique » avec un CVSS v3.0 note de 9,3 ?

Pourquoi MTK-su est une vulnérabilité de sécurité critique

Pour réitérer, la manière typique d'obtenir un accès root sur un appareil Android consiste à d'abord déverrouiller le chargeur de démarrage, ce qui désactive la vérification de la partition de démarrage. Une fois le chargeur de démarrage déverrouillé, l'utilisateur peut introduire un binaire de superutilisateur dans le système ainsi qu'une application de gestion de superutilisateur pour contrôler quels processus ont accès à root. Le déverrouillage du chargeur de démarrage désactive intentionnellement l'une des principales fonctionnalités de sécurité de l'appareil, c'est pourquoi l'utilisateur doit autorisez explicitement que cela se produise en activant généralement une bascule dans les options du développeur, puis en émettant une commande de déverrouillage au chargeur de démarrage. Avec MediaTek-su, cependant, l'utilisateur n'a pas besoin de déverrouiller le chargeur de démarrage pour obtenir un accès root. Au lieu de cela, tout ce qu'ils ont à faire est de copier un script sur leur appareil et de l'exécuter dans le shell. Cependant, l’utilisateur n’est pas le seul à pouvoir le faire. N'importe quelle application sur votre téléphone peut copier le script MediaTek-su dans son répertoire privé, puis l'exécuter pour obtenir un accès root dans le shell. En fait, le membre diplomatique de XDA souligne cette possibilité dans leur fil de discussion lorsqu'ils suggèrent un autre ensemble d'instructions en utilisant soit le Application Émulateur de terminal pour Android ou Termux plutôt que la BAD.

Avec l’accès root, le modèle de sécurité d’Android s’effondre. Par exemple, les autorisations n'ont plus de sens dans le contexte de root, car une application ayant accès à un shell racine peut s'accorder n'importe quelle autorisation qu'elle souhaite. De plus, avec un shell racine, l'intégralité de la partition de données, y compris les fichiers stockés dans les répertoires de données privés généralement inaccessibles des applications, est accessible. Une application avec root peut également installer silencieusement toute autre application de son choix en arrière-plan, puis lui accorder toutes les autorisations dont elle a besoin pour violer votre vie privée. Selon le développeur reconnu XDA topjohnwu, une application malveillante peut même « injecter du code directement dans Zygote en utilisant ptrace », ce qui signifie qu'une application normale sur votre appareil pourrait être détournée pour exécuter les ordres de l'attaquant. Ces exemples n’abordent que quelques façons dont une application peut violer votre confiance en arrière-plan à votre insu. Cependant, les applications malveillantes peuvent faire des ravages sur votre appareil sans cacher ce qu'elles font. Les ransomwares, par exemple, sont extrêmement puissant avec accès root; si vous ne payez pas, une hypothétique application de ransomware pourrait totalement et irréversiblement rendez votre appareil inutilisable en essuyant tout l’appareil.

La seule « faiblesse » de MediaTek-su est qu'il n'accorde à une application qu'un accès root « temporaire », ce qui signifie qu'un processus perd l'accès superutilisateur après un redémarrage de l'appareil. De plus, sur les appareils fonctionnant sous Android 6.0 Marshmallow et supérieur, la présence de Démarrage vérifié et dm-verity bloquer les modifications des partitions en lecture seule comme le système et le fournisseur. Cependant, ces deux facteurs ne sont pour la plupart que des obstacles pour les moddeurs sur nos forums plutôt que des acteurs malveillants. Pour surmonter la limitation de la racine temporaire, une application malveillante peut simplement réexécuter le script MediaTek-su à chaque démarrage. D'un autre côté, il n'est guère nécessaire de contourner dm-verity car il est peu probable que les modifications permanentes apportées au système ou aux partitions du fournisseur intéressent la plupart des auteurs de logiciels malveillants; après tout, il y en a déjà tonnes des choses qu'une application malveillante peut faire avec un shell root.

Si vous vous demandez sur le plan technique ce qu'exploite MediaTek-su, MediaTek a partagé avec nous le tableau ci-dessous qui résume le point d'entrée. La faille existe apparemment dans l'un des pilotes du noyau Linux de MediaTek appelé "CMDQ". La description indique que "en exécutant IOCTL commandes dans [le] nœud du périphérique CMDQ », un attaquant local peut « lire/écrire arbitrairement la mémoire physique, vider [la] table des symboles du noyau dans le tampon DMA pré-alloué, [et] manipuler le tampon DMA pour modifier les paramètres du noyau afin de désactiver SELinux et passer à la « racine » privilège."

Selon le graphique que MediaTek a partagé avec nous, cette vulnérabilité affecte les appareils MediaTek dotés des versions 3.18, 4.4, 4.9 ou 4.14 du noyau Linux exécutant les versions Android 7 Nougat, 8 Oreo ou 9 Pie. La vulnérabilité n'est apparemment pas exploitable sur les appareils MediaTek fonctionnant sous Android 10, puisque « l'autorisation d'accès de CMDQ Les nœuds de périphérique sont également appliqués par SELinux. " Cette atténuation provient probablement d'une mise à jour du BSP de MediaTek plutôt que d'Android. lui-même. La seule atténuation d'Android 10 pour cette vulnérabilité est son restriction sur les applications exécutant des binaires dans leur répertoire personnel; cependant, comme le note topjohnwu, développeur reconnu par XDA, une application malveillante peut simplement exécuter le code MediaTek-su dans une bibliothèque dynamique.

Même si MediaTek a corrigé ce problème sur tous les chipsets concernés, ils ne peuvent pas forcer les fabricants d'appareils à implémenter les correctifs. MediaTek nous a dit qu'ils avaient des correctifs prêts dès mai 2019. Sans surprise, Amazon a immédiatement corrigé le problème sur tous ses appareils dès qu'ils en ont été informés. Pourtant, 10 mois se sont écoulés depuis que MediaTek a mis un correctif à disposition de ses partenaires, pourtant en Mars 2020, des dizaines d'OEM n'ont pas réparé leurs appareils. La plupart des appareils concernés utilisent des versions Android plus anciennes avec des niveaux de correctifs de sécurité Android (SPL) obsolètes, et la situation de mise à jour est encore pire si l'on considère le des centaines de modèles d'appareils moins connus utilisant ces puces MediaTek. MediaTek a un sérieux problème entre ses mains ici, ils se sont donc tournés vers Google pour obtenir de l'aide.

Contrairement à MediaTek, Google peut obliger les OEM à mettre à jour leurs appareils via accords de licence ou les termes du programme (tels qu'Android One). Pour qu'un OEM puisse déclarer qu'un appareil est conforme au niveau de correctif de sécurité (SPL) du 05/03/2020, l'appareil doit inclure tous les frameworks, Correctifs du noyau Linux et des pilotes du fournisseur applicables dans le bulletin de sécurité Android de mars 2020, qui inclut un correctif pour CVE-2020-0069, ou MediaTek-su. (Google ne semble pas réellement appliquer cela Les OEM fusionnent en fait tous les correctifs en déclarant un certain SPL, cependant.) Maintenant que le bulletin de mars 2020 est sorti, cette histoire devrait être terminée, n'est-ce pas? Malheureusement, nous devons également mettre les pieds au feu par Google pour avoir traîné les pieds dans l'intégration des correctifs.

La faille dans le processus de patch de sécurité

Au cas où cela ne serait pas déjà clair, toutes les vulnérabilités de sécurité ne doivent pas nécessairement se retrouver dans un bulletin de sécurité Android. De nombreuses vulnérabilités sont découvertes et corrigées par les fournisseurs sans qu'elles n'apparaissent dans le bulletin mensuel. MediaTek-su aurait dû en faire partie, mais pour plusieurs raisons, plusieurs OEM n'ont pas réussi à intégrer les correctifs proposés par MediaTek. (Il existe de nombreuses raisons potentielles à cela, allant du manque de ressources aux décisions commerciales en passant par un échec de communication.) Quand j'avais auparavant a déclaré que MediaTek « s'est tourné vers Google » pour obtenir de l'aide, cela impliquait que MediaTek recherchait activement l'aide de Google pour amener les OEM à enfin réparer leur problème. dispositifs. Cependant, cela n’a peut-être pas été le cas. Je crois comprendre que Google n'était pas au courant de MediaTek-su jusqu'à ce qu'il soit évoqué par hasard dans un rapport de sécurité de TrendMicro publié le 6 janvier 2020. Dans le rapport, TrendMicro documentait un autre vulnérabilité de sécurité, surnommée le "utilisation après libération dans le pilote de classeur" vulnérabilité, qui était activement exploitée dans la nature. TrendMicro a noté comment trois applications malveillantes ont obtenu l'accès root en utilisant l'une des deux méthodes suivantes, soit la vulnérabilité « utilisation après libération dans le pilote de classeur » ou MediaTek-su.

Dans le code qui TrendMicro partagés, nous pouvons clairement voir comment les applications malveillantes ciblaient des modèles d'appareils spécifiques (par ex. Nokia 3, OPPO F9 et Redmi 6A) et en utilisant MediaTek-su dessus.

je ne peux pas parler pour TrendMicro, mais il semble qu'ils ignoraient que MediaTek-su était un exploit non encore corrigé. Après tout, ils se sont concentrés sur l'exploit "utilisation après libération dans le pilote de classeur", et la découverte de l'utilisation de MediaTek-su semble avoir été une réflexion après coup. (je suis sûr que si TrendMicro étaient au courant de la situation entourant MediaTek-su, ils auraient coordonné leurs efforts de divulgation avec Google.) Nous n'avons été informés que de nous-mêmes avons découvert cet exploit le 5 février 2020, et après avoir enquêté par nous-mêmes sur la gravité de la situation, nous avons contacté Google à ce sujet le 7 février, 2020. Google était tellement préoccupé par les répercussions de la publicité sur MediaTek-su qu'il nous a demandé de retarder la publication de cette histoire jusqu'à aujourd'hui. Après avoir considéré le préjudice irréparable qui peut être infligé aux utilisateurs ciblés par des logiciels malveillants utilisant MediaTek-su, nous avons convenu de suspendre cette histoire jusqu'à l'annonce de l'Android de mars 2020 Bulletin de sécurité. Néanmoins, compte tenu du temps qu'il faudra à de nombreux appareils pour obtenir la dernière mise à jour de sécurité, le cas échéant comprenez-le, il y aura forcément une tonne d'appareils encore vulnérables à MediaTek-su dans quelques mois maintenant. Cela devrait être horrible pour toute personne possédant un appareil vulnérable.

Même si cette vulnérabilité très grave et de gravité « critique » est activement exploitée dans la nature, Google ne a inséré le correctif pour ce problème dans le bulletin de mars 2020, soit environ 2 mois après avoir été informé du problème. problème. Bien que Google informe ses partenaires Android du dernier bulletin de sécurité Android 30 jours complets avant que le bulletin ne soit rendu public (c.-à-d. Les OEM ont été informés du contenu du bulletin de mars 2020 début février 2020), Google peut mettre à jour le bulletin, et le fait souvent, avec des modifications ou de nouveaux correctifs. Pourquoi Google n'a pas choisi d'accélérer l'inclusion d'un correctif pour un problème aussi grave me dépasse, surtout lorsque MediaTek a trouvé un correctif il y a 10 mois. Si un tel bug avait été découvert sur les appareils Apple, je suis convaincu qu'ils auraient publié un correctif. beaucoup, beaucoup plus vite. Google a essentiellement misé sur le pari risqué que MediaTek-su resterait aussi discret qu'il l'était déjà jusqu'au bulletin de mars 2020. Bien que Google semble avoir eu de la chance à cet égard, nous n'avons aucune idée du nombre d'auteurs de logiciels malveillants qui connaissent déjà l'exploit. Après tout, il se trouve dans un fil de discussion aléatoire du forum XDA depuis presque une année entière.

Il y a une autre partie dans cette débâcle dont je n'ai pas beaucoup parlé, et c'est l'auteur de l'exploit, XDA Member Diplomatique. À son honneur, je ne pense pas qu'il ait eu une intention malveillante en publiant MediaTek-su. Nous pouvons clairement retracer l'origine de l'exploit au désir diplomatique de modifier les tablettes Amazon Fire. Diplomatic me dit que son objectif principal en développant cette méthode racine était d'aider la communauté. La personnalisation de votre appareil est l'essence même de XDA, et les efforts diplomatiques au sein de la communauté sont ce que les gens apprécient sur les forums. Bien que le refus du diplomate d'ouvrir le projet en source libre soulève certaines inquiétudes, il explique qu'il souhaitait que la communauté puisse profiter de cet accès root le plus longtemps possible. Lorsque j'ai contacté le diplomate pour la première fois, il a également déclaré qu'il collaborait avec certains partenaires, ce qui l'empêchait de partager le code source et les recherches du projet. Bien que je n'aie pas pu obtenir plus de détails sur cette collaboration, je me demande si les diplomates auraient choisi de rendre public cet exploit si MediaTek proposait un programme de prime aux bogues. Je ne peux pas imaginer qu'une vulnérabilité de cette ampleur ne rapporterait pas une grosse somme d'argent si MediaTek disposait réellement d'un tel programme. Diplomatic affirme que cet exploit est possible depuis le chipset MediaTek MT6580 fin 2015, il faut donc se demander si Diplomatic est même la première personne à trouver cet exploit. Il me dit qu'il n'avait aucune idée que MediaTek-su était activement exploité jusqu'à la publication de cet article.

Si vous souhaitez vérifier si votre appareil est vulnérable à MediaTek-su, exécutez manuellement le script publié par le membre diplomatique de XDA. dans ce fil de discussion du forum XDA. Si vous entrez dans un shell racine (vous saurez quand le symbole passe de $ à #), alors vous saurez que l'exploit fonctionne. Si cela fonctionne, vous devrez attendre que le fabricant de votre appareil déploie une mise à jour corrigeant MediaTek-su. Si votre appareil signale le niveau de correctif de sécurité du 05/03/2020, qui est le dernier SPL de mars 2020, alors il est presque certainement protégé contre MediaTek-su. Sinon, il vous suffira de vérifier si votre appareil est vulnérable.

---

Mise à jour 1 (02/03/2020 à 21 h 45 HNE): Cet article a été mis à jour pour clarifier que le membre diplomatique de XDA était réellement conscient de l'étendue de cette vulnérabilité dès qu'il l'a découvert en février 2019, mais qu'il n'était pas au courant de l'utilisation de l'exploit dans la nature jusqu'à la publication de cet article. article. Nous avons également corrigé notre formulation concernant l'une des raisons pour lesquelles les diplomates ont refusé de partager le code source du projet.