Luis Delgado

XMPP, algo más que chat (2/2)

Mon, 28 May 2012 12:27:00 +0200

Siguiendo con lo comentado en la entrega anterior, en esta segunda parte lo que voy a comentar es la parte práctica relacionada con Tuenti y, en mayor medida, Google Talk.

Con respecto a Tuenti, comenté que podíamos aprovechar que la operadora Tuenti Tu nos ofrecía navegación móvil gratuita por la red social (creo que ya no es así, necesitas hacer recargas todos los meses) para tunelizar nuestro tráfico a través de XMPP y que, por tanto, éste tuviera como “primer destino” los servidores de Tuenti y, por tanto, que entrara dentro de las condiciones del servicio gratuito.

Las aplicaciones para la prueba de concepto las desarrollé en Java por lo que el rendimiento es bastante pobre (la idea era probarlo en Android, y por comodidad desarrollé directamente todo en el mismo lenguaje), así que, del siguiente esquema, realmente lo que nos interesa es el retardo con los servidores de Tuenti (~130ms) que sería con lo que tendríamos que jugar para aumentar el rendimiento del servicio (p.e más de una petición por cada comunicación XMPP).

Este concepto de tunelización no es nada nuevo, y son de obligada mención otros desarrollos del estilo como la tunelización a través de Facebook (Facecat de Jose Selvi), MSN o Skype, proxy a través de Google Spreadsheet o Facebook, etc.

Visto esto, pasemos a la parte de Google Talk.

Antes de empezar, comentar que todo lo descrito a continuación se basa en la realización previa de una ataque man-in-the-middle y que sólo se analizan las opciones/servicios ofrecidos de forma oficial por Google.

¿Qué vectores de ataque podemos encontrar en Google Talk? Pues antes que nada, hay que ver qué formas de acceso al servicio nos pone a nuestra disposición Google. En este caso, nos encontramos la aplicación para dispositivos Android, el formato móvil (Talk Gadget) y la aplicación de escritorio.

Lo primero que se nos puede ocurrir es ver si realmente todas ellas cifran el tráfico… (por eso anteriormente no he nombrado la implementación de GTalk en GMail, cuya comunicación ya va cifrada). Analicemos cada una de las situaciones.

Dispositivos Android
En este caso podemos comprobar como cifran la comunicación desde el primer momento (ya entenderemos luego a qué me refiero), por lo que no nos interesa (y podemos estar ‘algo más tranquilos’).

Formato móvil
En un primer momento el tráfico no se cifraba por lo que, al tratarse de un servicio de Google sin SSL por defecto, podíamos iniciar sesión en el servicio capturando la cookie no-ssl de la sesión del usuario (explicado en el post anterior). Actualmente ya obliga a que el tráfico se cifre por lo que quedaría descartada (en ningún momento se pretende hacer ninguna suplantación de certificados, la clave es que sean técnicas totalmente transparentes).

Aplicación de escritorio
En este caso ocurre una situación curiosa porque sólamente la versión inglesa cifra el tráfico (y ya veremos que en XMPP es una medida insuficiente) por lo que todos aquellos que se descarguen la versión en su idioma directamente tendrán todo el tráfico en texto claro. Por lo tanto, será en este caso en el que nos centraremos.

Además, cabe destacar que hace unas semanas Google publicó una extensión para Chrome que permite utilizar Google Talk sin tener abierto el navegador. En ese caso, junto con la implementación en Gmail comentada anteriormente, no se tiene en cuenta por ser un servicio BOSH a través de SSL.

Vistos los tres vectores de ataque… ¿a qué nos enfrentamos?

La cadena de conexión

