Hace poco se dio a conocer información importante sobre cuatro vulnerabilidades en los componentes del Realtek SDK, que es utilizado por varios fabricantes de dispositivos inalámbricos en su firmware. Los problemas detectados permiten a un atacante no autenticado ejecutar código de forma remota en un dispositivo con privilegios elevados.

Se estima que los problemas afectan al menos a 200 modelos de dispositivos de 65 proveedores diferentes, incluidos varios modelos de enrutadores inalámbricos de las marcas Asus, A-Link, Beeline, Belkin, Buffalo, D-Link, Edison, Huawei, LG, Logitec, MT -Link, Netgear, Realtek, Smartlink, UPVEL, ZTE y Zyxel.

El problema abarca varias clases de dispositivos inalámbricos basados ​​en SoC RTL8xxx, desde enrutadores inalámbricos y amplificadores Wi-Fi hasta cámaras IP y dispositivos inteligentes para el control de la iluminación.

Los dispositivos basados ​​en chips RTL8xxx utilizan una arquitectura que implica la instalación de dos SoC: el primero instala el firmware del fabricante basado en Linux y el segundo ejecuta un entorno Linux reducido por separado con la implementación de las funciones del punto de acceso. El llenado del segundo entorno se basa en componentes típicos proporcionados por Realtek en el SDK. Estos componentes, entre otras cosas, procesan los datos recibidos como resultado del envío de solicitudes externas.

Las vulnerabilidades afectan a los productos que utilizan Realtek SDK v2.x, Realtek «Jungle» SDK v3.0-3.4 y Realtek «Luna» SDK hasta la versión 1.3.2.

Por la parte de la descripción de las vulnerabilidades identificadas es importante mencionar que a las dos primeras se les asignó un nivel de gravedad 8.1 y al resto, 9.8.

• CVE-2021-35392: Desbordamiento de búfer en procesos mini_upnpd y wscd que implementan la funcionalidad «WiFi Simple Config» (mini_upnpd maneja paquetes SSDP y wscd, además de admitir SSDP, maneja solicitudes UPnP basadas en el protocolo HTTP). Con ello un atacante puede lograr la ejecución de su código enviando solicitudes UPnP SUBSCRIBE especialmente diseñadas con un número de puerto demasiado alto en el campo de devolución de llamada.
• CVE-2021-35393: una vulnerabilidad en los controladores «WiFi Simple Config», que se manifiesta cuando se usa el protocolo SSDP (usa UDP y un formato de solicitud similar a HTTP). El problema se debe al uso de un búfer fijo de 512 bytes al procesar el parámetro «ST:upnp» en los mensajes M-SEARCH enviados por los clientes para determinar la disponibilidad de servicios en la red.
• CVE-2021-35394: es una vulnerabilidad en el proceso MP Daemon, que se encarga de realizar operaciones de diagnóstico (ping, traceroute). El problema permite realizar la sustitución de sus comandos debido a una validación insuficiente de los argumentos al ejecutar utilidades externas.
• CVE-2021-35395: es una serie de vulnerabilidades en interfaces web basadas en servidores http/bin/webs y /bin/boa. Se identificaron vulnerabilidades típicas en ambos servidores, causadas por la falta de validación de argumentos antes de ejecutar utilidades externas usando la función system(). Las diferencias se reducen solo al uso de diferentes API para el ataque.
  Ambos manejadores no incluían protección contra ataques CSRF y la técnica de «rebinding DNS», que permite enviar solicitudes desde la red externa mientras restringe el acceso a la interfaz solo a la red interna. Los procesos también utilizaron la cuenta de supervisor/supervisor predefinida de forma predeterminada.

La corrección ya se ha publicado en la actualización 1.3.2a del SDK «Luna» de Realtek, y también se están preparando parches para el SDK «Jungle» de Realtek para su publicación. No se planean arreglos para Realtek SDK 2.x, ya que el mantenimiento de esta rama ya ha sido descontinuado. Se han proporcionado prototipos funcionales de exploits para todas las vulnerabilidades, lo que les permite ejecutar su código en el dispositivo.

Además, se observa la identificación de varias vulnerabilidades más en el proceso de UDPServer. Al final resultó que, uno de los problemas ya había sido descubierto por otros investigadores en 2015, pero no se solucionó por completo. El problema es causado por la falta de validación adecuada de los argumentos pasados ​​a la función system() y puede explotarse enviando una línea como ‘orf; ls’ al puerto de red 9034.

Fuente: https://www.iot-inspector.com