Tuenti Security Issues

[LUK]

Tuenti es una red social que tiene el honor de ser una de las startups tecnológicas españolas que más éxito están teniendo. A día de hoy cuenta con una cuota de uso entre jóvenes altísima, y es la más popular aquí en España, con diferencia, en rangos de edad de menores de 30 años – como es mi caso -.

Sin embargo, como dijo el tío Ben, todo gran poder conlleva una gran responsabilidad, por lo que debido a que son el punto de acceso principal de los jóvenes españoles, deben tener especial cuidado contra los depredadores y atacantes.

Sé de buena tinta que se toman los bugs de seguridad bastante en serio, tras la experiencia que tuvimos con un bug de XSS que permitía hacer Hijacking, aunque también tienen cosas que pueden ser mejoradas, por eso me decidí a pedir contribuciones por twitter de fallos y debilidades en el sistema de Tuenti que ellos conozcan porque ya se los hayan notificado, y que deban ser mejorados.

Me consta que muchas de estos issues están en el roadmap de Tuenti y que los tienen en el ToDo para dejar una plataforma más segura. Sin embargo, a día de hoy todavía están aquí. Vamos con la primera parte del artículo con lo que a primera vista cualquiera puede notar.

Issue 1: La página de login bajo HTTP

Una de las cosas que deben ser tenidas en cuenta es que hay que evitar los puentes HTTP-HTTP-s en las páginas donde un usuario debe introducir sus credenciales de acceso. Hay que tener en cuenta que un atacante podría realizar una ataque Man in the Middle para hacer un ataque SSLStrip, es decir, en el que se quitan todos los links HTTP-s entre la víctima y el atacante y robar las credenciales.

Figura 1: Puente http/http-s en el formulario de login

Al estar entregado el formulario bajo HTTP, la victima jamás recibiría una alerta de seguridad si hay un mitm con sslstrip. Es por eso que es necesario que las credenciales se introduzcan bajo formularios entregados con HTTP-s y que no mezcle contenido mixto HTTP y HTTP-s en la misma página.

Issue 2: La página de login bajo HTTP… quieras o no

En muchas aplicaciones web, la página de login se entrega por defecto bajo HTTP, pero los usuarios más avanzados y preocupados por la seguridad, solicitan el acceso bajo HTTP-s forzando manualmente la URL o utilizando extensiones de los navegadores que eviten las redirecciones a HTTP. Sin embargo, con Tuenti es imposible, porque si se solicita la página bajo HTTP-s siempre obliga a autenticarse bajo HTTP.

[YOUTUBE]http://www.youtube.com/watch?v=MYXz7SyfA4w&feature=player_embedded[/YOUTUBE]

Olvidate por tanto, de utilizar extensiones para forzar el uso de HTTP-s en las conexiones con HTTPS Everywhere, Force-TLS o KB SSL Enforcer.

Issue 3: Certificado digital sin validación extendida

Los certificados digitales que compran las organizaciones pueden obtenerse con procesos automáticos o mediante la validación extendida de personas. La validación extendida ayuda a garantizar a un usuario que el certificado no ha sido obtenido mediante un proceso automático que, como demostró Moxie Marlinspike, con el bug del null byte, pueden ser susceptibles de fallar.

Issue 4: Certificado digital con cifrados débiles

A la hora de generar un certificado digital, se pueden elegir los algoritmos que se van a permitir en los túneles SSL. En este caso, los algoritmos que permite son algunos inseguros y deberían deshabilitarse para evitar ataques de crackeo offline de las conexiones, además de establecerse una prioridad de uso.

Figura 2: Cifrados permitidos, sin preferencia por el servidor

Issue 5: TLS-Renegotiation gap, SSL Resumption y PCI-Compliant

Cuando se realiza el análisis de Qualys para certificados digitales, llama la atención la baja nota que se obtiene con este tipo de certificados y, especialmente, en la parte de negociación de claves. Esto es así porque han anulado la Renegociación TLS para evitar el bug de TLS-Renogation en lugar de parchearlo, está anulado, que es un workaround bastante criticado porque deja en manos del cliente definir el nivel de seguridad del servidor manualmente.

Figura 3: Calficación obtenida en el test Qualys

