Estaba viendo HackerNews mientras tomaba once cuando me topé con una noticia que me hizo dejar el mate en el aire. Una cámara de seguridad coreana — la marca se llama Hanwha Vision, antes Samsung Techwin — estaba despachando un token de administrador de GitHub incrustado directamente en el firmware de sus equipos. Y no es que estuviera bien escondido. Estaba en treinta y tantos archivos del sistema, metido ahí por el lado del proceso de build de la interfaz web.
Desde el firmware a los repos del DoD
El investigador que lo descubrió simplemente bajó el firmware, lo abrió con binwalk, usó la clave que otra persona había encontrado — literalmente HTW más el modelo — y ahí estaba: el rootfs completo de la cámara. Después tiró TruffleHog, una herramienta que ya uso en la pega para encontrar secretos en repos, y el resultado fue inmediato. Un token ghp_... con privilegios de administrador sobre cientos de repositorios de la organización.
Pero la wea no termina ahí. Dentro de las variables de entorno inyectadas en el build también aparecían IPs del Departamento de Defensa de Estados Unidos. Eso me hizo ruido. Resulta que Hanwha Vision es subsidiaria de Hanwha Group, que a su vez tiene Hanwha Defense USA y fabrica artillería autopropulsada. No es que sea una cámara de un supermercado cualquiera. Es hardware de doble uso, vendido a entornos críticos, y su pipeline de CI tenía todo el entorno de ejecución volcado en los archivos del frontend.
El problema real no es el token
El verdadero problema es la mentalidad. Vite, el bundler que usaron para la interfaz, tenía una línea que tiraba process.env entero en una variable de JavaScript. Cualquiera que haya trabajado con Node sabe que eso es un error de novato, pero acá pasó en la línea de producción de una empresa de hardware que vende cámaras a entornos corporativos, institucionales y militares. Treinta archivos con el mismo token, porque la variable de entorno se inyectó múltiples veces en el build. Es pereza técnica con consecuencias reales.
Lo que más me rescató del reporte es que el investigador usó Claude Code para auditar el binario fwupgrader mientras cenaba. La IA le dio un rootfs completo a los pocos minutos. Eso me parece bacán y un poco aterrador al mismo tiempo: la misma tecnología que ayuda a encontrar vulnerabilidades es la que permite fabricar el hardware con estas cagadas.
¿Qué aprendemos de esto?
Primero, si eres de los que maneja cámaras IP en la pega, deberías revisar el firmware antes de desplegarlo. No es para paranoicos. Es para gente que no quiere que su infraestructura de video quede como backdoor de un atacante. Segundo, los tokens de CI nunca, nunca deberían llegar al artefacto de build. Tercero, si tu frontend incluye process.env completo, tienes un problema de arquitectura que no se arregla con un parche, se arregla con educación.
La buena noticia es que Hanwha respondió en menos de doce horas, revocó el token y al parecer ya cerraron el hoyo. Pero el daño ya estaba hecho: ese firmware circuló en cientos de equipos, y el token tenía acceso a repositorios de producción que podrían contener código de sistemas de defensa. A veces me pregunto cuántas cámaras más andan con secretos adentro, esperando a que alguien con curiosidad y unas horas libres les eche un ojo.
Cachai? En seguridad, la cadena más débil no es el algoritmo. Es el build que hizo Juanito a las 3 de la mañana un viernes.
Fuente de inspiración: My security camera shipped a GitHub admin token in its login page
