XMPP, algo más que chat (2/2)
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.
XMPP, algo más que chat (1/2)
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.
Entrevista al equipo de Backend de Tuenti
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
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” />
XSS en Google Code
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
Spameando a la SGAE que es gerundio
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…
Curioso XSS en Peliculas(Series) Yonkis
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”.
WIFI Auditor 0.4 - ¡Compatible con XP!
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
Comentario sobre Dropbox y la autenticación por host_id
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.
¿Tanto cuesta configurar bien las cookies?
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!
El autor:
