Curso de privacidad y protección de comunicaciones digitales Lección 3. Comunicaciones seguras mediante mensajería instantánea

Transcripción

1 Curso de privacidad y protección de comunicaciones digitales Lección 3. Comunicaciones seguras mediante mensajería instantánea D. Luis Delgado

2 INTRODUCCIÓN La mensajería instantánea permite la comunicación en tiempo real entre usuarios (generalmente en modo texto aunque en la actualidad se permita la realización de videollamadas, transmisión de ficheros, etc). La principal diferencia con respecto al correo electrónico es que la comunicación se realiza en tiempo real entre usuarios que han permitido previamente dicha conexión entre ellos. Para poder mantener una comunicación a través de mensajería instantánea es necesario hacer uso de un cliente que realice el servicio. A lo largo del tema se detallará el funcionamiento de varios protocolos (propietarios o de código abierto), siendo los más utilizados en la actualidad los siguientes (sin ningún orden en particular): ICQ y AIM (AOL) Yahoo! Messenger Windows Live Messenger XMPP (Google Talk, Facebook Chat, WhatsApp, etc) En un primer momento cada servicio permitía conectarse únicamente con los usuarios que utilizaban ese mismo servicio, siendo necesario el uso de clientes como Pidgin cuya compatibilidad con la gran mayoría de los protocolos permitía mantener una conexión multiprotocolo y multicuenta. En la actualidad, con protocolos como XMPP es posible conectar varios servicios desde una misma cuenta (p.e a través de la cuenta de Google Talk es posible comunicarse con usuarios de otros dominios/servicios, como Jabber). Con respecto a la seguridad, a pesar de que se trate en profundidad en puntos posteriores, es importante destacar que, por norma general, los protocolos no implementaban (o habilitaban por defecto) el cifrado de las comunicaciones, transmitiéndose éstas en texto claro y quedando expuestas a numerosos ataques como el robo de información, suplantación de identidad, alteración de la información transmitida, etc. En la actualidad, y gracias al auge del uso de teléfonos inteligentes con conexión a internet, la mensajería instantánea ha conseguido posicionarse por delante de servicios como los mensajes cortos (SMS y MMS); algunos clientes populares son WhatsApp, Line, Google Talk, Facebook Chat, etc. ARQUITECTURA GENERAL Como se ha comentado anteriormente en la introducción, en un primer momento los sistemas eran incompatibles entre sí. A pesar de esta situación, el IETF publicó en el año 2000 dos RFCs sobre una arquitectura genérica y universal de mensajería instantánea, a la que denominaron IMPPWG. Básicamente éstas RFCs recogían una serie de requisitos mínimos que debía incorporar un futuro protocolo que soportase servicios de presencia y mensajería instantánea. Durante ese mismo año, Jeremie Miller envió al IETF un borrador del protocolo IMPP que no fue incluido dentro del grupo de trabajo hasta el año 2002, siendo renombrado a XMPP. En 2004 se establecieron las cuatro RFCs que lo definen.

3 Con respecto a la arquitectura común de los sistemas de mensajería instantánea, ésta se basa en un sistema cliente-servidor permitiendo a los servicios un cierto control sobre los usuarios que los utilizan; evitando problemas comunes que suponen los cortafuegos en los clientes pero incluyendo la complejidad que supone el mantenimiento de una infraestructura que mantiene el servicio centralizado y que dificulta enormemente su escalabilidad (desviando ciertos servicios como la transmisión de ficheros o las video-llamadas hacia una solución P2P). Figura 1: Arquitectura general de un servicio de mensajería instantánea. De acuerdo con la Figura 1, los usuarios 'Alice' y 'Bob' se registran en el servidor (autenticación, actualización del estado, etc) y acceden a través de él a las solicitudes de estado del resto de sus contactos. Si Alice quiere comunicarse con Bob simplemente tendrá que enviar al servidor una petición de contacto y éste establecerá la comunicación entre ellos. En el caso de que Bob quiera enviar un fichero a Alice, enviará una solicitud al servidor, éste preguntará a Alice y en caso de que la acepte se indicará a Bob la información necesaria para que se conecte con Alice. A continuación se va a analizar la arquitectura de los protocolos más utilizados, siendo éstos MSNP (Windows Live Messenger) y OSCAR (AOL); también se describirá brevemente el protocolo YMSG (Yahoo!). A pesar de que el protocolo QQ tiene un número de usuarios activos más que considerable (450 millones según las cifras publicadas en Agosto de 2009), no se va a tener en cuenta en este análisis por ser popular únicamente en China. PROTOCOLO MSNP El protocolo MSNP ('Mobile Status Notification Protocol') es el protocolo de mensajería instantánea de Microsoft. El cliente oficial de Microsoft era 'Windows Live Messenger' y cuya última versión implementaba la versión MSNP19 del protocolo (última actualización en 2011). A pesar de la popularidad del cliente oficial de Microsoft, en Noviembre de 2012 se anunció que a principios de 2013 se inhabilitaría el servicio forzando a sus usuarios a utilizar en su lugar Skype. Finalmente la fecha elegida fue el 8 de abril.

