Credenciales de Facebook enviadas por HTTP y no HTTPs

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.

El primer punto que hay que conseguir es situarse entre medias de la comunicación. Esto se puede hacer de mil formas, desde configurarse como rogue-AP y router a nivel de red, hasta hacer un ataque de ARP-Spoofing, pasando por los ataques Stateless Adrees Auto Configuration en IPv6 o Web Proxy Auto Configuration en IPv4 o IPv6.  Estos tres últimos los puedes hacer con Evil FOCA.

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 un bug 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í tenéis la presentación original de Moxie Marlinspike en BlackHat 2009.

  Figura 3: 2009 BlackHat DC Presentation on SSL Stripping de Moxie Marlinspike
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 a https://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ón http://www.google.com, cuando el servidor devuelva un redirect a https://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 los redirect 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.

Figura 7: Política HSTS generada por Google para Gmail

Nota, hay que tener en cuenta que si el cliente ya se ha conectado una vez a Facebook y este le ha puesto un forzado de HTTPs mediante la etiqueta HSTS (HTTP Strict Trasnport Secuirty) entonces hay que hacer que caduque dicha protección con un ataque como el de Delorean.

Mitigaciones

Si estás en un esquema de man in the middle hay poco que hacer salvo cifrar contra un punto de conexión seguro con una VPN con L2TP o SSTP con Certificate Pinning - que PPTP es susceptible de ataques de man in the middle y se puede crackear por diccionario o atacando MS-Chap-v2 con brute-force tras reducción - , y si no es posible mejor que no se navegue nunca. Un plug-in que obligue a navegar siempre vía HTTPS, el uso de certificate pinning para evitar que te comas un bug de BasicConstrains en el futuro o un entidad intermedia maliciosa, además de intentar no entrar a los sitios haciendo clics en ningún sito o confiando en los redirects a HTTPS ayudarán mucho a detectar el ataque.

Saludos Malignos!