Ataques de padding oracle en detalle

En el modo CBC (Cipher Block Chaining), el descifrado de cada bloque consiste en descifrar el bloque de texto cifrado con el cifrador de bloques y, después, aplicar XOR al resultado con el bloque de texto cifrado anterior. Esta operación XOR introduce una propiedad crítica: al modificar bits de un bloque de texto cifrado, un atacante puede afectar de forma predecible bits específicos del texto plano descifrado del bloque siguiente. Esta propiedad permite el ataque de oráculo de relleno.

Los cifradores de bloques requieren entradas divididas en bloques de tamaño fijo. El relleno PKCS#7 completa el último bloque: si se necesitan 3 bytes de relleno, se añaden tres bytes, cada uno con valor 0x03. Si el bloque ya está completo, se añade un bloque de relleno completo cuyos 16 bytes tienen el valor 0x10. Durante el descifrado, se comprueba que los bytes de relleno sean coherentes (los N bytes tienen valor N) y se eliminan. Si el relleno no es válido, el descifrado debe fallar.

Un oráculo de relleno es cualquier sistema que revela si un texto cifrado descifrado tiene un relleno PKCS#7 válido. El oráculo puede ser un mensaje de error explícito (Invalid padding), un código de estado HTTP diferente (500 frente a 403), un cuerpo de respuesta de error diferente o incluso una diferencia de tiempo (el descifrado con relleno válido es ligeramente más rápido). El atacante no necesita conocer la clave; solo necesita esta señal binaria: relleno válido o no.

El atacante elige como objetivo un bloque de texto cifrado específico. Para recuperar el último byte del texto plano, modifica el último byte del bloque de texto cifrado anterior y envía el texto cifrado modificado al oráculo. Repite el proceso con los 256 valores posibles hasta que el oráculo indique que el relleno es válido. Para el valor que produce un relleno válido (0x01), se conoce el valor intermedio del descifrado, ya que al aplicar XOR con el byte modificado produce 0x01. Al aplicar XOR con el byte original del texto cifrado se revela el byte del texto plano.

Una vez recuperado el último byte, se elige como objetivo el penúltimo. El valor intermedio del último byte ya se conoce, por lo que puede forzarse a 0x02. Después, se prueban los 256 valores del penúltimo byte hasta que el relleno 0x02 0x02 sea válido. El proceso se repite para cada byte y permite recuperar un bloque completo de 16 bytes con 256 * 16 = 4.096 consultas al oráculo de media por bloque. Con un oráculo rápido, el proceso puede completarse en segundos.

El proceso se repite para cada bloque de texto cifrado (excepto el IV, que no se puede recuperar sin el bloque anterior). Un texto cifrado de 128 bytes (8 bloques AES) requiere aproximadamente 32 000 consultas al oráculo, en promedio, para descifrarlo por completo. En un servidor web que procesa cientos de solicitudes por segundo, esto tarda minutos. El atacante recupera todo el texto plano sin llegar a conocer la clave de cifrado.

POODLE (Padding Oracle On Downgraded Legacy Encryption) aprovechó la validación del padding CBC de SSL 3.0. SSL 3.0 utilizaba un esquema de padding distinto de PKCS#7, pero el ataque adaptó el concepto del oráculo. Un atacante que pudiera inyectar contenido en una sesión SSL 3.0 y forzar a los clientes a degradar la conexión a SSL 3.0 podía recuperar cookies de sesión mediante la técnica del oráculo de padding. POODLE provocó que SSL 3.0 dejara de utilizarse.

Lucky Thirteen (2013) aprovechó un canal lateral de temporización en el esquema MAC-then-encrypt de CBC de TLS. El tiempo de verificación del MAC variaba unos pocos nanosegundos según si el padding era válido, lo que creaba un oráculo de temporización. BEAST (2011) aprovechó el IV predecible del modo CBC de TLS 1.0 para lanzar un ataque de texto plano elegido contra las cookies de sesión. Ambos ataques demostraron que el modo CBC en TLS era fundamentalmente difícil de implementar correctamente.

La defensa definitiva contra los ataques de oráculo de padding consiste en utilizar modos AEAD (cifrado autenticado con datos asociados) en lugar de CBC. Los modos AEAD, como AES-256-GCM y ChaCha20-Poly1305, verifican la autenticación antes de realizar cualquier descifrado o comprobación del padding. Si la etiqueta de autenticación no es válida, el descifrado nunca se realiza y no se filtra ninguna información sobre el padding. TLS 1.3 exige el uso de AEAD y elimina CBC por completo.

Si AEAD no está disponible, la construcción Encrypt-then-MAC añade un MAC sobre el texto cifrado, no sobre el texto plano. El MAC se verifica antes del descifrado o de comprobar el padding. Si el MAC falla, la operación se interrumpe inmediatamente sin revelar información sobre el padding. Esto debe realizarse en tiempo constante para evitar oráculos de temporización. El fallo de verificación del MAC no revela nada sobre si el padding habría sido válido.

Para comprobar si existen vulnerabilidades de oráculo de padding, cifre un mensaje conocido, envíe después un texto cifrado modificado a la aplicación y observe la respuesta. Si un padding válido y uno no válido producen respuestas observablemente distintas (mensaje de error, código de estado o tiempo de respuesta), existe un oráculo de padding. Herramientas automatizadas como padbuster y PadBuster prueban específicamente la existencia de oráculos de padding en aplicaciones web mediante la modificación sistemática de textos cifrados y el análisis de las respuestas.

¿Qué necesita un ataque de oráculo de padding del sistema objetivo para descifrar el texto cifrado sin la clave?

Resumen del oráculo de padding: la propiedad XOR del descifrado CBC permite manipular de forma controlada los bytes del texto plano; la validación del padding PKCS#7 revela un oráculo binario; el atacante itera sobre los valores de los bytes y observa respuestas válidas o no válidas para recuperar el texto plano byte a byte; los exploits reales incluyen POODLE, Lucky Thirteen y BEAST; la defensa consiste en cambiar a AEAD (GCM, ChaCha20-Poly1305), que verifica la autenticación antes del descifrado.