4 Windows Live Messenger tiene su antecesor en MSN Messenger, siendo uno de los motivos de su éxito el que viniera preinstalado en Windows. A pesar de que el protocolo MSNP no es de código abierto, a través de técnicas de ingeniería inversa se ha podido conocer su funcionamiento permitiendo su implementación en clientes multiprotocolo como Pidgin. En la arquitectura del protocolo hay presentes tres tipos distintos de servidores utilizados para distintos procesos, siendo éstos 'Dispatch Server' (DS), 'Notification Server' (NS) y 'Switchboard Server' (SS). En primer lugar el cliente se conecta con el servidor DS que se encarga de redireccionar a los clientes a uno de los servidores NS a través del cual realizará el proceso de autenticación (puede conectarse directamente al servidor NS en el caso de que el cliente tuviera ya almacenada su dirección debido a conexiones anteriores). La dirección del servidor DS es messenger.hotmail.com y 1863 como puerto de conexión. El servidor NS es el servidor principal del protocolo MSNP. Una vez que el usuario ha sido redireccionado al servidor éste debe autenticarse. Atendiendo de forma más concreta al proceso de autenticación: 1. El cliente crea un mensaje SOAP con la información de autenticación ( y contraseña, es decir, las credenciales de la cuenta). 2. El cliente se conecta con un servidor de Microsoft indicado en el fichero y le envía el mensaje SOAP, recibiendo como respuesta un 'token' de seguridad y una cadena 'secreta' que posteriormente tendrá que entregar. 3. A partir de la información recibida se calcula el valor a entregar al servidor NS (3DES y múltiples SHA1) y se envía junto al 'token' de seguridad y el GUID de la máquina. Una vez que el proceso de autenticación se ha realizado correctamente se le entregará al cliente la lista de sus contactos y el estado de los mismos. La petición que manda el cliente permite el uso de SSL aunque el cliente oficial (WLM) la realiza en texto claro. Para evitar que en cada petición se descargue la lista completa, el cliente envía al servidor un 'timestamp' de la versión que tiene actualmente y de esta forma el servidor responde únicamente con las modificaciones a aplicar en ella. El servidor NS también se encarga de asignar a los usuarios los servidores SS a través de los cuales pueden mantener las conversaciones. Una vez que se les asigne un servidor SS en concreto, éste se encargará de gestionar la comunicación entre los usuarios haciendo de nodo intermedio. Todos los mensajes que se intercambian entre un cliente y el servidor se envían en forma de comandos, siendo éstos de cuatro tipos: normales, 'payload', error y asíncronos. Cada uno de los comandos tiene asignado un nombre compuesto por tres letras mayúsculas, por ejemplo 'USR' para 'usuario', o tres números si se trata de un error. Además, a cada comando se le establece un identificador que relaciona peticiones del cliente con respuestas del servidor (los mensajes desde el servidor no contienen identificador o el valor de éste es 0).

5 Cuando los usuarios están conectados al servidor SS pueden enviar los mensajes al resto de participantes haciendo uso del comando MSG (de tipo 'payload'). Figura 2: Ejemplo de una captura de red de un mensaje. SKYPE Como ya se ha comentado anteriormente, desde el 8 de abril de 2013 el servicio de Windows Live Messenger ha iniciado su proceso de cierre y se ha ofrecido a los usuarios a que actualicen sus cuentas a Skype. Skype es un protocolo basado en una arquitectura P2P excepto para el componente encargado de la autenticación de los usuarios, que está basado en una arquitectura de tipo central (modelo de cliente-servidor haciendo uso de mecanismos de clave pública). Una vez que el proceso de autenticación se ha realizado, las comunicaciones se realizan en la red P2P. La red de Skype tiene dos tipos de nodos, los hosts (clientes que hacen uso del servicio de Skype) y los supernodos (se encargan de gestionar el tráfico de Skype con el objetivo de evitar NATs y Firewalls; es a éstos a los que se conectan los nodos de tipo 'host'). Aquellos nodos con suficiente CPU/RAM/Ancho de banda como para satisfacer las necesidades de los supernodos, se autoconfiguran como tal. Con respecto a este servicio de mensajería instantánea y VoIP es importante destacar algunas de sus características de seguridad más importantes: El cifrado utilizado es seguro y proporciona las medidas técnicas necesarias para evitar que se puedan impersonar cuentas salvo que se disponga de las credenciales. Dado que hace un uso continuo de conexiones P2P, se puede acceder fácilmente a la dirección IP de ambos usuarios de una misma comunicación. Las mensajes procedentes de la mensajería instantánea son almacenados por defecto. Al igual que ocurría con el resto de protocolos estudiados, Skype tampoco es código abierto (se distribuye únicamente en formato ejecutable y además -al contrario que en otros casos- contiene medidas anti-debugging). Es importante limitar la comunicación con usuarios pertenecientes a la lista de contactos para evitar ataques típicos de SPAM/Phising/etc. Otras medidas de seguridad que se pueden tomar son el deshabilitar la API y la transmisión de ficheros (cuyos problemas de seguridad veremos en el apartado de amenazas).

6 A pesar de todas las características de seguridad descritas anteriormente, este mismo mes (mayo de 2013) se han hecho públicos los resultados de una investigación llevada a cabo por el equipo de "Heise Security" en la que se ha demostrado como Microsoft monitoriza todas las comunicaciones de mensajería instantánea realizadas a través de Skype y accede a los enlaces que se hayan intercambiado en ellas. Aunque oficialmente han posicionado esta práctica como un filtrado preventivo anti-spam, se ha detectado que no todos los enlaces son analizados siguiendo los mismos criterios, sino que no todos los enlaces HTTP son analizados pero, en contraposición, todos los enlaces HTTPS sí que son analizados. Log del servidor: [30/Apr/2013:19:28: ] "HEAD /.../login.html?user=tbtest&password=geheim HTTP/1.1" Figura 3: Geolocalización de la IP que visita el enlace intercambiado a través de Skype. Se puede acceder a más información en el siguiente enlace (inglés):