En segundo lugar, aparece una nota negativa porque el certificado no está hacieno uso de los IDS para reutilizar datos de sesiones exitosas, lo que haría que el rendimeinto de las conexiones fuera mucho más alto.

Figura 4: Issues en el certificado digital

Así, mirando las características en total del certificado, como se puede ver, no pasaría una auditoría PCI, aunque hay que decir que Tuenti no está obligado a pasarla.

Estos 5 Issues no son bugs de seguridad en Tuenti, sino puntos que deben mejorarse para aplicar los principios de Minimo Punto Exposición, Minimo Privilegio y Defensa en Profundidad, fundamentales en los procesos de Hardening de Sistemas.

Saludos Malignos!
http://www.elladodelmal.com/2011/06/tuenti-security-issues-i-de-v.html

[LUK]

Issue 6: Registros PTR publicados en los servidores DNS

Dentro de los servidores DNS de Tuenti se puede ver que Primary Master es dns01.tuenti.com, uno de los servidores publicados en Internet, así que era muy probable que tuviera concentrada en él toda la información de los registros PTR. Haciendo uso de FOCA es bastante sencillo descubrir la infraestructura interna de servidores y máquinas que utiliza todo Tuenti con un PTR Scanning.

Figura 5: Infraestructura de servidores en Tuenti

El exponer la lista de cientos de servidores abre mucho más el abanico a un potencial atacante que quiera probar la seguridad, uno a uno, de todos ellos, complicando mucho más la vida de los equipos de seguridad.

Además esta lista de equipos de red se puede complementar con Shodan, ya que tienen indexados bastantes de los equipos de Tuenti en cada rango, y basta con utilizar el comando NET aplicado a los segmentos descubiertos, para tener una visión bastante completa de toda la red.

Issue 7: Servidores sin actualizar

La parte negativa de que se puedan descubrir muchos servidores con los registros PTR es que permite encontrar servidores perdidos, olvidados, o fuera de la política principal de seguridad porque son de pruebas, temporales, o, incluso, que son dispositivos IP. Mirando alguno al azar, era posible descubrir servidores Apache publicados en servidores accesible por Internet, en los que se muestran las versiones de los productos y, algunos, como en este caso, con vulnerabilidades conocidas, como esta de D.O.S. de fácil explotación con el CVE-2010-1452.

Figura 6: Servidor Sanson.tuenti.com con vulnerabilidades conocidas

Es suficiente con revisar el ChangeLog completo de Apache para ver todos los CVE que le afectan a la versión que estaba publicada.

Issue 8: Los metadatos

No podría dejar de mirar los servidores de Tuenti con la FOCA sin poner un ojo en la recomendación del Esquema Nacional de Seguridad sobre los Metadatos, para ver si estaban haciendo uso de alguna política de limpieza de documentos antes de publicarlos.

Figura 7: Metadatos en documentos publicados en Tuenti

Basta con buscar algunos de los documentos en PDF publicados en Internet, y descubrir nombres de usuarios, versiones del software que han comprado para utilizar en la organización, y quién lo usa, etcétera.

Issue 9: La transferencia de datos del perfil sin HTTPs

Una de las cosas que más problemas genera es la no posibilidad ni por defecto, ni configurándolo, de utilizar conexiones HTTP-s entre el usuario y los servidores de tuenti. Esto hace que cualquier cosa que se transmita pueda ser escuchada y capturada en una red insegura. Quiero centrarme en el término de red insegura, porque a veces los responsables de infraestructuras lo utilizan para pasar responsabilidades de la compañía al usuario – no he dicho que sea el caso de Tuenti -.

Una red insegura es aquella que no ofrece garantías a sus usuarios sobre la seguridad de sus comunicaciones porque no hay garantía que un atacante pueda capturar los datos o manipularlos.

Así, bajo esta definición de redes seguras nos quedarían un puñadito nada más, en las que, por ejemplo entrarían las redes TCP/IP que usan IPSec (con certificados digitales o Kerberos, no con PSK), las redes WiFi que no usan WPA/WPA2-Enterprise con EAP, las redes WIFI con WPA/WP2 con una contraseña no crackeable [WPA/WPA2 Craking] - ya que pueden ser atacadas con man in the middle [Atacar WPA/WPA2 PSK] - y las que se hacen con redes PPTP con SSTP, PPTP con passwords no crackeables y con L2TP/IPSec. El resto serían inseguras.

