Gracias a Google, la mayoría de las páginas web usan HTTPS en la actualidad. Con ello, todas las comunicaciones que hacemos entre nuestro dispositivo y la web están cifradas. Otra cosa es lo que ocurra en el servidor una vez llegue la información, ya que, si ésta es propiedad de un hacker, accederá a los datos que le hemos dado. Sin embargo, un nuevo ataque estaría poniendo en jaque al HTTPS.
Para evitar que un atacante pueda acceder a la información, el navegador no intercambia información con el servidor hasta que se ha asegurado de que el certificado es válido. Eso evita que un atacante pueda acceder a cookies de autenticación, o ejecutar código malicioso modificando los datos enviados.
HTTPS no es tan seguro como creíamos
El problema es que una nueva vulnerabilidad permite llevar a cabo un ataque man-in-the-middle que confunda al navegador para conectarse a un servidor FTP o de email que usa un certificado compatible con la web. Para ello, si el dominio de la web coincide con el del certificado del email o del FTP, el navegador establecerá una conexión TLS con los servidores en lugar de con la web que el usuario intentaba visitar.
Con esto, el atacante podría recibir una cookie de autenticación descifrada, o podría directamente ejecutar código malicioso en el dispositivo del usuario. Según una investigación, 14,4 millones de servidores web usan un dominio compatible con este fallo. De ellos, 114.000 son considerados como explotables porque el servidor FTP o de email usa software vulnerable.
El fallo puede aprovecharse porque, en estos casos, TLS no protege la integridad de la conexión TCP. Con ello, los atacantes pueden redirigir tráfico TLS desde el servidor previsto a otro, ya que TLS no protege la dirección IP o el puerto. En el pasado se había considerado realizar ataques man-in-the-middle donde el atacante redirige a un navegador a un servidor web diferente, pero en este caso se está redirigiendo al navegador desde un webserver a un servidor diferente de FTP o email.
Los investigadores alemanes que han analizado la vulnerabilidad han descubierto tres ataques diferentes, que han bautizado como ALPACA, abreviatura de Application Layer Protocols allowing Cross-Protocol Attacks.
El primero es Upload Attack, donde se asume que el atacante tiene la posibilidad de enviar datos a un servidor distinto y recuperarlo después. En él, el atacante trata de almacenar partes de la solicitud HTTP del navegador en ese servidor. Si el ataque tiene éxito, el atacante puede recuperar el contenido del servidor independientemente de la conexión, y recuperar la cookie HTTPS.
El segundo es Download Attack, donde se asume que el atacante puede descargar información del servidor distinto. En este caso, al usarse un protocolo distinto de HTTPS, las protecciones contra los ataques XSS no funcionan.
El tercero es Reflection Attack, donde el atacante trata de engañar al servidor. Si el atacante tiene éxito, puede enviar un script malicioso en JavaScript.
ALPN y SNI: las dos soluciones para protegernos
Para evitar el ataque, los investigadores proponen una aplicación más estricta de los métodos de protección, como Application-Layer Protocol Negotiation (ALPN). Al aplicar esta capa de protección adicional al negociar qué protocolo se usa en una conexión, se evitan este tipo de ataques. El uso de Server Name Indication (SNI) también puede ayudar a evitar los ataques donde se comparte el mismo nombre de dominio.
ALPACA no representa un peligro para la mayoría de usuarios en la actualidad, pero en el futuro podrían aumentar el número de ataques y vulnerabilidades descubiertas.
