Denis Selianin, investigador de la firma de seguridad Embedi, publicó un informe donde ofrece detalles de una nueva vulnerabilidad que afecta al firmware de algunos chips WiFi. Lo preocupante de esto es que este chip se encuentra dentro de una amplia gama de dispositivos, como portátiles, smartphones, consolas, routers y dispositivos IoT.
Según la información, esta vulnerabilidad ataca a ThreadX, el sistema operativo en tiempo real (RTOS) que se utiliza como firmware para miles de millones de dispositivos. En el caso de esta investigación, Selianin describe cómo ThreadX podría servir para ejecutar código malicioso en el chipset inalámbrico Marvell Avastar 88W8897.
Los parches ya vienen en camino
Selianin menciona que eligió el chip de Marvell al ser uno de los más populares en el mercado, el cual se encuentra en consolas como la PlayStation 4 y Xbox One, ordenadores Surface y Chromebooks de Samsung, así como en los smartphones Galaxy J1 y los dispositivos Valve SteamLink, entre muchos más.
El investigador asegura que la vulnerabilidad puede activarse sin la interacción del usuario durante la búsqueda de redes, y no se necesitaría conectarse a ninguna red en especifico, ya que se trataría de un proceso que se inicia en automático cada cinco minutos. Todo lo que el atacante tiene que hacer es enviar el paquete vía WiFi a cualquier dispositivo con este chip y listo, esperar hasta que se inicie para así ejecutar un código malicioso y tomar el control.
Selianin afirma que se trata de un sofisticado ataque que pasa completamente desapercibido ante los ojos del usuario, por eso puede ser muy peligroso. Para explotar esta vulnerabilidad, Selianin asegura que hay dos formas: una es por medio de un ataque especifico al dispositivo que se busca controlar; mientras que el otro es genérico, el cual puede afectar a todos los dispositivos con firmware basado en ThreadX, es decir, aproximadamente 6.200 millones de dispositivos.
En Embedi se dan detalles técnicos de esta vulnerabilidad e incluso hay un vídeo que demuestra cómo funciona. Hasta este momento no hay reportes de dispositivos afectados, y afirma que las compañías ya están al tanto, quienes prometen que los parches ya vienen en camino.
"Express Logic se toma muy en serio la seguridad y la protección, tanto que hemos trabajado muy duro para lograr soluciones únicas de tiempo de ejecución con certificaciones SIL 4, ASIL D y EAL4+. Como tal, es fácil comprender por qué nos alarmó mucho escuchar el reciente informe de vulnerabilidad en el chip WiFi Marvell Avastar 88W8897 que utiliza nuestro RTOS ThreadX.
Después de analizar el informe y las declaraciones de los medios de comunicación relacionadas con ThreadX, consultamos con el autor del análisis de seguridad inicial, quien sugirió que algunos de los informes de los medios pueden haber malinterpretado el ángulo y que los problemas de seguridad descritos en el artículo original no apuntaban a ThreadX en sí. La conclusión es que esta vulnerabilidad no es un problema sistémico en el RTOS de ThreadX. El firmware de la aplicación y los controladores que se ejecutan en el SoC Avastar 88W8897 son los únicos responsables y tienen el control total sobre la corrupción de memoria citada en este informe. De hecho, el problema descrito podría ocurrir en cualquier RTOS, SO o incluso sin un RTOS. En resumen, la vulnerabilidad citada por el autor reside en el firmware de la aplicación y no tiene absolutamente nada que ver con el propio ThreadX RTOS. Por lo tanto, ninguna de las implementaciones extensivas a los 6.200 millones de dispositivos que utilizan ThreadX RTOS estás comprometidos de ninguna manera por el código o comportamiento de ThreadX RTOS. Esto es totalmente un problema de firmware de la aplicación.
Nos gustaría agradecer al autor por poner este tema en primer plano, creando un momento de aprendizaje muy valioso. El manejo adecuado de los paquetes es una necesidad absoluta para el firmware de la aplicación IoT, especialmente porque dichos paquetes representan uno de los medios más vulnerables de un ataque de denegación de servicio. Este problema también es una gran lección para la programación defensiva: el firmware de la aplicación siempre debe garantizar que la memoria de destino sea lo suficientemente grande como para contener la carga útil, y no simplemente copiar sin verificar el posible desbordamiento del búfer. Finalmente, también hay una lección acerca de cuánta visibilidad debe proporcionar un SDK en el firmware de la aplicación. El acceso permitido por el SDK en este ejemplo fue bastante amplio y, por lo tanto, hizo que la ingeniería inversa fuera relativamente fácil. En el futuro, comunicaremos estas importantes lecciones con nuestra base de clientes, así como con la comunidad general integrada de IoT y, con suerte, ayudaremos a evitar tales inconvenientes en el futuro."
Ver 5 comentarios