Eso sí, ésta red “segura” lo sería solo hasta el operador, ya que después no hay garantía ni control más allá de la red, y sucedería lo mismo con la conexión del servidor VPN a los servidors de Tuenti. Además tendríamos que quitar de la lista las conexiones VPN con L2TP/IPsec y PPTP en aquellas redes como hoteles, universidades, etcétera, donde los puertos de conexión estén bloqueados. Las 3G y GPRS deberíamos dejarlas también fuera por los problemas con GSM con A5/0 y A5/1, y por supuesto las redes WPA/WPA2-PSK en las que seamos más de 1 usuario, ya que se podrían hacer ataques de Mitm.

Figura 8: Gráfico de conexiones "seguras"

En este ejemplo, asumiento Internet como red Insegura, los datos del usuario pasarán siempre en abierto, una vez salga de la "red segura" del usuario o de la "red segura del servidor VPN" que usa el usuario.

Tras esta reducción de redes seguras nos queda:

a) Aceptar que el sistema no ofrece privacidad alguna, como en los correos SMTP/POP3, y eso debería dejarse claro cuando se solicitan datos de caracter personal o mensajes privados de los usuarios.

b) Asumir que el servidor se ha diseñado solo para unos pocos afortunados que tienen suerte de que ningún ataque a un Router mueva tráfico a China o algún insider de un operador tenga una tarde graciosa y publique en pastebin los datos de las sesiones de tuenti que pasen por su red.

c) Poner HTTPS con certificados de validación extendida y protocolos de cifrado robustos para extender la seguridad de la red hasta el usuario.

Es por eso, que lo más fácil para mejorara la seguridad es montar HTTP-s y que justificarlo con un “no te conectes desde una red insegura” es una falacia. Evidente, la falta de Http-s en la transferencia de datos no solo afecta a la privacidad de la información intercambiada, como fotos, mensajes, chats, comentarios en muros, etcétera, sino a los datos de la sesión del usuario, lo que hace que sea fácil perpetrar ataques a la cuenta del mismo.

El usuario debe por tanto tener extremado cuidado con la red que utiliza para conectarse, si valora su privacidad y qué datos envía. Este problema, lo han tenido la mayoría, si no todas, de las redes sociales, aunque muchas ya han optado y están optando por poner HTTP-s opcional, cuando menos, para los usuarios más preocupados, y Tuenti lo pondrá no tardando mucho, seguro.

[LUK]

Issue 10: Hijacking en “redes inseguras”

Tras el análisis en el issue 9 de lo que es una “red insegura” o no en un entorno como el de Tuenti, hay que hablar del clásico del robo de la sesión o hijacking de una cuenta en Tuenti. Para que sea entendible por todos, baste decir que cuando un usuario se autentica contra una aplicación web, esta genera un conjunto de variables en el servidor que le identifican de forma única, y que se entregan al usuario en forma de cookie. Esa cookie se convierte en un token que le permite entrar en todas las partes de su cuenta, y debe ser enviada en cada petición.

Si esta cuenta se envía por HTTP, es decir, sin cifrar, cualquier persona con acceso a la red podrá acceder a ella, copiarla y utilizarla para entrar en su cuenta.
Estos ataques de hijacking se han hecho de forma “artesanal” habitualmente, o con herramientas personales, como el caso de nuestra Grifa, pero desde que se presentó en ToorCON la herramienta Firesheep, esto se convirtió en un juego de niños. En Seguridad Apple publicamos un ejemplo de cómo realizar hijacking a cuentas de Tuenti con Firesheep.

Figura 9: Uso de Firesheep con Tuenti

Redes sociales como Facebook y Twitter, desde la aparición de herramientas automatizadas como Firesheep permiten a los usuarios que todas las conexiones vayan cifradas con HTTPS, eliminando muchos de los issues que aparecen en esta serie.

Issue 11: No firmado de parámetros en cookie

El uso de Firesheep a la hora de robar una sesión, siempre suele ir asociado a un ataque en la misma red. Sin embargo, si la cookie es robada por una vulnerabilidad de XSS, tal y como ya se ha visto en muchas ocasiones, haría que el ataque de hijacking se hiciera remotamente, es decir, desde otra red remota. Para evitar esto, las aplicaciones web utilizan firmado de parámetros de cookie que identifican la posición de la conexión original, para identificar cuando ha sido robada.

Por ejemplo, un cambio en la dirección IP de una conexión puede producirse por muchas causas, tales como una renovación en el DHCP o un cambio en la configuración del operador de servicios de Internet durante la conexión, pero también puede significar un robo de la cookie y una conexión fraudulenta.

Debido a esto, muchos de los servicios web en Internet optan por restringir las cookies a las direcciones IP de las conexiones, o incluso cifran características propias del navegador que se usa en la conexión. De esta forma, aunque no se reduce el riesgo total, sí que se consigue que los ataques de Hijacking se limiten a zonas de ataque cercanas.

En el caso de Tuenti esto no es así, y basta con robar la conexión para poder crear una cookie que permita el acceso desde cualquier sitio. Se podría poner una sonda en cualquier “red insegura” capturando las cookies de Tuenti. Luego enviar esas cookies a otra ubicación y crear una nueva sesión con ella.

Figura 10: Captura de cookie de Tuenti con Wireshark

Con cualquier complemento para gestión de cookies, como por ejemplo Cookie Editor para Google Chrome o Firefox, se crea una nueva cookie con el nombre sid, en el campo valor se copia el valor capturado en sid, el dominio será .tuenti.com y el path /.

Figura 11: Cookie Editor haciendo cociando una galleta de Tuenti

Una vez añadida la cookie es suficiente con ir a la página de tuenti.com y se entrará directamente en la cuenta de la víctima. El resultado es el siguiente:

Figura 12: Dentro de la cuenta

Esta demo es cortesía de mis amigos de Flu-Project }). Como curiosidad, las cookies del tuenti móvil, aunque se llaman de forma distinta, permiten realizar exactamente lo mismo, y se pueden usar en las conexiones desde equipos de escritorio.

Issue 12: Imágenes de pefiles estáticas

Tuenti utiliza servidores de la red Tuenti.Net para almacenar las fotos que los usuarios suben a la red. No hay ninguna protección extra más allá que saberse el nombre del fichero de la foto, con lo que basta con saber el nombre de la foto como para hacerla pública a todo el mundo. En este ejemplo, el link a una foto de un amigo mío en Tuenti.

Issue 13: Configuración insegura de robots.txt frente a Google

En teoría, la mayoría de los servidores de Tuenti.net tienen configurados los servidores web con un robots.txt que prohibe la indexación de los contenidos. Sin embargo, saltarse el fichero robots.txt no es complicado, y a veces, es tan sencillo como poner links de forma correcta. Así, a pesar de que tengan configurado ficheros robots.txt restrictivos, como el caso de del servidor http://ll3.images.tuenti.net/robots.txt, resulta que sus contenidos acaban indexados.

Figura 13: Contenidos de tuenti.net indexados

Además, esto pasa con muchas fotografías que quedan indexadas en Google. Es por esto que sería necesario utilizar un dispatcher de fotos que compruebe la sesión del visitante de la foto. En este caso, subir una foto a Tuenti es hacerla pública.

Google ofrece herramientas para Webmasters para eliminar de la caché todo lo que no deba ser indexado. En esta captura se ven imágenes, aplicaciones y servidores web con configuraciones por defecto.

Por último sobre este tema, es curiosa la protección contra el Http-referer de Google, es decir, que si alguien viene desde Google no se le deja ver la página, pero basta con recargar la página para evitar el HTTP-Referer y la imagen sale. No entiendo bien la protección que han puesto ya que Http-referer no es necesario para hacer un GET.

Figura 14: Referer prohibido

[LUK]

Cuando comencé con la serie de Tuenti Security Issues recibí muchos ofrecimiento de colaboración, hoy os dejo 4 issues de @luisdelgadoj.

Issue 14: Privacidad en los vídeos de Tuenti

