El rootkit crítico de MediaTek afecta a millones de dispositivos Android

El primer lunes de cada mes, Google publica el Boletín de seguridad de Android, una página que revela todas las vulnerabilidades de seguridad y sus parches enviados por el propio Google o por otros terceros. Hoy no fue la excepción: Google acaba de hacer público el Boletín de Seguridad de Android correspondiente a marzo de 2020. Una de las vulnerabilidades documentadas en el último boletín es CVE-2020-0069, un exploit de seguridad crítico, específicamente un rootkit, que afecta a millones de dispositivos con chipsets de MediaTek, la gran empresa taiwanesa de diseño de chips. Aunque el Boletín de seguridad de Android de marzo de 2020 es aparentemente la primera vez que CVE-2020-0069 se divulga públicamente, Los detalles del exploit han estado disponibles abiertamente en Internet (más específicamente, en los foros de desarrolladores de XDA) desde abril. de 2019. A pesar de que MediaTek puso a disposición un parche un mes después del descubrimiento, la vulnerabilidad aún se puede explotar en docenas de modelos de dispositivos.

Peor aún, los piratas informáticos están explotando activamente la vulnerabilidad. Ahora MediaTek ha recurrido a Google para cerrar esta brecha de parches y proteger millones de dispositivos contra este problema de seguridad crítico.

Para aquellos lectores que no estén familiarizados con Desarrolladores XDA, somos un sitio que alberga los foros más grandes para modificaciones de software de Android. Por lo general, estas modificaciones se centran en obtener acceso de root en los dispositivos para eliminar bloatware, instalar software personalizado o modificar los parámetros predeterminados del sistema. Las tabletas Fire de Amazon son objetivos populares para los piratas informáticos aficionados en nuestros foros: están llenas de elementos no instalables. bloatware, carecen de acceso a aplicaciones de software básicas como Google Play Store y, lo más importante, son muy barato. El desafío de rootear tabletas Amazon Fire es que están fuertemente bloqueadas para evitar que los usuarios salgan del jardín amurallado de Amazon; Amazon no proporciona un método oficial para desbloquear el gestor de arranque de las tabletas Fire, que suele ser el primer paso para rootear cualquier dispositivo Android. Por lo tanto, la única manera de rootear una tableta Amazon Fire (sin modificaciones de hardware) es encontrar un exploit en el software que permita al usuario eludir el modelo de seguridad de Android. En febrero de 2019, eso es exactamente lo que hizo el diplomático miembro senior de XDA cuando publicó un hilo en nuestros foros de tabletas Amazon Fire. Rápidamente se dio cuenta de que este exploit tenía un alcance mucho más amplio que el de las tabletas Fire de Amazon.

Después de algunas pruebas por parte de diplomáticos miembros de XDA y otros miembros de la comunidad, se confirmó que este exploit funciona en una gran cantidad de chips MediaTek. El autor afirma que el exploit funciona en "prácticamente todos los chips de 64 bits de MediaTek" y menciona específicamente los siguientes como vulnerables: 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, y MT6595. Debido a la cantidad de conjuntos de chips MediaTek afectados por este exploit, se le dio el nombre de "MediaTek-su" o "MTK-su", para abreviar. El 17 de abril de 2019, la diplomacia publicó un segundo hilo titulado "Increíble raíz temporal para MediaTek ARMv8" en nuestro foro "Desarrollo varios de Android". En este hilo, compartió un script que los usuarios pueden ejecutar para otorgarles acceso de superusuario en el shell, así como configurar SELinux, el módulo del kernel de Linux que proporciona control de acceso a procesos, a los altamente inseguros "permisivos" estado. Para que un usuario obtenga acceso root y configure SELinux como permisivo en su propio dispositivo es sorprendentemente fácil de hacer: todo lo que tiene que hacer es copiar el script a una carpeta temporal, cambie los directorios donde se almacena el script, agregue permisos ejecutables al script y luego ejecute el guion.

