Linux vulnerable y claves expuestas: NanoKVM, sueño de hackers y pesadilla para administradores

En febrero, un investigador esloveno de seguridad informática publicó un análisis del dispositivo chino de gestión remota NanoKVM, del que se supo: un kit KVM barato de €30–60 se suministraba con todo un conjunto de vulnerabilidades y un micrófono oculto que podía activarse de forma remota vía SSH. Parte de los problemas se ha corregido en los meses transcurridos, pero la historia muestra lo peligroso que es introducir «cajas negras» en las redes sin pensar.

NanoKVM es una placa compacta basada en RISC-V, lanzada al mercado el año pasado como alternativa económica al PiKVM. El dispositivo puede capturar vídeo HDMI, emular teclado y ratón USB, gestionar la alimentación y ofrecer acceso por navegador al PC conectado. Para administradores y entusiastas es una forma cómoda de «tener control» del servidor o del equipo doméstico desde el encendido —desde la BIOS hasta la instalación del sistema operativo— sin instalar ningún software en la máquina objetivo. No es de extrañar que estas cajitas hayan empezado a aparecer también en infraestructuras TI reales.

Según el investigador, los problemas de seguridad empiezan literalmente desde el arranque del dispositivo. Las primeras series de NanoKVM se entregaban con una contraseña por defecto y acceso SSH abierto. Él informó de esto a Sipeed y la compañía cambió después esas configuraciones. Sin embargo, la interfaz web sigue estando mínimamente protegida: no cuenta con protección contra ataques CSRF ni con un mecanismo para forzar el cierre de sesiones activas —no es posible cerrar la sesión «de verdad».

Otra historia es el manejo de las contraseñas. La clave de cifrado con la que NanoKVM protege los inicios de sesión en el navegador resultó estar incrustada de forma fija en el firmware y ser idéntica en todos los dispositivos. Es decir, al obtener esa clave, un atacante podría potencialmente descifrar las contraseñas de cualquier NanoKVM. Según el investigador, los desarrolladores tuvieron que explicar el problema «varias veces» antes de reconocer su gravedad.

El comportamiento de red de la placa también planteó preguntas. Por defecto el dispositivo enviaba consultas DNS a través de servidores en China y se comunicaba regularmente con la infraestructura de Sipeed para actualizaciones y un componente binario cerrado. La clave para verificar ese componente estaba en el dispositivo en texto claro, y la integridad del firmware descargado no se verificaba en absoluto. Esto crea un punto conveniente para ataques a la cadena de suministro, tanto por parte del fabricante como en caso de compromiso de sus servidores.

A la vez, la imagen de Linux instalada resultaba paradójica: un sistema muy recortado sin las herramientas administrativas habituales, pero con tcpdump y aircrack preinstalados —utilidades más asociadas al análisis de tráfico y a las pruebas de Wi‑Fi que a un producto «en caja» para operar en redes privilegiadas.

En este contexto, resultó especialmente inquietante el hallazgo de un micrófono minúsculo en la placa. En la documentación oficial no se menciona, pero en el sistema estaban disponibles utilidades ALSA como amixer y arecord, listas para capturar audio de inmediato. En muchos dispositivos ya desplegados seguían usándose las credenciales SSH de fábrica, y el investigador demostró que grabar y enviar audio desde NanoKVM se puede organizar con un esfuerzo mínimo. Para transmitir audio en tiempo real, según su estimación, basta con un pequeño script adicional.

Lo que salva la situación es que NanoKVM se presenta formalmente como una plataforma de código abierto. La comunidad se movilizó rápidamente y empezó a portar al dispositivo distribuciones alternativas de Linux: primero Debian, luego Ubuntu. Para flashearlo hay que desmontar la carcasa y grabar una nueva imagen en la microSD interna, pero las primeras compilaciones ya pueden trabajar con el código KVM modificado de Sipeed. También es posible retirar físicamente el micrófono, aunque por su tamaño y ubicación es una operación bastante minuciosa sin una lente de aumento.

Según el investigador, en los meses transcurridos Sipeed ha corregido una parte significativa de las vulnerabilidades encontradas. No obstante, muchos en la comunidad coinciden en que no conviene confiar exclusivamente en el firmware de fábrica. La recomendación es una: si decide usar NanoKVM, conviene reflashearlo con un Linux personalizado y restringir de forma estricta el acceso al dispositivo. Por ahora, estas placas se consideran más a menudo como un juguete para experimentos en laboratorios domésticos que como una herramienta para redes corporativas responsables.