TLS Downgrade(Ataque de degradación de TLS) ; Explicación y PoC

Un ataque de downgrade, también denominado de ataque degradación de TLS, es una técnica criptográfica que explota la compatibilidad retroactiva de sistemas o protocolos, como el protocolo SSL/TLS, para forzar una conexión segura a utilizar algoritmos de cifrad o suites de cifrado más antiguos o menos seguros.

Este tipo de ataque se aprovecha de servidores web o aplicaciones que aún permiten versiones anteriores de protocolos de seguridad, debilitando así el sistema objetivo. En algunos casos, una vulnerabilidad en el navegador puede facilitar la degradación de la comunicación a versiones más inseguras.

Para realizar un ataque de degradación , los atacantes interceptan y alteran la comunicación de un sistema, manipulándolo para que utilice protocolos menos seguros. Es posible que te preguntes cómo se lleva a cabo un ataque de este tipo. Aunque es un proceso técnico, vamos a desglosarlo utilizando el ejemplo de TLS. El funcionamiento es el siguiente:

Cuando un usuario intenta conectarse a un servidor web que usa HTTPS(HTTP sobre TLS/SSL), el navegador y el servidor negocian una conexión segura para proteger la confidencialidad e integridad de los datos transmitidos. Durante esta negociación, el servidor envía una lista de protocolos criptográficos y algoritmos de cifrado compatibles.

El atacante intercepta esta comunicación mediante un ataque man-in-the-middle y la modifica para eliminar las opciones más seguras, dejando solo las versiones más antiguas o débiles. Esta manipulación se aprovecha de vulnerabilidades en los canales de comunicación o mediante scripts maliciosos.

Como resultado, cuando el navegador recibe la lista alterada, se ve obligado a elegir entre las opciones inseguras, lo que lleva a una degradación de la seguridad en HTTPS. La conexión se establece utilizando un cifrado de menor calidad o incluso a través de HTTP sin cifrado, lo que elimina cualquier protección.

El usuario podría no notar ninguna diferencia en su experiencia de navegación, ya que la página web continúa cargándose normalmente. Sin embargo, la seguridad de la conexión se ve comprometida, haciéndola vulnerable a ser interceptada por el atacante.

Cualquier información sensible que se transmita entre el usuario y el servidor web, como contraseñas, datos de tarjetas de crédito o información personal, queda expuesta y puede ser capturada y explotada por el atacante.

A pesar de los esfuerzos para parchear vulnerabilidades y actualizar los protocolos de seguridad, un ataque de degradación TLS sigue siendo efectivo cuando se utiliza software obsoleto o no se siguen las normas de seguridad, dejando a muchos usuarios y sistemas expuestos al riesgo.

PoC

En nuestro laboratorio, nuestro navegador nos advierte sobre un certificado «malo», autofirmado.

Vamos a ver que sta ocurriendo. La suite OpenSSL cuenta con una herramienta de línea de comandos llamada openssl. Este comando es increíblemente versátil y permite realizar diversas tareas relacionadas con TLS/SSL, como inspeccionar y convertir certificados, así como probar conexiones TLS/SSL.

A primera vista, vemos la versión TLSv1.2 con ECDSA-RSA es un estándar sólido y adecuado para la mayoría de los contextos.

Pero hay detalles que llaman la atención:

• Como se anticipaba, este servidor utiliza un certificado autofirmado.

• El servidor está usando la versión actual de TLS, v1.2, junto con un conjunto robusto de algoritmos.

• El servidor nos confirma que la renegociación segura ESTÁ soportada

Este último aspecto sugiere que el servidor está abierto a negociar con nosotros sobre la utilización de estándares y algoritmos alternativos. Vamos a comprobar si es posible emplear versiones más antiguas de TLS.

Pero vemos que podemos hacer que el servidor utilice TLSv1.0, una versión que ya está obsoleta. Muchos navegadores han dejado de aceptar TLSv1.0 y v1.1 por completo.

Antes teníamos SSLv2 y SSLv3, que hoy en día son conocidos por ser vulnerables a ataques como POODLE. Este permite a un atacante interceptar y descifrar tu tráfico. Por eso los navegadores dejaron de soportar estos protocolos hace tiempo.

Las versiones actuales del comando openssl ya no soportan SSLv2 y SSLv3 a menos que se compile manualmente desde el código fuente.

SSLyze nos informa que, aunque SSLv2 no está habilitado, SSLv3 sí está disponible. Además, se admite el uso de algoritmos antiguos como RC4, lo que podría darnos una oportunidad para descifrar la encriptación. Ahora, probemos con TestSSL.sh para ver si podemos descubrir algo más.

Al final, parece que esta aplicación web fue desarrollada hace bastante tiempo y estaba diseñada para usuarios con navegadores antiguos, como ese y gran famoso Internet Explorer 6. El sitio parece estar potencialmente expuesto a ataques como POODLE, así como a intentos de descifrar RC4.

Llevar a cabo un ataque real requeriría configurar un ataque de hombre en el medio (MitM) para interceptar y manipular el tráfico.

Como nuestro laboratorio esta corriendo en docker vamos a listarlos y entraremos en uno de ellos.

El script que tenemos llamado start-interceptor.sh se encarga de agregar una regla al firewall local y de iniciar el script en Python interceptor.py, que se comunica con esta regla de firewall.

La regla de firewall que configuramos se encargará de que cada paquete TCP/IP entrante sea interceptado y analizado por el script en Python interceptor.py. Este reenviará todos los paquetes hacia el contenedor Docker, excepto los paquetes Client Hello de TLSv1.2. El paquete «Client Hello» es el primer paso para establecer una conexión TLS completa.

Si inicias el interceptor sin modificar nada, nos permitirá que verla salida de depuración. Es importante destacar que las conexiones TLSv1.0 y v1.1 no activarán el ataque MitM (Man in the Middle), mientras que TLSv1.2 sí lo hará.

Destaco los byytes `»\x03\x03″`. Estos bytes indican la versión de TLS que está siendo utilizada. Más adelante, vamos a modificar esto a `»\x03\x01″`.

De forma predeterminada, nuestro navegador como OpenSSL intentarán usar las configuraciones más avanzadas y modernas mediante TLSv1.2. Para hacerlo manualmente con OpenSSL, basta con omitir la versión:openssl s_client -connect 10.0.0.50:5000 </dev/null Debemos tener

en en cuenta que OpenSSL y los navegadores modernos están diseñados para protegerte contra ataques de degradación de TLS. Por eso es útil que nuestro contenedor Docker esté utilizando una versión antigua de OpenSSL. Para verificar su funcionamiento, mientras el interceptor está en ejecución, no conectaremos con OpenSSL al contenedor