BREACH ( acrónimo de Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext ) es una vulnerabilidad de seguridad contra HTTPS cuando se utiliza la compresión HTTP . BREACH está construido sobre la base del exploit de seguridad CRIME . BREACH fue anunciado en la conferencia Black Hat de agosto de 2013 por los investigadores de seguridad Angelo Prado, Neal Harris y Yoel Gluck. La idea había sido discutida en la comunidad antes del anuncio. [1]
Si bien el ataque CRIME se presentó como un ataque general que podría funcionar de manera efectiva contra una gran cantidad de protocolos, solo se demostraron vulnerabilidades contra la compresión de solicitudes SPDY y la compresión TLS , que se mitigaron en gran medida en navegadores y servidores. Las vulnerabilidades de CRIME contra la compresión HTTP no se mitigaron en absoluto, a pesar de que los autores de CRIME advirtieron que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas.
BREACH es una instancia del ataque CRIME contra la compresión HTTP: el uso de algoritmos de compresión de datos gzip o DEFLATE a través de la opción de codificación de contenido dentro de HTTP por parte de muchos navegadores web y servidores. [2] Dado este oráculo de compresión, el resto del ataque BREACH sigue las mismas líneas generales que el exploit CRIME, al realizar una búsqueda inicial de fuerza bruta a ciegas para adivinar unos pocos bytes, seguida de una búsqueda de divide y vencerás para expandir una suposición correcta a una cantidad arbitrariamente grande de contenido.
BREACH explota la compresión en el protocolo HTTP subyacente. Por lo tanto, desactivar la compresión TLS no supone ninguna diferencia para BREACH, que aún puede realizar un ataque de texto simple elegido contra la carga HTTP. [3]
Como resultado, los clientes y servidores se ven obligados a desactivar por completo la compresión HTTP (lo que reduce el rendimiento) o a adoptar soluciones alternativas para intentar frustrar BREACH en escenarios de ataque individuales, como el uso de protección contra falsificación de solicitudes entre sitios (CSRF). [4]
Otro enfoque sugerido es deshabilitar la compresión HTTP siempre que el encabezado de referencia indique una solicitud entre sitios o cuando el encabezado no esté presente. [5] [6] Este enfoque permite una mitigación efectiva del ataque sin perder funcionalidad, solo incurriendo en una penalización de rendimiento en las solicitudes afectadas.
Otro enfoque es agregar relleno en el nivel de TLS, encabezado HTTP o carga útil. Alrededor de 2013-2014, hubo una propuesta preliminar del IETF para una extensión TLS para relleno de ocultación de longitud [7] que, en teoría, podría usarse como una mitigación contra este ataque. [5] Permite disfrazar la longitud real de la carga útil TLS mediante la inserción de relleno para redondearla a un conjunto fijo de longitudes, o para aleatorizar la longitud externa, disminuyendo así la probabilidad de detectar pequeños cambios en la relación de compresión que es la base del ataque BREACH. Sin embargo, este borrador ha expirado desde entonces sin más acciones.
Una mitigación muy eficaz es HTB (Heal-the-BREACH) [8] , que agrega un relleno de tamaño aleatorio a los datos comprimidos, lo que proporciona cierta variación en el tamaño del contenido de salida. Esta aleatoriedad retrasa la determinación de los caracteres correctos en el token secreto por un factor de 500 (máximo de 10 bytes) a 500 000 (máximo de 100 bytes). HTB protege todos los sitios web y páginas del servidor con un uso mínimo de la CPU y un aumento mínimo del ancho de banda.