En este artículo voy a explicar cómo nos podríamos hacer con el control de la cuenta de Tuenti de un usuario que se encuentre en nuestra misma red local, siempre y cuando ésta permita la realización de un ataque ‘man in the middle’ (de ahora en adelante MITM).
No me hago responsable del mal uso que pueda darse a esta información o al código de la aplicación que la complementa.
En ningún momento la intención del artículo es la de incitar a que se produzcan ataques sobre las cuentas de los usuarios de Tuenti (siendo exportable a cualquier otro servicio), más bien su finalidad es la de concienciar, pues si no cuidamos dónde y cómo nos conectamos, la privacidad de nuestros datos (y en muchas ocasiones los de otras personas) puede verse comprometida.
1. Introducción
Todos sabemos lo nada recomendable que es el navegar por una red que no conocemos, pues no podemos saber si el administrador (u otro usuario) está monitorizando nuestro tráfico.
Puesto que muchas veces nos veremos en la situación de utilizar una, es más que recomendable cifrar el tráfico a través de una VPN de confianza.
Aprovecho para recomendar la
serie de artículos que escribió Chema Alonso en su blog,
El lado del mal, sobre la seguridad de las VPN y qué soluciones son las más recomendadas.
Visto esto y orientándolo a Tuenti, por ser una red social con gran presencia nacional, vamos a preguntarnos: ¿qué podemos hacer con ella y una red local insegura? Pues muchas cosas interesantes, a la par que muchas medidas de seguridad han de ser implementadas.
A lo largo de cada apartado aprovecharé para comentar las medidas que Tuenti ha decido tomar al respecto tras haber sido avisados (podremos estar de acuerdo o no con los motivos pero siempre es interesante saberlos).
Preparando una de las charlas sobre el artículo, desde Tuenti se puso mucho interés en que contara algunas de las implicaciones legales que conlleva el realizar el ataque. Por este motivo, aquí tenéis un breve comentario sobre lo que me comunicó su departamento legal:
Debido a que obtendremos control total sobre la cuenta de Tuenti de la víctima y realizaremos peticiones en su nombre, estaremos cometiendo un delito de Suplantación de Identidad, penado con entre seis meses y tres años de cárcel. Además, para realizar esto habremos monitorizado su tráfico por lo que estaremos cometiendo un delito de Interceptación de comunicaciones penado con entre uno y cuatro años de cárcel.
2. El escenario
Los requisitos necesarios para poder llevar a cabo el ataque consisten en encontrarnos en la misma red local que la víctima y el haber realizado un ataque MITM para poder monitorizar/manipular el tráfico.
No voy a explicar cómo realizar el ataque MITM ni cómo monitorizar el tráfico pues creo que es ampliamente conocido por todos y hay mucha documentación al respecto, aun así decir que utilicé Ettercap (MITM) y TShark (monitorización).
A pesar de esto, a lo largo del artículo se recomendará el no depender de aplicaciones externas (no nos aportan ninguna funcionalidad extra) sino que será más interesante el programar e implementar éstas por nuestra cuenta (en el caso del sniffer bastaría con uno simple que dumpee el tráfico o que trabaje ‘al vuelo’ y con respecto al ataque MITM podremos tener un mayor control de los paquetes antes de redireccionarlos a la víctima).
3. El TuentiChat
Aprovechando que el tráfico del TuentiChat no está cifrado, podremos monitorizar las conversaciones de la víctima e incluso, más orientado con lo que se verá en la segunda entrega, podremos modificar las mismas (lo que envía y lo que recibe).
El TuentiChat utiliza el protocolo abierto XMPP, el cual está basado en XML. Por lo tanto, a la hora de monitorizar el tráfico sería aconsejable utilizar un filtro para el protocolo HTTP/XML.
Un ejemplo del contenido del paquete de un mensaje sería:
<body rid='RID' sid=’SID’ xmlns='http://jabber.org/protocol/httpbind' key=’KEY’>
<message xmlns="jabber:client" to="IDUSUARIO@xmppX.tuenti.com/tuenti">
<body>MENSAJE</body>
</message>
</body>
¿Es posible seguir una conversación?
De forma manual no, pues la cantidad de paquetes que no tienen que ver con la conversación (que no contienen mensajes) nos desbordaría. Además nos encontraríamos con un problema a la hora de seguir multiconversaciones pues el ID del usuario no nos es fácil de recordar por lo que será difícil diferenciar qué mensaje corresponde a qué conversación. Por lo tanto, para poder seguir el TuentiChat de la víctima será necesario realizar una aplicación con un FrontEnd “amigable”.
No voy a detallar el cómo programar la aplicación, pero si voy a hacer algunos comentarios al respecto.
En primer lugar, es necesario realizar un filtrado del tráfico de la víctima pues, si obligamos al programa a trabajar con toda la captura, hará que en muchas ocasiones el TuentiChat no sea fluido, pues estará procesando otro tráfico innecesariamente (por ejemplo, si el usuario está viendo un vídeo en YouTube). Con respecto al TuentiChat, tendremos que procesar únicamente el tráfico proveniente del rango de IPs 95.131.x.x.
A la hora de procesar los paquetes y dividir los mensajes por conversaciones, tendremos que centrarnos en 4 datos importantes, siendo éstos el RID (para evitar paquetes duplicados), el emisor (etiqueta from), el receptor (etiqueta to) y el mensaje (entre las etiquetas body de segundo nivel).
En el caso de que sea la víctima la que inicie la conversación y el otro usuario no le responda, no sabremos el ID de la víctima pues no manda la etiqueta from (la asigna a posteriori el servidor), por lo que tendremos que tener cuidado de procesar esos mensajes correctamente.
En mi caso opté por generar un buffer temporal a la espera de poder ponerle nombre a la víctima. Otra opción sería realizar una petición al perfil del usuario nada más obtener el SID, obtenerlo de ahí y olvidarnos de este problema (el SID aparece siempre).
Después de haber visto todo esto es interesante preguntarse ¿es seguro utilizar el TuentiChat?
Mi respuesta es que no siempre que nos encontramos en una red insegura y no nos hayamos encargado nosotros mismos de cifrar el tráfico. A pesar de esto, aún me sorprende lo poco que le importa a la gente su privacidad.
¿Tuenti va a tomar alguna medida al respecto?
Tras reportarlo me comentaron que, a medio plazo, se dará la opción al usuario para que elija que sus sesiones de chat se cifren (con sus ventajas e inconvenientes).
Cuando les pregunté por qué el SSL no había sido implantado desde el principio me contestaron que, debido a los microcortes que sufren por culpa de su ISP (de unos 30s), si implantaban el SSL los servidores no iban a aguantar el pico de reconexiones si éstas estaban cifradas y que una reconexión escalar no era solución porque a los usuarios no les gustaría tener que esperar para seguir utilizando el servicio.
Ya hemos visto como podemos monitorizar conversaciones ajenas del TuentiChat de una forma preocupantemente sencilla, ahora bien, ¿qué más podemos hacer?
Algunas capturas de la aplicación:
4. Obteniendo el SID y el CSFR
Para poder realizar peticiones al servidor como si fuéramos la víctima y, por consiguiente, tener acceso total a su cuenta, tenemos que obtener dos datos, el SessionID (de ahora en adelante SID) y el CSFR (código utilizado para evitar peticiones desde enlaces externos a la página de Tuenti).
¿Cómo podemos obtener el SID?
Al haber realizado el ataque MITM todo el tráfico de la víctima pasa a través de nosotros, por lo tanto tenemos acceso a las cabeceras de las peticiones y, al encontrarse el SID en una cookie que se envía en cada una de ellas, podemos obtenerlo fácilmente en cualquier comunicación entre la víctima y los servidores de Tuenti.
Una vez que hemos obtenido el SID ya podríamos, por ejemplo, saber el nombre de cualquier usuario. Simplemente habría que hacer una petición a su perfil y obtenerlo del HTML que nos devuelve el servidor, y de ésta forma ya podríamos olvidarnos del ID. La petición se realizaría a la siguiente url:
http://www.tuenti.com/?m=profile&user_id=ID
¿Cómo obtenemos el CSFR?
El CSFR lo podemos obtener fácilmente, una vez conseguido el SID, realizando una petición a cualquier página de Tuenti (perfil propio, de amigos, etc) y parseando el HTML recibido como respuesta, pues éste no está contenido en una cookie como en el caso del SID. El código HTML en el que se encuentra es:
var SiteConfig = { (…) CSFR: 'CSFR' (…) }
Antes el CSFR era único (por usuario) e invariante (no cambiaba en cada sesión como el SID), pero tras reportarlo, Tuenti ha decidido que varíe cada sesión. Aun así, a nosotros no nos afecta.
¡Hasta aquí todo! Ya para terminar con esta primera entrega...
A continuación se enlaza el código fuente de la aplicación utilizada. En esta versión están implementadas la monitorización de conversaciones, acceso/edición de la información personal de la víctima y algunas acciones como guardar el contenido de la conversación o cerrar la sesión. Faltaría por añadir el robo de sesión y el acceso a los credenciales. Ambos se pueden hacer con el Ettercap o de forma personalizada haciendo uso de la clase MITM.
Lo ideal sería tomar esta aplicación como punto de partida y modificar su código, pues está programado como forma de ir automatizando las pruebas pero sin tener una visión global, por lo que la parte principal del programa es la monitorización de conversaciones (que debería ser una opción dentro de la aplicación) y no el apartado de acciones sobre la cuenta de la víctima (lo que en realidad engloba todo). Esto imposibilita manejar la cuenta de la víctima si ésta no tiene una conversación en el TuentiChat (a pesar de que hayamos obtenido el SID, que es lo verdaderamente importante).
Nombre:
aplicacion_src.7z
CRC-32: a323e8ad
MD5: f1f936e1f26a059add4e888a14748bec
SHA-1: 89afaf9342a3282989222001e1409a9344bdfb77
