Tras las demos del programa de televisión, lo que mucha gente preguntó fue eso de"¿No van las credenciales de Facebook siempre por HTTPs?". Eso les llevó incluso a pensar que la demostración que hice pudiera no funcionar o que fuera de cartón piedra. Con el objetivo de que entiendan mejor en que consiste el ataque, he hecho este artículo y un par de gráficos para que lo entiendan mejor, pero si quieres más, puedes leerte el libro de Ataques en redes de datos IPv4 & IPv6.
 |
| Figura 1: Esquemas de la interconexión IPv6-IPv4 para hacer el man in the middle |
Una vez que se está en medio, se tiene acceso al tráfico que se está enviando desde el cliente, y si se tiene acceso a él, existe la posibilidad de poder interceptarlo y manipularlo, que es lo que hacen herramientas como Cain, SSLStrip, SSLSniff,Ettercap en Kali o la Evil FOCA.
Un Fake CA
Según la herramienta para atacar la red que utilices, el comportamiento será uno u otro cuando hay que lidiar con conexiones HTTPs. En el caso de Cain, la herramienta hace una copia del certificado digital original para enviarle al cliente un Fake-CA. Algunas herramientas no validan que el certificado digital cumplan que el certificado esté emitido para ese sitio, que esté caducado o que esté emitido por una entidad certificadora válida en la que se confía, como por ejemplo publicamos con el cliente aMSN. Con el resto de ellas, o bien no funciona la conexión, o se obtiene una alerta de seguridad.
 |
| Figura 2: Certificado falso de passport.com creado por Cain |
Si el usuario acepta ese certificado, a partir de ese momento estará enviando los datos cifrados al atacante, que los descifrará, leerá, manipulará y los volverá a enviar al servidor cifrados con una conexión HTTP-s hecha, esta vez sí, con el certificado original del servidor web.
El bug de las BasicConstraints
En el caso de SSLSniff, lo que se hace es algo similar, pero aprovechándose de unbug en los clientes que no verifican las BasicConstrains del certificado que reciben. La gracia es que se utiliza un certificado auténtico pero que no tiene validez para crear nuevos certificados. Es decir, supongamos que el atacante se saca un certificado digital para un servidor web llamado miserver.com en Verisign. La cadena de confianza es correcta, y no genera ninguna alerta de seguridad.
El ataque se basa en usar el certificado de miserver.com para crear certificados digitales falsos para sitios como www.facebook.com pero firmado por miserver.com. Si el cliente tiene el bug de BasicConstrains y no comprueba que el certificado de miserver.com no tiene autoridad para crear certificados, podría tomar el falso certificado de facebook.como como bueno. Esto le ha pasado a casi todos los navegadores, y al propio iOS de iPhone no hace mucho.
El Stripping de HTTPs
En el caso de herramientas como SSLSniff o Evil FOCA el ataque se basa en hacer que el cliente navegue entre él y el atacante con HTTP y luego las herramientas navegarán con HTTPs cuando se conecten al servidor oficial. Aquí tienes la presentación original de Moxie Marlinspike en BlackHat 2009.
En el caso de que el servidor haga un re-direct a HTTPs, como sería por ejemplo cuando el cliente pida http://www.google.com y el servidor le intente llevar ahttps://www.google.com, será el atacante el que hará la redirección, manteniendo al cliente siempre en HTTP.
 |
| Figura 4: El Bridging HTTPs-HTTP con un redirect de por medio |
Una vez que se obtenga la página de resultados, es importante que las cookies de sesión - que vendrán marcadas con el flag secure para no funcionen sobre HTTP - sean gestionadas por el atacante. Para ello se puede generar una cookie falsa que se envía al cliente sin dicho flag, permitiendo que él navegue, y que el servidor no note que ha habido una manipulación de la cookie.
 |
| Figura 5: La captura de las credenciales vía HTTP en el equipo que corre la Evil FOCA |
Esto no es necesario siempre. Muchos servidores que hacen el envío de un mensaje de redirect a HTTPS, siguen escuchando por HTTP, así que aunque pidan que todo se le envíe por HTTPS se puede seguir enviando la información de login por HTTP y permiten la autenticación.
Para conseguir más peticiones de inicio desde el cliente con HTTP, Evil FOCA filtra los resultados de Google, es decir, que si te conectas a Google a través de una conexión atacada por Evil FOCA poniendo en la barra de navegaciónhttp://www.google.com, cuando el servidor devuelva un redirect ahttps://www.google.com, Evil FOCA lo interceptará, hará la navegación a HTTPs y le entregará la página de búsqueda al cliente bajo HTTP. Es decir, hace un Bridging HTTPs-HTTP a www.google.com
 |
| Figura 6: Evil FOCA haciendo el Bridging a WWW.GOOGLE.COM y a los resultados de búsqueda de Facebook |
Después, cuando el usuario busque en Google algo como Facebook, todos los resultados que vengan apuntando a HTTPs serán sustituidos por HTTP y losredirect Javascript serán eliminados también, para que el engaño sea completo. El resto, será volver a hacer el Bridging HTTP-HTTPs otra vez, pero esta vez a Facebook. Esta es la demo que hice en DEFCON 21.
Mitigaciones
