mpgn/poodle-poc🐩 Ataque Poodle (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 🐩
Una prueba de concepto del ataque Poodle (Padding Oracle On Downgraded Legacy Encryption) :
un exploit de hombre en el medio que aprovecha la degradación a SSL 3.0 de los clientes de software de seguridad y de Internet
El ataque Poodle te permite recuperar datos cifrados enviados por un cliente a un servidor si la capa de transporte segura (Transport Layer Security) utilizada es SSLv3. No te permite recuperar la clave privada utilizada para cifrar la solicitud.
SSLv3 es un protocolo para cifrar/descifrar y asegurar tus datos. En nuestro caso, utiliza el modo de cifrado CBC con encadenamiento . El texto plano se divide en bloques según el algoritmo de cifrado (AES, DES, 3DES) y la longitud es múltiplo de 8 o 16. Si el texto plano no completa la longitud, se añade un relleno al final para completar el espacio que falta. Te recomiendo encarecidamente que abras estas imágenes de cifrado y descifrado para leer este readme.
| Cifrado | Descifrado |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
Básicamente esto es solo un simple XOR, también puedes ver este vídeo (no soy yo) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Una solicitud enviada a través de HTTPS usando SSLv3 se cifrará con AES/DES y el modo CBC. La particularidad de SSLv3 sobre TLS1.x es el relleno. En SSLv3 el relleno se completa con bytes aleatorios excepto el último byte, que es igual a la longitud del relleno.
Ejemplo:
T|E|X|T|0xab|0x10|0x02 donde 0xab|0x10|0x02 es el relleno.
T|E|X|T|E|0x5c|0x01 donde 0x5c|0x01 es el relleno.
También el último bloque puede rellenarse con un bloque completo de relleno, lo que significa que el último bloque puede estar lleno de bytes aleatorios excepto el último byte.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 donde |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 es el relleno y solo el 0x07 es conocido por el atacante. Así que si un atacante puede influir en el bloque de relleno, podrá saber que el último byte del último bloque es igual a la longitud de un bloque.
Un atacante debe ser capaz de hacer que la víctima envíe solicitudes (usando JavaScript mediante la explotación de un XSS, por ejemplo). Entonces puede controlar la ruta y los datos de cada solicitud:
Ejemplo: añadiendo el byte "A" a la ruta de la solicitud
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
Con esta técnica puede influir en el relleno.
SSLv3 también usa HMAC para comprobar la integridad y autenticar el texto plano.
el código de autenticación de mensajes basado en hash con clave (HMAC) es un tipo específico de código de autenticación de mensajes (MAC) que implica una función hash criptográfica (de ahí la 'H') en combinación con una clave criptográfica secreta
Con esto, un atacante no puede interceptar y alterar la solicitud para luego reenviarla. Si el servidor encuentra un problema, enviará un error HMAC.
El protocolo SSLv3 usa la siguiente rutina: recibe los datos del cliente, descifra los datos y comprueba la integridad con el HMAC.
MAC-then-Encrypt: No proporciona ninguna integridad sobre el texto cifrado, ya que no tenemos forma de saber hasta que desciframos el mensaje si era realmente auténtico o falsificado. Integridad del texto plano. Si el esquema de cifrado es maleable, podría ser posible alterar el mensaje para que parezca válido y tenga un MAC válido. Esto es un punto teórico, por supuesto, ya que en la práctica el secreto del MAC debería proporcionar protección. Aquí, el MAC tampoco puede proporcionar información sobre el texto plano, ya que está cifrado.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Esto significa que podemos alterar el texto cifrado sin que el servidor lo sepa. Esto es genial, de verdad :)
Primero el último bloque debe estar lleno de relleno; como vimos anteriormente, el atacante usa la ruta de la solicitud y comprueba la longitud de la misma.
Dado que el último bloque, excepto el último byte, está lleno de bytes aleatorios, puede reemplazar este último bloque Cn por el bloque que quiere descifrar Ci. La solicitud alterada se envía al servidor.
El servidor:
Al reemplazar el último bloque, el atacante también cambia el último byte del último bloque (la longitud del relleno). Hay una probabilidad de 1/256 de que el último byte reemplazado en el bloque de relleno sea el mismo que el original; en ese caso no habrá error de relleno y el atacante puede usar esta operación XOR para recuperar el último byte del bloque Ci mediante la siguiente operación:
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 o xxxxxxx15 y x es un byte aleatorio)
El último byte del bloque se puede recuperar Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] En caso de error de relleno, el atacante necesita cerrar la sesión SSL para realizar otro handshake (nueva clave AES) y obtener un nuevo cifrado, luego reemplazar el último bloque, etc. (generalmente se necesitan +300 handshakes)
Una vez que se recupera un byte, obtendrá todos los demás bytes del bloque añadiendo un byte en la ruta y eliminando un byte de los datos:
| Solicitud para recuperar los bytes E,I,K,O |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
Aunque las especificaciones de TLS requieren que los servidores comprueben el relleno, algunas implementaciones no lo validan correctamente, lo que hace que algunos servidores sean vulnerables a POODLE incluso si deshabilitan SSL 3.0
TLS normalmente es seguro frente a Poodle, pero algunas implementaciones no comprueban el relleno; es como si usáramos SSLv3, por eso algunas versiones de TLS son vulnerables.