¿Qué tipo de ataque se evita con el código de error AH02032 de Apache2 (“El nombre de host proporcionado a través de SNI y el nombre de host proporcionado a través de HTTP son diferentes”)?

  

¿Qué tipo de vulnerabilidad o vector de ataque se evita con el error?

El ataque se denomina "confusión de host virtual" y en 2014, varios CDN se encontraron vulnerables contra él . La idea principal es que no coincida el nombre de destino en el protocolo de enlace TLS ( "proporcionado a través de SNI" ) y el nombre de destino en el protocolo HTTP ( "proporcionado a través de HTTP" ) puede ser explotado. Dependiendo de la configuración del servidor, se puede utilizar para suplantar los sitios HTTPS que son propiedad de otros, lo que también se puede usar para robar cookies de sesión, etc.

Para obtener más información, lea el documento "Ataques de confusión de origen basados en la red contra el alojamiento virtual HTTPS ", lea la información de en HackerOne , vea un video de cómo este ataque ayuda a "use Akamai para evitar la censura en Internet" o vea la charla en Blackhat 2014 donde se demostró este y otros ataques contra TLS.

Indicación de nombre de servidor (SNI) es una extensión TLS que permite a un cliente TLS indicar qué host está intentando alcanzar. Esto es importante para los servidores web con hosts virtuales (es decir, múltiples dominios alojados desde una caja) para que puedan decidir qué certificado devolver. Normalmente, el host virtual de destino se detecta a través del encabezado HTTP Host , pero eso no se puede enviar antes de que se construya un túnel TLS. SNI permite que el cliente TLS indique el nombre para que se sirva el certificado correcto, antes de que se realice la llamada HTTP subyacente. Otra característica de la mayoría de los servidores TLS es que se puede usar SNI para elegir entre diferentes configuraciones TLS que se han configurado para cada host virtual.

Como ahora tiene dos indicadores de a qué host intentaba llegar (SNI y encabezado de host) puede haber comportamientos extraños si los obliga a no coincidir. Ahora, imagine una situación en la que tenga un sitio que use HTTPS, pero también un subdominio administrativo, y ambos estén alojados en el mismo servidor. El subdominio administrativo está bloqueado en el nivel de configuración de SNI para que requiera un certificado de cliente. Esto significa que el uso regular del sitio solo ejecuta HTTPS normal, pero necesita un certificado de cliente para conectarse al subdominio de administración.

Sin embargo, si hiciera una solicitud en la que el SNI apunta al dominio principal, pero el encabezado del Host apunta al subdominio administrativo, puede construir el túnel TLS sin el certificado del cliente (porque se usan las reglas del sitio principal) pero el servidor web puede ofrecer contenido como si estuviera conectado al subdominio administrativo. Esto podría permitirle omitir la restricción del certificado de cliente.

Si tiene una configuración en la que una interfaz liviana usa SNI para enviar solicitudes a través de diferentes servidores HTTPS, la verificación adicional realizada por Apache protege contra el uso de solicitudes no válidas para acceder a contenido que de otra manera sería inaccesible.

Dado que el campo SNI está en el mensaje de saludo del cliente TLS enviado por el cliente antes de que el servidor haya enviado algo, es posible construir una interfaz liviana que no sepa nada sobre HTTP y muy poco sobre TLS pero que aún sea capaz de enviar Conexiones TLS a diferentes backends dependiendo del nombre de host.

Tal interfaz solo necesitaría saber suficiente TLS para analizar el mensaje de saludo del cliente y extraer el nombre de host. Una vez que lo tiene, puede pasar todos los datos sin modificar a backends HTTPS separados. Solo los backends necesitan la clave del servidor necesaria para establecer la conexión TLS.

En esta configuración, la interfaz nunca podrá saber qué nombre de host se envió en el encabezado del host HTTP porque no puede descifrar el tráfico. Por lo tanto, es imposible para una interfaz de este tipo comparar los dos nombres de host.

Esta configuración permite que se alojen múltiples dominios detrás de una sola dirección IP, incluso si los servidores HTTPS no saben nada sobre SNI. Sin embargo, si los servidores HTTPS no saben nada sobre SNI, es posible que un cliente envíe una solicitud dañada en la cual el frontend y el backend ven dos nombres de host diferentes para la misma solicitud HTTPS.

Es posible configurar el frontend y el backend de tal manera que solo se pueda acceder a un vhost diciendo a los nombres de host diferentes del frontend y del backend.

Si no se puede acceder a un vhost por cada solicitud HTTPS válida, se puede considerar una vulnerabilidad si se puede acceder a dicho vhost mediante el envío de solicitudes HTTPS no válidas. Si el backend es una versión de Apache con soporte SNI, la comprobación que solicite protegerá contra la vulnerabilidad.