XMPP, algo más que chat (2/2)
Siguiendo con lo comentado en la entrega anterior, en esta segunda parte lo que voy a comentar es la parte práctica relacionada con Tuenti y, en mayor medida, Google Talk.
Con respecto a Tuenti, comenté que podíamos aprovechar que la operadora Tuenti Tu nos ofrecía navegación móvil gratuita por la red social (creo que ya no es así, necesitas hacer recargas todos los meses) para tunelizar nuestro tráfico a través de XMPP y que, por tanto, éste tuviera como “primer destino” los servidores de Tuenti y, por tanto, que entrara dentro de las condiciones del servicio gratuito.
Las aplicaciones para la prueba de concepto las desarrollé en Java por lo que el rendimiento es bastante pobre (la idea era probarlo en Android, y por comodidad desarrollé directamente todo en el mismo lenguaje), así que, del siguiente esquema, realmente lo que nos interesa es el retardo con los servidores de Tuenti (~130ms) que sería con lo que tendríamos que jugar para aumentar el rendimiento del servicio (p.e más de una petición por cada comunicación XMPP).
Este concepto de tunelización no es nada nuevo, y son de obligada mención otros desarrollos del estilo como la tunelización a través de Facebook (Facecat de Jose Selvi), MSN o Skype, proxy a través de Google Spreadsheet o Facebook, etc.
Visto esto, pasemos a la parte de Google Talk.
Antes de empezar, comentar que todo lo descrito a continuación se basa en la realización previa de una ataque man-in-the-middle y que sólo se analizan las opciones/servicios ofrecidos de forma oficial por Google.
¿Qué vectores de ataque podemos encontrar en Google Talk? Pues antes que nada, hay que ver qué formas de acceso al servicio nos pone a nuestra disposición Google. En este caso, nos encontramos la aplicación para dispositivos Android, el formato móvil (Talk Gadget) y la aplicación de escritorio.
Lo primero que se nos puede ocurrir es ver si realmente todas ellas cifran el tráfico… (por eso anteriormente no he nombrado la implementación de GTalk en GMail, cuya comunicación ya va cifrada). Analicemos cada una de las situaciones.
Dispositivos Android
En este caso podemos comprobar como cifran la comunicación desde el primer momento (ya entenderemos luego a qué me refiero), por lo que no nos interesa (y podemos estar ‘algo más tranquilos’).
Formato móvil
En un primer momento el tráfico no se cifraba por lo que, al tratarse de un servicio de Google sin SSL por defecto, podíamos iniciar sesión en el servicio capturando la cookie no-ssl de la sesión del usuario (explicado en el post anterior). Actualmente ya obliga a que el tráfico se cifre por lo que quedaría descartada (en ningún momento se pretende hacer ninguna suplantación de certificados, la clave es que sean técnicas totalmente transparentes).
Aplicación de escritorio
En este caso ocurre una situación curiosa porque sólamente la versión inglesa cifra el tráfico (y ya veremos que en XMPP es una medida insuficiente) por lo que todos aquellos que se descarguen la versión en su idioma directamente tendrán todo el tráfico en texto claro. Por lo tanto, será en este caso en el que nos centraremos.
Además, cabe destacar que hace unas semanas Google publicó una extensión para Chrome que permite utilizar Google Talk sin tener abierto el navegador. En ese caso, junto con la implementación en Gmail comentada anteriormente, no se tiene en cuenta por ser un servicio BOSH a través de SSL.
Vistos los tres vectores de ataque… ¿a qué nos enfrentamos?
La cadena de conexión
[stream:features][starttls xmlns=”urn:ietf:params:xml:ns:xmpp-tls”][required][/required][/starttls][mechanisms xmlns=”urn:ietf:params:xml:ns:xmpp-sasl”][mechanism]X-GOOGLE-TOKEN[/mechanism][mechanism>X-OAUTH2[/mechanism][/mechanisms][/stream:features]
<auth xmlns=”urn:(…):xmpp-sasl” mechanism=”X-GOOGLE-TOKEN”>(…)</auth>
Como podemos ver, la autenticación se hace a través de un token obtenido a partir del servicio ClientLogin. Podríamos pensar que se trata de un token de un sólo uso pero a parte de no cumplirse eso, además tiene un timeout bastante generoso. Por lo tanto, si se accediese al proceso de autenticación obtendríamos un token válido de la sesión del usuario generado para el servicio mail. Por suerte, actualmente ese tipo de token tiene restringido el acceso a ‘sólamente’ el feed de Gmail, por lo que sólo tendría permisos de lectura de los snippets/resúmenes de los correos no leídos (aunque veremos más adelante que no es así).
Siguiendo con el tema de la conexión, podemos observar que es el servidor el que le indica al cliente qué mecanismos de autenticación tiene habilitados, pero… ¿podríamos forzar la autenticación en claro (mechanism=’PLAIN’)? A pesar de que los servidores de Google nos rechazarían la autenticación por no soportar esa opción, podríamos obligar (debido al ataque MiTM para el cliente somos nosotros el servidor XMPP) que el cliente utilice ese mecanismo y, la aplicación de escritorio, en ningún momento rechaza esta situación (y debería por tratarse del cliente oficial, que debería evitar que los credenciales se utilicen fuera de la autenticación por ClientLogin que sí que utiliza SSL).
Continuando por este camino, si nos fijamos vemos que el servidor obliga al cliente a iniciar una comunicación cifrada (starttls required) pero, ¿es un requisito también del cliente?. Sabiendo que las versiones no-inglesas no cifran el tráfico ya sabemos que no pero aún así, si forzáramos al cliente a no cifrar la comunicación éste no lo rechazaría y, por tanto, podemos volver a forzar al cliente a que se comunique bajo los requisitos de nuestra pasarela.
Para estas acciones desarrollé una pequeña aplicación (cuyo enlace al ejecutable/código está al final del post) que simplemente abre dos sockets, uno para el cliente (a modo de servidor) y otro para Google (a modo de cliente). Aprovechándose de un ataque DNS-Spoofing (desarrollado junto al ataque MiTM) las conexiones del cliente al dominio talk.google.com irán a parar a nuestra pasarela que enrutará a los servidores de Google previa manipulación en base a los filtros que hayamos utilizado. Viendo más en detalle los filtros quedaría:
Obtención de los credenciales del usuario de forma transparente
Cuando el usuario inicia la conexión, en la respuesta del servidor se reemplaza el mecanismo X-GOOGLE-TOKEN por PLAIN (o se eliminan todos y se añade éste último). De esta forma, en la respuesta del cliente obtendremos codificado en base64 su usuario y su contraseña. Con estos datos se genera un token a partir del servicio ClientLogin y se envía la petición correcta a Google estableciendo como mecanismo X-GOOGLE-TOKEN y en base64 el usuario y token generado (realmente el usuario lo obvia y autentica en base al token); a partir de aquí el resto del tráfico se enruta sin modificaciones. De esta manera, de forma totalmente transparente al usuario, éste se autentica pero nosotros obtenermos sus credenciales de Google.
Evitar el cifrado de la comunicación
En este caso, cuando el usuario inicia la conexión, en la respuesta del servidor se elimina el tag starttls forzando al usuario a no cifrar la comunicación. Puesto que Google lo permite en sus servidores (aunque lo mande como obligatorio, luego no lo exige) no es necesario que la comunicación de la pasarela con los servidores sea cifrada.
Como podéis ver, con dos técnicas sin ciencia alguna (y apoyadas en el ataque MiTM, más que conocido) es posible obtener en claro toda la comunicación XMPP aunque se fuerze a cifrarla y, lo que es más grave, conseguir las credenciales de la cuenta (por una mala gestión, en el cliente, de los mecanismos permitidos). No nos olvidemos que, al tratarse siempre de clientes oficiales, éstos no tienen que tener configuraciones globales, sino las adaptadas al único servicio que soportan (y habrá casos que se puedan entender, pero estos dos deberían estar contemplados).
Rizando algo más el rizo, en el post anterior comentábamos cómo XMPP es un protocolo muy ‘extensible’, permitiéndo implementar funcionalidades adicionales de una forma muy sencilla (normalmente a través de las stanzas IQ). Por este motivo, ¿qué más cosas se pueden hacer con una sesión de Google Talk?
Si acudimos a la página de desarrolladores de Google Talk podemos encontrarnos con extensiones de acceso al correo y de manejo de contactos (entre otras).
En el caso del correo, antes comentábamos que el token generado para el servicio mail nos permite acceder únicamente al feed de gmail (correos no leidos). Si observamos, en este caso a través de XMPP también podemos acceder a los snippets/resúmenes (y con información más detallada del mensaje). Lo peligroso del tema es que en este caso se nos permite realizar búsquedas (como las que realizamos desde Gmail) por lo que podemos utilizar parámetros como ‘in:anywhere’ para obtener todos los correos, ‘in:chats’ para acceder a conversaciones guardadas, y todo lo que se nos ocurra.
En el caso de los contactos, puesto que el roster del chat está ligado con este servicio, podemos acceder a todos los contactos de la cuenta (estén o no en nuestra agenda de Gtalk) y, además, si forzamos la subscripción con alguna cuenta lo que estaremos haciendo paralelamente es añadir esa cuenta a los contactos del usuario (p.e podría resultar útil para futuro spam, pudiéndose utilizar diferentes técnicas para ‘ocultar’ el remitente). De esta forma, en este caso no nos limitamos a una situación ‘read only’ como con los correos sino que podemos incluso gestionar los contactos de la cuenta (añadir registros, bloquear usuarios, etc).
En este video podéis ver la demo con todo lo explicado anteriormente:
https://www.youtube.com/watch?v=Fj5kbwqXsqY
Visto ya todos los ‘descuidos’ que nos podemos encontrar en la aplicación oficial de Google Talk para escritorio, si vamos un paso más allá podemos comprobar como no cifra el tráfico ni para comprobar las actualizaciones por lo que, a través de otro DNS Spoofing podríamos manipular la respuesta a esa consulta. Si bien parece que firma las peticiones, no tengo del todo claro si lo que firma es el ejecutable de la nueva versión (y en caso contrario podríamos forzar la instalación de malware en el equipo) o la respuesta en sí (que en caso contrario podríamos manipular los comandos que se ejecutan con la instalación de la actualización).
Y esto es todo. Espero que haya resultado cuanto menos curioso (que era el objetivo) y que nos quedemos con la idea de que es importante securizar hasta el servicio más pequeño (como en este caso el chat) porque sino, a través de él, es posible comprometer servicios críticos como es el caso de Gmail o Google Contacts (o en el caso del robo de credenciales, la cuenta completa de Google).
Directorio de la aplicación (la descarga aún no está habilitada):
http://www.ldelgado.es/?xmpploit
Podéis acceder a las slides de la presentación (en PDF) aquí
El autor: