Cámaras de seguridad Hanwha Vision se enviaron con un token de administrador de GitHub en la página de inicio de sesión de la UI web

 (hhh.hn)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Unas 30 archivos de la UI web de administración del firmware de las cámaras Hanwha Vision incluían el mismo token de GitHub, y ese token tenía permisos de administrador sobre cientos de repositorios dentro de la organización.
  • El fwupgrader del firmware restauraba una clave AES hardcodeada aplicando XOR con una tabla estática, y luego descifraba el sistema de archivos raíz con openssl; la clave y el IV se reutilizaban en toda la misma familia de modelos.
  • Como una variable de build de Vite quedó configurada con todo process.env, las variables de entorno del trabajo de CI terminaron grabadas en el resultado, e incluso GITHUB_NPM_TOKEN y varias configuraciones internas quedaron incluidas en el firmware de las cámaras.
  • Se revisaron unas 500 firmwares con el mismo método y se pudo extraer el 62%; los 3 firmwares donde apareció un token de GitHub contenían exactamente el mismo token.
  • Hanwha revocó el token en menos de 12 horas tras el reporte, pero una configuración que inserta todo el entorno de CI en los artefactos del cliente puede exponer credenciales e información de infraestructura interna en el producto.

Obtención del firmware y primera capa de cifrado

  • El sitio de Hanwha Vision publica las imágenes de firmware por modelo de cámara, por lo que fue posible descargar los archivos y analizarlos.
  • Al inspeccionar la imagen con binwalk, se encontró un tarball separado con componentes de IA para la cámara y un fwimage.tgz cifrado.
  • Siguiendo el análisis de descifrado del firmware Hanwha de Matt Brown, se usó una contraseña formada por HTW y el número de modelo.
    • En el caso analizado, funcionó HTWXNP-9300RW.
  • Dentro del tarball extraído había otro fwimage.tgz cifrado con un método distinto, así que no se podía reutilizar tal cual el procedimiento anterior.

Reconstrucción del método de descifrado desde fwupgrader

  • Se analizó el binario fwupgrader incluido en el tarball externo con Ghidra y Claude Code para extraer el sistema de archivos raíz real.
  • fwupgrader tenía ofuscación para ocultar el método de descifrado.
    • La clave AES se reconstruía en tiempo de ejecución tras aplicar XOR con una pequeña tabla de claves estática dentro del binario.
    • El IV estaba en texto plano dentro del binario.
    • Los fragmentos del comando openssl también estaban ofuscados con XOR de la misma forma.
  • El comando reconstruido tenía esta forma, usando SHA-256 y AES-256-CBC: 
    openssl enc -md sha256 -aes-256-cbc -d \  
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
  • La clave y el IV estaban hardcodeados y se compartían en la misma familia de modelos. 
    KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0  
IV  = 53f926801b81454a4f889c9a390db6e6

Token de administrador de GitHub incluido en el firmware

  • Al revisar el sistema de archivos raíz extraído con trufflehog, el mismo token de GitHub apareció repetido en unos 30 archivos.
  • Ese token tenía permisos de administrador sobre cientos de repositorios dentro de la organización de GitHub de Hanwha.
  • La UI de la cámara se construye con Vite, y se confirmó que una variable de build quedó configurada con todo process.env, por lo que todo el entorno del trabajo de CI terminó grabado en los archivos generados. 
    var W = {  
  DATAPORT: "9090",  
  GIT_LFS_SKIP_SMUDGE: "1",  
  npm_command: "run-script",  
  KUBERNETES_SERVICE_PORT_HTTPS: "443",  
  GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",  
  npm_config_userconfig: "/home/docker/.npmrc",  
  // etc  
}
  • No fue posible verificar el comportamiento real porque no se tenía una cámara física.
    • Es posible que el token se haya enviado por red a usuarios que accedían a la UI de administración.
    • También es posible que el archivo solo existiera en disco y en realidad no se sirviera.

