INCUMPLIMIENTO

BREACH ( acrónimo inverso : Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext ) es una vulnerabilidad de seguridad contra HTTPS al usar compresión HTTP . BREACH se basa en el exploit de seguridad CRIME . BREACH fue anunciado en la conferencia Black Hat USA de agosto de 2013 por los investigadores de seguridad Angelo Prado, Neal Harris y Yoel Gluck.

Si bien el ataque CRIME se presentó como un ataque general capaz de funcionar eficazmente contra un gran número de protocolos, solo se demostraron vulnerabilidades contra la compresión de solicitudes SPDY y la compresión TLS , las cuales fueron mitigadas en gran medida en navegadores y servidores. Las vulnerabilidades de CRIME contra la compresión HTTP no se han mitigado en absoluto, a pesar de que sus autores advirtieron que esta vulnerabilidad podría ser incluso más generalizada 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 content-encoding dentro de HTTP por muchos navegadores y servidores web. ^{[ 1 ]} 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 ciega 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 afecta a BREACH, que aún puede realizar un ataque de texto plano elegido contra la carga útil HTTP. ^{[ 2 ]}

Como resultado, los clientes y servidores se ven obligados a deshabilitar completamente la compresión HTTP (reduciendo así 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). ^{[ 3 ]}

Otro enfoque sugerido es deshabilitar la compresión HTTP cuando el encabezado referrer indique una solicitud entre sitios o cuando el encabezado no esté presente. ^{[ 4 ] [ 5 ]} Este enfoque permite mitigar eficazmente el ataque sin perder funcionalidad, incurriendo únicamente en una penalización de rendimiento en las solicitudes afectadas.

Otro enfoque consiste en añadir relleno a nivel de TLS, encabezado HTTP o carga útil. Alrededor de 2013-2014, hubo una propuesta preliminar de la IETF para una extensión de TLS para relleno que ocultaba la longitud ^{[ 6 ]} que, en teoría, podría usarse como mitigación contra este ataque. ^{[ 4 ]} Permite disfrazar la longitud real de la carga útil de 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 son la base del ataque BREACH. Sin embargo, esta propuesta preliminar ha caducado sin que se haya tomado ninguna medida al respecto.

Una medida de mitigación muy eficaz es HTB (Heal-the-BREACH) ^{[ 7 ]} , que añade relleno de tamaño aleatorio a los datos comprimidos, lo que proporciona cierta variabilidad en el tamaño del contenido de salida. Esta aleatoriedad retrasa el tiempo que tarda BREACH en adivinar los caracteres correctos del token secreto, con un factor de entre 500 (máximo 10 bytes) y 500 000 (máximo 100 bytes). HTB protege todos los sitios web y páginas del servidor con un uso mínimo de CPU y un mínimo aumento del ancho de banda.

• Sitio web oficial de BREACH
• Herramienta que ejecuta el ataque BREACH demostrado en Black Hat 2013.
• HEIST , un ataque relacionado basado en compresión en el cuerpo de la respuesta demostrado en BlackHat 2016.