[stream:features][starttls xmlns=”urn:ietf:params:xml:ns:xmpp-tls”][required][/required][/starttls][mechanisms xmlns=”urn:ietf:params:xml:ns:xmpp-sasl”][mechanism]X-GOOGLE-TOKEN[/mechanism][mechanism>X-OAUTH2[/mechanism][/mechanisms][/stream:features]

<auth xmlns=”urn:(…):xmpp-sasl” mechanism=”X-GOOGLE-TOKEN”>(…)</auth>

Como podemos ver, la autenticación se hace a través de un token obtenido a partir del servicio ClientLogin. Podríamos pensar que se trata de un token de un sólo uso pero a parte de no cumplirse eso, además tiene un timeout bastante generoso. Por lo tanto, si se accediese al proceso de autenticación obtendríamos un token válido de la sesión del usuario generado para el servicio mail. Por suerte, actualmente ese tipo de token tiene restringido el acceso a ‘sólamente’ el feed de Gmail, por lo que sólo tendría permisos de lectura de los snippets/resúmenes de los correos no leídos (aunque veremos más adelante que no es así).

Siguiendo con el tema de la conexión, podemos observar que es el servidor el que le indica al cliente qué mecanismos de autenticación tiene habilitados, pero… ¿podríamos forzar la autenticación en claro (mechanism=’PLAIN’)? A pesar de que los servidores de Google nos rechazarían la autenticación por no soportar esa opción, podríamos obligar (debido al ataque MiTM para el cliente somos nosotros el servidor XMPP) que el cliente utilice ese mecanismo y, la aplicación de escritorio, en ningún momento rechaza esta situación (y debería por tratarse del cliente oficial, que debería evitar que los credenciales se utilicen fuera de la autenticación por ClientLogin que sí que utiliza SSL).

Continuando por este camino, si nos fijamos vemos que el servidor obliga al cliente a iniciar una comunicación cifrada (starttls required) pero, ¿es un requisito también del cliente?. Sabiendo que las versiones no-inglesas no cifran el tráfico ya sabemos que no pero aún así, si forzáramos al cliente a no cifrar la comunicación éste no lo rechazaría y, por tanto, podemos volver a forzar al cliente a que se comunique bajo los requisitos de nuestra pasarela.

Para estas acciones desarrollé una pequeña aplicación (cuyo enlace al ejecutable/código está al final del post) que simplemente abre dos sockets, uno para el cliente (a modo de servidor) y otro para Google (a modo de cliente). Aprovechándose de un ataque DNS-Spoofing (desarrollado junto al ataque MiTM) las conexiones del cliente al dominio talk.google.com irán a parar a nuestra pasarela que enrutará a los servidores de Google previa manipulación en base a los filtros que hayamos utilizado. Viendo más en detalle los filtros quedaría:

Obtención de los credenciales del usuario de forma transparente
Cuando el usuario inicia la conexión, en la respuesta del servidor se reemplaza el mecanismo X-GOOGLE-TOKEN por PLAIN (o se eliminan todos y se añade éste último). De esta forma, en la respuesta del cliente obtendremos codificado en base64 su usuario y su contraseña. Con estos datos se genera un token a partir del servicio ClientLogin y se envía la petición correcta a Google estableciendo como mecanismo X-GOOGLE-TOKEN y en base64 el usuario y token generado (realmente el usuario lo obvia y autentica en base al token); a partir de aquí el resto del tráfico se enruta sin modificaciones. De esta manera, de forma totalmente transparente al usuario, éste se autentica pero nosotros obtenermos sus credenciales de Google.

Evitar el cifrado de la comunicación
En este caso, cuando el usuario inicia la conexión, en la respuesta del servidor se elimina el tag starttls forzando al usuario a no cifrar la comunicación. Puesto que Google lo permite en sus servidores (aunque lo mande como obligatorio, luego no lo exige) no es necesario que la comunicación de la pasarela con los servidores sea cifrada.

Como podéis ver, con dos técnicas sin ciencia alguna (y apoyadas en el ataque MiTM, más que conocido) es posible obtener en claro toda la comunicación XMPP aunque se fuerze a cifrarla y, lo que es más grave, conseguir las credenciales de la cuenta (por una mala gestión, en el cliente, de los mecanismos permitidos). No nos olvidemos que, al tratarse siempre de clientes oficiales, éstos no tienen que tener configuraciones globales, sino las adaptadas al único servicio que soportan (y habrá casos que se puedan entender, pero estos dos deberían estar contemplados).

Rizando algo más el rizo, en el post anterior comentábamos cómo XMPP es un protocolo muy ‘extensible’, permitiéndo implementar funcionalidades adicionales de una forma muy sencilla (normalmente a través de las stanzas IQ). Por este motivo, ¿qué más cosas se pueden hacer con una sesión de Google Talk?

Si acudimos a la página de desarrolladores de Google Talk podemos encontrarnos con extensiones de acceso al correo y de manejo de contactos (entre otras).

En el caso del correo, antes comentábamos que el token generado para el servicio mail nos permite acceder únicamente al feed de gmail (correos no leidos). Si observamos, en este caso a través de XMPP también podemos acceder a los snippets/resúmenes (y con información más detallada del mensaje). Lo peligroso del tema es que en este caso se nos permite realizar búsquedas (como las que realizamos desde Gmail) por lo que podemos utilizar parámetros como ‘in:anywhere’ para obtener todos los correos, ‘in:chats’ para acceder a conversaciones guardadas, y todo lo que se nos ocurra.

En el caso de los contactos, puesto que el roster del chat está ligado con este servicio, podemos acceder a todos los contactos de la cuenta (estén o no en nuestra agenda de Gtalk) y, además, si forzamos la subscripción con alguna cuenta lo que estaremos haciendo paralelamente es añadir esa cuenta a los contactos del usuario (p.e podría resultar útil para futuro spam, pudiéndose utilizar diferentes técnicas para ‘ocultar’ el remitente). De esta forma, en este caso no nos limitamos a una situación ‘read only’ como con los correos sino que podemos incluso gestionar los contactos de la cuenta (añadir registros, bloquear usuarios, etc).

En este video podéis ver la demo con todo lo explicado anteriormente:
https://www.youtube.com/watch?v=Fj5kbwqXsqY

Visto ya todos los ‘descuidos’ que nos podemos encontrar en la aplicación oficial de Google Talk para escritorio, si vamos un paso más allá podemos comprobar como no cifra el tráfico ni para comprobar las actualizaciones por lo que, a través de otro DNS Spoofing podríamos manipular la respuesta a esa consulta. Si bien parece que firma las peticiones, no tengo del todo claro si lo que firma es el ejecutable de la nueva versión (y en caso contrario podríamos forzar la instalación de malware en el equipo) o la respuesta en sí (que en caso contrario podríamos manipular los comandos que se ejecutan con la instalación de la actualización).

Y esto es todo. Espero que haya resultado cuanto menos curioso (que era el objetivo) y que nos quedemos con la idea de que es importante securizar hasta el servicio más pequeño (como en este caso el chat) porque sino, a través de él, es posible comprometer servicios críticos como es el caso de Gmail o Google Contacts (o en el caso del robo de credenciales, la cuenta completa de Google).

Directorio de la aplicación (la descarga aún no está habilitada):
http://www.ldelgado.es/?xmpploit

Podéis acceder a las slides de la presentación (en PDF) aquí

XMPP, algo más que chat (1/2)

Tue, 17 Apr 2012 10:19:07 +0200

Hace ya más de un mes desde la RootedCON 2012 y aún no había publicado un resumen de lo que comenté en la charla y la aplicación que utilicé para hacer las pruebas de concepto con Google Talk, asi que ya era hora…

Como dije en la charla, no voy a centrarme en explicar el protocolo XMPP, simplemente decir que tiene estructura XML, basado en conexiones TCP de larga duración (en el caso de HTTP sería BOSH, utilizando un elemento intermedio denominado ‘Connection Manager’ que hace la traducción de la comunicación HTTP a XMPP) y con intercambio asíncrono de información.

Los mensajes XML que se intercambian entre entidades se denominan stanzas y existen tres tipos, siendo a grandes rasgos:

Message: enviar mensajes de una entidad a otra, pudiéndose organizar en ‘threads’
Presence: es la forma básica de broadcast entre una entidad y todos sus subscriptores (anunciar la disponibilidad, permitir que un usuario pueda contactar con otro, etc)
IQ: permite intercambiar información entre entidades (ya sean clientes o servidores). Aquí cabe destacar la presencia de las extensiones.

Si alguno está interesado en profundizar en el protocolo, os recomiendo el libro XMPP: The definitive guide, completo e interesante.

En este primer post me voy a centrar en un breve resumen de la parte correspondiente a la seguridad en el protocolo. En el próximo hablaré de los casos prácticos

Antes de nada, comentar que la seguridad se ha tomado como un pilar importante desde la propia definición del protocolo (al igual que la privacidad). Además, cabe destacar que, desde 1999, se han reportado pocas vulnerabilidades y ninguna de ellas ha sido crítica (es decir, a nivel de código).

¿A qué nos enfrentamos?

Básicamente nos podríamos encontrar rogue servers, address spoofing, ataques de denegación de servicio, spam y phising, fuga de información, almacenamiento indebido de logs, fallos a nivel de código…

Entrando algo más en detalle en alguno de los vectores de ataque comentados anteriormente:

1. Comunicación cifrada (TLS-SSL):

Hay dos tipos de comunicaciones, las que interviene cliente y servidor y aquellas en las que la comunicación es entre los servidores de los dominios de las entidades que se comunican (la conexión es directa, el tráfico no pasa por servidores intermedios). A pesar de ésto, nadie nos garantiza que no se guarden logs de las conversaciones (aunque se pueda especificar en las preferencias de cada usuario y que los clientes deberían tener en cuenta) por lo que es siempre recomendable optar por cifrado ‘end-to-end’ (p.e PGP).

2. Autenticación e identidad

Una de las ventajas en cuanto a la lucha contra el address spoofing es que la etiqueta ‘from’ no se tiene en cuenta a la hora de manejar las stanzas (es el servidor el que la asigna, por lo que en el caso de que se haya utilizado una ésta es sobreescrita con el identificador correspondiente a la sesión activa).

Con respecto a la comunicación entre servidores, ya hemos dicho antes que ésta se realiza sin saltos intermedios (p.e si se comunican los usuarios luis@server1 y manuel@server2, la comunicación se establece directamente entre server1 y server2) pero… ¿es posible suplantar la identidad en esa comunicación?. Dejando de lado las posibilidades de un ataque en una misma red, los servidores destino comprueban la identidad a través de un sistema/protocolo denominado ‘dial-back’ que, a grandes rasgos, consiste en un intercambio de tokens que se comprueba con el servidor raiz de ese dominio (resolución DNS) y, en función de que éste de el visto bueno con respecto al token entregado por el servidor emisor del mensaje, se valida la comunicación o no. De esta forma, si el token entregado a la hora de establecer la comunicación no es validado por el servidor raiz del dominio, el servidor destino rechaza la conexión.

Además, no hay que descuidar el tema de la codificación. Puesto que XMPP trabaja con el set de caracteres unicode, recae en el cliente la gestión ‘segura’ de estos para evitar casos como paypal.com <-> paypa1.com o el caso de la a <-> a(cirílica).

3. Spam

Debido al sistema de subscripciones que incorpora XMPP ya no es posible, como ocurre con el correo electrónico, mandar mensajes a entidades arbitrarias puesto que primero ésta tiene que autorizarnos esa comunicación (presence - subscripción). Por este motivo, el spam en XMPP no es rentable y hace que no se explote como en otros servicios.

Además, incorpora un límite de envíos en un tiempo determinado (si bien es recomendable acompañarlo con sistemas de tipo Captcha para evitar la creación automática de cuentas).

Al final, vistas algunas de las medidas de seguridad que implementa el protocolo podemos intuir que las vulnerabilidades se encontrarán probablemente en la implementación que hagan de él (autenticación, cifrado…) y los clientes que lo utilicen (gestión de las subscripciones, ataques en redes locales…).

Antes de terminar, voy a aprovechar para comentar un tema que nos servirá para entender uno de los vectores de ataque del próximo post.

Como sabréis, Google nos permite autenticarnos en todos sus servicios con sólo introducir una vez las credenciales a través Google Accounts. Por comodidad resulta un comportamiento muy interesante pero, por el mero hecho de sólo introducir las credenciales una vez, estamos almacenando en nuestro explorador una/s cookie/s que funcionan a modo de llave maestra en todos los servicios ofrecidos por Google (que son muchos y algunos bastante críticos).

Si nos fijamos más en detalle en esas ‘llaves maestras’ podemos ver, a muy grandes rasgos que se tratan de dos conjuntos de cookies, las que denominaremos No-SSL y SSL. El porqué de estos dos grupos tiene su explicación en que, en Google, tenemos dos tipos de servicios, los que ofrecen navegación utilizando SSL por defecto y los que son a elección del usuario (y por tanto, permiten ambas situaciones). Por lo tanto, es fácil intuir que la llave maestra No-SSL se utilizará para acceder a los servicios que no obligan a utilizar SSL y la llave SSL que permite acceder a todos los servicios (con SSL por defecto o sin él).

Por lo tanto, aquí nos encontramos con un problema puesto que las cookies No-SSL se intercambian en conexiones no cifradas (accesibles de forma trivial a través de un ataque MiTM) y que el tráfico hacia el dominio ‘google.com’ es excesivamente común (aunque no sea directo), por lo que, sin navegar expresamente por servicios de Google, estamos ‘compartiendo’ esas cookies con la red de forma bastante habitual.

Ahora bien, ¿qué servicios no utilizan SSL por defecto?. Si acudimos al listado proporcionado por Google en su sección de productos veremos que son la minoría (p.e Picasapero que, curiosamente, hay hasta servicios delicados como Youtube o Blogger (y ya podemos imaginar cuanto daño puede hacer a una persona con presencia en la red un ataque a esos servicios) y otros como Picasa, Google Code o Google Groups.

Para evitar, en cierta medida, esta situación, es recomendable utilizar extensiones en el navegador que fuercen el uso de SSL, como puede ser HTTPS Everywhere (Firefox y Chrome).

Vista esta pequeña introducción, en la próxima entrega comentaré el caso de Tuenti y la tunelización de tráfico a través de XMPP y el caso de Google Talk y los ataques que se pueden hacer a los usuarios de su cliente de escritorio (en redes locales, previa realización de un man-in-the-middle y dns spoofing).

Entrevista al equipo de Backend de Tuenti

Sat, 31 Mar 2012 18:41:00 +0200

Mucho se ha hablado en Security by Default sobre redes sociales (en mi caso, centrándome siempre en Tuenti) y siempre hemos tenido solamente una visión, la nuestra. Se me ocurrió hace unos meses que podía ser interesante organizar una entrevista con el equipo de Backend de Tuenti (evitando a departamentos de comunicación) y que nos contaran, desde la perspectiva de la seguridad, el funcionamiento interno de la red social. En un primer momento iba a ser una entrevista en video pero voy a estar unos meses ‘fuera de combate’ asi que
hemos optado por la opción clásica.

Agradecer a Guillermo Pérez (@bisho), responsable de Backend y Seguridad, todas las facilidades que ha puesto para poder llevar a buen puerto la entrevista. Todos los que hayáis reportado alguna vez una vulnerabilidad habréis tratado con él, y a los que no, deciros que el trato recibido siempre ha sido ejemplar (y eso que no siempre hemos coincidido y hemos tenido algún que otro roce… :D). Agradezco también a Chema Alonso (@chemaalonso) por las preguntas que me propuso.

La entrevista la estructuré en cinco partes, seguridad del lado del equipo de desarrollo, del de la empresa, acerca del reporte de vulnerabilidades, seguridad/privacidad y finalmente un par de ‘offtopic’.

Podéis acceder a ella en el post de SbD o en el PDF.

XSRF en Gmail

Mon, 16 Jan 2012 09:13:31 +0100

Hace unos meses reporté a Google un XSRF en su servicio de correo (Gmail). Creo que ya comenté en su día por donde iban los tiros pero no me centré en los detalles del mismo.

¡Comencemos!

Google ofrece un servicio feed en formato atom para acceder a los correos sin leer de nuestra bandeja de entrada y etiquetas. La dirección en cuestión es:
https://mail.google.com/mail/feed/atom/(etiqueta)

Cual fue mi sorpresa cuando me di cuenta de que no se validaba correctamente la etiqueta a la que se intentaba acceder, pudiendo “crear” feeds de etiquetas inexistentes y, por tanto, crear dichas etiquetas en la cuenta del usuario.

Por lo tanto, bastaba con acceder a un link con una etiqueta con nombre arbitrario para poderla crear en la cuenta del usuario que lo ejecutara.

Un ejemplo:
https://mail.google.com/mail/feed/atom/publicidad
<img src=”https://mail.google.com/mail/feed/atom/publicidad” />

Algunos vectores de ataque podrían ser:

1. Publicidad: como las etiquetas que se crean por defecto se muestran (o mostraban en la interfaz antigua) en el panel lateral, podías inyectar publicidad.

2. “Broma pesada”: para eliminar las etiquetas es necesario hacerlo de forma manual (de una en una) por lo que se podía crear un script que generara miles de etiquetas en la cuenta del usuario.

A la hora de notificarlo al security team de Google (podéis acceder al formulario a través de goo.gl/vulnz) tuve que intercambiar con ellos varios correos asi que, finalmente, hice un ‘screencast’ con todo el procedimiento:

Video:
https://www.youtube.com/watch?v=2PqEKDaMwpM

¡Y hasta aquí todo!

XSS en Google Code

Sat, 17 Sep 2011 14:22:00 +0200

Accediendo a la página de Damn Vulnerable Web App (DVWA) de Google Code me ha saltado el típico MessageBox que se utiliza cuando se descubre un XSS [alert(‘XSS’)]. Sorprendido, me he puesto a mirar el código para comprobar dónde estaba la vulnerabilidad.

Si nos fijamos, vemos que en la descripción del proyecto se carga (sin contenido) un gadget. La inyección se realiza a través de un iframe que apunta hacia la página Google User Content que se encarga de mostrar el gadget a través de su fichero XML con su especificación.

http://code-opensocial.googleusercontent.com/gadgets/ifr?url=http://www.ethicalhack3r.co.uk/spam/test1.xml

Si accedemos al fichero XML vinculado podemos ver lo siguiente:

<Module>
     <ModulePrefs author="Project Hosting Team" (...)>
          <Require feature="flash"/>
     </ModulePrefs>
     <UserPref datatype="string" name="video"/>
     <Content type="html">
          <script>alert('XSS');</script>
     </Content>
</Module>

Por lo tanto, basta con crear un fichero de especificación con un contenido cualquiera e introducirlo en la descripción de un proyecto de Google Code (o donde se permita incluir Gadgets de Google).

Un saludo!

REF: API de Google Gadgets

Spameando a la SGAE que es gerundio

Tue, 05 Jul 2011 11:28:02 +0200

Antes de nada, ¡¿por qué es obligatorio introducir las ‘www’ para acceder a su web?!… Como odio las páginas que me obligan a escribirlo y no basta solo con el dominio…

Bueno, si nos metemos en la página de la SGAE (no se qué motivo podríamos tener, seguro que ninguno bueno) vemos que en la cabecera tenemos un enlace llamado SGAE Responde que nos permite acceder a un formulario de contacto. Ayer no funcionaba (¿lo habrían deshabilitado cuando detuvieron a Teddy?) pero hoy si.

Si nos fijamos, podemos ver que utilizan el plugin CForms para Wordpress con el captcha habilitado para evitar spameos indiscriminados (salvo que tengamos mucho tiempo libre :P). El captcha en sí es bastante complejo, pues permite variar fondos, la tipografía, el color, la inclinación, etc. Aun así, he descubierto que es bastante sencillo saltarselo…

Bueno, antes de seguir simplemente decir lo de siempre… ¡no confies en el usuario!, ¡la configuración del lado del servidor!, ¡valida todo lo que te llegue del cliente! y un largo etcétera…

¿Donde está el fallo? Bien, si nos fijamos, el captcha no nos lo da el propio formulario con un token para su verificación (y que no pudiese repetirse claro) sino que nos da la siguiente URL a la imagen del mismo:

http://www.sgae.es/wp-content/plugins/cforms/cforms-captcha.php?ts=&c1=4&c2=5&ac=abcdefhijkmnrstuvwxyz23456789&i=i&w=115&h=33&c=FFBB00&l=DBDBDB&f=font4.ttf&a1=-15&a2=15&f1=17&f2=19&b=1.gif

Como podéis observar el captcha nos lo entrega cforms-captcha.php cuya configuración se encuentra en la propia petición. Es lógico pensar que al hacer una petición al captcha asocia el que te devuelve con tu sesión y al hacer submit al formulario hace la verificación. Por lo tanto, cambiemos la url del captcha por:

http://www.sgae.es/wp-content/plugins/cforms/cforms-captcha.php?c1=1&c2=1&ac=0

En este caso le estamos obligando a cforms-captcha.php a que nos genere un captcha de un único valor (parámetros c1 y c2) y que además éste solo tome el caracter 0 para su generación (parámetro ac).

Por lo tanto, para automatizar el envio de mensajes ‘de consulta’ a la SGAE bastaría con hacer una petición al formulario, otra al captcha (con la misma cookie) y al enviar el formulario poner como valor del captcha ‘0’.

Ya para terminar, decir que el fallo es del plugin, no de la implementación de la SGAE del mismo, pero no deja de ser curioso. Utilizan la versión 11.7.1 del plugin (como podemos ver aquí) aunque la última versión (la 11.9) parece también vulnerable (he mirado el código y acepta la configuración como parámetro).

Curioso XSS en Peliculas(Series) Yonkis

Mon, 20 Jun 2011 20:13:00 +0200

Hoy estaba descargandome un capítulo de Fringe cuando me he fijado en la url de la página “puente” de Peliculas/Series Yonkis cuando descargas desde Megaupload.

La url del enlace tiene el siguiente formato:
http://www.seriesyonkis.com/lista-series/descargar/n/0/?id=%C7%C7%B7%CD%B5%B2%A6%A8

Si modificamos el parámetro ‘id’ (p.e duplicando %A8) veremos que es algún tipo de codificación/XOR que transforma el contenido del parámetro al enlace de Megaupload.

Buscando por internet no encontré qué codificación es (p.e una pareja sería %C7=9) y pudiendome la pereza programé un script que obtuviera todas las parejas. Una vez que tenía todas las que me interesaban ya podía transformar una cadena cualquiera a esa “codificación”.

Un ejemplo sencillo sería:

‘><script>alert(‘XSS!’);</script>

%D9%C0%C2%8D%9D%8C%97%8E%8A%C0%9F%92%9B%8C%8A%D6%D9%A6%AD%AD%DF%D9%D7%C5%C2%D1%8D%9D%8C%97%8E%8A%C0

Pero como se ejecutaba varias veces y quedaba un poco feo, lo modifiqué quedando este.

WIFI Auditor 0.4 - ¡Compatible con XP!

Fri, 17 Jun 2011 09:59:00 +0200

Ya está publicada la versión 0.4 de WIFI Auditor, cuya principal novedad es que añade soporte para Windows XP SP2/3.

En un primer momento no había pensado en hacer la aplicación compatibilidad con Windows XP pues, al no estar soportada la interacción con las redes inalámbricas a través de netsh, se hacía bastante más compleja su implementación (hay que trabajar con la API nativa de Windows y con NDIS).

Además, en esta versión se han arreglado algunos problemas que había con la conexión automática para redes JAZZTEL_XXXX en Windows Vista/7, la validación de redes vulnerables en MacOS y la detección de redes con nombres ocultos (además de algunos cambios estéticos).

He aprovechado para reestructurar el código para que sea más sencillo añadir soporte a nuevas redes que vayan apareciendo. Ahora la validación de la red y la obtención de la contraseña es independiente del resto de la aplicación.

Podéis descargaros la nueva versión desde:
http://www.ldelgado.es/?wifiauditor

Entrando más en detalle con respecto a la compatibilidad con Windows XP, darle las gracias a Carlos Navarro que ha sido la persona que se ha encargado de reescribir practicamente todo el código de ‘xpmanager’ y la fusión con NDIS.

Basicamente, en Windows XP es necesario interactuar con la API nativa para poder obtener los datos de las redes disponibles, crear un perfil de una de ellas y realizar la conexión. En un primer momento intenté que lo realizará directamente WIFI Auditor a través de JNA pero daba numerosos problemas por lo que era más sencillo utilizar una aplicación externa desarrollada en C (para el que había mucha documentación). Nos basamos en la aplicación wifi_testing.c de Roberto Agostino pero finalmente Carlos tuvo que reescribirla casi por completo. El principal problema que nos encontramos fue que la API no nos daba el BSSID del punto de acceso (la función WlanGetNetworkBssList no está implementada en XP), por lo que no podíamos generar la clave. WZC solo permitía obtener el BSSID de la red a la que estaba conectado el dispositivo por lo que tampoco nos era útil y finalmente encontramos la solución, utilizar NDIS. Uniendo la API y NDIS es posible obtener en XP los datos necesarios para que WIFI Auditor pudiera funcionar :).

Bueno, hasta aquí todo.
Supongo que no habrá versiones nuevas hasta que no se liberen nuevas redes con el algoritmo para calcular su contraseña por defecto.

Un saludo!

Comentario sobre Dropbox y la autenticación por host_id

Tue, 17 May 2011 20:34:00 +0200

Para poner en antecedentes decir que el sistema de autenticación que utiliza Dropbox sólo se basa en un identificador llamado host_id, que es un string alfanumerico de 32 caracteres que se almacena en texto plano en un fichero sqlite en la ruta %appdata%/Dropbox/config.db

Últimamente cada vez que leo un artículo/post sobre el tema, veo el siguiente comentario (que creo que es el mismo argumento que expuso Dropbox en su comunicado) “No es tan grave, si tienen acceso al host_id están teniendo acceso a toda la carpeta y su contenido”.

Creo que es un error utilizar ese argumento pues puedes tener casos como el que el acceso al ordenador sea durante un tiempo muy limitado (innecesario para poder copiar el contenido de la carpeta de Dropbox si ésta tiene un tamaño considerable), que no esté completamente sincronizado y un largo etcétera.

El peligro de que la autenticación solo tenga en cuenta el host_id es que el atacante puede monitorizar esa cuenta de cara al futuro, comprometiendo todo lo que se sincronice con esa cuenta (por supuesto, hasta que la victima revoque el acceso a ese host). Éste es el verdadero peligro, pues el acceso no se limita a un momento concreto, sino que permite al atacante acceder cuando quiera. Además, como ya se ha dicho, el host_id no queda invalidado con un cambio de contraseña, asi que no sería nada extraño que la víctima nunca se llegase a dar cuenta que su cuenta ha sido comprometida).

