Estado actual de BREACH (GZIP SSL Attack)?

7

Ha pasado un año desde que BREACH se abrió camino en nuestros corazones, y no parece haber ningún artículo o publicación o parche desde entonces, ¿mi debilitamiento de Google-fu?

  1. ¿Se ha mitigado o parcheado BREACH en Apache / nginx?
  2. ¿Podemos habilitar GZIP en SSL si brindamos más protecciones?
pregunta 15.08.2014 - 12:07
fuente

1 respuesta

8

BREACH es una vulnerabilidad que está presente cuando se cumplen varias condiciones:

  • Se utiliza la compresión HTTP,
  • Se refleja una parte de la entrada,
  • Un secreto estático está presente en el cuerpo HTTP de la respuesta,
  • El atacante puede leer el tamaño de la respuesta cifrada,
  • El atacante puede falsificar solicitudes al sitio bajo ataque.

Cada una de estas condiciones no representa una amenaza en sí misma, pero combinadas conducen a una vulnerabilidad. Esta es en parte la razón por la que no existe una solución clara para esta vulnerabilidad: simplemente actualizar Apache o OpenSSL no es suficiente. Desactivar la compresión gzip para todo no tiene mucho sentido. Reflejar la entrada del usuario es totalmente bien la mayor parte del tiempo. Realmente no hay una solución simple, pero se han logrado algunos avances en los últimos años para mitigar el INCREMENTO.

Una de las soluciones más prometedoras es la cookie del mismo sitio bandera . Esto hace que las cookies ya no funcionen en solicitudes de origen cruzado, lo que resuelve los ataques CSRF y, por lo tanto, también BREACH. Alguien está trabajando en una especificación y ya está implementado en Chrome , Firefox , y Edge en Windows 10 .

También hay varios proyectos que aleatorizan la longitud de la respuesta. Algunos modules coloca un comentario HTML aleatorio en cada respuesta, lo que es un hack total. El soporte de relleno se ha formalizado en TLS 1.3 , pero tomará algún tiempo antes de que se implemente. en servidores.

Algunos marcos también han tomado medidas para mitigar los ataques BREACH, particularmente para evitar adivinar el token CSRF. Django aleatoriza el token CSRF en cada solicitud, de modo que no se pueda adivinar sobre múltiples solicitudes. Esto es relativamente nuevo, lanzado este año en Django 1.10.

También ha habido algún progreso para los atacantes. Este año, los investigadores han demostrado que BREACH también se puede convertir a un ataque de tiempo (HEIST) , donde es explotable simplemente ejecutando Javascript en el navegador. Finalmente, este nuevo kit de herramientas (Rupture) también se ha desarrollado este año para explotar las vulnerabilidades de los canales laterales de compresión.

    
respondido por el Sjoerd 07.11.2016 - 11:31
fuente

Lea otras preguntas en las etiquetas