Ataque de injeção de vídeo

O que é um ataque de injeção de vídeo

Um ataque de injeção de vídeo consiste em alimentar o fluxo da câmera de um aplicativo com conteúdo escolhido pelo atacante, sem exibir nada ao sensor. O aplicativo recebe imagens com o formato e a cadência que esperaria da câmera física, mas essas imagens nunca passaram por uma lente.

O conteúdo injetado pode ser um vídeo real do titular, obtido de uma rede social ou de um vazamento, ou um rosto sintético gerado com um modelo. A técnica de geração é indiferente: o que define a injeção é o ponto por onde entra, não como a imagem foi produzida.

Essa é a diferença que organiza todo o resto. Em um ataque de apresentação o sistema captura corretamente algo falso. Em uma injeção o sistema não captura nada: recebe um arquivo e o trata como se fosse uma captura.

Na segurança de aplicações o mesmo nome designa outra família de ataques, a de injeção de código ou de comandos contra um banco de dados ou um interpretador. São conceitos distintos que compartilham a palavra: o que se injeta aqui é um fluxo de vídeo, não uma instrução.

A apresentação e a injeção se detêm com controles distintos

Os dois vetores costumam ser agrupados sob o mesmo rótulo, e essa confusão deixa uma brecha aberta na maioria dos fluxos.

• Ataque de apresentação — o atacante mostra algo diante da câmera real: uma foto impressa, uma tela que reproduz um vídeo, uma máscara, um deepfake projetado. A câmera funciona normalmente e captura o que tem à frente.
• Ataque de injeção — o atacante intervém no canal: uma câmera virtual registrada no sistema operacional, um emulador, um dispositivo manipulado ou uma interceptação do tráfego para o servidor. Não há nada diante da lente porque a lente não participa.

Um sistema que analisa a imagem em busca de sinais de presença pode aprovar uma injeção sem dificuldade, porque a imagem injetada é a de uma pessoa real filmada por uma câmera real, em outro momento e em outro lugar. A pergunta que a prova de vida responde é se o que se vê corresponde a uma pessoa viva. A pergunta que a injeção obriga a responder é outra: se essa imagem provém da câmera deste dispositivo, agora.

Como o ataque corre, passo a passo

A sequência é mais técnica que a de um ataque de apresentação, e uma vez montada se repete sem custo adicional.

1. Conseguir o material. Um vídeo do titular ou um rosto sintético construído a partir de uma imagem dele. Nos dois casos, sem acesso a nenhum sistema da organização.
2. Preparar o material para o fluxo. Se a verificação pede gestos, o atacante os grava ou gera de antemão, ou monta uma animação que responde em tempo real. O objetivo é ter resposta para cada desafio que o fluxo possa pedir.
3. Montar o ponto de injeção. Uma câmera virtual que o sistema operacional enumera como mais um dispositivo de captura, um emulador que simula um telefone completo, ou um dispositivo real modificado para interceptar a chamada entre o aplicativo e a câmera.
4. Executar a verificação. O aplicativo pede a captura e recebe o vídeo preparado. A comparação biométrica aprova, porque o rosto corresponde. A análise de presença também pode aprovar, porque analisa uma imagem de uma pessoa que efetivamente esteve viva diante de alguma câmera.
5. Repetir em escala. Este é o passo que separa a injeção de tudo o que veio antes. Um ataque de apresentação é artesanal e consome tempo por tentativa. Uma injeção montada se automatiza: o mesmo ambiente processa cadastros em série, trocando a identidade de entrada.

O passo 5 é o que converte o vetor em um problema de volume e não de casos isolados. Os quatro anteriores exigem conhecimento técnico, mas é conhecimento disponível, e as ferramentas de câmera virtual são produtos legítimos com usos legítimos.

Onde aparece em uma jornada de identidade

• Cadastro de conta com captura biométrica — o momento mais exposto, porque a organização ainda não tem nenhuma referência prévia dessa pessoa.
• Recuperação de acesso com rosto — onde um fluxo se resolve comparando com a captura do cadastro.
• Autorização de operações por biometria — a confirmação que um sistema pede antes de uma ação de valor.
• Canais não presenciais de alto volume — os que rodam no navegador ou em aplicativos que não controlam a integridade do dispositivo.

Os controles que respondem a esse vetor não são biométricos: são de integridade. Detecção de câmeras virtuais e emuladores, verificação da origem da imagem e checagem do ambiente de execução. Vários dependem do que o sistema operacional e o fabricante do dispositivo expõem, então nenhum provedor de identidade os resolve sozinho.

A quem afeta e quanto custa

O vetor ataca o canal de captura, então afeta qualquer processo que confie em uma câmera remota sem verificar de onde vem a imagem.

