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!

Heartbleed puede desangrarte vivo. Tómatelo en serio.

Aunque últimamente ando bastante falto de tiempo libre debido a la cantidad de proyectos que intento llevar en paralelo pero mi carácter curioso e impulsivo me la ha vuelto a jugar y me ha hecho perder un poco de tiempo jugando con un servidor. Por motivos que no vienen al caso, estaba yo echando un vistazo a la página web de alguien relacionado con mi trabajo, el de experto en sistemas de automatización industrial concretamente, que ya sabéis que es de lo que me gusta hablar a mí en mis artículos, pero me topé con un bug de HeartBleed en un puerto menos habitual y he querido hacer este artículo para enfatizar estas cosas:

1.- HeartBleed puede estar en cualquier parte
2.- Es muy fácil de explotar
3.- Cambia las passwords
4.- Pon un segundo factor de autenticación a tus cuentas.

Fase 1: Descubriendo la Vulnerabilidad de HeartBleed

Mientras leía la web y me interesaba por lo que allí había hice lo que cualquier persona normal -, lancé un nmap al servidor donde se aloja - vale, supongo que esto de normal encajaría solo dentro de los que estamos por estas comunidades y que no será tan normal en otros lares -. De entre todos los servicios y puertos que salieron en los resultados hubo uno de todos ellos que me llamó la atención.

Figura 1: Lanzando nmap contra el servidor

Era un servidor de Plesk 11.0.9, algo que no es que sea inhabitual, pero que abre siempre las puertas de poder encontrar algo interesante especialmente al estar alojado en un puerto menos habitual al escaneo, especialmente esos días que la vulnerabilidad de Heartbleed estaba en todo su esplendor.

Figura 2: Plugin de HeartBleed para FOCA

Como aún no había sacado Eleven Paths su plugin de HeartBleed para FOCA que puedes ver en la imagen superior, me fui a buscar cualquiera funcional en exploit-db, y use este en concreto. Lo lancé y esperé el resultado.

Figura 3: Lanzando el exploit al puerto 8443

Como podéis ver, es vulnerable y devuelve 16384 bytes de información de la memoria del proceso OpenSSL dentro de este servidor, pero en este primer intento no hay información de interés en la respuesta que pueda considerarse jugosa. Por el momento.

Figura 4: El servidor es vulnerable al exploit

Fase 2: Explotando HeartBleed de forma automatizada

A estas alturas, como os habéis podido imaginar, ya no tengo mayor interés por la página web que estaba leyendo y me centro en mi vulnerable amigo. Decido pedir la página de login del panel y probar a introducir algunas combinaciones habituales de usuario y contraseña de las que no espero resultados. Ya sabéis, los "sospechosos habituales" admin/admin, admin/Abc123456, admin/123456, etcétera. Creo que hacer esto es un mecanismo de mi cerebro para poder pensar mientras las manos son comandadas por el sistema parasimpático.

Tras varias pruebas obviamente infructuosas vuelvo a lanzar el script de Python y obtengo en el volcado de la memoria la última combinación user/password que había utilizado. Perfecto, es cuestión de hacer peticiones hasta que el usuario legítimo entre al panel, cosa bastante improbable teniendo en cuenta la hora que es.

Figura 5: Opción de fijar el ataque de HeartBleed en el Plugin de FOCA

Esto es algo que hoy en día está bastante automatizado en todos los ataques de HeartBleed, y por eso en el plugin de HeartBleed para FOCA se ha añadido de la opción de lanzar el ataque cada 5 segundos y generar un log, algo que ya podían haber publicado antes y no habría tenido que hacérmelo yo.

Como no tenía claro si a la mañana siguiente tendría tiempo de ponerme de nuevo, preparé un pequeño script en Bash que me hiciera el trabajo sucio de explotar la vulnerabilidad periódicamente guardando los datos cada 30 segundos hasta que pueda volver a evadirme de las obligaciones y centrarme en las diversiones.

Figura 6: Script en Bash para fijar la explotación del bug de HeartBleed

Poco que explicar, sencillo pero funcional. Abro una conexión ssh hacia el equipo que se va quedar haciendo el trabajo y creo una sesión con Screen, me parece una buena opción cuando abro terminales de forma remota porque al cerrar la conexión la sesión se queda abierta en el servidor. Solo queda esperar el tiempo suficiente.

Al día siguiente, cerca del mediodía echo un vistazo al log y sorpresa, en algún momento se ha conectado alguien con credenciales de administrador y éstas han sido capturadas.

Figura 7: Una password en el log

Llegados a este punto no puedo vencer la tentación y entro al panel a echar un vistazo, solo un vistazo, os lo juro, para poder mostrar esta captura y conseguir enfatizar el mensaje final de este artículo.

Figura 8: El panel accesible

Conclusiones sobre HeartBleed

Una de las webs alojadas en este servidor pertenece a un bufete de abogados, por lo que para que quede claro desde el principio el carácter didáctico del ataque he decidido ponerme en contacto con ellos directamente y que sean ellos los que se encarguen de exigir a quien estimen conveniente que apliquen una política de seguridad adecuada.

Hoy en día HeartBleed es ya una vulnerabilidad conocida en profundidad, explotada de manera habitual por todas las herramientas, pero seguro que seguiremos encontrándola aún en multitud de sitios durante años. Es muy fácil de automatizar y sería más que recomendable que tomaras en serio las recomendaciones del principio de este artículo. Haz un escaneo profundo de todos equipos de la red - todos, incluidos los dispositivos de red - y por todos los puertos - todos los puertos - buscando cualquier OpenSSL vulnerable que pueda estar ahí.

Por supuesto, todas las passwords que tuvieras antes de HeartBleed deben ser cambiadas, al igual que los certificados digitales, deben ser cambiadas, porque mucha gente ha estado haciendo estas mismas pruebas y pueden estar en manos de cualquiera. Pon un segundo factor de autenticación a cada identidad que puedas o Latch si puedes a tu web que como dice este artículo "Con Latch el problema de Heartbleed no hubiera sido tan grande". Además, visto este ejemplo de hoy, tal vez sería bueno que el equipo de Eleven Paths - o alguien - sacara un plugin de Latch para Plesk, que parece que hace falta.

Autor: Juan Luis Valverde Padilla
jl.valverde@jvalverde.es