🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónAtaques de oráculo de relleno (Padding Oracle)
4 tareas · 25 min · Principiante
El modo CBC (Cipher Block Chaining) fue durante décadas el rey del cifrado simétrico en la web y las VPNs. Sin embargo, cuando se combina con un relleno PKCS#7 y una aplicación que informa de errores de desrellenado, un atacante pasivo puede descifrar cualquier mensaje byte a byte sin conocer la clave secreta. En esta sala dominarás el mecanismo de los ataques de oráculo de relleno.
Objetivo de la sala
El modo CBC (Cipher Block Chaining) fue durante décadas el rey del cifrado simétrico en la web y las VPNs. Sin embargo, cuando se combina con un relleno PKCS#7 y una aplicación que informa de errores de desrellenado, un atacante pasivo puede descifrar cualquier mensaje byte a byte sin conocer la clave secreta. En esta sala dominarás el mecanismo de los ataques de oráculo de relleno.Los algoritmos por bloques como AES procesan datos en fragmentos fijos de 16 bytes. Si el último bloque de un mensaje tiene solo 13 bytes, faltan 3 bytes para completarlo. El estándar PKCS#7 rellena esos 3 bytes vacíos con el valor hexadecimal del número de bytes añadidos: 0x03 0x03 0x03. Si falta 1 byte, añade 0x01. Si el mensaje ya mide un múltiplo exacto de 16 bytes, se añade un bloque entero de 16 bytes de relleno con valor 0x10. Al descifrar, el receptor lee el último byte y retira esa cantidad de bytes del final.
Responde para continuar
Bajo la norma PKCS#7 con bloques de 16 bytes, si el mensaje ocupa 14 bytes en el último bloque, ¿qué bytes de relleno se añaden?
Ver pista de ayuda
Se añaden tantos bytes como falten, y cada byte tiene un valor igual al total de bytes agregados.
Un 'oráculo' es cualquier sistema que responde de manera diferente según si el relleno es válido o no. Si un atacante intercepta un token cifrado en una cookie y altera el último byte del bloque anterior, al enviar la petición al servidor pueden pasar dos cosas: 1) El servidor responde HTTP 500 'Error de desrellenado / Padding inválido'. 2) El servidor responde HTTP 403 'Datos inválidos / Sesión expirada'. Esa sutil diferencia de código o tiempo de respuesta confirma al atacante si su modificación produjo un relleno PKCS#7 válido.
Responde para continuar
¿Qué comportamiento de un servidor web convierte a su endpoint en un oráculo de relleno?
Ver pista de ayuda
La confirmación de si el padding fue válido o corrupto filtra el bit que el atacante necesita.
En AES-CBC, el texto claro del bloque actual se obtiene haciendo un XOR entre el bloque descifrado intermedio y el bloque cifrado anterior. Modificando el byte del bloque anterior desde 0x00 hasta 0xFF (256 intentos como máximo), el atacante encuentra el valor exacto que hace que el receptor interprete el último byte como 0x01. Conociendo el byte que inyectó y el resultado del XOR, el atacante calcula algebraicamente el byte del texto claro original. Repitiendo el proceso hacia la izquierda, descifra el bloque entero en apenas unos miles de peticiones.
Responde para continuar
¿Cuántas peticiones como máximo debe enviar un atacante a un oráculo de relleno para descubrir un byte del texto claro en un bloque?
Ver pista de ayuda
Un byte tiene 256 combinaciones posibles (de 0 a 255).
La razón por la que los ataques de oráculo de relleno tuvieron tanto éxito (POODLE, Lucky Thirteen) es que la arquitectura descifraba primero y comprobaba la integridad después (o no la comprobaba). En los esquemas modernos AEAD (como AES-GCM o ChaCha20-Poly1305), el orden es estricto: el tag de autenticación se valida en tiempo constante ANTES de intentar descifrar cualquier contenido. Si el texto cifrado ha sufrido la menor alteración de un solo bit, la operación se cancela en seco sin ejecutar desrellenado.
Responde para continuar
¿Por qué los esquemas de cifrado autenticado AEAD (como AES-GCM) son completamente inmunes a los ataques de oráculo de relleno?
Ver pista de ayuda
La verificación previa del tag de autenticación impide que se procesen bloques manipulados.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.