Además, una pequeña reflexión sería ¿la seguridad de mis datos sólo está garantizada por un string a.n de 32 carácteres?. Como se ha podido comprobar, el parámetro email no afecta, por lo que si encontramos un host_id válido (quitando la inviabilidad del ataque, pensemos en un random que nos dé un valor válido) estamos accediendo a los archivos sincronizados de una cuenta sin más.

Por lo tanto, simplemente quiero dejar clara mi preocupación ante este incidente que Dropbox ha manejado como problema menor cuando en realidad, bajo mi punto de vista, es bastante crítico (independientemente de que haya que tener acceso a la máquina, puedes robar el host_id mediante un usb o cualquier otro método).

Ya para terminar, dejo un video que he grabado del proceso. Lo he hecho a mano leyendo del fichero config.db para que se viera la estructura del mismo. Decir que cualquiera puede hacer un script que automatize el ataque o utilizar aplicaciones como Dropbox-Cloner.

http://www.youtube.com/watch?v=SsXV1OXW3fo

Un saludo!

¿Tanto cuesta configurar bien las cookies?

Wed, 20 Apr 2011 12:18:29 +0200

Enlazando con el artículo Cookies si pero credenciales mejor que se publicó la semana pasada en Security by Default sobre el autocompletado de formularios de autenticación por parte de los navegadores y su explotación a través de un XSS, ahora le toca el turno a la configuración de las cookies.

