He visto demasiados proyectos fracasar no porque la cámara se rompiera, sino porque alguien la hackeó. La seguridad del firmware ya no es opcional. Es un factor decisivo.
Las auditorías estrictas de ciberseguridad de firmware incluyen análisis estático de código (SAST), pruebas de penetración de terceros, escaneo de vulnerabilidades CVE y verificación de credenciales codificadas. La mayoría de las cámaras PTZ de gama baja a media de China se envían sin estas auditorías. Solo unos pocos fabricantes que se dirigen a mercados de infraestructura crítica realizan pruebas de seguridad completas y verificables antes del lanzamiento.
Vulnerabilidades de auditoría de ciberseguridad de firmware de cámaras PTZ
Muchos integradores como David Miller me hacen esta pregunta antes de realizar un solo pedido. Necesitan pruebas, no promesas. En este artículo, desgloso cada capa de seguridad del firmware, desde los cambios forzados de contraseña hasta el parcheo de CVE, para que sepa exactamente qué exigir a su proveedor. Permítame guiarlo.
Índice
¿El firmware fuerza un cambio de contraseña al iniciar sesión por primera vez para prevenir hackeos?
Una vez ayudé a un cliente en Texas a recuperarse de una brecha. ¿La causa raíz? El instalador dejó la contraseña predeterminada admin:admin en 47 cámaras. Cada una de ellas fue comprometida en una semana.
El firmware seguro para cámaras PTZ debe obligar a los usuarios a crear una contraseña nueva y compleja en el primer inicio de sesión. Este único paso bloquea el vector de ataque más común — credenciales predeterminadas y débiles — que los informes del FBI y múltiples registros CVE confirman como el principal punto de entrada para los hackeos de cámaras.
seguridad de cambio de contraseña forzado al primer inicio de sesión de firmware de cámara PTZ
Por qué las contraseñas predeterminadas son un problema masivo
Las cifras son claras. El FBI emitió una Notificación a la Industria Privada (PIN) en 2024 advirtiendo que el grupo de amenazas HiatusRAT estaba escaneando Internet en busca de cámaras con contraseñas predeterminadas conocidas y CVE sin parchear como CVE-2017-79211 y CVE-2021-362602. Estos no son ataques raros y dirigidos. Son barridos automatizados a gran escala.
CVE-2025-35452 hace esto aún más real. Las cámaras PTZOptics que ejecutaban el firmware compartido ValueHD utilizaban la misma contraseña de administrador predeterminada en todas las unidades. Esa única falla dio a los atacantes acceso completo de administrador remoto a docenas de modelos en múltiples marcas. La causa raíz fue simple: no hubo cambio forzado de contraseña al primer arranque.
Cómo se ve una política adecuada de primer inicio de sesión
Me aseguro de que nuestro firmware Loyalty-Secu siga un estricto flujo de primer inicio de sesión. Esto es lo que sucede:
| Paso | Acción | Propósito |
|---|---|---|
| 1 | Bloquear todas las funciones hasta que se cambie la contraseña | Evitar cualquier uso con credenciales predeterminadas |
| 2 | Exigir un mínimo de 8 caracteres con mayúsculas, minúsculas, números y caracteres especiales | Detener contraseñas débiles como 123456 |
| 3 | Rechazar contraseñas que coincidan con el número de serie del dispositivo o “admin” | Bloquear patrones predecibles |
| 4 | Bloquear la IP después de 5 intentos fallidos de inicio de sesión | Prevenir ataques de fuerza bruta |
Más allá del primer inicio de sesión
Un cambio forzado de contraseña es solo la primera barrera. También configuro nuestro firmware para admitir recordatorios periódicos de caducidad de contraseña y control de acceso basado en roles (RBAC). Esto significa que la cuenta del instalador y la cuenta del administrador tienen diferentes niveles de permiso. Si las credenciales de un técnico de campo se filtran, el atacante aún no podrá cambiar la configuración de red ni actualizar el firmware.
Algunos clientes me preguntan si esto ralentiza la implementación. Añade unos 30 segundos por cámara. Eso son 30 segundos frente a un posible costo de recuperación de una brecha de 50.000 $. Creo que las matemáticas son sencillas.
¿Puedo ver un informe de “prueba de penetración” para la interfaz web de la cámara y el puerto 4G?
Recibo esta pregunta con frecuencia de los integradores de proyectos gubernamentales. No solo quieren una hoja de datos. Quieren un informe con un sello. Y, sinceramente, deberían.
Un informe de prueba de penetración debe cubrir la interfaz de administración web de la cámara (HTTP/HTTPS), los puertos de transmisión RTSP/ONVIF, la interfaz del módem 4G y cualquier punto final de API. Debe ser realizado por una empresa de seguridad independiente de terceros, dirigida al modelo específico y la versión de firmware que se está comprando.
informe de prueba de penetración interfaz web de cámara PTZ puerto 4G
Qué cubre una prueba de penetración real
He aprendido que muchos compradores confunden un escaneo de vulnerabilidades con una prueba de penetración. No son lo mismo. Un escaneo de vulnerabilidades es automatizado. Una prueba de penetración tiene a una persona intentando irrumpir, utilizando las mismas herramientas y métodos que usaría un atacante real.
Para nuestras cámaras PTZ, organizo pruebas de penetración que cubren tres áreas:
Auditoría de puertos y servicios
El probador escanea cada puerto abierto de la cámara. Para una cámara configurada correctamente, solo los puertos 80 (HTTP), 443 (HTTPS) y 554 (RTSP) deberían estar abiertos. Si el probador encuentra Telnet en el puerto 23 o SSH en el puerto 22 ejecutándose por defecto, eso es un fallo inmediato. He visto cámaras de la competencia enviadas con Telnet completamente abierto. Eso es como dejar la puerta principal sin cerrar y poner un cartel en ella.
Fuzzing de Protocolos
Aquí es donde el probador envía paquetes de datos rotos, sobredimensionados o malformados a las interfaces ONVIF, RTSP y SDK de la cámara. El objetivo es bloquear el dispositivo o forzarlo a comportarse de manera inesperada. CVE-2024-8957 es un ejemplo perfecto. Los atacantes explotaron un filtrado de entrada débil en el ntp_cliente binario para lograr la ejecución remota de código. Una prueba de fuzzing adecuada habría detectado esto antes de que se enviara el firmware.
Pruebas de Interfaz Web contra OWASP Top 10
La página de administración web de la cámara se prueba para detectar las OWASP Top 103 vulnerabilidades. Esto incluye scripting entre sitios (XSS), autenticación rota y configuraciones de seguridad erróneas. Requiero que la prueba verifique específicamente si la interfaz web transmite contraseñas en texto plano. Se ha descubierto que algunas cámaras IP chinas envían admin:admin12345 en texto plano HTTP — visible para cualquiera que espíe la red.
Qué preguntar a su proveedor
Si su proveedor no puede proporcionar un informe de prueba de penetración, eso le dice algo importante. Aquí está lo que recomiendo que solicite:
| Documento | Lo que demuestra | Bandera roja si falta |
|---|---|---|
| Informe de prueba de penetración de terceros (para modelo y versión de firmware específicos) | Verificación independiente de la seguridad | El proveedor solo se basa en pruebas internas |
| Resultados del escaneo de CVE contra la última base de datos NVD | No hay vulnerabilidades conocidas de alta gravedad | Firmware desactualizado con CVEs sin parches |
| Detalles del certificado de firma de firmware | Las actualizaciones no pueden ser manipuladas | El atacante puede inyectar firmware malicioso |
Proporciono estos documentos a mis clientes. Si un proveedor duda o dice “es confidencial”, insiste más. La seguridad de tu proyecto depende de ello.
¿Cómo parchea el fabricante las vulnerabilidades CVE recién descubiertas en el campo?
Rastreo las bases de datos de CVE cada semana. No porque disfrute leyendo informes de vulnerabilidades, sino porque una falla sin parches puede convertir una cámara de $200 en una responsabilidad de $200,000 para mi cliente.
Los fabricantes responsables mantienen un Equipo de Respuesta a Incidentes de Seguridad de Producto (PSIRT)4 que monitorea las bases de datos globales de CVE, emite avisos de seguridad y entrega parches de firmware OTA firmados dentro de los 90 días posteriores a la divulgación de una vulnerabilidad crítica. Sin este proceso, las cámaras en el campo permanecen expuestas permanentemente.
Parcheo de vulnerabilidades CVE actualización de firmware OTA cámara PTZ
El problema con el firmware “Configurar y Olvidar”
Muchas cámaras desplegadas en el campo nunca reciben una sola actualización después de la instalación. El informe de Bleeping Computer sobre CVE-2024-8956 y CVE-2024-8957 mostró que las cámaras PTZ que utilizan el SoC Hisilicon Hi3516A V600 con firmware VHD anterior a la versión 6.3.40 eran completamente explotables. Los atacantes podían tomar el control de la cámara, pivotar hacia la red local e incluso reclutar la cámara en una botnet.
El problema no es solo que existan vulnerabilidades. Todo software tiene errores. El problema real es si el fabricante tiene un sistema para solucionarlos rápidamente y enviar actualizaciones de manera confiable.
Cómo manejo el parcheo de CVE en Loyalty-Secu
Construí nuestro proceso de parcheo en torno a cuatro principios:
Monitoreo y Triaje
Nuestro equipo de seguridad interno monitorea la Base de Datos Nacional de Vulnerabilidades (NVD)8, la lista CVE de MITRE y los feeds de amenazas específicos de IoT a diario. Cuando aparece un nuevo CVE que afecta a cualquier componente de nuestro firmware, incluidas bibliotecas de terceros como OpenSSL o lighttpd, lo clasificamos por gravedad utilizando la puntuación CVSS.
Desarrollo y Pruebas de Parches
Para vulnerabilidades críticas (CVSS ≥ 7.0), requiero que se desarrolle y pruebe un parche dentro de los 30 días. El parche pasa por pruebas de regresión para asegurarnos de que no rompa las funciones existentes como el descubrimiento ONVIF o la transmisión RTSP. He visto casos en los que un parche de seguridad rompió la interfaz web de la cámara. Eso no es aceptable.
Entrega OTA Firmada
Cada paquete de actualización de firmware se firma digitalmente utilizando nuestra clave privada. Antes de que la cámara instale cualquier actualización, verifica la firma. Si la firma no coincide, la actualización se rechaza. Esto evita que los atacantes envíen un archivo de firmware modificado a la cámara. También admito la protección de reversión: la cámara no aceptará una versión de firmware anterior a la instalada actualmente.
Notificación al cliente
Envío un correo electrónico de aviso de seguridad a todos los integradores y distribuidores registrados cuando se lanza un parche. El aviso incluye el ID de CVE, los modelos afectados, las versiones de firmware, el nivel de riesgo y el enlace de descarga. La transparencia genera confianza. Ocultar vulnerabilidades la destruye.
¿La función UPnP está deshabilitada por defecto para prevenir la entrada no autorizada a la red?
Desactivé UPnP en nuestro firmware por defecto hace dos años. Fue una de las decisiones de seguridad más fáciles que he tomado, y desearía que más fabricantes hicieran lo mismo.
UPnP (Universal Plug and Play) debe estar desactivado por defecto en todas las cámaras PTZ. Cuando está habilitado, UPnP abre automáticamente puertos en el router de red sin el conocimiento del usuario, creando vías directas para que los atacantes accedan a la cámara desde Internet. Desactivarlo por defecto reduce significativamente la superficie de ataque de la cámara.
UPnP desactivado por defecto seguridad de red de cámaras PTZ
Lo que UPnP hace realmente — y por qué es peligroso
UPnP fue diseñado para facilitar la conexión en red. Un dispositivo se conecta al router y dice: “Oye, ábreme el puerto 8080 para que la gente pueda contactarme desde Internet”. El router lo hace automáticamente. Sin preguntas. Sin autenticación requerida.
Para un altavoz inteligente de consumo, eso podría ser aceptable. Para una cámara de seguridad que protege un sitio de construcción, una autopista o una subestación eléctrica, es un desastre. He aquí por qué:
La ruta de ataque que crea UPnP
Cuando UPnP abre un puerto, la cámara se vuelve directamente accesible desde Internet. Un atacante puede entonces:
- Buscar el puerto abierto utilizando herramientas como Shodan5 o Censys.
- Identificar el modelo de cámara y la versión de firmware a partir de las cabeceras HTTP.
- Buscar CVE conocidos para ese modelo.
- Explotar la vulnerabilidad — o simplemente probar contraseñas por defecto.
Así es exactamente como las botnets como Mirai reclutaron cientos de miles de cámaras IP. Muchas de esas cámaras tenían UPnP habilitado por defecto.
Nuestra filosofía de configuración por defecto
Sigo una regla simple: todos los puertos y servicios que no sean estrictamente necesarios deben cerrarse o deshabilitarse por defecto. Así es como configuro nuestras cámaras PTZ Loyalty-Secu nada más sacarlas de la caja:
| Característica / Servicio | Estado por defecto | Razón |
|---|---|---|
| UPnP | Deshabilitado | Evita el reenvío automático de puertos sin el consentimiento del usuario |
| Telnet | Deshabilitado | Shell remoto sin cifrar — riesgo grave |
| FTP | Deshabilitado | Transferencia de archivos sin cifrar — no es necesaria para el funcionamiento normal |
| SSH | Deshabilitado | Puede ser habilitado por el administrador si es necesario, pero desactivado por defecto |
| HTTPS | Habilitado | Interfaz de gestión web cifrada |
| Autenticación RTSP | Habilitado | Evita el acceso no autorizado a la transmisión de video |
| Acceso a la nube P2P | Opcional, desactivado por defecto | Reduce los vectores de ataque basados en la nube |
Cuando un cliente necesita acceso remoto
Algunos de mis clientes sí necesitan acceder a las cámaras de forma remota. En lugar de UPnP, recomiendo usar un túnel VPN7 o una conexión P2P segura con cifrado de extremo a extremo. Esto mantiene la cámara invisible a los escaneos públicos de Internet. La cámara solo se comunica con el servidor VPN o la aplicación autorizada, no con todo Internet.
También aconsejo a los clientes que segmenten su red de cámaras de su red comercial principal utilizando VLANs6. Incluso si una cámara se ve comprometida, el atacante no puede acceder a los ordenadores de la oficina, al sistema de facturación o a la base de datos de clientes. La segmentación de red es una de las medidas de seguridad más baratas y efectivas que conozco.
Para las cámaras PTZ solares conectadas por 4G desplegadas en áreas remotas, esto es aún más importante. Estas cámaras a menudo se encuentran en redes celulares con direcciones IP públicas. Si UPnP estuviera habilitado, serían blancos fáciles. Al mantener UPnP desactivado y requerir acceso basado en VPN, me aseguro de que las cámaras remotas de mis clientes permanezcan invisibles para los actores de amenazas que escanean Internet las 24 horas del día, los 7 días de la semana.
Conclusión
La seguridad del firmware no es una característica que puedas omitir. Desde cambios forzados de contraseña hasta UPnP deshabilitado, cada capa importa. Incorporo estas protecciones en cada cámara PTZ de Loyalty-Secu porque la reputación de mis clientes, y la seguridad de sus clientes, dependen de ello. Pide pruebas a tu proveedor, no promesas.
1. Fallo crítico de omisión de autenticación en cámaras Hikvision; ampliamente explotado en la naturaleza. ︎↩︎ 2. Vulnerabilidad de inyección de comandos que afecta a las cámaras Hikvision; utilizada en el reclutamiento de botnets. ︎↩︎ 3. El OWASP Top 10 es la lista estándar de la industria de riesgos de seguridad de aplicaciones web. ︎↩︎ 4. Una PSIRT es un equipo dedicado que gestiona las divulgaciones de vulnerabilidades y coordina los parches. ︎↩︎ 5. Shodan es un motor de búsqueda de dispositivos conectados a Internet, a menudo utilizado por atacantes para encontrar cámaras expuestas. ︎↩︎ 6. Las VLAN segmentan el tráfico de red, limitando el radio de explosión si una cámara se ve comprometida. ︎↩︎ 7. Un túnel VPN cifra y autentica el acceso remoto, manteniendo las cámaras fuera de Internet público. ︎↩︎ 8. La NVD es el repositorio del gobierno de EE. UU. de datos de gestión de vulnerabilidades basados en estándares. ︎↩︎