Ataques de Oráculo de Preenchimento em Detalhes

No modo CBC (encadeamento de blocos de cifra), a descriptografia de cada bloco envolve descriptografar o bloco de texto cifrado com a cifra de bloco e, em seguida, aplicar XOR ao resultado com o bloco de texto cifrado anterior. Essa operação XOR introduz uma propriedade crítica: ao modificar bits em um bloco de texto cifrado, um invasor pode afetar de forma previsível bits específicos do texto em claro descriptografado do bloco seguinte. Essa propriedade possibilita o ataque de oráculo de preenchimento.

As cifras de bloco exigem entradas em blocos de tamanho fixo. O preenchimento PKCS#7 completa o último bloco: se forem necessários 3 bytes de preenchimento, adicione três bytes, cada um com o valor 0x03. Se o bloco já estiver completo, adicione um bloco completo de preenchimento no qual todos os 16 bytes tenham o valor 0x10. Durante a descriptografia, os bytes de preenchimento são verificados para garantir consistência, de modo que todos os N bytes tenham o valor N, e depois são removidos. Se o preenchimento for inválido, a descriptografia deverá falhar.

Um oráculo de preenchimento é qualquer sistema que revele se um texto cifrado descriptografado tem preenchimento PKCS#7 válido. O oráculo pode ser: uma mensagem de erro explícita, como Preenchimento inválido, um código de status HTTP diferente, como 500 em vez de 403, um corpo de resposta de erro diferente ou até mesmo uma diferença de tempo, pois a descriptografia com preenchimento válido é ligeiramente mais rápida. O invasor não precisa conhecer a chave; ele precisa apenas deste sinal binário: preenchimento válido ou inválido.

O invasor escolhe como alvo um bloco específico de texto cifrado. Para recuperar o último octeto do texto em claro: altere o último octeto do bloco de texto cifrado anterior e envie o texto cifrado modificado ao oráculo. Repita o processo com os 256 valores possíveis até que o oráculo informe que o preenchimento é válido. No valor que produz um preenchimento válido, 0x01, o valor intermediário da descriptografia é conhecido, pois foi submetido a XOR com o octeto modificado para produzir 0x01. Aplicar XOR ao octeto original do texto cifrado revela o octeto do texto em claro.

Depois que o último octeto é recuperado, o penúltimo octeto se torna o alvo. O valor intermediário do último octeto já é conhecido, portanto ele pode ser forçado para 0x02. Em seguida, repita o processo com os 256 valores do penúltimo octeto até que o preenchimento 0x02 0x02 seja válido. Esse processo se repete para cada octeto, recuperando um bloco completo de 16 octetos com 256 * 16 = 4.096 consultas ao oráculo, em média, por bloco. Com um oráculo rápido, isso pode ser concluído em segundos.

O processo é repetido para cada bloco de texto cifrado, exceto o IV, que não pode ser recuperado sem o bloco anterior. Um texto cifrado de 128 bytes, composto por 8 blocos AES, exige em média aproximadamente 32.000 consultas ao oráculo para ser completamente descriptografado. Contra um servidor web que processa centenas de solicitações por segundo, isso leva minutos. O invasor recupera todo o texto claro sem jamais descobrir a chave de criptografia.

O POODLE (Oráculo de preenchimento em criptografia legada rebaixada) explorou a validação de preenchimento CBC do SSL 3.0. O SSL 3.0 usava um esquema de preenchimento não-PKCS#7, mas o ataque adaptou o conceito de oráculo. Um invasor que conseguisse injetar conteúdo em uma sessão SSL 3.0 e forçar os clientes a rebaixar para o SSL 3.0 poderia recuperar cookies de sessão usando a técnica do oráculo de preenchimento. O POODLE forçou a descontinuação do SSL 3.0.

O Lucky Thirteen, de 2013, explorou um canal lateral temporal no esquema MAC-then-encrypt do TLS baseado em CBC. O tempo de verificação do MAC diferia em alguns nanossegundos conforme o preenchimento fosse válido ou não, criando um oráculo temporal. O BEAST, de 2011, explorou o IV previsível no modo CBC do TLS 1.0 para realizar um ataque de texto claro escolhido contra cookies de sessão. Ambos os ataques demonstraram que o modo CBC no TLS era fundamentalmente difícil de implementar corretamente.

A defesa definitiva contra ataques de oráculo de preenchimento é usar modos AEAD (Criptografia autenticada com dados associados) em vez de CBC. Modos AEAD como AES-256-GCM e ChaCha20-Poly1305 verificam a autenticação antes que qualquer descriptografia ou verificação de preenchimento ocorra. Se a marca de autenticação for inválida, a descriptografia nunca acontecerá e nenhuma informação sobre o preenchimento será vazada. O TLS 1.3 exige AEAD e remove completamente o CBC.

Se AEAD não estiver disponível, a construção de criptografar e depois aplicar MAC adiciona um MAC sobre o texto cifrado, não sobre o texto claro. Antes da descriptografia ou da verificação do preenchimento, o MAC é verificado. Se o MAC falhar, a operação é imediatamente interrompida sem revelar nenhuma informação sobre o preenchimento. Isso deve ser feito em tempo constante para impedir oráculos temporais. A falha na verificação do MAC não revela nada sobre a validade que o preenchimento teria.

Para testar vulnerabilidades de oráculo de preenchimento, criptografe uma mensagem conhecida, envie um texto cifrado modificado à aplicação e observe a resposta. Se preenchimentos válidos e inválidos produzirem respostas observavelmente diferentes, como mensagem de erro, código de status ou tempo de resposta, existirá um oráculo de preenchimento. Ferramentas automatizadas como padbuster e PadBuster testam especificamente oráculos de preenchimento em aplicações web, modificando sistematicamente textos cifrados e analisando as respostas.

O que um ataque de oráculo de preenchimento exige do sistema-alvo para descriptografar um texto cifrado sem a chave?

Recapitulação do oráculo de preenchimento: a propriedade XOR da descriptografia CBC permite a manipulação controlada de bytes do texto claro; a validação do preenchimento PKCS#7 revela um oráculo binário; o invasor itera pelos valores de byte e observa respostas válidas ou inválidas para recuperar o texto claro byte a byte; as explorações reais incluem POODLE, Lucky Thirteen e BEAST; a defesa consiste em mudar para AEAD, como GCM e ChaCha20-Poly1305, que verifica a autenticação antes da descriptografia.