Ataque de inyección de video

Qué es un ataque de inyección de video

Un ataque de inyección de video consiste en alimentar el flujo de la cámara de una aplicación con contenido elegido por el atacante, sin exhibirle nada al sensor. La aplicación recibe imágenes con el formato y la cadencia que esperaría de la cámara física, pero esas imágenes nunca pasaron por un lente.

El contenido inyectado puede ser un video real del titular, obtenido de una red social o de una filtración, o un rostro sintético generado con un modelo. La técnica de generación es indistinta: lo que define a la inyección es el punto donde entra, no cómo se produjo la imagen.

Esa es la diferencia que ordena todo lo demás. En un ataque de presentación el sistema captura correctamente algo falso. En una inyección el sistema no captura nada: recibe un archivo y lo trata como si fuera una captura.

En seguridad de aplicaciones el mismo nombre designa otra familia de ataques, la de inyección de código o de comandos contra una base de datos o un intérprete. Son conceptos distintos que comparten la palabra: lo que se inyecta acá es un flujo de video, no una instrucción.

La presentación y la inyección se detienen con controles distintos

Los dos vectores suelen agruparse bajo la misma etiqueta, y esa confusión deja un hueco abierto en la mayoría de los flujos.

• Ataque de presentación — el atacante muestra algo frente a la cámara real: una foto impresa, una pantalla que reproduce un video, una máscara, un deepfake proyectado. La cámara funciona con normalidad y captura lo que tiene enfrente.
• Ataque de inyección — el atacante interviene el canal: una cámara virtual registrada en el sistema operativo, un emulador, un dispositivo manipulado o una intercepción del tráfico hacia el servidor. No hay nada frente al lente porque el lente no participa.

Un sistema que analiza la imagen buscando señales de presencia puede aprobar una inyección sin dificultad, porque la imagen inyectada es la de una persona real filmada por una cámara real, en otro momento y en otro lugar. La pregunta que la prueba de vida contesta es si lo que se ve corresponde a una persona viva. La pregunta que la inyección obliga a contestar es otra: si esa imagen proviene de la cámara de este dispositivo, ahora.

Cómo corre el ataque, paso a paso

La secuencia es más técnica que la de un ataque de presentación, y una vez montada se repite sin costo adicional.

1. Conseguir el material. Un video del titular o un rostro sintético construido a partir de una imagen suya. En los dos casos, sin acceso a ningún sistema de la organización.
2. Preparar el material para el flujo. Si la verificación pide gestos, el atacante los graba o los genera de antemano, o arma una animación que responde en tiempo real. El objetivo es tener respuesta para cada desafío que el flujo pueda pedir.
3. Montar el punto de inyección. Una cámara virtual que el sistema operativo enumera como un dispositivo de captura más, un emulador que simula un teléfono completo, o un dispositivo real modificado para interceptar la llamada entre la aplicación y la cámara.
4. Ejecutar la verificación. La aplicación pide la captura y recibe el video preparado. La comparación biométrica aprueba, porque el rostro corresponde. El análisis de presencia también puede aprobar, porque analiza una imagen de una persona que efectivamente estuvo viva frente a alguna cámara.
5. Repetir a escala. Este es el paso que separa a la inyección de todo lo anterior. Un ataque de presentación es artesanal y consume tiempo por intento. Una inyección montada se automatiza: el mismo entorno procesa altas en serie, cambiando la identidad de entrada.

El paso 5 es el que convierte al vector en un problema de volumen y no de casos aislados. Los cuatro anteriores requieren conocimiento técnico, pero es conocimiento disponible y las herramientas de cámara virtual son productos legítimos con usos legítimos.

Dónde aparece en un recorrido de identidad

• Alta de cuenta con captura biométrica — el momento más expuesto, porque la organización todavía no tiene ninguna referencia previa de esa persona.
• Recuperación de acceso con rostro — donde un flujo se resuelve comparando contra la captura del alta.
• Autorización de operaciones por biometría — la confirmación que un sistema pide antes de una acción de valor.
• Canales no presenciales de alto volumen — los que corren en el navegador o en aplicaciones que no controlan la integridad del dispositivo.

Los controles que responden a este vector no son biométricos: son de integridad. Detección de cámaras virtuales y emuladores, verificación del origen de la imagen y comprobación del entorno de ejecución. Varios dependen de lo que exponen el sistema operativo y el fabricante del dispositivo, así que ningún proveedor de identidad los resuelve solo.

A quién afecta y qué cuesta

El vector ataca al canal de captura, así que afecta a cualquier proceso que confíe en una cámara remota sin verificar de dónde viene la imagen.