Los miembros de la comunidad XDA confirmaron que el exploit funcionó al menos en los siguientes dispositivos:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Serie de tabletas Alba
4. Alcatel serie 1 5033
5. Alcatel 1C
6. Alcatel 3L (2018) serie 5034
7. Alcatel 3T 8
8. Alcatel A5 LED serie 5085
9. Serie Alcatel A30 5049
10. Alcatel Ídolo 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019: hasta Fire OS 6.3.1.2, compilación 0002517050244 únicamente
15. Amazon Fire HD 8 2016: hasta Fire OS 5.3.6.4, compilación 626533320 solamente
16. Amazon Fire HD 8 2017: hasta Fire OS 5.6.4.0, compilación 636558520 solamente
17. Amazon Fire HD 8 2018: solo hasta Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017: hasta Fire OS 5.6.4.0, compilación 636558520 únicamente
19. Amazon Fire HD 10 2019: solo hasta Fire OS 7.3.1.0
20. Amazon Fire TV 2: hasta Fire OS 5.2.6.9 únicamente
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. Serie basada en ASUS ZenPad Z3xxM(F) MT8163
24. Tableta NOOK de Barnes & Noble de 7" BNTV450 y BNTV460
25. Barnes & Noble NOOK Tablet 10.1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Max
29. BLU Life One X
30. Serie BLU R1
31. BLU R2 LTE
32. AZUL 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. GATO S41
40. Coolpad Cool Juego 8 Lite
41. Dragón táctil K10
42. Sensación de eco
43. Gionee M7
44. HiSense Infinity H12 Lite
45. HUAWEI GR3 TAG-L21
46. Huawei Y5II
47. Serie Huawei Y6II MT6735
48. Lava Iris 88S
49. Serie Lenovo C2
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. Dinastía tributo LG
55. Serie LG X power 2/M320 (MTK)
56. Serie LG Xpression Plus 2/K40 LMX420
57. Lumigón 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. Una tableta Android de 7"
69. Serie de tabletas Onn de 8" y 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. Protruly D7
76. realme 1
77. Sony Xperia C4
78. Serie Sony Xperia C5
79. Sony Xperia L1
80. Sony Xperia L3
81. Serie Sony Xperia XA
82. Serie Sony Xperia XA1
83. Telecomunicaciones del Sur Smartab ST1009X (MT8167)
84. TECNO Spark serie 3
85. Serie Umidigi F1
86. Poder Umidigi
87. Wiko Ride
88. Wiko Sunny
89. Wiko View3
90. Serie Xiaomi Redmi 6/6A
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

leer más

Con la excepción de los teléfonos basados ​​en MediaTek de Vivo, Huawei/Honor (después de Android 8.0+), OPPO (después de Android 8.0+) y Los miembros de la comunidad Samsung y XDA descubrieron que MediaTek-su funciona la mayoría de las veces cuando se intenta en dispositivos con problemas conjuntos de chips. Según un diplomático miembro de XDA, los dispositivos Vivo, Huawei/Honor, OPPO y Samsung "utilizan modificaciones del kernel para impedir el acceso root a través de exploits", lo que significa que el desarrollador necesitaría profundizar en el código fuente del kernel de estos dispositivos para crear "versiones adaptadas" del explotar. No valió la pena el esfuerzo adicional, por lo que el desarrollador decidió no agregar soporte para estos dispositivos a pesar de que, "en teoría", el exploit aún podría funcionar.

A estas alturas debería quedar claro que este exploit afecta a una gran cantidad de dispositivos en el mercado. Los chips MediaTek impulsan cientos de modelos de teléfonos inteligentes económicos y de gama media, tabletas económicas y otras marcas. decodificadores, la mayoría de los cuales se venden sin la expectativa de actualizaciones oportunas por parte del fabricante. Por lo tanto, es poco probable que muchos dispositivos aún afectados por MediaTek-su obtengan una solución durante semanas o meses después de la divulgación de hoy, si es que la obtienen. Entonces, ¿qué hace que MediaTek-su gane su gravedad "crítica" con un CVSS v3.0 puntuación de 9,3?

Por qué MTK-su es una vulnerabilidad de seguridad crítica

Para reiterar, la forma típica de lograr acceso root en un dispositivo Android es desbloquear primero el gestor de arranque, lo que desactiva la verificación de la partición de arranque. Una vez desbloqueado el gestor de arranque, el usuario puede introducir un binario de superusuario en el sistema y también una aplicación de gestión de superusuario para controlar qué procesos tienen acceso a la raíz. Desbloquear el gestor de arranque es desactivar intencionalmente una de las funciones de seguridad clave del dispositivo, por lo que el usuario debe permitir explícitamente que esto suceda habilitando normalmente un interruptor en Opciones de desarrollador y luego emitiendo un comando de desbloqueo al gestor de arranque. Sin embargo, con MediaTek-su, el usuario no tiene que desbloquear el gestor de arranque para obtener acceso de root. En cambio, todo lo que tienen que hacer es copiar un script a su dispositivo y ejecutarlo en el shell. Sin embargo, el usuario no es el único que puede hacer esto. Cualquier aplicación en su teléfono puede copiar el script MediaTek-su a su directorio privado y luego ejecutarlo para obtener acceso de root en el shell. De hecho, el diplomático miembro de XDA destaca esta posibilidad en el hilo del foro cuando sugieren un conjunto alternativo de instrucciones usando el Aplicación Emulador de terminal para Android o Termux en lugar del BAsD.

