Exploit crítico en chipsets Wi-Fi de MediaTek: vulnerabilidad zero-click

 (blog.sonicwall.com)
1 puntos por GN⁺ 2024-09-22 | 1 comentarios | Compartir por WhatsApp

Vulnerabilidad grave en chipsets Wi-Fi de MediaTek: la vulnerabilidad Zero-Click (CVE-2024-20017) amenaza a routers y smartphones

Resumen
  • El equipo de investigación de amenazas de SonicWall Capture Labs identificó la vulnerabilidad CVE-2024-20017, evaluó su impacto y desarrolló medidas de mitigación
  • CVE-2024-20017 es una vulnerabilidad zero-click crítica con una puntuación CVSS 3.0 de 9.8, que afecta a los chipsets Wi-Fi MT7622/MT7915 de MediaTek y al paquete de drivers RTxxxx SoftAP
  • Están afectadas las versiones 7.4.0.1 y anteriores del SDK de MediaTek, utilizadas en productos de varios fabricantes como Ubiquiti, Xiaomi y Netgear, así como OpenWrt 19.07 y 21.02
  • La vulnerabilidad permite ejecución remota de código sin interacción del usuario, y MediaTek distribuyó un parche para mitigarla
  • La vulnerabilidad fue divulgada y corregida en marzo, pero un PoC publicado recientemente aumenta la probabilidad de explotación
Resumen técnico
  • La vulnerabilidad existe en wappd, un demonio de red incluido en el SDK MT7622/MT7915 de MediaTek y en el paquete de drivers RTxxxx SoftAP
  • wappd se encarga de configurar y administrar interfaces inalámbricas y puntos de acceso, especialmente en relación con la tecnología Hotspot 2.0
  • La arquitectura de wappd está compuesta por el propio servicio de red, un conjunto de servicios locales que interactúan con las interfaces inalámbricas del dispositivo y un canal de comunicación entre componentes mediante sockets de dominio Unix
  • La vulnerabilidad se produce por un desbordamiento de búfer causado al usar en una copia de memoria un valor de longitud tomado directamente de datos de paquetes controlados por el atacante
Activación de la vulnerabilidad
  • La vulnerabilidad se produce en la función IAPP_RcvHandlerSSB, donde un valor de longitud controlado por el atacante se pasa al macro IAPP_MEM_MOVE
  • No se realiza validación de límites más allá de verificar que no se exceda la longitud máxima de paquete de 1600 bytes
  • El atacante debe enviar el paquete anteponiendo a la carga maliciosa la estructura esperada
  • La longitud de la estructura RT_IAPP_HEADER debe ser pequeña y el campo RT_IAPP_HEADER.Command debe ser 50
Explotación
  • El código de exploit publicado logra ejecución remota de código mediante una cadena ROP usando una técnica de sobrescritura de la tabla global de direcciones
  • Aprovecha una llamada a system() para ejecutar un comando que envía una reverse shell al atacante
  • La reverse shell se configura usando las herramientas Bash y Netcat
Protección de SonicWall
  • Para ayudar a los clientes de SonicWall a defenderse frente a la explotación de esta vulnerabilidad, se distribuyeron las siguientes firmas
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
Recomendaciones de mitigación
  • Dado que el código de exploit ya fue publicado, se recomienda enfáticamente a los usuarios actualizar al firmware más reciente disponible para los chipsets afectados
Enlaces relacionados

