Poodle PoC 🐩 🐩 🐩

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.

1. 🐩 Concepto del ataque 🐩

SSLv3 y el modo de cifrado CBC

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.

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.

Influir en el relleno

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.

HMAC

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.

MAC-then-encrypt

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 :)

2. 🔑 Criptografía 🔑

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.

• Guarda la longitud del cifrado original
• Añade un byte en la ruta y comprueba la longitud.
  • Si la longitud no cambia, añade otro byte, etc.
  • Si no: la longitud de la solicitud cifrada cambia, sabe que el último bloque está lleno de relleno.

Dado que el último bloque, excepto el último byte, está lleno de bytes aleatorios, puede reemplazar este último bloque C_n por el bloque que quiere descifrar C_i. La solicitud alterada se envía al servidor.

El servidor:

• elimina el relleno según la longitud del último byte
• obtiene el hmac de la solicitud = HMAC
• obtiene el texto plano
• compara hmac(texto_plano) y HMAC
  • si son iguales => buen relleno
  • si no => mal relleno

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 C_i mediante la siguiente operación:

P_n = D_k(C_n) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
xxxxxxx7 = D_k(C_i) ⊕ C_n-1
D_k(C_i) = xxxxxxx7 ⊕ C_n-1
P_i ⊕ C_i-1 = xxxxxxx7 ⊕ C_n-1
P_i = C_i-1 ⊕ xxxxxxx7 ⊕ C_n-1

(xxxxxxx7 o xxxxxxx15 y x es un byte aleatorio)

El último byte del bloque se puede recuperar P_i[7] = C_i-1[7] ⊕ xxxxxxx7 ⊕ C_n-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:

Acerca de TLS1.0

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.

3. 💥 Iniciar el ataque 💥

Hay tres archivos en este repositorio:

• poodle-poc.py -> Una prueba de concepto que no requiere ningún requisito previo
• parallelization-poodle.py -> Otra prueba de concepto, pero usando paralelización (muy rápida)
• poodle-exploit.py -> Un exploit para escenarios del mundo real

1. El archivo poodle-poc.py

Esta PoC explora la criptografía detrás del ataque. Este archivo nos permite entender cómo funciona el ataque de una manera sencilla.

python3 poodle-poc.py

2. El archivo poodle-poc.py

El archivo parallelization-poodle.py es un proyecto, y una idea :) consulta https://github.com/mpgn/poodle-PoC/issues/1

python3 parallelization-poodle.py

3. El archivo poodle-exploit.py

Este es el exploit real. Muy útil si quieres hacer una prueba de concepto sobre el ataque Poodle para un cliente durante un pentest si utiliza servidor y navegador antiguos. Solo pon la IP de tu proxy malicioso en la configuración del navegador con el puerto correcto; el proxy se encargará del resto.

Requisitos:

• asegúrate de que el cliente y el navegador puedan comunicarse con el protocolo SSLv3 solamente; fuerza solo SSLv3 en Firefox usando security.tls.version.min: 0, por ejemplo. Alternativamente, si el cliente también usa TLS, puedes forzar la degradación (downgrade)
• asegúrate de que el servidor sea vulnerable, usa la herramienta testssl.sh
• asegúrate de que puedes inyectar JavaScript en el lado del cliente (XSS)
• asegúrate de que puedes interceptar la conexión entre el cliente y el servidor

💀 Si cumples estos requisitos, puedes iniciar el ataque 💀:

Hay dos opciones disponibles para este exploit:

1. Configura la dirección IP y el puerto del proxy directamente en el lado del cliente y ejecuta el exploit (ve a la parte 3)
2. Configura un ataque de suplantación ARP para redirigir todo el tráfico entre el cliente y el servidor hacia tu máquina

• Habilita el reenvío y establece una regla de Iptables para redirigir el tráfico del cliente a tu proxy

$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337

• Usa la herramienta arpspoof, ettercap o bettercap para ejecutar un ataque de suplantación ARP

$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on

3. Ejecuta el proxy

⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h              13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
                         [--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
                         proxy port server rport

Poodle Exploit by @mpgn_x64

positional arguments:
  proxy                 ip of the proxy
  port                  port of the proxy
  server                ip of the remote server
  rport                 port of the remote server

optional arguments:
  -h, --help            show this help message and exit
  --start-block START_BLOCK
                        start the attack at this block
  --stop-block STOP_BLOCK
                        stop the attack at this block
  --simpleProxy SIMPLEPROXY
                        Direct proxy, no ARP spoofing attack

$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50

Elegir un bloque: si no especificas la opción de bloque, se descifrarán todos los bloques, pero esto puede llevar mucho tiempo. Te recomiendo encarecidamente que 'sepas' cómo se formateará la solicitud y uses el script request-splitter.py para saber el bloque que quieres descifrar (¡idealmente el bloque de la cookie! :)

Luego inserta el código JavaScript malicioso (poodle.js) en el sitio web vulnerable usando, por ejemplo, un XSS. Ejecuta el script de Python y escribe help, luego search y finalmente active. Durante ese tiempo, solo se necesitarán dos interacciones con el JavaScript (los comandos search y active).

Actualización 01/04/2018: se ha añadido la opción de degradación al exploit. Cuando el exploit detecte el protocolo TLS, introduce el comando downgrade para degradar a SSLv3.0.

¿Cómo funciona? Durante el handshake (después del hello client), el exploit envía un handshake_failure 15030000020228; entonces el navegador debería reenviar un hello client con SSLv3.0 como protocolo predeterminado. Probado en Chrome versión 15, pero no funciona en Firefox (creo que no soporta la renegociación de protocolo), consulta #4

Vídeo completo de la explotación:

Asciinema:

Colaborador

mpgn

Licencia

licencia MIT

Referencias

• https://en.wikipedia.org/wiki/POODLE
• https://www.openssl.org/~bodo/ssl-poodle.pdf