Como comentaba en el artículo, si se identifican los credenciales por host en vez de por página o servicio una vulnerabilidad en cualquier servicio de ese host/dominio afecta, además, a todos los demás. Relacionando éste caso con las cookies podemos observar que si no se configura adecuadamente a qué path del dominio corresponden (lo que identificaría, p.e, al servicio al que pertenece la cookie) éstas serán enviadas en todas las peticiones dentro de ese mismo dominio y por tanto con un XSS en cualquiera de los servicios se podrán obtener las cookies de todos ellos.

El ejemplo de explotación es el mismo que en caso de los formularios:

http://pagina.es/correo/login.php | cookie: mail=XXX
http://pagina.es/intranet/access.php | cookie: intranet=XXX
http://pagina.es/index.php | cookie: sid=XXX

En el caso de que index.php fuera vulnerable a un XSS a través de él se obtendrían las cookies de los tres servicios y por tanto se comprometerían las sesiones que estuvieran activas en ellos.

¡¿Es tan complicado configurar bien las cookies?!

Normalmente cuando nos autenticamos en un servicio vemos que en el encabezado de la respuesta del servidor tenemos:

Set-Cookie: sid=SessionID; expires=DATE; path=/; domain=DOMAIN

Si en lugar de dejar el parámetro path por defecto lo configurasemos correctamente (en el ejemplo tomaría los valores correo, intranet y / respectivamente) nos evitaríamos el problema.