• Servicios financieros — altas fraudulentas en serie, que después alimentan otros fraudes. Cuando la inyección se automatiza, el problema deja de ser una cuenta y pasa a ser una cohorte de cuentas abiertas en el mismo período.
• Plataformas de apuestas y gaming — verificación de edad e identidad evadida a escala, que es una exposición regulatoria antes que económica.
• Gobierno — trámites y beneficios tramitados a nombre de otra persona, en canales que suelen aceptar navegador web, donde este vector es más difícil de descartar.
• Background screening — identidad falsa en un proceso de contratación o acreditación remota.

El daño operativo tiene una forma particular: la organización conserva un registro de verificación aprobado, con su video y su resultado biométrico, y ese registro es indistinguible del de un usuario legítimo. La evidencia que normalmente serviría para investigar es la que el ataque fabricó.

La certificación bajo ISO/IEC 30107-3 no cubre este vector

Conviene decirlo sin rodeos, porque es la confusión más costosa de esta categoría al comparar proveedores.

La norma ISO/IEC 30107-3 define el método y las métricas para evaluar la detección de ataques de presentación. Un laboratorio acreditado construye instrumentos de ataque, los presenta contra el sistema en condiciones controladas y mide cuántos son aceptados. Su alcance son los ataques de presentación: los que ocurren frente al dispositivo de captura.

Los niveles que suelen citarse junto a la norma no son de la norma. Los niveles son los grados del programa de ensayo de iBeta, que aplica esa metodología: el Nivel 1 usa instrumentos de ataque de bajo costo y fácil construcción, el Nivel 2 incorpora instrumentos de mayor sofisticación y costo, y el laboratorio agregó un Nivel 3 para instrumentos de alta preparación. VU está certificada por iBeta en el Nivel 2.

Una inyección no se presenta ante el dispositivo de captura, así que queda fuera del alcance de ese ensayo. Ninguna certificación bajo ese estándar, la de VU incluida, dice nada sobre la resistencia de un sistema a la inyección. Un proveedor que responda a una pregunta sobre inyección exhibiendo su certificación de prueba de vida no está contestando la pregunta.

Lo que sí corresponde pedirle a cualquier proveedor, incluido VU, es qué controles específicos aplica contra la inyección, cómo los evalúa y con qué evidencia de un tercero, si la hay.

Qué controles detienen una inyección

Ningún control resuelve el vector solo, y los dos más determinantes no dependen del proveedor de verificación. Nombrar la lista completa es la única forma de que sea útil.

• Detección de cámara virtual — identifica dispositivos de captura registrados por software en lugar del hardware del equipo. Es el control más directo y el primero que un atacante intenta evadir.
• Detección de emulador y de entorno virtualizado — reconoce cuando la aplicación corre sobre un teléfono simulado y no sobre uno físico.
• Integridad del dispositivo y de la aplicación — detección de rooteo, jailbreak, instrumentación en tiempo de ejecución y manipulación del binario. Suele resolverse con herramientas de seguridad móvil, que son un mercado distinto del de identidad.
• Atestación del hardware de captura — verificación de que la imagen proviene de la cámara física del dispositivo. Depende de las interfaces que expongan el sistema operativo y el fabricante; un proveedor puede integrarlas, no puede sustituirlas.
• Verificación de la integridad del flujo — firma o sellado de la captura en el punto de origen, para detectar si el contenido fue reemplazado entre la cámara y el servidor.
• Señales de sesión y de dispositivo — reputación del equipo, repetición del mismo material en altas distintas, cadencia de la interacción, altas múltiples desde el mismo origen. Aportan contexto que el análisis de imagen no tiene.
• Análisis del contenido capturado — metadatos, tasa de cuadros, patrones de compresión y artefactos que delatan un archivo reproducido en lugar de una captura en vivo. Es un control complementario, no un sustituto de los anteriores.

La integridad del dispositivo y la atestación del hardware no las resuelve un proveedor de verificación por sí solo. Dependen de las garantías que expone el sistema operativo, y un proveedor que afirme cubrirlas de forma independiente está describiendo algo que la plataforma no le concede. En navegador web la situación es más restrictiva todavía: las interfaces de atestación de hardware son escasas o inexistentes, así que el mismo flujo ofrece menos certeza en web que en una aplicación móvil.

Un equipo que arma su defensa contra la inyección únicamente con lo que le vende su proveedor de biometría está cubriendo una parte del problema, y no es la parte que el atacante ataca primero.

Cómo lo aborda VU

VU aplica prueba de vida certificada dentro del mismo flujo que lee el documento y compara el rostro. Esa certificación, de iBeta en el Nivel 2 contra la metodología ISO/IEC 30107-3, es evidencia medida por un tercero y cubre presentación, no inyección. La página lo repite acá a propósito: la capacidad que VU puede demostrar con un ensayo independiente es la de presentación.

La capacidad que agrupa los controles de captura dentro del flujo es Verifica, y la que aporta señales de dispositivo y de sesión es Protege contra el fraude.