Direcciones del DoD incluidas en el entorno de CI

  • Entre las variables expuestas también había direcciones IP asignadas al Departamento de Defensa de EE. UU.
  • No se pudo determinar si esas direcciones se usaban arbitrariamente para servicios internos sin comunicación externa, o si provenían de una relación entre Hanwha y el Departamento de Defensa de EE. UU.
  • Hanwha Vision es una empresa de videovigilancia fundada como Samsung Techwin y una subsidiaria de Hanwha Group.
    • Entre sus productos pasados figuran el obús autopropulsado K9 Thunder, el vehículo blindado de reabastecimiento de munición K10, subsistemas del K2 Black Panther y el robot de vigilancia SGR-A1.
    • El SGR-A1 es un robot de vigilancia armado.
  • Es posible que el CI lo proporcionara una organización central de Hanwha y que variables relacionadas se compartieran por requisitos de Hanwha Aerospace o Hanwha Defense USA, pero esto sigue siendo una especulación no confirmada.

Revisión de todo el firmware

  • Para confirmar si era un caso aislado por accidente o si había más tokens distintos, se recopilaron firmwares de cámaras disponibles para descarga en el sitio de Hanwha.
  • De unas 600 cámaras, se obtuvieron alrededor de 500 firmwares correspondientes a modelos con firmware publicado.
  • Con el mismo método se pudo extraer el 62%, y no se pudo determinar por qué falló el resto.
  • Hubo 3 firmwares que contenían tokens de GitHub, y los 3 incluían el mismo token.