Un caso real:

Como caso real podemos tomar el de la Universidad Politécnica de Madrid que bajo el mismo dominio www.upm.es aloja distintos servicios como el campus virtual, el webmail…

Como se puede observar en la imagen a continuación, si abrimos ambos servicios y ejecutamos un simple alert(document.cookie) en el del campus virtual obtenemos las cookies de este servicio (en verde) y las del webmail (en rojo).

Si en el caso de los formularios de autenticación la única opción que tienen los administradores es añadir un autocomplete=off como parámetro al form (es un problema de los navegadores y la gestión que hacen de los credenciales), en este caso, y con una solución tan simple, debería hacerse desde el primer momento (independientemente de que tengamos solo un servicio; si está en un path distinto a / claro)

Ya para terminar aprovecho para añadir lo que comentó ayer Alejandro Ramos en el post Mitos de HTTPS y la navegación segura (en SbD); es importante establecer el parámetro secure para evitar que las cookies de sesión de una conexión SSL se envien utilizando otros canales.

Un saludo!

Cracking Minecraft for fun & profit!

Tue, 05 Apr 2011 11:31:00 +0200

Últimamente se ha puesto de moda en mi universidad el juego Minecraft por lo que se me ocurrió investigar cómo podríamos jugar en modo multiplayer sin ser usuario premium.