Con el acceso root, el modelo de seguridad de Android básicamente se desmorona. Por ejemplo, los permisos pierden sentido en el contexto de root, ya que una aplicación con acceso a un shell root puede otorgarse a sí misma cualquier permiso que desee. Además, con un shell raíz, se puede acceder a la totalidad de la partición de datos, incluidos los archivos almacenados en los directorios de datos privados de las aplicaciones, que normalmente son inaccesibles. Una aplicación con root también puede instalar silenciosamente cualquier otra aplicación que desee en segundo plano y luego otorgarle los permisos que necesite para violar su privacidad. Según el desarrollador reconocido de XDA topjohnwu, una aplicación maliciosa puede incluso "inyectar código directamente en Zygote usando ptrace", lo que significa que una aplicación normal en su dispositivo podría ser secuestrada para cumplir las órdenes del atacante. Estos ejemplos sólo abordan algunas formas en las que una aplicación puede violar su confianza en segundo plano sin su conocimiento. Sin embargo, las aplicaciones maliciosas pueden causar estragos en su dispositivo sin ocultar lo que están haciendo. El ransomware, por ejemplo, es extremadamente potente con acceso root; Si no paga, una hipotética aplicación de ransomware podría total e irreversiblemente Haga que su dispositivo no funcione limpiando todo el dispositivo.

La única "debilidad" de MediaTek-su es que otorga a una aplicación acceso raíz "temporal", lo que significa que un proceso pierde el acceso de superusuario después de reiniciar el dispositivo. Además, en dispositivos con Android 6.0 Marshmallow y superior, la presencia de Arranque verificado y dm-verity bloquear modificaciones a particiones de solo lectura como sistema y proveedor. Sin embargo, estos dos factores son en su mayoría sólo obstáculos para los modders en nuestros foros y no actores maliciosos. Para superar la limitación de la raíz temporal, una aplicación maliciosa puede simplemente volver a ejecutar el script MediaTek-su en cada inicio. Por otro lado, hay poca necesidad de superar dm-verity ya que es poco probable que las modificaciones permanentes en el sistema o en las particiones del proveedor interesen a la mayoría de los autores de malware; después de todo, ya hay montones de cosas que una aplicación maliciosa puede hacer con un shell raíz.

Si se pregunta a nivel técnico qué está explotando MediaTek-su, MediaTek compartió con nosotros el siguiente cuadro que resume el punto de entrada. La falla aparentemente existe en uno de los controladores del kernel de Linux de MediaTek llamado "CMDQ". La descripción establece que, "al ejecutar IOCTL comandos en [el] nodo del dispositivo CMDQ", un atacante local puede "leer/escribir arbitrariamente la memoria física, volcar [la] tabla de símbolos del núcleo al buffer DMA preasignado, [y] manipular el buffer DMA para modificar la configuración del kernel para deshabilitar SELinux y escalar a 'root' privilegio."

Según el cuadro que MediaTek compartió con nosotros, esta vulnerabilidad afecta a los dispositivos MediaTek con las versiones del kernel de Linux 3.18, 4.4, 4.9 o 4.14 que ejecutan las versiones de Android 7 Nougat, 8 Oreo o 9 Pie. Aparentemente, la vulnerabilidad no es explotable en dispositivos MediaTek que ejecutan Android 10, ya que "el permiso de acceso de CMDQ Los nodos de dispositivo también son aplicados por SELinux." Esta mitigación probablemente proviene de una actualización del BSP de MediaTek en lugar de Android. sí mismo. La única mitigación de Android 10 para esta vulnerabilidad es su restricción de aplicaciones que ejecutan binarios en su directorio de inicio; sin embargo, como señala topjohnwu, desarrollador reconocido por XDA, una aplicación maliciosa puede simplemente ejecutar el código MediaTek-su en una biblioteca dinámica.

