Tuenti Security Issues (III de V)
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
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 perfiles 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
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
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.
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.
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:
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 perfiles 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.
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.
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
3 comentarios:
sabes? buscando las bromas de Boca sobre RiBer Plate (Palerrrrmo) encontre un post tuyo y me encanto, ahora estoy viendo casi todas tus entradas y me parecen geniales.
Saludos.
Uhm... Hace tiempo hice unas pruebas sin ningún ánimo perverso sino para probar conceptos ya que el dueño estaba presente...
Y al "copiar" las cookies de una sesión abierta llegaba a entrar en dicha cuenta de Tuenti pero no paraba de recargarse sin que me dejara ver más allá que la parte superior de su página principal ni pulsar ningún enlace (debido a la continua recarga).
Tan solo tengo la duda de si eso es debido al navegador (SeaMonkey), aunque lo dudo, también me ha pasado en otras páginas; o es por alguna cosa de dejara en el tintero.
¿He de decirle a mi amigo el "pseudofracaso" de que se mantenga recargando todo el tiempo no es tal?
El primer enlace que figura en la imagen de arriba ha sido indexado porque está publicado en un blog con la dirección de Tuenti.
Publicar un comentario