¿Qué es Minecraft?
Según la Wikipedia, Minecraft es un videojuego detipo “sandbox” en el cual los jugadores pueden realizar construcciones en un mundo 3D compuesto de cubos, al estilo retro. Os recomiendo que os leáis el post de microsiervos sobre el juego.

¡Comencemos!

Minecraft permite registrarse gratuitamente en su página y jugar al juego en modo single player. En el caso de que queramos jugar en modo multiplayer (instalando la aplicación servidor que se puede descargar desde esa misma página) tendremos que convertirnos en usuario premium, es decir, pagar 15 euros.

Para poder saltarnos las restricciones tendremos que modificar la aplicación o la comunicación de ésta con los servidores de Minecraft. Voy a explicar la segunda opción porque me parece más útil, cómoda y limpia. Aun así, al final del artículo comentaré la manipulación de la aplicación.

Lo primero que tenemos que hacer es descargarnos el launcher desde la página de Minecraft.
Una vez descargado, nos intentamos autenticar con nuestro usuario free y veremos que nos da el error User not premium y no nos permite ni siquiera jugar en modo single player. Esto es un comportamiento extraño de esta versión del launcher puesto que en la anterior te permitía acceder aunque luego tuvieras bloqueada la opción de multiplayer.

Para saltarnos este pequeño “bug” simplemente tenemos que descargarnos en la carpeta de minecraft (por ejemplo, en Windows es APPDATA.minecraft) los archivos jinput.jar, lwjgl.jar, lwjgl_util.jar, minecraft.jar y windows_natives.jar.lzma (cambiando windows por linux, etc) y guardarlos en una carpeta llamada bin. Con respecto al archivo windows_natives.jar.lzma, tenéis que descomprimirlo para que os aparezca windows_natives.jar. Lo descomprimis y copiáis los archivos a la carpeta natives dentro de bin.

De esta forma, ya nos dejará acceder al single player. Intuyo que el problema está en que lanza el updater después del login y, en este caso al no ser premium, muestra el error sin llegar a descargar los archivos.

Una vez que nos encontramos en la pantalla principal del Minecraft, si intentamos acceder a la opción multijugador, al conectar con el servidor nos muestra el error User not premium.

Si monitorizamos la petición que hace el juego, podemos ver que es la siguiente:
http://www.minecraft.net/game/joinserver.jsp?user=USER&sessionId=SID&serverId=SRVID

La respuesta del servidor es User not premium si el usuario es free u OK si el usuario es premium. Por lo tanto, es trivial saltarse esta restricción modificando la respuesta del servidor.

Una opción puede ser instalarse un servidor en local y modificar el archivo hosts para que la resolución del dominio www.minecraft.net tenga como IP 127.0.0.1. Posteriormente, bastaría con emular la estructura de directorios y archivos en nuestro servidor, creando una carpeta game que contuviera el archivo joinserver.jsp. Como solo nos interesa que devuelva OK sea la petición que sea, bastará con que contenga esa string y nada más (la extension JSP del archivo no implica que se comporte como tal).

Como nuestra intención es conectarnos a un servidor remoto para jugar en modo ‘multiplayer’, yo instalaría el servidor ahí en vez de en local y tendría todo más centralizado.

Una vez que nos hemos saltado esta restricción, vemos que seguimos sin conectarnos pues nos aparece el error Failed to verify username!. Este error nos lo devuelve el servidor al que intentamos conectar porque no ha podido verificar que nuestro usuario tenga permiso para jugar en modo multiplayer (esto es porque nos hemos saltado la otra validación en los servidores de Minecraft).

Monitorizamos la comunicación del servidor con los servidores del Minecraft obteniendo la siguiente petición:
http://www.minecraft.net/game/checkserver.jsp?user=USER&serverId=SRVID

Los servidores de Minecraft darán tres respuestas, siendo éstas NO, NOT YET y YES. Por lo tanto, como en el caso anterior, bastará con modificar el hosts y crear el archivo checkserver.jsp con el contenido YES.

Una vez realizadas estas dos acciones (modificar el archivo hosts y crear un servidor que emule el de Minecraft) podremos jugar al Minecraft en modo multiplayer sin ser usuario premium.

Si os habéis fijado en las peticiones y las modificaciones que hemos hecho, os habréis dado cuenta de que, si consiguieramos hacernos pasar como otro usuario en la autenticación del Launcher, podríamos jugar como éste sin problemas (puesto que no se volvería a validar).

Si tenemos el launcher antiguo, bastaría con añadir a nuestro servidor local el archivo getversion.jsp que devolviese 1:2:USER:3 y estaríamos autenticados como ese usuario USER. En el caso del nuevo launcher, como la petición se hace por SSL, solo podemos saltarnos la validación si disponemos de un certificado válido, si es autofirmado la aplicación no podrá conectarse. En el caso de que lo tengamos, bastará con crear en la raiz un archivo index.php que devuelva lo anteriormente dicho.Sin embargo, modificando el launcher quedaríamos autenticados sin problemas.