El sistema que utiliza Tuenti para acceder a los metadatos de un video (y su reproducción) es a través de la API MediaPlayer, obteniendo la información a través del método getMetaDataById. El identificador del video es secuencial por lo que es trivial obtener los datos de cualquier video. Por lo tanto, independientemente de que los videos sean públicos en YouTube, tener en cuenta que es más fácil procesar los 4.100.000 que hay indexados en Tuenti. La petición es la siguiente:

[post] http://www.tuenti.com/api
{"session_id":"SID","version":"mediaPlayer-0.1","requests":[["getMetaDataById",{"internalId":ID}]]}

A pesar de lo anterior, que podría ser considerado como una anécdota pues no podemos identificar al dueño de dicho vídeo, ¿podemos considerar nuestros canales/listas de reproducción como algo privado solo accesible a nuestros amigos?

Cual ha sido mi sorpresa al comprobar cómo podemos acceder a los vídeos de los canales de cualquier usuario de Tuenti sea éste nuestro amigo (lógico), o un desconocido con perfil público o privado.

Las peticiones son las siguientes:

Obtener los datos de los canales del usuario:Podemos acceder a los thumbs de los canales y el número de vídeos contenidos en éstos.

http://www.tuenti.com/?m=Search&func=get_playlists&page_key=7_USERID&ajax=1

Obtener todos los videos contenidos en un canal:

http://www.tuenti.com/?m=Video&func=view_videos&collection_key=15-USERID-0ajax=1

Así, si quieres ver los datos de los vídeos que han subido alguien, averigua su USERID y listo.

Issue 15: El cambio de nombre

Limitan el cambio de nombre a dos por año pero la validación es nula, y lo que hacen es no enviarte el formulario de cambio pero si guardas la petición y la replicas cuando la necesites puedes cambiarlo cuantas veces quieras. La petición es la siguiente:

[post] http://www.tuenti.com/?m=Settings&func=process_change_name&ajax=1 csfr=CSFR&first_name=FNAME&surname=SNAME

Issue 16: La API y sus XSS de libro

Es curioso que nos encontremos en la API de Tuenti (activas desde por lo menos la versión 0.5 hasta la actual 0.7.1) vulnerabilidades de XSS “de libro”. Si se muestra un error con el código que ha introducido erróneamente el usuario, ¿no debería sanitizarse primero para evitar que pueda ser explotado? Aquí tenéis algunos ejemplos: 

Figura 15: Un XSS en la API

Figura 16: Otro XSS en la API

No es difícil encontrar más errores de este tipo en la API, además, hasta hace poco los estados de los usuarios eran considerados como un dato público, con el peligro que conlleva (p.e se podía obtener el código pin del BBM de muchos usuarios, que lo ponían en su estado pensando que solo podrían verlo sus amigos).


Issue 17: También hay XSS de los de toda la vida sin validación XSS

Como hemos podido observar en la Issue 16, los XSS de la API necesitan tener un SessionID válido para ser ejecutados. Puesto que Tuenti es una red social cuyo registro funciona por invitación, no podemos crear una cuenta fantasma y utilizar un SessionID de la misma (sería fácilmente traceable) por lo que habría que obtener uno. Como Tuenti sigue sin dar la opción de utilizar SSL, es trivial acceder a la cuenta de cualquier usuario que estuviera utilizando una red insegura y mandar una invitación a un email fantasma (vamos, ninguna complejidad si se quiere explotar).

Aun así, como era de esperar, no ha sido complicado obtener un XSS sin esta limitación, encontrándose otra vez en la API. Si introducimos una petición errónea, la API muy amablemente nos avisa del error cometido, por supuesto sin sanitzar.

Como podéis comprobar, la política de seguridad en el desarrollo de la API en cuanto a XSS brilla por su ausencia. Hemos decidido no hacer públicas las URLs explotables por XSS, aunque sean por POST y hagan difícil su explotación, porque están aún activas y esperamos reportarlas para que las corrijan.

[LUK]

Aprovechando que ayer publicaron en Security By Default TuentiDump para hacer backup de una cuenta Tuenti una vez comprometida su seguridad, voy a dejar zanjada esta serie dedicada a la red social de los más jóvenes.

Como dije al principio, está dedicada a issues de seguridad que siempre pueden mejorarse, porque la mejora continua de los servicios hace mejor las cosas. Así que, por favor, que nadie se tome esta serie cómo que Tuenti es insegura (aunque me siga pareciendo que lo del SSL tienen que arreglarlo cuanto antes porque abre infinitos vectores de ataque).