• Serviços financeiros — cadastros fraudulentos em série, que depois alimentam outras fraudes. Quando a injeção se automatiza, o problema deixa de ser uma conta e passa a ser uma coorte de contas abertas no mesmo período.
• Plataformas de apostas e gaming — verificação de idade e identidade burlada em escala, que é uma exposição regulatória antes de econômica.
• Governo — trâmites e benefícios solicitados em nome de outra pessoa, em canais que costumam aceitar navegador web, onde esse vetor é mais difícil de descartar.
• Background screening — identidade falsa em um processo de contratação ou credenciamento remoto.

O dano operacional tem uma forma particular: a organização conserva um registro de verificação aprovado, com seu vídeo e seu resultado biométrico, e esse registro é indistinguível do de um usuário legítimo. A evidência que normalmente serviria para investigar é a que o ataque fabricou.

A certificação sob a ISO/IEC 30107-3 não cobre esse vetor

Convém dizer sem rodeios, porque é a confusão mais cara desta categoria ao comparar fornecedores.

A norma ISO/IEC 30107-3 define o método e as métricas para avaliar a detecção de ataques de apresentação. Um laboratório acreditado constrói instrumentos de ataque, os apresenta contra o sistema em condições controladas e mede quantos são aceitos. Seu alcance são os ataques de apresentação: os que ocorrem diante do dispositivo de captura.

Os níveis que costumam ser citados junto à norma não são da norma. Os níveis são os graus do programa de testes da iBeta, que aplica essa metodologia: o Nível 1 usa instrumentos de ataque de baixo custo e fácil construção, o Nível 2 incorpora instrumentos de maior sofisticação e custo, e o laboratório acrescentou um Nível 3 para instrumentos de alta preparação. A VU é certificada pela iBeta no Nível 2.

Uma injeção não se apresenta diante do dispositivo de captura, então fica fora do alcance desse teste. Nenhuma certificação sob esse padrão, a da VU incluída, diz nada sobre a resistência de um sistema à injeção. Um fornecedor que responda a uma pergunta sobre injeção exibindo sua certificação de prova de vida não está respondendo à pergunta.

O que sim cabe pedir a qualquer fornecedor, incluindo a VU, é quais controles específicos aplica contra a injeção, como os avalia e com que evidência de um terceiro, se houver.

Quais controles detêm uma injeção

Nenhum controle resolve o vetor sozinho, e os dois mais determinantes não dependem do fornecedor de verificação. Nomear a lista completa é a única forma de ela ser útil.

• Detecção de câmera virtual — identifica dispositivos de captura registrados por software em vez do hardware do equipamento. É o controle mais direto e o primeiro que um atacante tenta burlar.
• Detecção de emulador e de ambiente virtualizado — reconhece quando o aplicativo roda sobre um telefone simulado e não sobre um físico.
• Integridade do dispositivo e do aplicativo — detecção de root, jailbreak, instrumentação em tempo de execução e manipulação do binário. Costuma se resolver com ferramentas de segurança móvel, que são um mercado distinto do de identidade.
• Atestação do hardware de captura — verificação de que a imagem provém da câmera física do dispositivo. Depende das interfaces que o sistema operacional e o fabricante expõem; um fornecedor pode integrá-las, não pode substituí-las.
• Verificação da integridade do fluxo — assinatura ou selagem da captura no ponto de origem, para detectar se o conteúdo foi substituído entre a câmera e o servidor.
• Sinais de sessão e de dispositivo — reputação do equipamento, repetição do mesmo material em cadastros distintos, cadência da interação, cadastros múltiplos a partir da mesma origem. Trazem contexto que a análise de imagem não tem.
• Análise do conteúdo capturado — metadados, taxa de quadros, padrões de compressão e artefatos que delatam um arquivo reproduzido em vez de uma captura ao vivo. É um controle complementar, não um substituto dos anteriores.

A integridade do dispositivo e a atestação do hardware não são resolvidas por um fornecedor de verificação sozinho. Dependem das garantias que o sistema operacional expõe, e um fornecedor que afirme cobri-las de forma independente está descrevendo algo que a plataforma não lhe concede. No navegador web a situação é ainda mais restritiva: as interfaces de atestação de hardware são escassas ou inexistentes, então o mesmo fluxo oferece menos certeza na web do que em um aplicativo móvel.

Uma equipe que monta sua defesa contra a injeção unicamente com o que seu fornecedor de biometria vende está cobrindo uma parte do problema, e não é a parte que o atacante ataca primeiro.

Como a VU aborda

A VU aplica prova de vida certificada dentro do mesmo fluxo que lê o documento e compara o rosto. Essa certificação, da iBeta no Nível 2 contra a metodologia ISO/IEC 30107-3, é evidência medida por um terceiro e cobre apresentação, não injeção. A página repete isso aqui de propósito: a capacidade que a VU pode demonstrar com um teste independente é a de apresentação.

A capacidade que agrupa os controles de captura dentro do fluxo é o Verifica, e a que traz sinais de dispositivo e de sessão é o Protege contra a fraude.