Supongamos que existe el siguiente proxy TLS
User <-----> Load Balancer that decrypts, encrypts <------> WebServer
Cuando el servidor web ejecuta una versión vulnerable de OpenSSL.
¿Puede el usuario explotar el servidor web si es vulnerable a TLS o Beast, suponiendo que el primer enlace al equilibrador de carga sea seguro?
BEAST es una vulnerabilidad en el cliente , no en el servidor. Un servidor no es, y nunca ha sido, "vulnerable a BESTIA". Existe cierta confusión acerca de las herramientas que "prueban los servidores SSL", que pueden reportar una "vulnerabilidad BEAST" si el servidor no puede reparar un cliente vulnerable, es decir, si el cliente es vulnerable, y se especifican en su ClientHello prefiere utilizar un conjunto de cifrado con un cifrado de bloque en modo CBC, y también dice que acepta el uso de un conjunto de cifrado no vulnerable (por ejemplo, basado en RC4), luego el servidor tiene la posibilidad de guardar el cliente eligiendo la suite de cifrado que no es CBC, a pesar de las preferencias del cliente. Cuando el servidor no hace eso, las herramientas de prueba de SSL informarán "vulnerable a BEAST", pero la vulnerabilidad aún está en el cliente, no en el servidor.
Dicho esto, tanto BEAST como CRIME se basan en un contexto de uso donde el atacante puede hacer todo lo siguiente:
El atacante puede elegir parte de los datos que se cifran, junto con algunos datos secretos en los que el atacante está muy interesado (normalmente, una cookie HTTP).
El atacante puede ver el resultado cifrado.
La información obtenida del punto 2 se puede usar para el punto 1: el ataque es adaptativo.
En su caso, esto requeriría que el atacante pueda escuchar las comunicaciones entre el equilibrador de carga y el servidor web, y pueden elegir los datos que el equilibrador de carga encripta. Dado que el equilibrador de carga cifra los datos que acaba de descifrar, directamente del usuario, se aplica el concepto de BEAST y CRIME. Esto es cierto independientemente de cómo se transmiten los datos desde el navegador del usuario al equilibrador de carga. Ese TLS específico protege los datos en tránsito entre el usuario y el equilibrador de carga, pero el ataque realmente está en la conexión entre el equilibrador de carga y el servidor web, es decir, fuera del alcance de ese primer TLS.
Las cosas seguirán siendo difíciles para el atacante, por las siguientes razones:
El método habitual mediante el cual un atacante puede insertar sus datos en el flujo de texto sin formato y observar el resultado cifrado es a través de un punto de acceso WiFi falso. Sin embargo, en su situación, el atacante debe de alguna manera inyectar su JavaScript malicioso en el lado del cliente (por lo tanto, debe estar cerca del usuario, en cuanto a la red), pero también debe observar cosas en la red interna entre el equilibrador de carga y el servidor web. El atacante debe estar en dos lugares a la vez.
BEAST ya no funciona. Para aplicar el ataque, el atacante debe tener un control bastante preciso sobre los bytes que agrega a la secuencia de texto sin formato; meros encabezados HTTP no son suficientes. Tenga en cuenta que estamos hablando aquí del código malicioso que se ejecuta en el cliente, es decir, dentro del contexto del navegador del usuario. Los autores de BEAST habían encontrado dos formas de insertar sus bytes en el flujo, utilizando un agujero Java o un borrador de implementación de WebSockets. Ambos agujeros se han arreglado en los navegadores durante varios años.
Incluso si BEAST aún funciona, puede que tenga problemas para atravesar el equilibrador de carga: el ajuste fino de la entrada adicional del atacante no es compatible con la solicitud HTTP; Las cosas deben ser un poco más bajas que eso.
Sin embargo,CRIME saldrá bien.
Lea otras preguntas en las etiquetas network threat-mitigation crime beast