Esta semana ha saltado la noticia de una vulnerabilidad crítica en el firmware de algunos dispositivos basados en Hi Silicon que ejecutan software de Xiongmai, entre los que se incluyen grabadores de vídeo en red, cámaras habilitadas para IP y grabadores de vídeo digital. HiSilicon es un fabricante de "sistemas en un chip" (o SoC), y algunos de sus productos están destinados a utilizarse en equipos de vídeo con IP. La vulnerabilidad fue descubierta por Vladislav Yarmak, que la caracteriza como una "puerta trasera". Su informe explica cómo los dispositivos activan un servidor telnet cuando reciben una "llamada secreta" enviada al puerto 9530/tcp. Yarmak aplicó ingeniería inversa al firmware y descubrió cómo activar la puerta trasera.
En Censys, nuestro conjunto de datos ampliado para clientes empresariales, el Universal Internet Data Set (UIDS), lleva algún tiempo escaneando el puerto 9530 y ha encontrado 188.989 hosts con ese puerto abierto, aunque la mayoría son servidores HTTP y otros protocolos bien conocidos, incluido SSH. Siguiendo el informe de Yarmak, hicimos un escaneo más específico para buscar globalmente el servicio vulnerable de HiSilicon. Usando la infraestructura de escaneo de Censys , encontramos 9362 hosts escuchando en 9530/tcp que hablan el protocolo HiSilicon.
Geográficamente, los dos países más populares para estos dispositivos son Taiwán y Vietnam, seguidos de Brasil, Turquía y otros países.
El puerto 9530 es sólo uno de los más de 1.000 puertos que escaneamos regularmente, por lo que también podemos explorar qué otros puertos están abiertos en esos hosts. Domina el servicio RTSP (protocolo de transmisión en tiempo real) en 554/tcp, que es algo que cabría esperar de un sistema de vídeo sobre IP. De los 137 hosts que analizamos, 100 de ellos tenían RTSP escuchando en el puerto 554, 50 tenían HTTP abierto en el puerto 80 y 17 tenían el puerto 9527 abierto.
Otras vulnerabilidades
Yarnak describe cómo los dispositivos utilizan un protocolo de desafío-respuesta para activar la puerta trasera: el servidor envía un número aleatorio de ocho dígitos y requiere que el cliente responda con ese número cifrado con una clave precompartida incrustada en el firmware.
Observando un conjunto de valores "aleatorios" enviados por los hosts receptivos, nos dimos cuenta de que están dominados por un único valor, con varios otros valores que también aparecen repetidamente. El siguiente gráfico muestra los diez valores más comunes, ordenados por frecuencia (nótese la escala logarítmica en el eje vertical):
Está claro que ni siquiera son aleatorios. La primera barra muestra que 8759 de los 9362 valores "aleatorios" eran idénticos.
Tras una investigación más profunda, parece que hay dos familias distintas de hosts, cada una con su propio defecto interesante en el generador de números pseudoaleatorios (PRNG):
- La mayoría de los hosts parecen utilizar una semilla codificada para el PRNG, haciendo que emita una secuencia fija, que probablemente se reinicia cada vez que se inicia el dispositivo. La gran mayoría de los dispositivos no han sido probados antes, por lo que todos utilizan el mismo valor de desafío. Un atacante que observara la respuesta correcta para ese valor podría reproducirla en todos los demás dispositivos que se encuentren en el mismo estado PRNG.
- Un número menor de hosts parece utilizar un PRNG basado en el tiempo que se siembra con la hora actual, en segundos. Esto hace posible reproducir las respuestas de desafío de un dispositivo a los demás en un intervalo de tiempo corto (más de un segundo, porque los relojes no están todos sincronizados).
Por supuesto, gracias a los fallos ya revelados por Yarnak, los dispositivos se pueden explotar sin aprovecharse de estas vulnerabilidades PRNG: la clave precompartida utilizada para crear las respuestas de desafío está codificada en el firmware y es fácil de extraer. Aún así, es un ejemplo interesante de debilidad en profundidad: una implementación que tiene un comportamiento de seguridad muy malo, como la presencia de una puerta trasera, es probable que tenga otros fallos de seguridad importantes, que podrían proporcionar a los atacantes una forma de entrar.
Los fallos de seguridad como los detectados en el sistema SoC de HiSilicon rara vez se producen de forma aislada, sino que suelen representar fallos sistémicos en el diseño y la implementación. No está claro si el fallo detectado pretendía ser una puerta trasera maliciosa, pero el riesgo de explotación maliciosa se vio ciertamente agravado por la negligencia en forma de credenciales codificadas y criptografía rota. Por desgracia, este tipo de fallos son demasiado frecuentes en los dispositivos integrados y ponen en peligro a millones de consumidores y organizaciones.
Para saber más sobre Censys y ver nuestras herramientas en acción, visítenos en www.censys.io, y síganos en @censysio.