Resumen de GN⁺

  • Este artículo trata sobre una vulnerabilidad zero-click crítica en chipsets Wi-Fi de MediaTek que permite ejecución remota de código sin interacción del usuario
  • El equipo de investigación de SonicWall identificó la vulnerabilidad y desarrolló medidas de mitigación, además de recomendar a los usuarios actualizar al firmware más reciente
  • La vulnerabilidad afecta a routers y smartphones de varios fabricantes, y la reciente publicación de un PoC eleva el riesgo de explotación
  • Un producto con funciones similares son los chipsets Wi-Fi de Qualcomm, y es importante revisar periódicamente las actualizaciones de seguridad

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-22
Opiniones en Hacker News

  • Habiendo comparado el código fuente del driver del SDK de proveedor de MediaTek con mt76, no me sorprende mucho. Siendo generosos, es bastante desordenado.
    Lamentablemente, como da un poco más de throughput que mt76, también andan circulando algunas compilaciones de firmware de terceros que incluyen el driver del proveedor.
    Por suerte, en MediaTek y en el departamento de WiSoC hay algunos ingenieros que se comunican activamente con la comunidad de software libre y de código abierto, e incluso mantienen directamente un pequeño fork de OpenWrt basado en mt76: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • No entiendo por qué este hardware/firmware se siente tanto como si hubieran desplegado código de prueba de concepto en producción. ¿No pueden contratar a alguien que sepa hacer las cosas bien?
    • Me pregunto si hay algún comunicado de prensa o información sobre el objetivo de ese programa, o sobre cuánto de ese feed se fusionó en el proyecto upstream.

  • El título es un poco engañoso. Tengo varios routers en casa con Wi-Fi mt76, así que hice clic pensando que era un bug de firmware o de silicio, pero me tranquilizó ver que resultó ser un bug en el código basura del SDK del proveedor.
    Aun cuando el soporte de mt76 en el kernel mainline y hostapd es bastante bueno, no entiendo que alguien haya querido usar eso.

    • Para decir “me tranquilizó que fuera un bug en el código basura del SDK del proveedor”, hay varios proveedores por los que preocuparse.
      Dice que es un “paquete de drivers usado en productos de varios fabricantes, incluidos Ubiquiti, Xiaomi, Netgear, etc.”
      Aunque también hay proveedores, como Ubiquiti, que han aclarado que no lo usan en productos reales: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • Se dice que la línea OpenWRT 21.02.x está afectada aunque se basa en el kernel mainline 5.4. Esa gente suele conocer bien el networking inalámbrico de Linux y, de hecho, tengo entendido que el driver mt76 del kernel mainline también lo mantiene un desarrollador de OpenWRT.

  • Blog original: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • El servicio wappd se usa principalmente para configurar y coordinar interfaces inalámbricas y el funcionamiento de puntos de acceso mediante Hotspot 2.0 y tecnologías relacionadas.
      La estructura de la aplicación es algo compleja, pero en esencia está compuesta por un servicio de red, servicios locales que interactúan con las interfaces inalámbricas del dispositivo y canales de comunicación entre componentes que usan sockets de dominio Unix.
      Al menos lo bueno es que esto suena más a un problema en un servicio de “valor agregado” que no es estrictamente necesario para el funcionamiento de la propia tarjeta de red inalámbrica, y no a un bug dentro del firmware de banda base.
      Me recuerda a cómo algunos paquetes de drivers de dispositivos tienen un driver real pequeño y silencioso, pero instalan junto con él bloatware varios órdenes de magnitud más grande para funciones que el 99% de los usuarios no necesitan ni quieren. Las impresoras y las GPU son especialmente malas en esto.

  • Me pregunto si hay alguna lógica en la convención de nombres de MediaTek, o si todos los dispositivos son simplemente MTxxxx y la x es un valor incremental o aleatorio.
    Tengo un dispositivo con un chip Wi-Fi mt6631 y, como no aparece en la lista de afectados, puedo suponer que está bien, pero es difícil saber dónde encaja dentro de la familia de productos.

  • Dicen que OpenWrt 19.07 y 21.02 están afectados, pero por lo que veo las compilaciones oficiales de OpenWrt parecen usar solo el driver mt76, no el SDK de Mediatek.

  • No entiendo por qué, cuando compro una laptop con CPU AMD, siempre viene con una tarjeta Wi-Fi MediaTek RZ616.
    Las he reemplazado todas por tarjetas Wi-Fi Intel, y ahora tengo una pila de tarjetas RZ616 que serán microplásticos del futuro.

    • Intel vende dos tipos de tarjetas Wi-Fi. Los modelos que terminan en 1 usan el protocolo CNVI, funcionan solo con chips Intel y se venden muy baratos a los OEM.
      Los modelos que terminan en 0 usan PCIe estándar y se venden a los OEM por unos 10 dólares más.
      Lo que hizo AMD fue renombrar las MediaTek MT7921 y MT7922 como RZ608 y RZ616, respectivamente, para tener algo que vender a los OEM en el mismo rango de precio que los chips xx1 de Intel.
    • Lenovo también se cansó de MediaTek y empezó a soldar chips Qualcomm para WLAN en plataformas AMD, pero volvió a golpearse con un bug de interacción entre firmware y driver en Linux. Y eso a pesar de que Lenovo vende y da soporte oficial a Linux.
      Cuando una generación de chipsets Qualcomm deja de ser la más reciente, el soporte en el kernel mainline se vuelve bastante limitado. Hoy hace falta una presión enorme de los proveedores para mover a Qualcomm.
    • iwlwifi también tiene sus propios problemas, y el mayor es que no tiene modo AP en 5 GHz. La licencia del firmware de Intel también es más restrictiva que la de MediaTek y, al ser fullmac, el firmware asume mucho más trabajo.
      Personalmente prefiero softmac. Hoy no hay muchas buenas opciones, y la época dorada de ath9k ya pasó.
    • Me pregunto si realmente las has usado, más allá de simplemente “no confío en MediaTek”.
      Para el trabajo usé sucesivamente una ThinkPad Intel y una ThinkPad AMD, y el Wi-Fi con chipset MediaTek de la AMD fue mucho mejor que el chipset Intel de la Intel.
      En la Intel la conexión de red se caía varias veces por hora y, aun en 5 GHz, la latencia era tan horrible que se notaba de inmediato al usar ssh. El dispositivo MT7921 que uso ahora ha sido muy estable en Linux durante los últimos 2 o 3 años.
      Al final parece depender bastante de la combinación de chipset y laptop.

  • Recuerdo que mi teléfono también usa un chipset MediaTek. Y recuerdo vagamente que la razón por la que el fabricante luego se alejó de MediaTek fue la, digamos, calidad de esos productos.
    No sé cómo está configurado el Wi-Fi en los teléfonos. ¿Hay alguna forma de verificar si este teléfono está afectado? Tengo datos celulares ilimitados y buena cobertura, así que casi no uso Wi-Fi, pero igual sería bueno saberlo.

    • En termux, ejecuta "sudo su" y luego mira ls /sys/module.
      La salida se parece a lsmod.

  • Incluso en esta época en la que la gente compra cualquier silicio que pueda conseguir, sigo sin entender por qué estos proveedores de tercera no siguen la estrategia de PC y abren por completo el firmware para dejarlo en manos de la comunidad open source.

    • Las normas de la FCC, que obligan a dificultar la transmisión fuera de las bandas autorizadas, suelen crear este tipo de situaciones.

  • Dice que “las versiones afectadas incluyen MediaTek SDK 7.4.0.1 y anteriores, y OpenWrt 19.07, 21.02”, y que “la vulnerabilidad está en el daemon de red wappd incluido en los paquetes de drivers MediaTek MT7622/MT7915 SDK y RTxxxx SoftAP”, pero en realidad parece que OpenWRT no usa wappd.

    • Como contribuidor de OpenWrt, me pregunto por qué la gente no distingue entre OpenWrt y un SDK propietario de proveedor. Si hubiera un bug en Nobara, no habrían mencionado a Fedora.
    • Me preguntaba lo mismo, porque en mi red doméstica uso OpenWRT en varios AP Netgear. Según esta explicación, ¿estoy bien?

  • Por eso necesitamos firmware libre. Ya me cansé de Broadcom y Ralink.