7 PROTOCOLO OSCAR El protocolo OSCAR ('Open System for Communication in Real-time') es el protocolo de mensajería instantánea de AOL. Este protocolo es implementado por los dos principales clientes de la compañía, AIM e ICQ. Al igual que ocurría con el protocolo MSNP, OSCAR no es de código abierto pero también se ha podido acceder a una gran parte de su funcionamiento gracias a técnicas de ingeniería inversa. Su uso se ha centrado principalmente en el mercado americano, teniendo en los Estados Unidos su nicho principal de usuarios y sin poder hacer frente a Windows Live Messenger (WLM) en Europa. Al igual que ocurría en el caso de MSNP, la arquitectura detrás de ICQ/AIM consta de varios servidores con distintas finalidades, siendo los principales el 'Authorization Server' (AS) y el 'Basic OSCAR Service Server' (BOSS). Cuando un usuario quiere conectarse al servicio, en primer lugar accede al servidor AS en el que hace una primera autenticación (envía un MD5 formado por una clave de autenticación, recibida del servidor tras validar que el usuario existe, y la contraseña), a través de la cual obtiene una 'cookie' de sesión. Una vez completada esta primera fase, se redirige al cliente al servidor BOSS (el servidor principal). La dirección del servidor AS es login.oscar.aol.com En el servidor BOSS el usuario se autentica en la red de mensajería instantánea de AOL haciendo uso de la 'cookie' obtenida del servidor AS. Una vez autenticado, el servidor BOSS entregará al cliente información de la cuenta (p.e la velocidad con la que puede enviar mensajes) y éste podrá solicitar la lista de contactos, las preferencias de privacidad, etc. Las conexiones con los servidores a través del protocolo OSCAR se realizan a través de distintos 'frames' o canales. Gracias a estos canales es posible realizar comunicaciones paralelas sin necesidad de conectarse a múltiples servidores (como veremos en XMPP con los 'stanzas'). Existen cuatro canales principales, siendo éstos: 'Connection Start Frame': se utiliza como canal de autenticación, ya sea en el servidor AS como en el servidor BOSS. 'Main Frame': es el canal que más se utiliza y que alberga la mayor parte de la funcionalidad del protocolo. 'Error Frame' y 'Connection End Frame'. Figura 4: Ejemplo de una captura de red de un mensaje.

