Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
BEAST-PoC — :muscle: Prueba de concepto del ataque BEAST contra SSL/TLS CVE-2011-3389 :muscle: | Kitploit
Herramientas/GitHubGitHub/mpgn/beast-poc
Análisis de VulnerabilidadesExplotaciónSeguridad WebCriptografíaPruebas de PenetraciónAprendizaje y Educación
GitHubmpgn/beast-poc

BEAST-PoC

💪 Prueba de concepto del ataque BEAST contra SSL/TLS CVE-2011-3389 💪

Ver Repositorio
8031hace 7 añosRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

BEAST-PoC (ataque de texto plano elegido)

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;

Sé el BEAST

1. SSLv3/TLS1.0 y el modo de cifrado CBC

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.

2. Criptología

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:

  • primero enviamos una petición llamada C² para obtener el último bloque del cifrado, es decir, el siguiente IV de la segunda petición
  • esto es un ataque de texto plano elegido, por lo que el atacante puede enviar este mensaje 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)

  • el atacante quiere recuperar la información en el bloque C0 C1, C2 ... siempre necesita el bloque anterior
  • una tercera petición se envía después de construir un bloque especial P'0. El primer bloque será cifrado así: C'0 = Ek(P'0 ⊕ IV') Como esto es un ataque de texto plano elegido, el atacante puede construir un bloque P'0 así:

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!

Lanzamiento

root@kitploit:~
python BEAST-poc.py

asciicast

Ataque

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:

beast

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.

Contribuidor

mpgn

Licencias

licencia MIT

Referencias

  • http://netifera.com/research/beast/beast_DRAFT_0621.pdf
  • http://www.bortzmeyer.org/beast-tls.html
  • http://fr.slideshare.net/danrlde/20120418-luedtke-ssltlscbcbeast
  • http://crypto.stackexchange.com/questions/5094/is-aes-in-cbc-mode-secure-if-a-known-and-or-fixed-iv-is-used
  • http://security.stackexchange.com/questions/18505/is-beast-really-fixed-in-all-modern-browsers
  • https://defuse.ca/cbcmodeiv.htm
  • http://stackoverflow.com/questions/22644392/chrome-websockets-cors-policy
Descargar herramienta
CifradoDescifrado
Ci = Ek(Pi ⊕ Ci-1), y C0 = IVPi = Dk(Ci) ⊕ Ci-1, y C0 = IV