
💪 Prueba de concepto del ataque BEAST contra SSL/TLS CVE-2011-3389 💪
Esta prueba de concepto se centra en la criptografía detrás del ataque BEAST (Browser Exploit Against SSL/TLS) presentado por Thai Duong y Juliano Rizzo el 23 de septiembre de 2011. Esto es un ataque de texto plano elegido y permite recuperar información sensible si la seguridad de la capa de transporte utilizada es TLS1.0 o SSLv3. La prueba de concepto original se puede encontrar aquí: Here come the Ninjas
Nota: Esta es también una implementación de la vulnerabilidad descubierta originalmente por Phillip Rogaway. Descubierta en 2002, no se publicó ningún exploit hasta BEAST en 2011. OpenSSL ya conocía el problema y por eso actualizaron TLS1.0 a TLS1.1 en abril de 2006.
2 El IV de CBC para cada registro excepto el primero es el último bloque de cifrado del registro anterior. Por lo tanto, el cifrado no es seguro contra adversarios que puedan elegir textos planos de forma adaptativa;
SSLv3/TLS1.0 son protocolos para cifrar/descifrar y asegurar tus datos. En nuestro caso, ambos usan el encadenamiento de modos de cifrado CBC. 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 faltante. 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.
Presentaré el IV en el siguiente punto. Recuerda que todas estas propiedades nos ayudarán a llevar a cabo nuestro ataque.
Cuando usamos CBC necesitamos un vector de inicialización llamado IV. Este IV es aleatorio (o fijo), pero en cualquier caso no debería ser predecible por nadie. En TLS1.0 y SSLv3 el primer IV de la petición es aleatorio, bien. Pero para ganar tiempo y no generar un nuevo IV aleatorio cada vez, la implementación de TLS1.0 y SSLv3 usaba el último bloque del texto cifrado anterior como IV. En otras palabras, el IV ahora es adivinable. Supondremos que la longitud de cada bloque será 8 (DES) y que el atacante tiene un MiTM para recuperar todo el cifrado.
Ejemplo:
C0 | C... | Ci-1 | Ci | Ci+1 |Cn
Ahora la parte interesante, estos son los diferentes pasos criptográficos del ataque para recuperar un byte:
bbbbbbbTHIS_IS_A_SECRET_COOKIE a través de la víctima.Puedes notar las siete b antes de la cookie secreta. Si la longitud de un bloque es 8, necesitamos empujar 7 bytes conocidos. Esta información es muy importante, el atacante conoce los 7 primeros bytes del primer bloque.
¿Pero por qué? ¡Esto nos permite tener solo 256 posibilidades para encontrar un byte y no 256^8 para encontrar 8 bytes!
Ahora la víctima envía la petición y será cifrada así:
C0 | C1 | C2 | C3 | C4
Donde C0 = Ek(IV ⊕ bbbbbbbT) = Ek(C²n ⊕ bbbbbbbT)
P'0 = C²n ⊕ C4 ⊕ bbbbbbbX
El único elemento desconocido es X, hay 256 posibilidades, así que probará como máximo 256 caracteres.
La petición se envía y se cifra así:
C'0 = Ek(P'0 ⊕ IV')
C'0 = Ek(C²n ⊕ C4 ⊕ bbbbbbbX ⊕ IV') o C4 ⊕ IV' = 0
C'0 = Ek(C²n ⊕ bbbbbbbX)
C'0 = Ek(IV ⊕ bbbbbbbX)
Ahora compara: C'0 y C0, si son iguales, entonces acaba de encontrar el byte X en la posición 8. Si no coincide, reintenta con otro carácter y compara de nuevo, etc.
Ahora tenemos un byte, podemos obtener otro desplazando la petición anterior un lugar a la izquierda: bbbbbbTHIS_IS_A_SECRET_COOKIE. Ahora tiene seis b y también conocemos la T, por lo que tenemos un carácter desconocido. Construimos un nuevo P'0 = C0 ⊕ C4 ⊕ bbbbbbTX etc...
Nota: otra forma con solo dos peticiones es establecer el primer bloque del texto plano y usar esta información para los tres XOR. Ya no necesitamos el último bloque de C². C1 = Ek(C0 ⊕ bbbbbbbT) y luego P'0 = C0 ⊕ C4 ⊕ bbbbbbbX. También necesita comparar C'0 y C1. Esta es otra forma de hacerlo, puedes notar que en el PoC codifiqué las dos posibilidades :)
¡Ahora podemos recuperar todos los caracteres!
python BEAST-poc.py
Un atacante no puede usar el protocolo HTTP porque el primer bloque estará lleno con GET / HTTP/1.1\r\n.
... no puede controlar los primeros bytes de cada petición porque siempre están establecidos como una cadena fija como GET /, POST /, etc. En su lugar, puede usar socket.
También necesita inyectar algo de javascript en una página maliciosa. La víctima debe estar conectada a esta página y permanecer en ella hasta que el ataque esté completo. Esto es un ataque de texto plano elegido, por lo que el atacante puede enviar a través del código javascript cada texto plano que quiera e interceptar el resultado con un Hombre en el Medio. Este es el diagrama del ataque:

Este ataque necesita condiciones importantes para tener éxito (TLS1.0 o inferior, modo de cifrado CBC, MiTM, javascript malicioso). Pero Thai Duong y Juliano Rizzo demostraron que es posible y mostraron su exploit robando cookies en el sitio web de Paypal.
Todo está arreglado ahora y este ataque tiene poca probabilidad de realizarse.
| Cifrado | Descifrado |
|---|
| Ci = Ek(Pi ⊕ Ci-1), y C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, y C0 = IV |