Reporte y respuesta

  • Se envió al correo público de reporte de seguridad de Hanwha la información mínima necesaria para identificar la ubicación del token.
  • Hanwha respondió en menos de 12 horas tras el reporte y revocó ese token.
  • Incluir un token de GitHub en el firmware fue un error, pero la recepción del reporte y la remediación fueron muy rápidas.

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Hacker News

  • Estoy buscando cámaras IP white-label o productos casi plug-and-play cuyo fabricante dé soporte, pero que permitan eliminar el rootfs si hace falta.
    Antes solo había kits de desarrollo caros que ni siquiera tenían carcasa, pero ahora parece que hay opciones como GoodCam.

    • Aunque no sea firmware abierto, usar ONVIF en una red aislada se acerca bastante.
      Las cámaras ONVIF son compatibles con la mayoría de los grabadores de video en red (NVR), y también hay varios NVR open source.
      Si no expones al exterior cámaras PoE baratas, la seguridad del firmware del fabricante importa menos, pero hay que configurar las VLAN y la separación de redes con muchísimo cuidado.
    • Creé Wyrecam para resolver este problema, y es compatible con el Ingenic T31 de la Wyze v3.
      La estabilidad es parecida a la de Apple HomeKit, o sea, no es particularmente buena.
    • Thingino tiene una lista clara de cámaras compatibles, y si el modelo permite flasheo por tarjeta SD, la instalación es sencilla.
      Actualicé dos Sonoff Slim Gen2 sin problemas.
    • En algunas cámaras se puede reemplazar el firmware existente por Thingino, y también vale la pena consultar la lista de hardware compatible con OpenIPC.
    • La página de la tienda parece no funcionar y muestra errores como Stránka nenalezena y There's been a glitch....

  • Me parece que el problema mayor es que el firmware trae incrustadas direcciones IP del Departamento de Defensa de EE. UU., y siento que habría que evitar los productos de seguridad hechos en Corea.

    • Algunas empresas hacen blackhole de todo el rango de IP del Departamento de Defensa de EE. UU. y lo usan como direcciones internas, así que podría ser un caso así; aun así, es muy raro.
    • La Marina canadiense también parece haber tomado una decisión parecida recientemente en un gran proyecto: resultados de búsqueda
    • El Departamento de Defensa de EE. UU. tiene un espacio de direcciones IP tan enorme que también es muy posible que haya sido una coincidencia.
    • Lo mismo pasa con los productos IoT coreanos; los métodos de seguridad de los productos que he manejado personalmente eran absurdos.
    • Los productos del propio país también suelen ser un desastre por vulnerabilidades de seguridad e ingeniería descuidada.

  • Muchos proveedores usan valores predeterminados peligrosos, seguridad rota y valores hardcodeados.
    Aunque la seguridad no sea la máxima prioridad, al menos hacen falta revisiones básicas como detectar credenciales hardcodeadas.

    • Es irónico que, en una cámara de seguridad, la seguridad no sea una prioridad.
    • En un modelo operativo donde se asigna el trabajo al personal más barato y con menos experiencia, es difícil esperar siquiera controles mínimos de referencia.
    • Hoy en día basta con agregar al repositorio alguna función que ejecute revisiones básicas de seguridad, así que casi no hay excusa.

  • Lo mínimo es poner las cámaras en una VLAN separada y bloquear por completo el acceso a internet desde esa VLAN.

  • Hace tiempo revisé muchos dongles OBD-II y vi que se enviaban con la misma dirección MAC; como resultado, se podía acceder a toda la información de varios sitios web.
    Este tipo de problemas sigue apareciendo aunque uno quiera evitarlos.

    • Me da curiosidad cómo una misma dirección MAC terminaba dando acceso total.
      Si el sitio web usaba la dirección MAC proporcionada por el cliente como mecanismo de autenticación, es el típico fracaso de seguridad IoT.

  • Mejor sería quitar seguridad del nombre del producto y llamarla simplemente cámara.

  • Me molesta que este blog use mal el ícono de enlace externo.

    • El selector a[href*="://"]::after asume que los enlaces internos son rutas relativas como href="/about", pero este sitio usa URL absolutas también en los enlaces de navegación, como [https://hhh.hn/about](https://hhh.hn/about), así que todos los enlaces reciben el ícono.
      Se puede resolver excluyendo los enlaces que empiezan con la dirección del sitio: a[href*="://"]:not([href^="https://hhh.hn";])::after

  • Una luz ambiental de interior que compré hace poco no se podía controlar sin su app dedicada.
    Descargué el APK de Google Store y lo analicé; tenía prácticamente expuestas tal cual claves de API del backend y de Shopify, entre otras, aunque todavía no he usado eso para hacer nada.

    • Las claves públicas muchas veces no otorgan ningún acceso especial.
      Un desarrollador que se preocupe por la seguridad usaría App Attest o la función equivalente de Google Store.
    • No se me ocurre una razón válida para que una app de iluminación necesite acceso a la API de Shopify.
      Dicho eso, por experiencia asesorando tiendas Shopify, la calidad del código que entregan consultores o diseñadores baratos suele ser desastrosa, así que no sorprende.
    • Aunque no siempre sea lo mejor por la apariencia, es más seguro comprar solo dispositivos inteligentes con control local, como Zigbee o Z-Wave.
    • Publicar esta información es riesgoso porque la empresa podría responder legalmente.
      Había una compañía que protegía a investigadores frente a consecuencias legales, pero no recuerdo el nombre.
    • Como al final se puede controlar sin la app dedicada, ojalá alguien haga ingeniería inversa del protocolo y publique cómo hacerlo.

  • Por culpa de los LLM, la ofuscación de código quedó prácticamente inutilizada.
    La ofuscación solo servía como obstáculo al volver tedioso el trabajo, pero a la IA no le molesta ese esfuerzo.

    • La ofuscación solo era eficaz contra atacantes casuales que no toleran el aburrimiento.
      Los organismos estatales o grupos criminales de hackers están más que dispuestos a asumir ese esfuerzo.
    • Visto de forma positiva, incluso con un LLM local pequeño se puede mejorar fácilmente este código de baja calidad.

  • He visto sistemas de este tipo en una feria de la industria de defensa de EE. UU., así que es muy probable que realmente se estén usando en algún lugar.