Como he dicho al principio del artículo, podríamos habernos saltado las validaciones modificando la aplicación (cliente y servidor) pero me parece más comodo emular las respuestas de los servidores de Minecraft puesto que no interfiere con las actualizaciones del mismo (salvo que cambien el sistema de validación, claro).

A continuación os muestro los datos a modificar de cada una de las aplicaciones:

Launcher:

Minecraft (APPDATA.minecraft\bin\minecraft.jar):

Server:

Como podéis ver, las clases del cliente y el servidor están ofuscadas. En nuestro caso como solo queremos hacer ese cambio no es problema, pero se puede utilizar MCP que nos simplifica todo el proceso.

¡Esto es todo! Ya para terminar…

Como ultimamente me ha dado por hacer videos demostrativos, aquí tenéis una demo de lo explicado en el artículo.

Simplemente decir que, aunque sea extremadamente sencillo jugar al Minecraft sin ser un usuario premium, si de verdad os gusta el juego… ¡comprarlo! (que seguro que con las horas que le vais a echar lo amortizaréis rápido :D)

Nueva versión de WIFI Auditor!

Tue, 15 Feb 2011 10:30:00 +0100

Ya está disponible la versión 0.3 de WIFI Auditor cuya principal novedad es que añade soporte a MacOS (10.5 y superiores) y a Linux.

En esta nueva versión se ha reescrito/reestructurado todo el código, destacando lo fácil que es ahora hacerla compatible con cualquier sistema operativo, siempre y cuando éste permita interactuar con las redes inalámbricas mediante la consola.

A parte de algunos cambios estéticos, ahora al inciar la aplicación comprueba si tiene internet y, en caso de que lo haya, si existe una nueva versión disponible.

En el caso de que tu S.O no sea compatible (por ejemplo, Windows XP), la aplicación te permite calcular la clave a través del ESSID/BSSID (como cualquier otro script).

El funcionamiento es el siguiente:

Windows Vista/7: obtiene las redes y se conecta a la vulnerable a través del comando netsh (creando un perfil de nombre ‘WIFI Auditor’).

MacOS 10.5+: obtiene las redes disponibles a través del comando airport y se conecta con networksetup

Linux: obtiene el adaptador inalámbrico a través del comando ifconfig, las redes a través de iwlist y posteriormente se conecta con wpa_supplicant (se para el proceso network-manager, por lo que el icono nos mostrará desconectados aunque tengamos conexión, basta con hacer un ping o navegar para comprobar si la red tenía la contraseña por defecto o no).

¡Y hasta aquí todo!

Cualquier comentario/problema/sugerencia podéis comentarlo en el post de Security by Default o a través del email wifiauditor@ldelgado.es

Un saludo!

Accediendo a los contenidos premium de Ramoncín y compañía

Fri, 11 Feb 2011 08:31:00 +0100

En este artículo voy a hablar de un BSQLi que tenía Dropcards en su servicio de descarga de contenidos premium. Éste servicio es utilizado por muchos artístas para permitir la descarga de la versión digital utilizando el código que se encuentra en el interior del disco.

Con respecto al BSQLi, el usuario utilizado era DBA por lo que podíamos obtener el control total del servidor. Aunque no nos encontrabamos ante un Microsoft SQL Server, aprovecho para enlazaros este artículo muy interesante, escrito por Jose Selvi en Pentester. En él se explica como hacernos con un Meterpreter ejecutándose en la máquina con los privilegios del usuario ‘Servicio de red’.

Quiero destacar la rápida actuación de Dropcards para solucionar la vulnerabilidad, pues a las pocas horas de haberlo reportado me respondieron comunicándome que ya estaba parcheado.

¡Comencemos!

Todo empezó en la página de Ramoncín (evitaré comentar los motivos por los que visitaba su web).

Si nos fijamos, podemos ver que tiene un apartado llamado Canjear código que nos permite descargar la versión digital del vinilo que tiene a la venta. Lo primero que hice fue observar qué petición hacía para comprobar si era válido o no el pin del código. La petición es la siguiente:

http://www.dropcards.com/download/widget/xml.php
artist=ARTIST&pin=PIN

Si comprobamos si alguno de los parámetros es vulnerable, veremos que artist lo es, por lo que, utilizando sqlmap (simplemente para automatizar la tarea), podríamos haber obtenido PINs válidos y haber descargado los temas de cualquier artista que utilice el servicio, haber accedido a datos de carácter personal, etc.

Una vez que comprobé que era vulnerable a un ataque de BSQLi, lo único que hice fue ver cuantas bases de datos había en el servidor (encontrándome con que la cifra era bastante considerable) y si el usuario era DBA. Para comprobar si el usuario es DBA:

sqlmap.exe —url “http://www.dropcards.com/download/widget/xml.php?artist=6109” —is-dba
[Info] The back-end DBMS is MySQL
Web server operation system: Linux Red Hat
Current user is DBA: ‘True’

Por lo tanto, al ser el usuario DBA podemos ejecutar comandos, obtener una shell remota, etc.

Ya para terminar, un par de curiosidades.

Si realizamos la petición sin enviar el parámetro PIN veremos que nos responde con un error pero desconocido (no es ni “bad pin” ni “bad artist”). Si lo realizamos desde el widget (basta con poner como PIN &) veremos que nos da acceso al siguiente paso. Aunque seguiremos sin poder descargar el archivo (pues no conocemos el PIN), descubrimos que nos pide que les enviemos nuestro email y que aceptemos las condiciones de uso. La petición que realiza dicha acción es la siguiente:

http://www.dropcards.com/download/widget/email.php
pin=PIN&email=EMAIL

Por lo tanto, en el caso de que el parámetro PIN sea vulnerable (y conozcamos uno válido, que tampoco es muy complicado) se podría volver a obtener acceso al servidor a través de ésta petición y no la otra.

Y por último, simplemente decir que tenían activado el linsting por similitud (feature MultiViews de Apache), y por lo tanto podemos obtener mucha información gracias a él. Una petición curiosa era:

http://dropcards.com/x

(…)
lrwxrwxrwx 1 root root 59 Jan 19 00:21 -> /var/www/vhosts/dropcards.com/../artists/4096
lrwxrwxrwx 1 root root 59 Jan 19 00:21 -> /var/www/vhosts/dropcards.com/../artists/3218
(…)

