Tuenti y las redes locales inseguras
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).
Debido a que el artículo completo era excesivamente largo (lo vi antes de publicarse e invitaba a no leerlo) he decidido realizar dos entregas del mismo y, de esta forma, evitarme el hacer un resumen pues me daba la sensación de que todo lo que eliminaba era algo interesante que se quedaba en el tintero (y poca gente acude al PDF completo, como sucedió con el artículo de la gestión de contraseñas en la UPM).
En esta primera entrega hablaré un poco del TuentiChat (el nombre me lo he inventado pero así nos entendemos), de su estructura y algunos comentarios para realizar una aplicación que monitorice el tráfico y nos muestre las conversaciones de una forma más amigable. Además comentaré la forma de obtener el SID y CSFR de la cuenta para tomar el control de la misma.
En la segunda entrega se explicarán un par de acciones que podemos realizar sobre la cuenta de la víctima y cómo podríamos robar una sesión e incluso los credenciales del usuario de una forma totalmente transparente (o al menos de una forma que sería más efectiva a nivel de sospechas que una suplantación de certificado, sabiendo que la mayoría lo aceptarían sin contemplaciones).
Al artículo acompañará el código de la aplicación (escrita en Java para aprovechar que sea multiplataforma) que utilicé para todas las pruebas y las demostraciones de las charlas. Este código lo publicaré al final de esta entrega pues no están implementados los ataques de la segunda parte (los hice manualmente aunque si están incluidas las clases que habría que utilizar).
¡Comencemos!
Disclaimer:
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
Artículo cortesía de: Luis Delgado J.
Publicado por Contribuciones en http://www.securitybydefault.com/2010/10/tuenti-y-las-redes-locales-inseguras-12.html
Tuenti y las redes locales inseguras (2ª parte)
Como vimos en la primera entrega, podemos aprovechar que el TuentiChat no está cifrado para monitorizar las conversaciones de cualquier usuario que se encuentre en nuestra red local y al que le hayamos realizado previamente el ataque MITM.
A pesar de lo interesante que pueda ser la monitorización de las conversaciones (y las acciones que podamos realizar sobre ellas) creo que es más importante destacar que indirectamente obtenemos el sessionID (de ahora en adelante SID) de la víctima, por lo que nos hacemos con el control total de su cuenta (en realidad casi total, porque algunas acciones requieren la introducción de la contraseña, la cual no obtenemos en ningún momento, por ahora...).
Como se comentó, para poder realizar peticiones en nombre de la víctima necesitaremos, además del SID, el CSFR y en ocasiones el ID (que habremos obtenido durante la monitorización del TuentiChat). Un breve esquema sobre su utilización en las peticiones:
- Petición GET: SID, ID (a veces)
- Petición POST: SID, CSFR, ID (a veces)
Bueno, como ya se dijo, en esta segunda entrega se va a hablar de algún ejemplo de peticiones sobre la cuenta de la víctima y sobre robo de sesiones (obligar a la víctima a generar un SID válido) y robo de credenciales (aprovechándonos de que la página de login no está cifrada).
¡Comencemos!
1. Tuenti, yo soy la víctima
Una vez obtenido el SID ya tendríamos control total sobre la cuenta, pues bastaría con abrir nuestro navegador y modificar la cookie SID añadiendo el contenido del de la víctima (abriéndose Tuenti con su sesión). Aun así, si queremos que sea un programa nuestro el que realice las peticiones, voy a dar alguna información sobre como el modificar la información personal de la víctima.
Cuando realicemos la petición no es necesario que enviemos todos los parámetros pero sí todos los relacionados entre sí (por ejemplo los que tienen que ver con el número de teléfono) y, lo más importante, si alguno falla la petición no se procesará, independientemente de que otros datos fueran correctos.
Con respecto a la ciudad, lo importante es el código de la misma (location_hidden) y no su nombre (que no se valida), al contrario que con el barrio (neighborhood_autofill) el cual tiene que tener el nombre exacto o no validará.
Para obtener el código de la ciudad o el nombre del barrio basta con realizar las siguientes peticiones:
http://www.tuenti.com/?m=Dmz&func=get_cities_for_data_source
search=CIUDAD
http://www.tuenti.com/?m=Dmz&func=get_neighborhoods_for_data_source
search=BARRIO&city_id=IDCIUDAD
Obteniendo como respuesta:
{"search_string":"","results":[{"id":ID,"string":"CIUDAD","info":{"location":"CIUDAD"} }]}
{"search_string":"","results":[{"id":ID,"string":"BARRIO","info":null}]}
Como apunte final, simplemente decir que en todas las peticiones que modifican información (todos los ‘POST’) ha de enviarse el CSFR.
¿Qué medida va a tomar Tuenti al respecto?
Pues Tuenti pretende introducir un sistema de firmado de peticiones a través de un token secreto intercambiado por SSL en el inicio de sesión y que no saldría del navegador (incrustado en la página o en una cookie que solo se enviaría en conexiones cifradas).
De ésta forma, junto con un timestamp que se enviaría para darle caducidad a las peticiones y evitar su duplicado, se evitaría que se pudiesen hacer peticiones al servidor sin dicho token.
¿Cómo podríamos obtener ese token secreto?
En principio, bastaría con modificar el HTML que le llega al usuario y hacer que en cualquiera de los formularios del mismo se envíe el mismo token que se utiliza para firmar. Aun así, habría que ver la implantación del mismo.
En la aplicación que se adjunta al artículo podéis ver otras acciones como cerrar la sesión, cambiar el estado, modificar la página web y números de teléfono (los demás campos de la información personal), etc.
2. Robando una sesión
Todo lo que se ha contado es aplicable siempre y cuando el usuario no decida cerrar la sesión, pues entonces el SID quedaría invalidado y no podríamos realizar ninguna acción sobre su cuenta, pero... ¿qué ocurriría si pudiésemos obtener una sesión, de forma transparente al usuario, y que éste no pueda cerrarla? Pues en ese caso tendríamos acceso completo a la cuenta y el usuario no podría hacer nada.
Es cierto que Tuenti establece un límite máximo de cinco SIDs válidos por cuenta/servicio (es decir, la versión normal y la móvil son independientes) y si la víctima abriese cinco cuentas al mismo tiempo nuestro SID quedaría invalidado pero es poco probable pues no es un dato que se conozca además de que el ataque se habría realizado de forma (casi) transparente.
¿Cuál sería el procedimiento?
Este ataque es muy fácil de llevar a cabo. Bastaría con bloquear el envío del SID de la víctima al servidor, de ésta forma éste creería que el usuario no está autenticado y le enviaría la página de login. La víctima se reautenticaría (sería extraño que se diera cuenta de que está siendo atacada pues tampoco es una situación anómala) y generaría un nuevo SID en el servidor. Si tras la reautenticación levantamos el bloqueo y le dejamos seguir operando con el SID antiguo, es decir, modificamos en la cabecera (en Set-Cookie) del paquete de respuesta el contenido de la cookie SID introduciendo el antiguo y nosotros nos quedamos con el nuevo, tendremos acceso a la cuenta de la víctima (tenemos un SID válido) sin que ésta pueda actuar al respecto.
Para realizar el bloqueo, podemos utilizar los filtros de Ettercap. Bastaría con modificar el contenido de la cookie SID. El filtro podría ser así.
if (ip.proto == TCP && tcp.dst == 80) {
if (search(DATA.data, "sid=")) { replace("sid=", "sid=0"); }
}
A pesar de que podríamos utilizar el Ettercap, yo recomendaría realizar una aplicación propia para el MITM para poder tener mayor control del tráfico antes de que éste se envíe a la víctima. De ésta forma podríamos crear un filtro más personalizado y no estar atados a las opciones que nos da el Ettercap. En el código adjunto al artículo se puede consultar la clase MITM para realizar el ataque desde Java.
¿Qué medida va a tomar Tuenti al respecto?
La medida que va a tomar Tuenti al respecto es el implantar un sistema de control de sesiones (similar al que tenemos, por ejemplo, en Gmail). Es verdad que si el atacante tiene acceso a la cuenta puede monitorizar este servicio y cerrar cada sesión generada por el usuario (bloqueándole el acceso a su cuenta), por lo que la idea es solicitar la contraseña cada vez que se vaya a cerrar una sesión (en todo el ataque no hemos obtenido los credenciales de usuario pues la idea es que el proceso sea lo más transparente posible y, a pesar de que la mayoría aceptaría un certificado falso sin fijarse, es demasiado “cantoso”).
3. Obteniendo los credenciales
Por desgracia es extremadamente sencillo. Bastaría con aprovechar que el “login page” no se cifra, para modificar el formulario de autenticación para que realice la petición sin SSL, obteniendo los credenciales en texto plano.
¿Cómo podríamos modificar el “login page”?
Como estamos realizando un ataque MITM y el tráfico no está cifrado, no sólo podemos monitorizarlo sino también alterarlo, por lo que podríamos utilizar un filtro de Ettercap que se encargue de realizar el proceso, bastando con reemplazar ‘https’ por ‘http’ en el action del formulario. El filtro podría ser así:
if (ip.proto == TCP && tcp.src == 80) {
replace("action=\"https", "action=\"http");
}
Otra opción podría ser la utilización de la aplicación SSLStrip.
¿Qué medida va a tomar Tuenti al respecto?
Para evitar el robo de credenciales Tuenti tiene previsto cifrar por completo (no solo el envió de los credenciales) el ‘login page’ para evitar su manipulación.
Aun así, es necesario concienciar al usuario de que el login ha de hacerse siempre por medio de una conexión segura, es decir, fijarse si estamos a través de SSL y que además el certificado es de Tuenti. Esto es importante porque sino el atacante, por ejemplo, puede obtener el ‘login page’ por SSL y brindárselo a la víctima sin cifrar, obteniendo los credenciales en texto plano.
Como apunte final, decir que actualmente la contraseña se envía tal cual, y como medida complementaria Tuenti pretende utilizar un token para la autenticación que se enviaría junto con el correo electrónico y cuya estructura sería:
token auth = token secreto + hash(contraseña)
¡Hasta aquí todo! Ya para terminar...
Simplemente decir que el artículo (comunicado hace meses) ha servido para que Tuenti implante (en principio se dijo a medio plazo, pero ahora me entra la duda de que vayan a tomar verdaderamente medidas al respecto) una serie de medidas de seguridad que nos benefician a todos los usuarios.
La mejor medida sería que toda la red social se ofreciera por SSL, opcionalmente al menos (independientemente de la complejidad que conllevara, hay que tener en cuenta los datos tan privados contenidos en la red social). Aun así al parecer (no lo digo yo ni significa que lo comparta) la infraestructura actual de Tuenti no lo soportaría (debido al sistema de balanceo que tienen implementado) además de que la experiencia de usuario se vería afectada en gran medida (ralentización).
Y con respecto a la aplicación...
Se han modificado muchas de las ideas que lancé al publicarlo. Por ejemplo, ahora ya podemos empezar a realizar acciones sobre la cuenta de la víctima esté ésta en el TuentiChat o no (como comentaba, lo importante es el SID). Además, se ha modificado el sistema de peticiones pues dejó de funcionar.
Además, se han realizado muchos cambios internos, por lo que os animo a echarle un vistazo al código (no solo compilarlo y ponerse a probar todo lo que se ha dicho en este artículo).
Muchas personas me han pedido que se publique, además del código, una versión ya compilada y lista para usarse. No lo voy a hacer pues es inmediato (puedes incluso abrir el proyecto desde un IDE y compilarlo con un click) y si uno no es capaz de hacer esa tarea tan sencilla es mejor no darle todo hecho...
Nombre: aplicacion_src.7z
CRC-32: f0bb0406
MD5: 919d2ac7b9e13c06c96784f52f38c492
SHA-1: 5ca1691308d7411fe6685f32fe25ad6d37508c15
Artículo cortesía de: Luis Delgado J.
