Cómo derrotar a CRIME, BREACH, TIME, etc ... del lado del servidor (sin sacrificar la compresión)

Question

Cómo derrotar a CRIME, BREACH, TIME, etc ... del lado del servidor (sin sacrificar la compresión)

#1 de Tom Leek (5 votos)
#2 de Alex Lauerman (0 votos)

5

Estoy escribiendo software de servidor de pila completa y he estado investigando ataques de CRIME y su relación con la compresión del encabezado SPDY cuando estoy implementando los códecs del lado del servidor para este momento.

La conclusión parece ser que la compresión y el cifrado no deberían mezclarse.

Habiendo examinado CRIME y BREACH. Me pregunto si los siguientes métodos son viables para deshabilitar TODOS los tipos de ataques de "trabajo inteligente" en flujos de datos comprimidos y encriptados (en el lado del servidor)

1) Limitación de velocidad: como se sugiere en el sitio de BREACH. Cualquier cliente que bombardee un servidor con una solicitud de más de 100 por segundo está destinado a ser malintencionado cuando las páginas de sus sitios solo ofrecen un máximo de X (un solo dígito / dos dígitos bajos) por solicitud.

2) Datos dinámicos: tanto CRIME como BREACH (y sus derivados) parecen depender de un sondeo repetido y asumen que la posición de los datos no cambia. ¿Qué sucede si tanto el encabezado como el cuerpo de HTTP se barajan según la respuesta del servidor? ¿Combinado con datos ficticios aleatorios de pequeña longitud variable inyectados en el cuerpo y el encabezado? ¿Puede esto deshabilitar efectivamente todos estos ataques con las características de CRIME y BREACH?

Gracias por tu tiempo.

EDIT 1: debo señalar que me estoy refiriendo específicamente a flujos de datos dentro del protocolo HTTP (es decir, compresión HTTP y compresión de encabezado SPDY) y no a compresión SSL / TLS.

EDIT 2: la solución de mitigación de ataques que estoy tratando de lograr / sugerir está en todos los posibles ataques de fuga de información de "compresión + encriptación", CRIME y BREACH solo pueden ser ejemplos recientes.

EDIT 3: La PUNTO DE INTERÉS parece sugerir longitud variable El relleno no es una mitigación válida. Sin embargo, no parece considerar la combinación de una estructura de mensajes aleatorizada + el relleno aleatorio puede crear una combinación infinita ( en teoría ) de salidas no confiables, eliminando así cualquier correlación entre la longitud de salida comprimida y encriptada a la significado real del mensaje.

encryption http compression

pregunta 03.10.2013 - 13:08

fuente

2 respuestas

Lea otras preguntas en las etiquetas encryption http compression

Estándar para representar firma digital en papel SSH: Seguridad de la autenticación de Pubkey frente a la contraseña

score 5 · Answer 1

CRIME y BREACH son ataques en el cliente . Su configuración es que se ejecuta algún código hostil en el cliente con capacidades limitadas (es decir, es Javascript en una página web). El atacante también controla el tráfico externo de la víctima: puede inspeccionarlo, pero también bloquearlo. Esto limita lo que el servidor realmente ve.

En ambos casos, el Javascript hostil activará varias (muchas) solicitudes dirigidas al servidor para el cual se recuperará el secreto (el valor de la cookie). El atacante solo necesita ver lo que sale del cliente; No es absolutamente necesario que la solicitud llegue al servidor. De hecho, los clientes HTTPS utilizan HTTP : envían habitualmente varias solicitudes seguidas por un solo canal y no les importa que no reciban una respuesta de inmediato. De esta manera, el código hostil hace que el navegador de la víctima envíe muchas solicitudes que los atacantes ven, pero no el servidor.

En estas condiciones, el servidor puede hacer muy poco para proteger al cliente, excepto que no le permite creer que las funciones de protocolo vulnerables (CBC desprotegido, compresión ...) se pueden usar en absoluto. Las limitaciones de tarifas no harán mucho en este caso.

Inyectar un relleno aleatorio es una posible defensa, pero debe hacerse en el cliente, no en el servidor. Ahí de nuevo, el servidor no puede hacer nada. Un encabezado personalizado, con contenido aleatorio y que aparece antes de la cookie en el encabezado, evitaría el INCREMENTO. Para CRIME, esto es más complejo; necesita un encabezado personalizado con una longitud aleatoria con una distribución bien elegida (no es inmediatamente obvio qué distribución debe usarse). Por supuesto, este relleno adicional implica más bytes para enviar, lo que podría cancelar los beneficios del uso de la compresión en primer lugar.

score 0 · Answer 2

@Tom, es un ataque a TLS, por lo que involucra tanto al cliente como al servidor. Parte del exploit se ejecuta en el cliente, pero el ataque está en los cuerpos de respuesta del servidor con BREACH. Los encabezados no están comprimidos con compresión HTTP. Creo que tienes BREACH y CRIME confundidos en tu cuarto párrafo.

1) La limitación de velocidad ralentizará el ataque, pero no lo detendrá. Este tipo de detección detendrá una buena cantidad de ataques, pero creo que ha sido difícil de implementar.

2) Incluso si su relleno es completamente aleatorio, o la distribución está compensada, aún puede tomar un cierto número de solicitudes y promediarlas para obtener un resultado. Esto hace que el ataque sea más costoso pero no imposible.

No haría nada de esto a menos que esté de acuerdo con la mitigación, no con la solución.

¿Por qué no solo se pone un token CSRF aleatorio en cada solicitud y se crea el marco alrededor de eso, para que un atacante nunca sepa cómo se ve una solicitud válida para que no puedan obligarte a hacerlo?