Uno de los problemas habituales en un esquema de Man in the middle es cómo lidiar con las conexiones HTTP-s que autentican la comunicación extremo a extremo por medio de certificados digitales. En estos entornos se pueden utilizar varias aproximaciones al problema, como hacer algún ataque criptográfico a los algoritmos utilizados por los certificados, tal y como hacen BEAST, CRIME, Lucky 13, o el reciente ataque a certificados digitales usando RC4 publicado por Dan Bernstein. De estos temas mejor preguntad a Juliano Rizzo (@julianor).
La siguiente aproximación es generar dinámicamente certificados digitales falsos a partir de una clave en la que confíe el cliente, es decir, robar un certificado digital a una entidad de certificación y firmate tus propios certificados - como hemos visto en varias ocasiones desde el asunto Comodo -, controlar una CA y generarte los certificados a la carta como sucede en países como China para poder filtrar el tráfico, o conseguir atacar los certificados digitales de las entidades de confianza para generar un certificado falso reconocido como el auténtico por los clientes, tal y como pasó en el caso TheFlame y los certificados de las licencias de Terminal Services.
La tercera aproximación es utilizar un esquema similar al que utiliza sslSniff, es decir, con un certificado en el que el cliente no confía como entidad de confianza para firmar certificados, crear los certificados de los sitios web visitados al vuelo, tal y como hace la popular herramienta Cain. Esto puede generar un mensaje de error típico de "este certificado ha sido emitido por una entidad en la que no se confía", o en el caso de que tenga un bug de BASIC Constraints como sucedió con iOS y los iPhone no hace tanto tiempo, conseguir que no de ninguna alerta.
Una última aproximación a lidiar con las conexiones HTTP-s en este entorno de man in the middle IPv4-iPv6 con Evil FOCA es el de hacer algo similar a sslStrip, es decir, antes de devolver las páginas HTML al cliente, se analiza el código fuente de la respuesta y se quita la "s" de todos los hiperenlaces que vienen. En esta versión alpha de Evil FOCA que vamos a publicar, ésta es la aproximación que está implementada hasta el momento.
Un ejemplo de sslStrip con Evil FOCA
Para probar esto, basta con entrar a la página http://www.google.es en tu navegador y mirar el código fuente de la página. En el enlace a Gmail se puede ver que es una conexión https la que se requiere en el momento en que se haga clic en el enlace.
Sin embargo, si entramos a través de la máquina de la víctima, se puede ver que Evil FOCA ha cambiado el hipervínculo por un enlace http para que la página se cargue sin pasar por una conexión segura.
Por supuesto, este truco solo tiene utilidad cuando la página requerida está también sobre HTTP. Si el servidor sólo está dando servicio bajo HTTP-s, entonces será necesario hacer un proceso de Bridging HTTP-S en el hombre en medio.
Bridging HTTP-s
El objetivo de este proceso es hacer que un hipervínculo que ha sido cambiado de https:// a http:// siga funcionando a pesar de que el servidor web sólo de servicio bajo HTTPs, para ello el hombre en medio hará la negociación con el servidor bajo HTTPs y con la víctima hablará solo bajo HTTP. En este entorno además, será importante manipular las cookies entre la víctima y el hombre en medio para crear cookies sin el atributo Secure, ya que estas se van a enviar en conexiones sin cifrar.
Actualmente Evil FOCA tiene implementado sslStrip y se está implementado Bridging HTTPs, pero en el futuro estará también implementado un comportamiento similar al de sslSniff.
Saludos Malignos!
La siguiente aproximación es generar dinámicamente certificados digitales falsos a partir de una clave en la que confíe el cliente, es decir, robar un certificado digital a una entidad de certificación y firmate tus propios certificados - como hemos visto en varias ocasiones desde el asunto Comodo -, controlar una CA y generarte los certificados a la carta como sucede en países como China para poder filtrar el tráfico, o conseguir atacar los certificados digitales de las entidades de confianza para generar un certificado falso reconocido como el auténtico por los clientes, tal y como pasó en el caso TheFlame y los certificados de las licencias de Terminal Services.
 |
