Una cámara de seguridad debería reducir el riesgo. Por eso el caso Hanwha Vision/Wisenet llamó tanto la atención: un investigador afirma que una imagen de firmware incluía un token de GitHub dentro de archivos usados por la página de inicio de sesión de la cámara.

Paquete de firmware de cámara de red con un token CI redactado detectado por un escáner

La lectura útil no es que todas las cámaras estén comprometidas. Según el autor, el token fue revocado rápido, y las fuentes públicas revisadas no prueban explotación masiva. La lectura útil es más concreta: un dispositivo embebido puede arrastrar errores típicos de CI/CD y frontend, pero luego esos errores quedan dentro de firmware que los clientes instalan y olvidan.

El post original del 24 de julio describe la descarga de firmware Hanwha, la extracción del filesystem y el uso de un escáner de secretos. El autor dice que TruffleHog encontró una credencial de GitHub duplicada en unos 30 archivos. También dice que el token tenía privilegios de administración sobre cientos de repositorios de la organización de Hanwha en GitHub y que la compañía respondió en 12 horas indicando que el token había sido revocado.

No encontré un aviso oficial de Hanwha que confirmara modelos afectados, versiones de firmware o permisos exactos. Sí está claro por el sitio de Hanwha que la empresa vende cámaras de red y soluciones de video para aeropuertos, banca, centros de datos, vigilancia urbana, gobierno, salud, transporte y servicios públicos. Por eso un secreto dentro del firmware no es solo un error menor de desarrollo.

El mecanismo importa. El autor apunta a una interfaz web construida con Vite y a una variable que, según su análisis, terminó copiando el entorno del job de CI en archivos de cliente. La documentación de Vite dice que las variables con prefijo VITE_ se exponen en el bundle del cliente; otras no deberían exponerse por esa vía normal. El problema no es "Vite filtra secretos", sino una frontera de build mal gobernada.

El firmware complica todo. Un bundle web puede corregirse y desplegarse de nuevo. Una imagen de firmware puede vivir en descargas del proveedor, mirrors, archivos de distribuidores y procedimientos de mantenimiento durante años. Revocar el token arregla el riesgo inmediato, pero no explica por qué el pipeline permitió que un secreto amplio llegara al artefacto final.

Para operadores de cámaras IP, la respuesta debe ser tranquila. Inventarien modelos y versiones de firmware. Revisen avisos del proveedor y actualizaciones. Si no hay comunicado, pregunten soporte: si su línea está afectada, si se eliminaron credenciales embebidas y si los secretos fueron rotados.

Traten las cámaras como pequeños computadores gestionados por un proveedor externo. Pónganlas en una VLAN o red aislada. Bloqueen acceso directo a internet salvo que una función lo requiera. Cuando sea posible, usen un NVR o servidor local que hable con las cámaras mediante ONVIF o RTSP, y controlen el acceso remoto por una ruta definida.

También roten lo que sí controlan: contraseñas de administrador, cuentas por defecto, acceso al panel de gestión y reglas de salida. Si la cámara necesita llegar al proveedor para actualizarse, documéntenlo. Si habla con redes inesperadas, investiguen.

En compras, la ficha técnica no basta. Hay que preguntar si el proveedor escanea firmware ya construido, si usa allowlists de variables de entorno, si sus tokens son de alcance limitado y corta vida, si firma releases y cómo responde a disclosure de vulnerabilidades.

Para fabricantes, el control debería ser automático: escanear el código fuente, el bundle web, el rootfs desempaquetado y el archivo final de firmware. El build debe fallar si aparece un token, una clave privada o una credencial interna. Un job de frontend no debería tener un token de toda la organización por comodidad.

La parte positiva es la respuesta reportada: 12 horas y revocación. No borra el fallo, pero muestra que un canal de seguridad visible y un proceso de respuesta importan. La discusión en Hacker News, con unas 640 points y 230 comments, se centró en defensas prácticas: ONVIF, VLANs, bloquear WAN, NVR propio y tratar cámaras como endpoints no confiables.

La lección es sencilla: un producto de seguridad sigue siendo software. Su firmware es un artefacto de release, su interfaz web es un bundle cliente y su sistema de actualización es parte de la supply chain. Si esas piezas pueden llevar un secreto de CI al cliente, la cámara ya no es una caja pasiva.