BREACH (un backronym : Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext ) es un exploit de seguridad contra HTTPS cuando se usa la compresión HTTP . BREACH se basa en el 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 se había discutido en comunidad antes del anuncio. [1]
Si bien el ataque CRIME se presentó como un ataque general que podría funcionar eficazmente contra una gran cantidad de protocolos, solo se demostraron las vulnerabilidades contra la compresión de solicitudes SPDY y la compresión TLS y se mitigaron en gran medida en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, aunque los autores de CRIME han advertido que esta vulnerabilidad podría estar aún 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 y servidores web. [2] Dado este oráculo de compresión, el resto del ataque BREACH sigue las mismas líneas generales que el exploit CRIME, realizando una búsqueda inicial ciega de fuerza bruta para adivinar unos pocos bytes, seguida de una búsqueda de divide y vencerás para expandir un adivinar correctamente una cantidad de contenido arbitrariamente grande.
BREACH aprovecha 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 sin formato elegido contra la carga útil HTTP. [3]
Como resultado, los clientes y servidores se ven obligados a deshabilitar la compresión HTTP por completo (reduciendo así el rendimiento) o a adoptar soluciones alternativas para intentar frustrar BREACH en escenarios de ataque individuales, como el uso de la protección de 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 la mitigación efectiva del ataque sin perder funcionalidad, solo incurriendo en una penalización de desempeño en las solicitudes afectadas.
Otro enfoque es agregar relleno en el TLS, el encabezado HTTP o el nivel de carga útil. Alrededor de 2013-2014, hubo un borrador de propuesta de IETF para una extensión de TLS para el relleno de ocultación de longitud [7] que, en teoría, podría usarse como una mitigación contra este ataque. [5] Permite disimular la longitud real de la carga útil TLS mediante la inserción de relleno para redondearla a un conjunto fijo de longitudes, o 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.