8 PROTOCOLO YMSG El protocolo YMSG ('Yahoo! Messenger') fue publicado en junio de 1999 y era similar al ya comentado MSNP (en aquél momento denominado 'MSN Messenger'). Una de las novedades que introdujo fue su excelente integración con la Web. Al igual que ocurre con el resto de protocolos comentados, YMSG tampoco es de código abierto. Con respecto a la arquitectura, se trata de un sistema cliente-servidor pero que, al contrario que en los protocolos MSNP y OSCAR, el cliente se conecta con un servidor aleatorio (del formato cs##.msg.dcn.yahoo.com, siendo ## un número decimal de dos dígitos) y a través de él realizará el resto de transmisiones (autenticación, acceso a la lista de contactos, comunicación con otro usuario, etc). Dado que el protocolo YMSG es síncrono (al contrario que MSNP que permitía el envío de varias peticiones, relacionando las respuestas del servidor en base al identificador establecido), la conexión queda a la espera de la respuesta del servidor antes de realizar una nueva petición. Atendiendo al proceso de autenticación, en el protocolo YMSG ocurre lo mismo que con OSCAR, no se envía la contraseña sino un hash (MD5 o SHA1) de la misma. Con respecto al cifrado de las comunicaciones, Yahoo! Messenger no lo implementa. En el caso de que se quiera utilizar un cliente que sí soporte el uso de conexiones con cifrado SSL será necesario utilizar 'Yahoo! Bussiness Messenger'. EJEMPLOS DE PROTOCOLOS SEGUROS QUE HAN SIDO PROPUESTOS Como ya se ha comentado anteriormente, los protocolos explicados carecen de unas características de seguridad adecuadas. Por este motivo se han ido proponiendo una serie de alternativas que cumplían con los requisitos de seguridad establecidos y no suponían un impacto en el rendimiento. A continuación se describen algunas de las propuestas. SILC El protocolo SILC ('Secure Internet Live Conferencing') fue propuesto por Pekka Riikonen en 1997 para securizar los sistemas de mensajería instantánea e IRC. El protocolo de intercambio de llaves de SILC (SKE) está basado en el protocolo criptográfico de Diffie-Hellman (DH). Tras una ejecución correcta de este protocolo se procede con el protocolo de autenticación 'SILC Connection Authentication Protocol' haciendo uso o de una 'passphrase' o una clave pública. La implementación del protocolo SKE es vulnerable a un ataque de tipo 'Man in the Middle' (MitM) aprovechando que el certificado utilizado durante el protocolo SKE no se verifica correctamente.

9 IMKE En el año 2005, M. Mannan y P. C. van Oorschot propusieron el protocolo IMKE ('Instant Messaging Key Exchange'). Este protocolo puede descomponerse en tres estados: el intercambio de claves (fase inicial de autenticación de los usuarios en el servidor), la comunicación cliente-servidor y las conexiones cliente-cliente. Se entiende que el certificado digital del servidor está incluido en el propio cliente (o se ha instalado previamente). Durante la fase de intercambio de claves: 1. El cliente genera dinámicamente un par de claves pública/privada (RSA 1024/2048-bit) y una clave simétrica aleatoria (AES-128 CBC). 2. Con la clave simétrica recién generada cifra los datos de autenticación (incluye el hash de la contraseña (SHA-1) y la clave pública del cliente) y envía los datos cifrados al servidor junto con la clave utilizada cifrada haciendo uso de la clave pública del servidor. 3. Si en el servidor concuerda la contraseña del usuario con la recibida, envía al cliente un 'challenge' cifrado con la clave pública del cliente y el hash de la contraseña (calculado con una función diferente de la utilizada en el primer caso, p.e RIPEMD-160) cifrado con la clave simétrica. 4. El cliente comprueba que la clave recibida es la correcta y en caso de que concuerden descifra el 'challenge' recibido y lo reenvía al servidor haciendo uso de SHA El servidor comprueba que el 'challenge' recibido es el correcto y en caso de que concuerden tanto el cliente como el servidor calculan el identificador de sesión (que será utilizado como clave de cifrado) y la MAC (HMAC utilizando SHA-1), a través de una nueva función hash conocida por ambos, en la que intervienen la clave simétrica inicial y el 'challenge'. Una vez autenticado en el servidor, si el usuario (Alice) quiere iniciar una comunicación con uno de sus contactos (Bob) enviará una petición al servidor solicitando la clave pública de ese usuario (Bob), éste se la entregará y además enviará al usuario (Bob) la clave pública de Alice. Una vez que Alice tiene la clave pública de Bob, generará una clave de sesión aleatoria y se la enviará a Bob a través de una conexión P2P. Una vez que ambos tienen la clave de sesión, crearán la clave de cifrado y MAC correspondientes e iniciarán la comunicación segura. Atendiendo a la seguridad del protocolo, cabe destacar que esta propuesta permite que, si la comunicación es interceptada en cualquiera de las fases de la misma (incluso en el intercambio de claves) el atacante no podrá descifrar la información por no disponer de la clave privada del cliente. Aun así, es sensible a ataques de denegación de servicio al poderse replicar los paquetes del cliente (p.e en la fase de intercambio de claves, no se podría continuar con el proceso pero si consumir los recursos del servidor enviando múltiples veces el mismo paquete cuyo contenido es válido y el servidor tiene que verificar). Además, dado que se producen conexiones P2P sin necesidad de enviar archivos, es posible acceder a la dirección IP de un contacto simplemente iniciando una sesión con él.

10 ECC IM IMPLEMENTATION En enero de 2008 C. H. Yang, T. Y. Kuo, T. Ahn y C. P. Lee propusieron un protocolo de mensajería instantánea basado en la utilización de criptografía de curva elíptica (ECC) en la creación de las claves públicas y las claves simétricas. El uso de ECC en el protocolo permite mejorar el rendimiento dado que el cifrado ECC con una longitud de clave de 160-bit es igual de seguro que el uso de RSA con longitudes de clave de 1024-bit. ANÁLISIS DE SEGURIDAD En términos de seguridad, la identidad y privacidad del usuario no han sido una prioridad en los protocolos y/o servicios utilizados en la mensajería instantánea clásica. Dado que únicamente es necesario un correo electrónico para registrarse, la identidad de los usuarios no puede ser verificada. Con respecto a la privacidad, dado que por norma general las comunicaciones no se cifran (y en algunos casos el cifrado propuesto por el protocolo es inútil, como veremos en XMPP), pueden ser interceptadas fácilmente. REQUISITOS DE SEGURIDAD En la actualidad la mensajería instantánea cada vez tiene una mayor presencia en las empresas. Los empleados utilizan estos servicios para colaborar y comunicarse con otros compañeros. Esta situación hace necesaria la adopción de una serie de requisitos a la hora de autorizar el uso de estos servicios. A continuación se detallan algunos de éstos requisitos: Confidencialidad de la comunicación: los mensajes transmitidos a través del servicio de mensajería instantánea sólo pueden ser leídos por el receptor, estableciendo las medidas de seguridad que sean necesarias para evitar que terceros puedan acceder a su contenido. Integridad del mensaje: los mensajes no deben poder ser alterados. Identificación: los mensajes deben contener la información de su emisor y la persona a la que va dirigido, evitando que el mensaje sea entregado a un destinatario equivocado. El emisor no debe poder modificar ni eliminar un mensaje ya enviado. ANÁLISIS DE MSNP Con respecto a la política de contraseñas, requiere al menos una contraseña de 6 caracteres pero no es necesario que ésta contenga números y caracteres especiales por lo que deriva en el uso de contraseñas inseguras por parte de los usuarios. La política que debería aplicarse es la de exigir una contraseña de al menos 8/10 caracteres mezclando minúsculas, mayúsculas, números y símbolos. A pesar de la utilización de una política de contraseñas insuficiente, la única vez que se transmite la contraseña del usuario (durante el proceso de autenticación con un servidor externo de Microsoft a través de SOAP) se realiza a través de una conexión SSL.

11 Atendiendo a la mensajería, como ya se ha comentado anteriormente, a pesar de que soporte la conexión SSL para la petición de la lista de contactos, el cliente oficial no hace uso de la misma. Además, los mensajes entre usuarios no se cifran por lo que la confidencialidad de las comunicaciones puede ser fácilmente comprometida. Aun así, el intercambio de ficheros entre usuarios sí que se realiza a través de una conexión cifrada. Con respecto al almacenamiento de 'logs' de las conversaciones en el servidor, información oficial de Microsoft indica que ni se almacenan 'logs' de conexiones ni del contenido de las comunicaciones entre usuarios. ANÁLISIS DE OSCAR Atendiendo a la política de contraseñas, el protocolo OSCAR no establece ninguna restricción. Aun así, la página de registro de AIM si que establece que la contraseña contenga entre 6 y 8 caracteres sin símbolos (claramente insuficiente, como se ha indicado en el análisis de MSNP). A pesar de la utilización de una política de contraseñas insuficiente (del lado del proveedor del servicio, no del protocolo), al menos no se transmite la contraseña sino un hash compuesto por un identificador de la cuenta recibido del servidor AS y la propia contraseña. Aun así, el hecho de que no se utilicen algoritmos de derivación de clave (como PBKDF2) y que las contraseñas sean inseguras, indica que el hash podría ser 'crackeado'. Con respecto a la mensajería, únicamente se hace uso de conexiones cifradas en AIM, mientras que en ICQ se envían las comunicaciones en texto claro. Esta situación hace que la confidencialidad de las comunicaciones a través del protocolo OSCAR en ICQ pueda ser fácilmente comprometida. AIM, a través plugins que complementan las funcionalidades del cliente por defecto, permite el uso de certificados digitales personales para garantizar la autenticación, integridad y confidencialidad de los mensajes. Acerca del almacenamiento de 'logs' de las conversaciones en el servidor, información pública de AOL indica que únicamente se almacenan registros de las conexiones de los usuarios pero nunca del contenido de las comunicaciones entre ellos (no hay datos públicos sobre el tiempo máximo que permanecen los registros almacenados). AMENAZAS 1. CONEXIONES INSEGURAS: Una vez que el usuario se ha autenticado, por norma general los sistemas de mensajería instantánea (ya sea el propio protocolo o la implementación del proveedor del servicio) carecen de medidas de seguridad adecuadas, como autenticación de los mensajes (además de durante la autenticación del usuario), confidencialidad e integridad de las comunicaciones. Esta situación provoca la aparición de otras vulnerabilidades como suplantación de identidad, robo de sesión, denegación de servicio (DoS), ataques de tipo MitM, etc. Por ejemplo, si bien un usuario sólo puede recibir mensajes de otro usuario que esté incluido en su lista de contactos, si un atacante captura una de las comunicaciones (una conexión abierta con otro contacto),

12 sería capaz de inundar al usuario con mensajes no deseados (el SPAM se verá posteriormente con mayor profundidad). 2. DENEGACIÓN DE SERVICIO: El ataque de denegación de servicio (DoS) puede afectar tanto a un usuario concreto (en el punto anterior se ha tratado el escenario en el que se inunda a un usuario con mensajes indeseados), como al propio servidor a través de los servicios disponibles. Si bien los usuarios pueden bloquear a un contacto en función de su identificador, si el servicio de mensajería instantánea no gestiona correctamente la creación de cuentas esta medida de seguridad puede resultar insuficiente. 3. CUENTAS IMPERSONADAS: Un atacante puede impersonar a un usuario válido de dos formas diferentes, si consigue capturar su contraseña o a través del identificador de la sesión. Si se desconecta al usuario a través de un ataque como los mencionados en el punto de denegación de servicio, el servidor no recibirá la notificación de desconexión y mantendrá esa sesión activa hasta que expire por inactividad. Durante ese periodo de tiempo, el atacante podría hacerse con el control de la sesión. 4. SERVIDORES FALSOS: Un programa malicioso podría modificar la configuración del servidor DNS de la máquina del usuario haciendo que éste se conecte a un servidor de mensajería instantánea que no es oficial. Adicionalmente, se podrían alterar las peticiones DNS a través de un ataque de tipo 'DNS Spoofing'. Para evitar estas situaciones es necesario que se verifique el servidor al que el cliente se conecta (p.e a través del certificado SSL que se utiliza para cifrar la conexión). 5. SPAM: Uno de los principales problemas de la mensajería instantánea para los proveedores del servicio es el envío masivo de mensajes por parte de los usuarios; causando problemas de colapso en la red. Dado que las medidas de protección tradicionales no son efectivas en este nuevo escenario, algunos proveedores han implementado medidas adicionales para mitigar el impacto, como es el caso del algoritmo de límite/advertencia de AIM o el límite estático de 3 mensajes por segundo de Yahoo! (implementado en el cliente oficial por lo que con el uso de otros clientes es posible saltarse esta restricción). Adicionalmente, el protocolo XMPP se ha diseñado teniendo en cuenta también este aspecto, por lo que implementa medidas del lado del servidor que mitigan en cierto grado este tipo de amenazas. Otra de las medidas que se han implementado es la desconexión de clientes en espera (aligerando la carga sobre los servidores). En el caso de AIM el cliente está obligado a enviar un paquete específico cada minuto, para YMSG se han implementado comprobaciones cada 60 minutos -y 13 posteriores si no ha respondido- y en el caso de MSNP tanto controles del lado del cliente como del servidor.

13 6. VIRUS: Debido a la posibilidad de enviar archivos entre usuarios, con la mensajería instantánea se ha abierto un nuevo vector de propagación de los ficheros maliciosos (virus, malware, caballos de troya, etc...). Algunos de los clientes más utilizados han optado por ofrecer al usuario la posibilidad de configurar un análisis de todos los ficheros que reciba haciendo uso del antivirus que tenga instalado. Si a este escenario añadimos la posibilidad que ofrecen algunos clientes de aceptar todos los envíos de ficheros (ICQ) o abrirlos tras su descarga (Yahoo! Messenger), los archivos maliciosos necesitan una menor interacción del usuario para infectar la máquina. Adicionalmente, con la popularización de los enlaces acortados, se ha abierto una nueva brecha que no requiere el envío del fichero sino que el usuario acceda a una página controlada por el atacante. 7. ACCESO A LA DIRECCIÓN IP DEL USUARIO: Dado que en muchos de los servicios adicionales ofrecidos por los proveedores de mensajería instantánea se hace uso de P2P en vez de la arquitectura con nodo intermedio, la dirección IP de los usuarios queda expuesta a terceros pudiendo éstos acceder a los contenidos que tengan públicos o mal configurados (p.e recursos compartidos o la opción de clientes como el de AOL-AIM&ICQ que permiten habilitar un servidor de ficheros o un servidor web en el propio cliente). 8. ALMACENAMIENTO INSEGURO DE INFORMACIÓN: Algunos clientes almacenan información de la cuenta del usuario (identificador, contraseña cifrada) accesible a programas maliciosos. Por ejemplo, MSN Messenger almacenaba en el registro de Windows la lista de contactos de la cuenta y los usuarios que estaban bloqueados. Esta información puede ser modificada para evadir filtros de seguridad (p.e añadir una cuenta del atacante a la lista de contactos de la víctima). 9. LOGGING: Depende del cliente de mensajería instantánea que utilice el usuario, es posible que sus mensajes estén siendo almacenados por defecto. Además, aunque el usuario deshabilite el 'logging' local (e incluso indique en su configuración que no se almacenen las conversaciones, como ocurre en XMPP), es posible que el resto de los nodos que intervienen estén almacenando el contenido de la comunicación (tanto los servidores del proveedor del servicio como el propio destinatario). Para evitar el acceso a la comunicación por parte de terceros sería necesario hacer uso de criptografía 'end-to-end' como puede ser el caso de OTR (tratado posteriormente). XMPP El protocolo XMPP ('Extensible Messaging and Presence Protocol') es un protocolo abierto (al contrario que MSNP, OSCAR y YMSG), basado en XML y fácilmente extensible, que se utiliza principalmente en servicios de mensajería instantánea.

14 Originalmente fue desarrollado en 1999 bajo el nombre de Jabber. Como ya se ha comentado en la introducción, en el año 2000, Jeremie Miller presentó el protocolo en la IETF con el nombre IMPP y ésta lo acepto en el año 2002 renombrándolo a XMPP. Este protocolo es utilizado en aplicaciones y servicios conocidos y ampliamente utilizados como Google Talk (cuyo soporte no se va a mantener en el nuevo servicio de Google, Hangouts), el chat de las redes sociales Tuenti&Facebook y Whatsapp (en algunos casos variaciones del mismo adaptadas al funcionamiento propio del servicio -como es el caso del WhatsApp-). La red XMPP hace uso de un arquitectura cliente-servidor en la que no existen servidores centrales que gestionan el servicio sino que cualquier usuario puede crear su propio servidor XMPP (la comunicación se realiza directamente entre el nodo emisor y el receptor, sin saltos intermedios). Todos los usuarios en la red tienen asignado un identificador denominado JID ('Jabber ID'). Este identificador tiene una estructura parecida a la del , tal que usuario@dominio. Para permitir accesos desde distintas localizaciones sin que éstos confluyan en una misma sesión, XMPP utiliza la figura del recurso (p.e 'casa', 'trabajo', etc) para especificar un cliente en concreto en el propio JID, quedando usuario@dominio/recurso. Otra de las características a destacar del protocolo es que permite el uso de 'Connection Managers' para utilizar el protocolo a través de conexiones HTTP persistentes ('long-lived'). De esta forma, es posible integrar este servicio en web-chats como ha ocurrido con Google Talk (Gmail) y Facebook Chat. El intercambio cliente-servidor se realiza de forma asíncrona asignando a cada petición un identificador (su valor es secuencial pero no debe ser predecible, es decir, por ejemplo siguiendo el formato R=RANDOM -> [R]0 -> [R]1 -> [R]2). La información se transmite en forma de 'stanzas' dentro de un mismo 'stream' (si éste se cierra se finaliza la comunicación). Las 'stanzas' no son mas que las entidades base del protocolo; siendo éstas: Message: permite enviar mensajes de una entidad a otra. Existen cinco tipos: normal (como el ), chat (mensajería instantánea), groupchat (mensajería instantánea en grupo, modo 'broadcast'), headline (envío de notificaciones) y error (permite un tratamiento de errores más complejo que el que ofrecía Jabber). <message to='usuario1@dominio' type='chat' xml:lang='es'> <subject>asunto</subject> <body>mensaje</body> </message> Presence: forma básica de 'broadcast' entre una entidad y todos sus subscriptores. Se puede especificar un único destinatario haciendo uso del atributo 'TO'. <presence to='usuario1@dominio' type='subscribe'/>

15 IQ: permite solicitar información de una entidad a otra o al propio servidor. Existen cuatro tipos: 'get' (solicita información), 'set' (modifica información), 'result' (indica que la operación se ha realizado correctamente) y error. <iq type='get'> <query xmlns='jabber:iq:roster' /> </iq> <iq from='usuario1@dominio' to 'usuario1@dominio' type='set'> <query xmlns='jabber:iq:roster'> <item jid='usuario@dominio'/> </query> </iq> Atendiendo a la seguridad del protocolo, cabe destacar que ésta junto con la privacidad están muy presentes en su propia definición (y queda patente tras comprobarse que nunca ha sufrido problemas de seguridad graves). Veamos más en detalle algunos ejemplos de amenazas a las que se enfrenta y qué medidas toma: Seguridad de las comunicaciones: El protocolo permite que las comunicaciones se realicen de forma cifrada (SSL/TLS), tanto entre el cliente y el servidor como aquellas que se producen entre servidores (p.e comunicación de usuarios pertenecientes a distintos dominios). Aun así, no incorpora características de cifrado 'end-to-end' por lo que las comunicaciones se cifran con los servidores, quedando expuestas en éstos. Autenticación e identidad: No permite la suplantación de identidad a través de técnicas de 'spoofing' del parámetro FROM porque éste siempre se valida en el servidor, obviándose el valor que haya establecido el cliente. Dado que el 'spoofing' se podría realizar en la comunicación servidor-servidor, se realiza una verificación del dominio (denominada 'dialback') en la que se consulta al servidor 'root' del dominio si el servidor que se está intentando autenticar como de ese dominio es realmente legítimo. A pesar de todas estas medidas de seguridad, como el set de caracteres es unicode, el propio cliente debe lidiar con los problemas que representan los distintos caracteres que, si bien son parecidos para la interpretación de los usuarios, indican JIDs diferentes. SPAM: En principio el sistema de subscripciones evita el envío masivo de mensajes a usuarios arbitrarios. A pesar de este sistema, algunas implementaciones habilitan por defecto la aceptación automática de peticiones de subscripción, anulando por completo la finalidad de las mismas. Por este motivo, el protocolo también implementa límites de envíos por tiempo (como se ha explicado en el apartado de amenazas globales). Finalmente, podemos concluir que los problemas de seguridad no radican en la especificación del protocolo en sí (como ocurría en otros vistos como MSNP) sino en la implementación que

16 se realiza del mismo y de la configuración que se establece a nivel servidor y como preferencias por defecto en las cuentas de los usuarios. ATAQUE PRÁCTICO EN XMPP Como hemos visto en la descripción del protocolo, XMPP permite el cifrado de las comunicaciones y, dada su naturaleza extensible, la habilitación de mecanismos de autenticación personalizados. Retomando la conclusión dada tras analizar las medidas de seguridad que implementa el protocolo, vamos a ver un ejemplo aplicado a Google Talk. A la hora de hacer uso del servicio Google Talk podemos encontrarnos ante tres escenarios: la web (que utilizaría un 'Connection Manager' y cuyo tráfico se cifraría por defecto al estar en un página bajo SSL), un dispositivo móvil Android y la aplicación oficial de escritorio (en la que nos vamos a centrar en este caso). Si nos descargamos la aplicación desde la página oficial de Google y nos conectamos al servicio GTalk con ella veremos que el tráfico se cifra por lo que, en principio, un atacante no podría acceder al contenido de nuestras comunicaciones. Si analizamos más en detalle la comunicación que se produce durante el inicio, veremos lo siguiente: cliente: <stream:stream to='gmail.com' xml:lang='en' version='1.0' xmlns:stream=' xmlns='jabber:client'> servidor: <stream:stream from='gmail.com' id='b db0854c5' version='1.0' xmlns:stream=' xmlns='jabber:client'> <stream:features> <starttls xmlns='urn:ietf:params:xml:xmpp-tls'><required/> </starttls><mechanisms value='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>x-google-token</mechanism> <mechanism>x-oauth2</mechanism></mechanisms></stream:features> cliente: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> servidor: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>...[comunicación CIFRADA]... Si nos centramos en el intercambio inicial de información podemos observar como el cliente y el servidor negocian el cifrado de la comunicación en texto claro. Qué ocurriría si en un nodo intermedio de la comunicación se establece una pasarela que altere esos datos y elimine la obligación impuesta por el servidor de cifrar la comunicación?. Veámoslo: cliente: <stream:stream to='gmail.com' xml:lang='en' version='1.0' xmlns:stream='

17 xmlns='jabber:client'> servidor: <stream:stream from='gmail.com' id='b db0854c5' version='1.0' xmlns:stream=' xmlns='jabber:client'> <stream:features> <mechanisms value='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>x-google-token</mechanism> <mechanism>x-oauth2</mechanism></mechanisms></stream:features> cliente: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='x-google-token'>ahr1zw80a(...)</auth> servidor: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>...[comunicación EN TEXTO CLARO]... Como se puede observar, ni el cliente ha rechazado la configuración indicada por el servidor (que, al ser el cliente oficial debería bloquear comunicaciones no cifradas puesto que el servicio no las permite) ni el servidor ha cerrado la conexión al no haberse cumplido las condiciones impuestas. Si analizamos en detalle el proceso de autenticación podemos observar que el cliente elige la autenticación 'X-GOOGLE-TOKEN'. Esta autenticación indica al cliente que a de autenticarse paralelamente a través del servicio 'ClientLogin' de Google y proveer como contraseña de la cuenta el token 'AUTH' devuelto por el servicio. Uno de los mecanismos que implementa XMPP por defecto es 'PLAIN' en el cuál se envían las credenciales de la cuenta codificadas en base 64. Qué ocurrirá si, al igual que hemos hecho con la configuración de cifrado, le indicamos al cliente que utilice 'PLAIN' en vez de 'X-GOOGLE- TOKEN'? Veámoslo: cliente: <stream:stream to='gmail.com' xml:lang='en' version='1.0' xmlns:stream=' xmlns='jabber:client'> servidor: <stream:stream from='gmail.com' id='b db0854c5' version='1.0' xmlns:stream=' xmlns='jabber:client'> <stream:features> <mechanisms value='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>plain</mechanism></mechanisms></stream:features> cliente: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='plain'>ahr1z(...)</auth>

18 pasarela: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='x-google-token'>ahr1zw80a(...)</auth> servidor: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> AHR1Z(...) -> Decodificación B64 [Usuario: Contraseña: mipassword] Como podemos observar, nuevamente el cliente no rechaza la conexión y utiliza el mecanismo indicado por el servidor (en este caso el único permitido es 'PLAIN'), pudiéndose interceptar sus credenciales al no cifrarse el tráfico. Aun así, el servidor de Google en este caso sí que denegaría la conexión porque no permite ese mecanismo, por lo que sería necesario realizar el proceso de autenticación 'ClientLogin' en la pasarela y entregar al servidor el token 'AUTH' correcto (indicando como mecanismo 'X-GOOGLE-TOKEN'). Como hemos visto, por dos errores de implementación, tanto en el cliente como en el servidor, el protocolo se vuelve inseguro. Por este motivo se recomienda el uso de SSL para securizar la comunicación desde el primer momento (como ocurre en las versiones de Gtalk de dispositivos Android, las nuevas versiones de WhatsApp, etc). OTR En 2004 Borisov, Goldberg y Brewer propusieron la comunicación OTR, o también conocida como 'off-the-record' (siguiendo el escenario de la vida real en la que dos personas mantienen una conversación en una habitación cerrada sin ninguna grabadora escondida). Este tipo de modelo de comunicación está diseñado para cumplir con los requisitos de autenticación y confidencialidad de los mensajes. A través de este modelo los usuarios se autentican entre ellos utilizando sus propias claves públicas (utilizadas únicamente para firmar digitalmente). Haciendo uso del protocolo criptográfico Diffie-Hellman (DH) se establecen una clave de cifrado y una MAC ('Message Authentication Code') y el usuario únicamente firma las claves públicas iniciales de DH. Cada mensaje que se envíe será cifrado con una clave diferente. La desventaja principal de este modelo radica en que los usuarios de mensajería instantánea por regla general no acostumbran a tener llaves de firma digital y su creación y mantenimiento supondría un problema. A pesar de esto, los plugins disponibles para los distintos clientes realizan este proceso de forma transparente, acercando a todos el uso del modelo. Otras desventajas serían la imposibilidad de intercambiar ficheros entre usuarios, realizar video-llamadas y demás servicios que se vean afectados por la negociación de la clave de cifrado y MAC que realiza continuamente el protocolo. Con soluciones como OTR (y otras que hacen uso directamente de GPG) es posible añadir una capa de seguridad adicional a las comunicaciones en cualquiera de los protocolos que soporte el cliente multiprotocolo que se esté utilizando (p.e permitiría cifrar los mensajes en MSNP).

19 PIDGIN Como indican en su página oficial, Pidgin es un cliente de mensajería instantánea multiprotocolo (soporta los principales protocolos como OSCAR, MSNP y XMPP) y multicuenta (puedes comunicarte simultáneamente con usuarios de distintos servicios). Es compatible con Windows, Linux y MacOS (utilizando Adium). Gracias a los plugins es posible no sólo hacer uso de las funcionalidades de cada uno de los servicios (como transferencia de archivos) sino que también se pueden ampliar (como hemos visto en el apartado de OTR). CONFIGURACIÓN DE UNA CUENTA EN PIDGIN Figura 5: Configuración segura de una cuenta de Google Talk Figura 6: Configuración por defecto de una cuenta de Facebook

20 Figura 7: Tráfico generado por Google Talk (Arriba) y Facebook Chat (Abajo) Figura 8: Tráfico generado por Facebook Chat Si observamos la Figura 7 podemos comprobar cómo, mientras que la configuración de Google Talk nos ofrece una comunicación correctamente cifrada, en el caso de Facebook podemos observar las trazas de tráfico propias del cifrado de XMPP (como son STARTTLS y PROCEED), pudiéndose observar de forma más clara en la Figura 8.

21 Por este motivo, es imprescindible realizar una configuración correcta del servicio. De esta forma el servicio no será vulnerable a los ataques descritos en el apartado 'Ataque práctico a XMPP'. Figura 9: Configuración segura de una cuenta de Facebook Chat. CONFIGURACIÓN DEL PLUGIN DE OTR EN PIDGIN El plugin se puede descargar desde la página: Figura 10: Configuración del plugin desde el panel de complementos.

22 Figura 11: Ventana de chat sin/con OTR instalado. Figura 12: Pantalla para verificar al usuario (menú OTR de la ventana de chat).

23 REFERENCIAS 1. A Study of Internet Instant Messaging and Chat Protocols - Raymond B. Jennings III, Erich M. Nahum, David P. Olshefski, Debanjan Saha, Zon-Yin Shae, and Chris Waters, IBM T.J. Watson Research Center 2. Cryptography in Instant Messaging - Daniel Senff 3. Hakin9: Instant Paranoia - Konstantin Klyagin 4. Honeybot, Your Man in the Middle for Automated Social Engineering - Tobias Lauinger, Veikko Pankakoski, Davide Balzarotti, Engin Kirda and Sophia-Antipolis 5. How safe is instant messaging? A security and privacy survey - CNET News 6. Insight into the Gtalk Protocol - Riyad Alshammari y A. Nur Zincir-Heywood 7. Instant Insecurity: Security Issues of Instant Messaging - Neal Hindocha 8. Instant Messaging Security - Government of the HKSAR 9. Instant Messaging: Architectures and Concepts - Lian Zheng 10. Instant Messaging: How Secure Is It? - SANS Institute 11. Instant Messenger Security - Gunter Ollmann 12. Mensajería Instantánea en Internet - Marcelo F. Fernández 13. Presence and Mobile Instant Messaging - Ajith Kannath y Sandeep Katumalla 14. Review and Comparison of Instant Messaging Protocols - Tim van Lokven 15. Secure MSN Messenger - Darren McCourt y Ning Zhang 16. Secure Public Instant Messaging - Mohammad Abdul Mannan 17. Securing Instant Messaging Communications Using Limited-Used Session Keys - Supakorn Kungpisdan and Nitoon Moonviriyakit 18. Securing Public Instant Messaging (IM) At Work - Niegel Williams and Joanne Ly 19. Security Analysis of Windows Live Messenger - Derick H. Christopher E., John K., y Oscar H. 20. Security of Instant Messenger - Juraj Sasko 21. Skype: A practical security analysis - SANS Institute 22. VoIP and Skype Security - Simson L. Garfinkel 23. XMPP: The protocol for Open, Extensible Instant Messaging - Jive Software White Paper