XMPP, algo más que chat (1/2)
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).
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).
El autor: