Sec-consult ha hecho pública una vulnerabilidad en el acceso por P2P a los grabadores y cámaras IP del fabricante Xiongmai, un fabricante chino (OEM) poco conocido por su nombre, pero cuyos equipos se venden bajo muchas otras marcas, entre las que se encuentran KMoon, Floureon, Sannce, Wnk, Zmodo, Canavis o Dagro.

Es probable que no os suenen muchas, o directamente ninguna de estas marcas; pero podéis reconocer de una forma sencilla un equipo fabricado por Xiongmai por el hecho de que para acceder de forma remota a estos equipos se usa la aplicación de móvil XMEye. Una gran cantidad de equipos low cost vendidos en Amazon, Ebay, Aliexpress, y webs de este estilo son fabricados por Xiongmai.

Es posible incluso reconocer un dispositivo Xiongmai por otras apps, puesto que hay versiones renombradas de la misma aplicación, como por ejemplo JFEye, GoodEye o iCSee Pro.

Otra forma de saber si nuestro dispositivo está fabricado por Xiongmai es accediendo a la página de error del equipo, mediante la UTL http://IP del equipo/err.htm, ya que aunque el interfaz pueda estar personalizado, parece que en el mensaje de error si que sale el nombre del fabricante.

El fabricante tiene noticia del problema desde el pasado mes de marzo, y siete meses después aún no ha ofrecido una solución a la vulnerabilidad de sus equipos, que se basa en 5 importantes problemas de seguridad:

• Los IDs usados en el cloud son predecibles. Cada dispositivo usa un ID aparentemente aleatorio para conectarse mediante P2P al cloud del fabricante, como puede ser por ejemplo 68ab8124db83c8db. Pero estos IDs pueden obtenerse con relativa facilidad por fuerza bruta, ya que se generan al arranque del equipo a partir de un identificador único y la dirección MAC del equipo.
  Un atacante puede ir probando IDs de forma secuencial, y en aquellos que estén conectados intentar conectarse con alguna de las credenciales por defecto.
  Este problema se agrava por el hecho de que el cloud de Xiongmay no limita el número de intentos que pueden hacerse desde una misma IP. Extrapolando datos, Sec-consult estima que en todo momento puede haber online en el sistema unos 9 millones de equipos conectados.

  Hop server location: CN; extrapolated devices 5,438,757
  Hop server location: DE; extrapolated devices 1,319,845
  Hop server location: JP; extrapolated devices 577,743
  Hop server location: SG; extrapolated devices 697,276
  Hop server location: TR; extrapolated devices 189,260
  Hop server location: US; extrapolated devices 742,101

• Usuario admin con contraseña en blanco por defecto. Los dispositivos vienen por defecto sin contraseña, y no obliga al usuario a crear una contraseña. Cualquier equipo puede estar conectado a internet sin contraseña. Este problema también se agrava por el hecho de que el acceso P2P viene activado de serie en todos los equipos.
• Usuario default con contraseña por defecto, de uso desconocido. Existe una cuenta default en los equipos cuya función no está documentada, que dispone de acceso a la visualización en directo de los canales de video. La contraseña de este usuario es tluafed y puede usarse para conectarse mediante XMEye.
• Comunicación por múltiples canales sin encriptar. Todas las comunicaciones se realizan sin encriptar, tanto el acceso desde XMEye como las comunicaciones con los servidores de actualizaciones. Si es posible analizar el tráfico de red entrante y saliente del equipo, es posible obtener de forma sencilla tanto el ID del cloud como el usuario y contraseña de acceso.
• No se verifica la integridad de las actualizaciones. Los firmwares que se instalan en un dispositivo no van firmados. Es por ello posible actualizar con un firmware malicioso, modificando por ejemplo el fichero InstallDesc, que es un simple fichero de texto con los comandos que se ejecutan durante el proceso de actualización.

Es solo cuestión de tiempo que alguien cree un gusano que se dedique a infectar dispositivos XMEye, como ya ha pasado otras veces como por ejemplo con Mirai. A día de hoy, ningún dispositivo al que se acceda con la aplicación XMEye es seguro, y la única recomendación que hace Sec-consult es dejar de usar cualquier dispositivo del fabricante.

Un posible escenario de ataque:

• Un atacante obtiene por fuerza bruta un listado de IDs válidos en el cloud.
• El atacante utiliza las credenciales inseguras de «admin» y «default» para obtener acceso al dispositivo a través del cloud.
• El atacante modifica los servidores DNS del dispositivo, para mediante un servidor de DNS y de web maliciosos poder crear un servidor de actualizaciones falso (upgrade.secu100.net).
• El atacante crea un firmware malicioso para actualizar el dispositivo. A través del cloud lanza el comando de actualización del dispositivo, que descargará el firmware infectado y se actualizará el equipo.

Llegados a este punto, ya todo depende de la imaginación del atacante.

Quizás alguien se moleste en crear un programa que se dedique a desconectar de internet todos los dispositivos que sean vulnerables, como ya pasó en su momento con los equipos Dahua vulnerables (aunque en este caso era necesario que el equipo tuviera el puerto web accesible desde el exterior). Quizás alguien piense que estos equipos deberían ir todos a la basura, y los brickee para convertirlos en bonitos pisa papeles.

Pero alguien puede ver más interesante con estos equipos crear una nueva botnet al estilo Mirai, dedicarlos a minar bitcoins, a mandar spam, o simplemente una vez ya está dentro de la red local puede dedicarse a husmear que otros equipos encuentra accesibles y vulnerables.