Issue 18: Descuidos en IT. Un proxy abierto al exterior

Una de las cosas que más me llamó la atención fue la de descubrir que en una de las direcciones IP de Tuenti había publicado un servidor Proxy que estaba abierto al exterior, lo que abre nuevas posibilidades de conectarse desde fuera a la red interna.

Figura
17: Un proxy al que conectarse desde Internet

El proxy ya está cerrado y tenía cierto control de acceso pero, como puede verse, además daba información de un dominio interno usado por la compañía para su red, lo que ayudaría a buscar cosas dentro en caso de un ataque dirigido. Buscando por Internet, es fácil casi hacerse con el nombre de muchos de los equipos internos de ese dominio, lo que ayuda a tener una visión clara de la red de Tuenti desde fuera.

sw33ext.tuenti.int - sw35ext.tuenti.int [95.131.168.14] - proxy2.tuenti.int [95.131.171.193] - sw11ext.tuenti.int [95.131.171.194] - sw12ext.tuenti.int [95.131.171.195] - sw3ext.tuenti.int [95.131.171.196] - sw14int.tuenti.int - sw16ext.tuenti.int - sw10ext.tuenti.int - sw25ext.tuenti.int -sw38ext.tuenti.int - sw17ext.tuenti.int - sw4ext.tuenti.int - sw7ext.tuenti.int - estaticos.tuenti.int - hades.tuenti.int [172.30.0.210]

He puesto los que aparecen en Google en una búsqueda rápida, pero además, una vez vistos los nombres y las direcciones IP es fácil predecir muchos de los que faltan.


Issue 19: Leaks de IT, Admins y Mega-Admins en Tuenti

Una de las tareas que realicé durante esta serie es la de trabajarme un poco la fase de footprinting del dominio. Así, busque direcciones de correo electrónico de miembros de Tuenti, especialmente de miembros que trabajase en IT o personajes públicos, para buscar lo que preguntaban en foros. Así, por las preguntas que realizan y los datos datos que envían en los foros, es posible descubrir cómo está montada la CDN de la red, o qué problemas tenían con los servidores.

Sin embargo, el que más me llamó la atención fue este pedazo de conversación que me envió un lector anónimo y pelirrojo en el que se puede ver quiénes son administradores de Tuenti (espero que no se conecten por redes inseguras a su perfil) y que, además, utilizan la misma red social, pero con alguna visibilidad más privilegiada para administrar las cuentas.

Figura
18: Conversación de admins en tuenti

Quizá falta una política de concienciación mayor entre los empleados de lo que se puede publicar o no sobre la infraestructura y la seguridad de la empresa.


Issue 20: Relación inmadura con los buscadores de vulnerabilidades

He querido dejar para el final este issue, pero no por eso es menos importante, sino al contrario. Durante los dos últimos años he tenido varias conversaciones con distintos expertos en seguridad que han reportado en un momento u otro vulnerabilidades a Tuenti. Todos coinciden en que la relación es muy difícil. Supongo que las empresas tienen que madurar en seguridad para entender que alguien que reporta un fallo de seguridad lo hace con la mejor de las intenciones y que lo último que hay que hacer es responder o tratarle mal.

Cuando un investigador reporta una vulnerabilidad, las empresas que han madurado estas relaciones, tienen un trato controlado, constante, y agradecido. Así, empresas como Nokia hacen regalos, Facebook paga a los investigadores de seguridad y Apple o Microsoft reconocen el esfuerzo de los investigadores en los parches de seguridad.

Tuenti no hace eso aún. No está maduro en esas relaciones, lo que hace que se estén dejando de reportar vulnerabilidades y pone en mayor riesgo a los usuarios de la red. Sin embargo, tras conversaciones mantenidas con Sebas Muriel de Tuenti, se que es algo que quieren trabajar desde ya, y crear un canal más amable para los investigadores.

Espero de corazón que esta red social siga creciendo, mejorando, y aumentando el número de registrados a nivel mundial, y que, de una vez... alguien me envíe una invitación para sacarme cuenta en Tuenti.


Saludos Malignos! @ http://www.elladodelmal.com