PadBuster: Ataque Padding Oracle Español
PadBuster: Ataque Padding Oracle Español
Si estás buscando aprender sobre PadBuster en Kali Linux, estás entrando en el interesante mundo de los ataques criptográficos, específicamente contra el relleno de bloques (padding).
Aquí tienes una guía rápida y clara sobre qué es y cómo usarlo.
¿Qué es PadBuster?
Es una herramienta escrita en Perl diseñada para automatizar ataques de Padding Oracle. Estos ataques permiten a un atacante descifrar datos cifrados sin conocer la clave, e incluso cifrar datos nuevos, aprovechando los mensajes de error que devuelve una aplicación cuando el "padding" (relleno) de un bloque de datos es incorrecto.
Uso básico de PadBuster
La sintaxis general es la siguiente:
padbuster URL EncryptedSample BlockSize [opciones]
Los parámetros principales:
URL: La dirección del objetivo (incluyendo el parámetro vulnerable).
EncryptedSample: El valor cifrado que quieres romper (usualmente una cookie o un parámetro en la URL).
BlockSize: El tamaño del bloque del algoritmo de cifrado (comúnmente 8 para DES/3DES o 16 para AES).
Ejemplo de comando paso a paso
Imagina que tienes una cookie cifrada llamada auth y sospechas que es vulnerable:
Identificar el objetivo:
padbuster http://sitio-vulnerable.com/index.php?auth=Lp6Jp02vkM4%3D Lp6Jp02vkM4%3D 8 -cookies "auth=Lp6Jp02vkM4%3D"Seleccionar el ID de error:
Al ejecutarlo, PadBuster probará diferentes variaciones. Te preguntará cuál de las respuestas del servidor indica un error de padding (basándose en el código de estado HTTP o el contenido de la página). Solo debes elegir el número de la lista que corresponda al error.
Descifrado:
Una vez configurado, la herramienta empezará a trabajar bloque por bloque hasta mostrarte el valor en texto plano (por ejemplo:
user=admin).
Opciones comunes que te ayudarán
-cookies: Para pasar cookies de sesión si el sitio las requiere.
-encoding: Define cómo están codificados los datos (0=Base64, 1=Hex, 2=UpperHex). Por defecto es Base64.
-plaintext: ¡Esta es genial! Te permite generar un nuevo token cifrado para suplantar a otro usuario (ej: cambiar
user=guestporuser=admin).
[!IMPORTANT]
Nota de seguridad: Recuerda que el ataque de Padding Oracle requiere realizar cientos o miles de peticiones HTTP. Es un proceso ruidoso y puede ser detectado fácilmente por un WAF (Web Application Firewall).
Vamos a simular un escenario práctico. Imagina que estás realizando una auditoría en una aplicación web y encuentras que el usuario se identifica mediante una cookie llamada user_session que parece estar en Base64.
El Escenario
URL:
http://test-app.local/profile.phpCookie detectada:
user_session=YTIzNGI1YTY3ODkwYWJjZA%3D%3DAlgoritmo sospechoso: AES (por lo que probaremos con un BlockSize de 16).
1. El Comando para Descifrar
Si quieres ver qué información hay dentro de esa cookie, el comando sería:
padbuster http://test-app.local/profile.php YTIzNGI1YTY3ODkwYWJjZA%3D%3D 16 -cookies "user_session=YTIzNGI1YTY3ODkwYWJjZA%3D%3D"
¿Qué pasará al ejecutarlo?
PadBuster enviará varias peticiones y te mostrará una tabla con diferentes respuestas HTTP. Te preguntará:
“Enter the response ID that matches an invalid padding response”
Deberás observar cuál de las opciones tiene una longitud de respuesta (Content-Length) o un código de estado (Status) que indique un error (normalmente el que aparece más veces en la lista). Escribe el número y presiona Enter.
2. El Comando para Suplantar (Ataque de Forja)
Supongamos que el comando anterior te reveló que el texto plano de la cookie es user=empleado. Ahora quieres elevar tus privilegios a user=admin.
Usarás la opción -plaintext:
padbuster http://test-app.local/profile.php YTIzNGI1YTY3ODkwYWJjZA%3D%3D 16 -cookies "user_session=YTIzNGI1YTY3ODkwYWJjZA%3D%3D" -plaintext "user=admin"
Resultado esperado:
Al finalizar, PadBuster no te dará el texto plano, sino que te entregará un nuevo valor cifrado (un nuevo string en Base64). Si sustituyes tu cookie actual por ese nuevo valor en tu navegador, la aplicación creerá que eres el administrador.
Diagrama del flujo de ataque
Para entender por qué necesitamos tantas peticiones, aquí puedes ver cómo el atacante interactúa con el "oráculo" (el servidor) enviando pequeñas modificaciones hasta que el relleno es correcto:
Consejos Pro:
-headers: Si el sitio requiere un User-Agent específico o un token de CSRF, agrégalo aquí.
-prefix: Úsalo si el valor cifrado tiene un IV (Vector de Inicialización) pegado al principio.
Identificar el tamaño de bloque (Block Size) es el primer paso crítico. Si te equivocas aquí, PadBuster simplemente no podrá encontrar patrones lógicos en las respuestas del servidor y fallará.
Aquí te explico cómo deducirlo como un profesional:
1. La Regla de la Longitud (Matemáticas simples)
Los algoritmos de cifrado por bloques (como AES o DES) siempre cifran datos en trozos de tamaño fijo. Por lo tanto, el texto cifrado (en bytes) siempre debe ser un múltiplo del tamaño del bloque.
Toma tu cadena en Base64:
YTIzNGI1YTY3ODkwYWJjZA==Decodifícala a bytes (puedes usar
echo "cadena" | base64 -d | wc -cen la terminal).Si el resultado es 16 bytes, el bloque podría ser 8 o 16. Si es 24, podría ser 8. Si es 32, podría ser 8 o 16.
[!TIP]
Si el número de bytes es impar, probablemente no sea un cifrado de bloque puro o tenga un formato especial.
2. El Método de "Fuerza Bruta" con PadBuster
Si no quieres hacer cálculos, PadBuster tiene una forma de avisarte si el tamaño es incorrecto. Cuando lanzas el comando:
Si eliges 8 y es 16: PadBuster lanzará errores constantes o no encontrará ninguna firma de respuesta que tenga sentido (todas las respuestas parecerán iguales).
Si eliges 16 y es 8: El ataque fallará rápidamente porque el padding esperado no coincidirá con la estructura de los datos.
¿Cómo probar tamaños no comunes?
Aunque el 95% de las veces será 8 (DES/3DES) o 16 (AES), existen otros tamaños. Puedes probar en este orden:
16 (El estándar moderno más común).
8 (Común en sistemas antiguos o aplicaciones legacy).
32 (Raro, pero posible en algunas configuraciones de Rijndael).
3. Observando el Comportamiento del Servidor
Puedes usar una herramienta como Burp Suite para confirmar el tamaño del bloque manualmente:
Envía la petición al Repeater.
Modifica el último byte del valor cifrado.
Si el servidor devuelve un error de padding, ya sabes que el bloque termina ahí.
Ahora, intenta modificar el byte en la posición 9 (contando desde el final). Si el error cambia o se mantiene, puedes mapear dónde empieza y termina cada bloque.
4. ¿Qué pasa si nada funciona?
Si ni 8 ni 16 funcionan, es posible que:
El IV (Vector de Inicialización) esté pegado al principio del texto cifrado. Prueba usar el parámetro
-prefixpara saltarte los primeros bytes.No sea un Padding Oracle: Quizás la aplicación usa un cifrado de flujo (Stream Cipher) como RC4, que no usa bloques ni relleno.
Encoding incorrecto: Asegúrate de que no sea Hexadecimal en lugar de Base64 usando
-encoding 1.
Usar Burp Suite junto con PadBuster es la combinación ganadora. Burp te permite ver exactamente qué está pasando "bajo el capó" antes de que PadBuster empiece a lanzar miles de peticiones.
Aquí tienes los pasos para interceptar, analizar y luego atacar:
1. Interceptar la petición en Burp Suite
Primero, asegúrate de que tu navegador está pasando el tráfico por Burp.
Abre Burp Suite y ve a la pestaña Proxy -> Intercept.
Realiza la acción en la web que genera la cookie o el parámetro sospechoso.
Haz clic derecho sobre la petición y selecciona Send to Repeater.
2. Identificar el comportamiento del "Oráculo" (Manual)
Antes de usar PadBuster, confirma que el servidor responde diferente cuando el relleno es malo.
En el Repeater, busca tu valor cifrado (ej: la cookie
user_session).Cambia el último carácter del valor cifrado por cualquier otro.
Dale a Send.
Observa la respuesta:
¿Recibes un
500 Internal Server Error?¿Un mensaje que dice "Invalid Padding"?
¿La página mide 5230 bytes en lugar de los 5500 habituales?
[!IMPORTANT]
Si la respuesta es exactamente igual a la original, la aplicación no es vulnerable a este ataque o estás modificando algo que no es el bloque de cifrado.
3. Preparar el comando de PadBuster con Burp
Una vez que sabes qué error buscar, lanza PadBuster. Si el sitio usa HTTPS o cabeceras complejas, lo más fácil es copiar la cookie directamente de Burp.
Comando Pro:
padbuster http://objetivo.com/perfil.php "VALOR_DE_BURP==" 16 -cookies "user_session=VALOR_DE_BURP==" -verbose
4. El truco del Proxy (Ver qué hace PadBuster)
Si quieres que PadBuster envíe todas sus peticiones a través de Burp para poder verlas en el historial (esto es muy útil para depurar), añade el parámetro -proxy:
padbuster http://objetivo.com/api "VALOR" 16 -proxy http://127.0.0.1:8080
¿Qué verás en Burp?
Verás cientos de peticiones en la pestaña HTTP History. Fíjate en la columna Length (Longitud).
Casi todas las peticiones tendrán el mismo tamaño (el error de padding).
Una petición será diferente (esa es la que tiene el byte de padding correcto). PadBuster detectará esa diferencia automáticamente para descifrar el siguiente byte.
Tabla de Errores Comunes en este flujo:
| Problema | Solución en PadBuster |
| El servidor te banea por exceso de peticiones | Usa -delay 500 (milisegundos) para ir más lento. |
| La cookie cambia en cada petición | Usa -headers "Cookie: session=..." con una cookie estática. |
El valor tiene caracteres raros (+, /, =) | Asegúrate de que el valor esté URL-encoded o usa -encoding 0. |
Vamos a entrar en la parte más "divertida" y potente de PadBuster: la forja de datos (bit-flipping / data forging). Aquí es donde pasas de ser un observador que descifra a un atacante que modifica la lógica de la aplicación.
El Objetivo: De "guest" a "admin"
Supongamos que, tras descifrar la cookie en el paso anterior, descubriste que el contenido original es:
user=guest;role=read;id=105
Tu meta es cambiarlo por:
user=admin;role=root;id=001
1. El Comando de Forja
Para generar un nuevo bloque cifrado que el servidor acepte como válido y que contenga tu texto personalizado, usamos el parámetro -plaintext.
padbuster http://objetivo.com/perfil.php "VALOR_CIFRADO_ORIGINAL" 16 -cookies "user_session=VALOR_CIFRADO_ORIGINAL" -plaintext "user=admin;role=root;id=001"
2. ¿Qué está haciendo PadBuster realmente?
PadBuster no necesita la clave secreta del servidor. Lo que hace es:
Trabajar hacia atrás: Empieza por el último bloque de tu nuevo texto plano.
Manipular el IV (Vector de Inicialización): Calcula qué valores debe tener el bloque anterior para que, al pasar por la operación XOR del algoritmo, el resultado sea exactamente la letra "a" de "admin", luego la "d", y así sucesivamente.
Iteración: Repite este proceso para cada bloque hasta llegar al principio.
3. El Resultado Final
Al terminar (esto puede tardar unos minutos dependiendo de la velocidad del servidor), PadBuster te mostrará algo como esto en la terminal:
-------------------------------------------------------
** Forged Bytes Found! **
-------------------------------------------------------
Original Plaintext: user=guest;role=read;id=105
Forged Plaintext: user=admin;role=root;id=001
Forged Bytes (Base64): ENCRYPTED_VALUE_GENERATED_BY_PADBUSTER==
-------------------------------------------------------
4. Cómo inyectarlo usando Burp Suite
Ahora que tienes el nuevo valor en Base64:
Ve a Burp Suite -> Proxy -> Intercept (asegúrate de que esté en ON).
Refresca la página en tu navegador.
Cuando Burp atrape la petición, borra el valor de la cookie original y pega el nuevo valor que te dio PadBuster.
Pulsa Forward.
Si el ataque tuvo éxito, la página debería cargarse reconociéndote como el usuario admin.
¿Qué puede salir mal?
Longitud del bloque: Si tu nuevo texto plano es más largo que el original, PadBuster tendrá que generar más bloques, lo que duplica el tiempo de espera.
Firma de error variable: Si el servidor empieza a dar respuestas inconsistentes (a veces 500, a veces 404), PadBuster se confundirá. En ese caso, usa
-errorpara especificarle exactamente qué texto buscar en la respuesta de error.
[!TIP]
Si el servidor tiene un CheckSum o un HMAC (una firma de seguridad adicional al final de la cookie), este ataque fallará porque, aunque logres descifrar o forjar el bloque, no podrás generar una firma válida sin la clave secreta.
Detectar si un sitio utiliza HMAC (Hash-based Message Authentication Code) es vital, porque el HMAC actúa como un "sello de lacre" sobre el paquete. Aunque logres manipular el contenido cifrado con PadBuster, si no puedes recrear ese sello (que requiere una clave secreta), el servidor rechazará la cookie inmediatamente.
Aquí te explico cómo identificarlo usando Burp Suite antes de lanzar el ataque:
1. Observa la Longitud de la Cookie
El HMAC tiene una longitud fija dependiendo del algoritmo (SHA-1, SHA-256, etc.). Si notas que tu cookie siempre termina con una cadena de la misma longitud, aunque cambies el contenido, sospecha de un HMAC.
SHA-1: Añade 20 bytes (40 caracteres hex).
SHA-256: Añade 32 bytes (64 caracteres hex).
2. La Prueba de la "Modificación del Primer Byte"
Esta es la prueba definitiva en Burp Suite (Repeater):
Envía la petición original: Asegúrate de que el servidor responde con un
200 OK(usuario logueado).Modifica UN solo bit/byte al principio del valor cifrado.
Analiza la respuesta:
Si el error es de Padding (ej. 500 Internal Error): ¡Buenas noticias! El servidor intentó descifrarlo antes de verificar la integridad. Es vulnerable.
Si el error es de Firma/Integridad (ej. 403 Forbidden o "Invalid Token"): Malas noticias. El servidor verificó el HMAC antes de intentar descifrar el padding. Esto detiene a PadBuster en seco.
3. ¿Cómo se ve un HMAC en PadBuster?
Si intentas atacar un sitio con HMAC sin saberlo, verás que PadBuster:
No encuentra ninguna respuesta que coincida con un error de padding.
Todas las respuestas del servidor (ID 1, ID 2, etc.) son idénticas, porque el servidor descarta el paquete antes de llegar a la capa de cifrado.
Resumen de la Estrategia Final
Para que tu ataque con PadBuster en Kali Linux sea exitoso, tu "checklist" debe ser:
Interceptar con Burp Suite.
Validar que no haya HMAC (modificando un byte y viendo el error).
Identificar el Block Size (8 o 16 bytes).
Ejecutar PadBuster con el comando
-plaintextpara forjar tu identidad.