Aunque MediaTek ha solucionado este problema en todos los conjuntos de chips afectados, no pueden obligar a los fabricantes de dispositivos a implementar los parches. MediaTek nos dijo que tenían parches listos en mayo de 2019. Amazon, como era de esperar, solucionó inmediatamente el problema en sus dispositivos una vez que se dieron cuenta. Sin embargo, han pasado 10 meses desde que MediaTek puso una solución a disposición de sus socios, aún en Marzo de 2020, decenas de fabricantes de equipos originales no han reparado sus dispositivos. La mayoría de los dispositivos afectados tienen versiones anteriores de Android con niveles de parche de seguridad (SPL) de Android obsoletos, y la situación de la actualización es aún peor si se considera el cientos de modelos de dispositivos menos conocidos que utilizan estos chips MediaTek. MediaTek tiene un grave problema que tiene entre manos aquí, por lo que recurrieron a Google en busca de ayuda.

A diferencia de MediaTek, Google poder obligar a los OEM a actualizar sus dispositivos a través de acuerdos de licencia o términos del programa (como Android One). Para que un OEM declare que un dispositivo cumple con el nivel de parche de seguridad (SPL) del 2020-03-05, el dispositivo debe incluir todo el marco, Kernel de Linux y correcciones de controladores de proveedores aplicables en el Boletín de seguridad de Android de marzo de 2020, que incluye una solución para CVE-2020-0069, o MediaTek-su. (Google en realidad no parece imponer eso Los OEM realmente fusionan todos los parches (Sin embargo, al declarar un determinado SPL). Ahora que salió el boletín de marzo de 2020, esta historia debería haber terminado, ¿verdad? Desafortunadamente, también tenemos que criticar a Google por demorarse en la incorporación de los parches.

La falla en el proceso del parche de seguridad.

En caso de que aún no esté claro, no todas las vulnerabilidades de seguridad deben aparecer en un boletín de seguridad de Android. Los proveedores descubren y reparan muchas vulnerabilidades sin que aparezcan en el boletín mensual. MediaTek-su debería haber sido uno de ellos, pero por múltiples razones, varios OEM no lograron integrar los parches ofrecidos por MediaTek. (Hay muchas razones potenciales para ello, que van desde la falta de recursos hasta decisiones comerciales y fallas en la comunicación). Cuando anteriormente afirmó que MediaTek "recurrió a Google" en busca de ayuda, implicó que MediaTek buscó activamente la ayuda de Google para lograr que los OEM finalmente arreglaran sus problemas. dispositivos. Sin embargo, es posible que ese no haya sido el caso. Tengo entendido que Google no estaba al tanto de MediaTek-su hasta que apareció incidentalmente en un informe de seguridad de TendenciaMicro publicado el 6 de enero de 2020. En el informe, TendenciaMicro estaba documentando otro vulnerabilidad de seguridad, denominada "uso después de liberar en el controlador de carpeta" vulnerabilidad, que estaba siendo explotada activamente en la naturaleza. TendenciaMicro observó cómo tres aplicaciones maliciosas obtuvieron acceso de root utilizando uno de dos métodos, ya sea la vulnerabilidad "use-after-free in binder driver" o MediaTek-su.

en el código que TendenciaMicro compartido, podemos ver claramente cómo las aplicaciones maliciosas se dirigían a modelos de dispositivos específicos (p. ej. Nokia 3, OPPO F9 y Redmi 6A) y empleando MediaTek-su en ellos.

no puedo hablar por TendenciaMicro, pero parece que no sabían que MediaTek-su era un exploit aún sin parchear. Después de todo, se centraron en el exploit "use-after-free in Binder Driver", y el descubrimiento del uso de MediaTek-su parece haber sido una ocurrencia tardía. (Estoy seguro de que si TendenciaMicro Si estuvieran al tanto de la situación que rodea a MediaTek-su, habrían coordinado sus esfuerzos de divulgación con Google). Solo se nos informó Este exploit lo hicimos nosotros mismos el 5 de febrero de 2020 y, después de investigar por nosotros mismos qué tan grave era, nos comunicamos con Google al respecto el 7 de febrero. 2020. Google estaba tan preocupado por las repercusiones de la publicidad de MediaTek-su que nos pidieron que postergáramos la publicación de esta historia hasta hoy. Después de considerar el daño irreparable que se puede infligir a los usuarios atacados por malware que utiliza MediaTek-su, acordamos suspender esta historia hasta el anuncio de Android de marzo de 2020 Boletín de seguridad. Aún así, considerando cuánto tiempo les tomará a muchos dispositivos obtener la última actualización de seguridad, si es que alguna vez la reciben. Si lo consigues, es probable que haya un montón de dispositivos todavía vulnerables a MediaTek-su dentro de unos meses. ahora. Esto debería ser aterrador para cualquiera que tenga un dispositivo vulnerable.

Aunque esta vulnerabilidad muy grave y de gravedad "crítica" se está explotando activamente en la naturaleza, Google sólo Se incluyó la solución para este problema en el boletín de marzo de 2020, aproximadamente 2 meses después de que se les informó sobre el asunto. Si bien Google informa a sus socios de Android sobre el último Boletín de Seguridad de Android 30 días antes de que se haga público (es decir, Los fabricantes de equipos originales conocieron el contenido del boletín de marzo de 2020 a principios de febrero de 2020), Google puede actualizar el boletín, y a menudo lo hace, con cambios o nuevas correcciones. No entiendo por qué Google no decidió acelerar la inclusión de un parche para un problema tan grave, especialmente cuando MediaTek lo solucionó hace 10 meses. Si se descubriera un error de este tipo en los dispositivos de Apple, no tengo dudas de que habrían publicado una solución. mucho, mucho más rápido. Básicamente, Google apostó por la arriesgada apuesta de que MediaTek-su seguiría aparentemente tan discreto como ya lo era hasta el boletín de marzo de 2020. Si bien Google parece haber tenido suerte en ese sentido, no tenemos idea de cuántos autores de malware ya conocen el exploit. Después de todo, ha estado en un hilo aleatorio del foro XDA durante casi un año entero.

Hay una parte más en esta debacle a la que no me he referido mucho, y es el autor del exploit, miembro diplomático de XDA. Hay que reconocer que no creo que haya tenido ninguna intención maliciosa al publicar MediaTek-su. Podemos rastrear claramente el origen del exploit hasta el deseo de los diplomáticos de modificar las tabletas Amazon Fire. Diplomatic me dice que su objetivo principal al desarrollar este método raíz era ayudar a la comunidad. Personalizar su dispositivo es de lo que se trata XDA, y los esfuerzos diplomáticos en la comunidad son lo que la gente disfruta de los foros. Aunque la negativa del diplomático a abrir el código fuente del proyecto genera algunas preocupaciones, explica que quería que la comunidad disfrutara de este acceso root durante el mayor tiempo posible. Cuando me comuniqué por primera vez con el diplomático, también afirmó que estaba colaborando con algunos socios que le impedían compartir el código fuente y la investigación del proyecto. Si bien no pude obtener más detalles sobre esta colaboración, me pregunto si los diplomáticos habrían elegido hacer público este exploit si MediaTek hubiera ofrecido un programa de recompensas por errores. No puedo imaginar que una vulnerabilidad de esta magnitud no pagaría una suma considerable de dinero si MediaTek realmente tuviera un programa de este tipo. Diplomatic afirma que este exploit ha sido posible desde el chipset MediaTek MT6580 de finales de 2015, por lo que uno debe preguntarse si Diplomatic es siquiera la primera persona en encontrar este exploit. Me dice que no tenía idea de que MediaTek-su estaba siendo explotado activamente hasta la publicación de este artículo.

Si desea comprobar si su dispositivo es vulnerable a MediaTek-su, ejecute manualmente el script publicado por el diplomático miembro de XDA. en este hilo del foro XDA. Si ingresa a un shell raíz (sabrá cuando el símbolo cambia de $ a #), entonces sabrá que el exploit funciona. Si funciona, deberá esperar a que el fabricante de su dispositivo implemente una actualización que parchee MediaTek-su. Si su dispositivo informa el nivel de parche de seguridad del 2020-03-05, que es el último SPL de marzo de 2020, es casi seguro que esté protegido contra MediaTek-su. De lo contrario, sólo tendrás que comprobar si tu dispositivo es vulnerable.

---

Actualización 1 (2/3/2020 a las 9:45 p. m. EST): Este artículo se actualizó para aclarar que el diplomático miembro de XDA estaba realmente consciente del alcance de esta vulnerabilidad tan pronto como lo descubrió en febrero de 2019, pero que no estaba al tanto del uso salvaje del exploit hasta la publicación de este artículo. También corregimos nuestra redacción con respecto a una de las razones por las que diplomático se negó a compartir el código fuente del proyecto.