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 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.
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.
Fuente http://www.elladodelmal.com
de Chema Alonso
