Un side-channel con Flash para detectar certificados falsos

Uno de los grandes problemas que intentan resolver desde hace mucho tiempo las grandes empresas en Internet es el de la detección de posibles conexiones de sus clientes que estén siendo interceptadas por un atacante en medio. Esas interceptaciones pueden ser mediante ataques a la red en esquemas de man in the middle o mediante interceptaciones de comunicaciones con un man in the browser. Un problema que lleva tiempo en estudio y que ha tomado muchas aproximaciones distintas para intentar solucionarlo.

En este caso, este estudio de la Universidad Carnegie Mellon "Analyzing Forged SSL Certificates in the Wild" realizado en conjunción y con la ayuda Facebook ha intentado conocer cómo se están falsificando las conexiones HTTPs a la web de la red social - que es una de las formas de robar las contraseñas de Facebook - utilizando un método para poder tener un side-channel que reporte el certificado digital que está viendo el usuario, y así saber si la conexión está siendo interceptada o no por algún certificado en la red que pueda estar viendo el tráfico.

Figura 1: El estudio sobre las conexiones falsas a Facebook

Por supuesto, en esquemas de man in the browser en el que el malware controle toda la comunicación, podría vetarse también este side-channel creado y además, como se utiliza un puerto de conexión no habitual para la generación del side-channel, en muchas conexiones a Internet filtradas no se han podido analizar los certificados, pero aún así la idea es buena y merece dedicarle atención.

El escenario bajo análisis de la web de Facebook

Para poder analizar las conexiones a Facebook, la web de la red social permitió correr un componente SWF que se cargaba en la web unos segundos después de que el usuario hubiera recibido la página web. Esto no se hizo en todos los servidores, pero sí en una parte de ellos que permitió que se analizaran 3 Millones de conexiones.

Ese componente Flash se conectaba al servidor de Facebook para ver si podía crear un Raw Socket con él, para lo que es necesario descargar el fichero de Cross Domain Policy llamado crossdomain.xml para ver si se puede abrir un socket. Configurar este fichero está explicado en la web de Adobe, y hay un estudio interesante de lo que se puede hacer con él en este paper de la Universidad de Sand Diego "Analyzing the Crossdomain Policies of Flash Applications".

Figura 2: Esquema del side-channel con SSL

Una vez conseguido el plugin de Flash el permiso para abrir un Raw Socket SSL, lo que hace este addon no es nada más que implementar el Handshake SSL para analizar el certificado digital que le es entregado en bruto, y ver qué datos tiene para reportarlo al servidor que está llevando el análisis de la conexión.

El análisis de los certificados en las conexiones a Facebook

Por supuesto, no todos los certificados son el que entrega Facebook, y por tanto la conexión es alterada por posibles sistemas que, de una forma o de otra, hacen un Bridging HTTPs para entregar un certificado digital de un hombre en medio que les permita descifrar las conexiones.

No todas estas interceptaciones se hacen con el objetivo de espiar  y dañar al usuario, sino que muchos de esos escenarios se basan en sistemas de seguridad que despliegan el certificado de un Firewall, Proxy de red - estas funciones fueron novedades en Forefront TMG - o Software de Control Parental, que buscan aplicar políticas de seguridad tanto corporativas como personales de los usuarios. En esos casos, lo que suele hacer ese software es algo tan sencillo como desplegar la clave pública de la CA del sistema de seguridad para que los clientes no generen alertas en los certificados que les vengan firmados por ellos, y la única forma en la que un usuario se podría dar cuenta de esto es si está usando algún software que realice Certificate Pinning.

Figura 3: Certificados descubiertos en el estudio

Curiosamente, uno de los fallos que este estudio ha sido capaz de sacar a la luz ha sido que uno de esos software de seguridad, en concreto los appliance Cyberoam de EliteCore utilizan todos la misma CA en todos los dispositivos, lo que hace que para que un atacante pueda robar los datos y hacer un man in the middle perfecto a una red que use este producto solo tiene que irse a otro appliance y sacar la clave privada. El resto sería tan sencillo como usar SSLSniff con esta clave privada para tener un man in the middle perfecto en esas redes.

Conclusiones

También apareció malware firmando sus propios certificados y atacantes haciendo man in the middle que estaba suplantando el emisor del certificado como si fuera Facebook para engañar visualmente a la víctima en las alertas mostradas durante el ataque, lo que deja a las claras que aún el usuario no acaba de entender bien todas las alertas de seguridad que se le muestra.

Figura 4: Falso certificado de Facebook que se uso para explotar un bug en Android

En cuanto a las soluciones propuestas, se habla de Strict HTTPs, algo que además evitaría el posible impacto de ataques de Bridging HTTP-HTTPs como el que hace la Evil FOCA en IPv6 para robar las contraseñas de Facebook -  La demo de esto la tienes en el vídeo de la conferencia de DefCON 21 "Attacking IPv6 in Internet Connections with Evil FOCA" y en el libro de Ataques en redes de datos IPv4/IPv6 -, el uso del sistema de notarios que propuso Moxie Marlinskpike o Certificate Pinning.

De todas formas, aún parece que estamos un poco lejos de poder acabar definitivamente con los ataques en redes de datos, especialmente porque son pocas las redes de empresas que utilizan sistemas como IPSec, DNSSec o similares, o que han preparado sus sistemas de seguridad para IPv6. Eso sí, el estudio ha mostrado una forma muy interesante de hacer una análisis de las conexiones HTTP-s en las aplicaciones web que puede ser replicado en tu sitio si quieres pillar a alguien con el pie cambiado.

Saludos Malignos!