Con esta petición podemos obtener códigos válidos de artistas (en el caso de que no tuvieramos uno, no como en nuestro caso que teníamos el 6109 correspondiente a Ramoncín), ver cual es el directorio que tendremos que decirle al sqlmap para intentar obtener una shell remota, etc.

He de reconocer que me sorprendió que el usuario fuera DBA, pues si un BSQLi ya es un tema muy delicado, si además le sumas un usuario con todos los privilegios, la situación es crítica.

El XSS de la Academia de Cine

Sat, 29 Jan 2011 01:37:00 +0100

¿Quién me iba a decir a mí que el XSS de la Academia de Cine iba a hacer que me echara unas risas todo el día?

Leyendo los tweets relacionados con el XSS y la supuesta enajenación temporal de Alex de la Iglesia, me he encontrado situaciones un tanto curiosas. Las he ido reuniendo y, además, he escogido a dos personas que son claros ganadores por la que han montado alrededor de la “nota de prensa”.

A las 18.30 la página de la Academia ha quedado inaccesible por tareas de mantenimiento. Actualmente se puede comprobar que el XSS ya no funciona, pero sigue pudiendose inyectar código (p.e “<>onload<>=alert(document.cookie);>), sería jugar con ello.

Antes de empezar, decir que el XSS era el siguiente (funcionaba en Chrome, Safari y Firefox sin NoScript): http://bit.ly/gL1lcG

Los primeros tweets son los que lo identifican con XSS:

@adelgado: La web de la Academia de cine tiene un agujero de seguridad mediante inyecciones XSS ¿XSS qué? http://j.mp/igS8Jt

@Belategui: Me temo que la web de la Academia de Cine ha sido saboteada. Está muy bien hecho. http://bit.ly/gLxmdT

@frandieguez: Ataque XSS na web da Academia de Cine de Espanha. Incríbel o sentido do humor do juaker @alexdelaiglesia http://twitpic.com/3u7rdu

@earcos: La web de la Academia de Cine tiene un hueco de seguridad XSS. Puedes escribir tu propia noticia http://bit.ly/foxThC /vía @secbydefault

Ahora pasamos a los tweets curiosos relacionados con el supuesto “hackeo”:

@PalomaLLaneza: Han hackeado la web :(..? RT @secbydefault Nota de prensa de la academia donde llaman enajenado a @alexdelaiglesia http://bit.ly/gL1lcG

@AzulCorrosivo: Posible ciberataque acaba con la web de la Academia de Cine. La que se está liando.

@carlosaganzo: Me dice @bookworm1979 que la web de la Academia del Cine no funciona. La habrán hackeado o simplemente no funciona desde UK? (¿se salva?)

Y por último, algunos de los tweets de las personas que creen que es real (XDD):

@rober_tr: Adoro el cine y twitter, no apoyo la #leysinde y estoy orgullosamente enajenado como @AlexdelaIglesia #todosconalexdelaiglesia

@rafamerino: En la nota de prensa de la Academia de cine pone “Descargar”. Además de impresentables, cínicos… #todosconalex #leysinde #sindeDimision

@rodrigompaz: La Academia de Cine vs Su Propio Presidente http://bit.ly/hBCZIh

@hilarioabadjr: Vaya tela con la notita de prensa que ha puesto la Academia de Cine… http://ccl.cl/b7k2)

@dbssdb: Vergonzoso… RT @hilarioabadjr: Vaya tela con la notita de prensa que ha puesto la Academia de Cine… http://ccl.cl/b7k2

Y ahora viene el premio a los más genios! @mfmaissa y @PMonteagudo:

@mfmaissa:Enajenación, así describían a Alex de la Iglesia_ A las 18:30 la Academia del Cine colgó una nota de prensa (cont) http://tl.gd/8etqpt

@mfmaissa: La “enajenación” de la Academia de Cine http://m.menea.me/orvb (@meneame_net) #redesociales #Internet #Alexdelaiglesia

@PMonteagudo: Así está la página de la Academia de Cine desde las 18:30 (aproximadamnt.) http://twitpic.com/3u8cnp

@mfmaissa: La “enajenación” de la Academia de Cine http://m.menea.me/orvb (@meneame_net) #redesociales #Internet #Alexdelaiglesia

@PMonteagudo: @mfmaissa #Alexdelaiglesia ENCONTRADO: http://xssacad.x10.mx/

¿Algún medio se ha hecho eco del XSS? Pues si en el caso del XSS de la RAE y la definición de “ley sinde” fue la voz de galicia con la “nota de prensa” le toca al diario de sevilla… ¡increíble!

Por lo tanto, de momento la cuenta es 2 a 1:
RAE y Warner Music a favor de la Ley Sinde
Academia de Cine en contra

Saludos!

Estrenando Tumblr!

Mon, 10 Jan 2011 18:48:00 +0100

Buenas!

Llevo un tiempo buscando algún sitio donde postear curiosidades varias y lo que se me vaya pasando por la cabeza, y creo que por fin he encontrado el sitio!.

Voy a estrenar el Tumblr contando una curiosidad de Tuenti que podemos utilizar junto con los artículos que publiqué en Security by Default (este y este), para monitorizar la cuenta de un usuario de forma bastante transparente (recomendado solo para bromas a los amigos!).

Como sabemos, Tuenti tiene un servicio movil llamado TuentiSMS que nos permite recibir alertas, cambiar el estado, etc. Aprovechándonos del escenario de los artículos y que TuentiSMS no pide la contraseña para activar el servicio, nada nos impide dar de alta nuestro movil. De esta forma, podemos tener controlada la cuenta de esa persona. Además, cuando se activa no muestra ningún tipo de notificación al usuario, por lo que puede pasar totalmente desapercibido (siempre y cuando la persona no lo usase, pues se daría cuenta de que ya no recibe las alertas).

La petición que habría que realizar es:

http://wwwb21.tuenti.com/?m=Settings&func=process_sms
csfr=CSRF&phone_number[]=PHONE&phone_number_id[]=34PHONE&phone_number_prefix[]=34&carrier=4

¿Podemos ir un paso mas allá? En principio, se me ocurre que podríamos utilizar el SMSSpoofing para dar de alta un número cualquiera (o el de la propia victima si no lo tiene activado y por tanto desactivando las alertas para que no le llegue ninguna) y simplemente usarlo para cambiar el estado, etc. No lo he podido comprobar porque el servicio que utilizo de web sms me rechaza el 22010/1, pero podría ser factible.

Con respecto al SMSSpoofing, os dejo con el video de la ponencia de Julian Vilas en la NoConName: http://goo.gl/EmmDw

La mejor solución que veo aquí es que se pida la contraseña para poder activar el servicio y además, no estaría mal que se notificara al usuario sobre su activación (bajo el avatar, como cualquier otra).

Un saludo!