| Figura 14: El certificado que TheFlame usurpó |
La tercera aproximación es utilizar un esquema similar al que utiliza sslSniff, es decir, con un certificado en el que el cliente no confía como entidad de confianza para firmar certificados, crear los certificados de los sitios web visitados al vuelo, tal y como hace la popular herramienta Cain. Esto puede generar un mensaje de error típico de "este certificado ha sido emitido por una entidad en la que no se confía", o en el caso de que tenga un bug de BASIC Constraints como sucedió con iOS y los iPhone no hace tanto tiempo, conseguir que no de ninguna alerta.
Una última aproximación a lidiar con las conexiones HTTP-s en este entorno de man in the middle IPv4-iPv6 con Evil FOCA es el de hacer algo similar a sslStrip, es decir, antes de devolver las páginas HTML al cliente, se analiza el código fuente de la respuesta y se quita la "s" de todos los hiperenlaces que vienen. En esta versión alpha de Evil FOCA que vamos a publicar, ésta es la aproximación que está implementada hasta el momento.
Un ejemplo de sslStrip con Evil FOCA
Para probar esto, basta con entrar a la página http://www.google.es en tu navegador y mirar el código fuente de la página. En el enlace a Gmail se puede ver que es una conexión https la que se requiere en el momento en que se haga clic en el enlace.
 |
| Figura 15: El enlace normal a Gmail desde http://www.google.es. Es un hipervínculo bajo https. |
Sin embargo, si entramos a través de la máquina de la víctima, se puede ver que Evil FOCA ha cambiado el hipervínculo por un enlace http para que la página se cargue sin pasar por una conexión segura.
 |
| Figura 16: Página de http://www.google.es "strippeada" |
Por supuesto, este truco solo tiene utilidad cuando la página requerida está también sobre HTTP. Si el servidor sólo está dando servicio bajo HTTP-s, entonces será necesario hacer un proceso de Bridging HTTP-S en el hombre en medio.
Bridging HTTP-s
El objetivo de este proceso es hacer que un hipervínculo que ha sido cambiado de https:// a http:// siga funcionando a pesar de que el servidor web sólo de servicio bajo HTTPs, para ello el hombre en medio hará la negociación con el servidor bajo HTTPs y con la víctima hablará solo bajo HTTP. En este entorno además, será importante manipular las cookies entre la víctima y el hombre en medio para crear cookies sin el atributo Secure, ya que estas se van a enviar en conexiones sin cifrar.
Actualmente Evil FOCA tiene implementado sslStrip y se está implementado Bridging HTTPs, pero en el futuro estará también implementado un comportamiento similar al de sslSniff.
Saludos Malignos!
***********************************************************************************
***********************************************************************************
¿Tenéis pensado qué hacer si usan HSTS?
ResponderEliminarPorque impediría al usuario visualizar la página si ya la ha visitado previsamente, y no valdría el bridging, la única opción sería dejarlo como estar (dado que los certificados tienen que ser válidos en HSTS).
Me encanta tu página y admiro muchísimo todo lo que sabes de un tema tan apasionante como es la seguridad.
ResponderEliminarSi algún dia te parece interesante tal vez podrías hablar sobre la seguridad de los wallet bitcoin que cada vez están más de moda. Que opinas?.
Saludos malignos y gracias por tu excelente página!.
conoces a manuel moreno ? o es puro marketing barato ?? .. en sus charlas dice ser amigo tuyo ...
ResponderEliminarhttps://twitter.com/insecurechile
Buenas, he estado probando esta practica y al hacer el ataque SLAAC mediante EVIL FOCA, al mavegar desde el ordenador de la víctima, no me cambia las paginas HTTPS a HTTP, es decir, AL PONER EL FILTRO "HTTP.REQUEST.METHOD==post" no me muestra ningun paquete.
ResponderEliminarSALUDOS MALIGNOS! :D