25 mayo 2010

Seguridad en protocolos de mensajería

Pese al paso de los años y los nuevos conceptos que se van 'inventando', el chat mediante protocolos de mensajería sigue teniendo una amplia cuota de protagonismo en las actividades online.

Con la transición del PC en casa a los dispositivos de tipo portátil y smart*, pasamos de entornos 'seguros' a entornos potencialmente mas peligrosos como Wifis públicas o centros de trabajo, donde es realmente fácil interceptar comunicaciones.

Existen muchos mitos sobre 'que te pueden hacer' si haces login en el MSN o Gtalk desde un lugar donde haya ojos curiosos, por eso vamos a explicar como funciona cada protocolo y el tipo de riesgos potenciales de cada uno.

Empezamos por 'el rey':
MSN / Messenger

Sin duda el protocolo mas empleado y con mas cuota de usuarios en España. El protocolo MSN no es un protocolo estático, va mutando periódicamente y Microsoft va sacando actualizaciones en las que varia ligeramente su funcionamiento. Dado que sus internals no son públicos, toca 'reversear' y deducir como funciona. A día de hoy la última especificación de la que se cuenta con información es esta y la parte que mas nos interesa es la que concierne a como se realiza la autenticación.

A grosso modo:
  • El cliente lanza la petición de login al servidor MSN, 
  • El servidor MSN facilita un 'reto' (un montón de caracteres aleatorios para generar entropía) y un servidor 'de tickets'
  • El cliente envía el Login + Password + Reto mediante una conexión SSL al servidor de tickets y, en caso de ser válida, obtiene un ticket
  • El cliente envía ese ticket al servidor MSN


Una vez completada esta secuencia, el resto de la comunicación se realiza en texto plano sin codificación alguna

Gtalk (cliente oficial)

Como es bien sabido, Google para implementar su sistema de mensajería se ha decidido por una implementación basada en XMPP / Jabber. El problema es que Jabber aun siendo un protocolo estandarizado admite mil y una forma de hacer las cosas (algunas mas seguras, otras mas inseguras). En concreto, Google en su implementación ofrece como formas de hacer auth dos posibilidades, una llamada Google-Token (totalmente fuera de especificación y propietaria de Google) y otra basada en TLS. El cliente oficial, como es lógico, emplea Google-Token y ciertamente debilita mucho la seguridad del sistema. Funciona de la siguiente manera:
  • El cliente se conecta vía SSL a Google para hacer el auth
  • Google entrega un token al cliente
  • El cliente usa ese token como método de autenticación

Terminada esta fase, el resto de la comunicación va en texto plano

Gtalk (clientes XMPP / Jabber alternativos)

Si obviamos el cliente oficial de Google y nos decantamos por alternativas como Gajim o Pidgin (necesario si empleas una plataforma como Linux), la cosa cambia radicalmente. El método empleado está completamente basado en TLS.
  • El cliente inicia la comunicación con el servidor XMPP
  • Se negocia un túnel TLS
  • Se envían las credenciales
A partir de ahí toda la comunicación va cifrada

Facebook

Recientemente Facebook ha abierto su chat públicamente mediante una plataforma basada en XMPP / Jabber. Como ya decía anteriormente, las formas en las que se puede hacer auth en XMPP son increíblemente versátiles. En el caso de Facebook han optado por un método basado en Digest SASL. SASL es un protocolo ampliamente utilizado para autenticación en servicios como IMAP o SMTP. Para hacerlo aun mas divertido, SASL soporta tres modos de autenticación en función de la seguridad que se quiera aplicar. El primero llamado 'auth' únicamente sirve para intercambiar credenciales de forma segura basado en retos, el servidor genera una cadena aleatoria y el cliente debe responder con un hash de sus credenciales + el reto. El segundo modo 'auth-int' añade una capa de integridad añadiendo a cada intercambio un 'código de integridad' empleando HMAC. El tercero, 'auth-conf' añade a todo eso una capa de cifrado. ¿Cual método ha elegido Facebook? auth normal.

Después de eso la conversación continua en texto plano

Conclusiones

Una vez explicado como funciona cada protocolo, a modo resumen una tabla con los riesgos potenciales que podemos sufrir si una sesión de chat es interceptada.

Los criterios de evaluación han sido

[ ] Crackeable: La posibilidad de que un atacante que capture la autenticación pueda aplicar fuerza bruta sobre lo interceptado para averiguar la contraseña
[ ] Usuario deducible: Se evalúa si durante la fase de autenticación un atacante podría averiguar el login / dirección de correo ej: fulano@hotmail.com
[ ] Sniffing conversación: El hecho de que los mensajes de chat intercambiados sean susceptibles de leerse en texto plano

** En el caso de Gtalk solo se contempla en formato 'cliente alternativo'


14 comments :

Rusty73 dijo...

A finales del año pasado intente hacer una especie de sniffing de las conversaciones del msn y me encontré que estaban cifradas, y volviendo a probar ahora, el wireshark me las pone correctamente en texto plano XD.

Yo creo que Microsoft ahora esta dando soporte a varios protocolos a la vez y escoge el adecuado para cada version, sobre todo para no dejar "de lado" a los clientes opensource, un ejemplo claro es la posibilidad de iniciar varias sesiones a la vez con su cliente oficial pero con los de opensource no se puede.

A falta de hacer pruebas, yo creo que si los dos extremos usan la ultima versión del cliente oficial, la conversación va cifrada.

Anónimo dijo...

Muy interesante

svoboda dijo...

Actualmente MSN no se como estará, pero desde luego antes era fácilmente snifable una conversación. De echo, esa era una de las razones por las que el MSN te sacaba siempre el mensaje de advertencia de no compartir claves, ni datos privados. Actualmente creo que ya no sale.

Lo que si que me ha sorprendido, es que para gtalk la aplicación oficial no cifré nada, y los clientes alternativos si. Me parece muy curioso.

Por lo demás, el artículo está muy bien, muy claro y entretenido.

Lo triste, es darte cuanta de que de las grandes compañías, ninguna se preocupa de la privacidad.

J. L. Pino dijo...

La pena es que Pidgin almacena las contraseñas en texto plano...
http://developer.pidgin.im/ticket/673

fearu dijo...

Y una cosa, el protocolo messenger puede ir sobre HTTP -por ejemplo pidgin lo admite- para evitar bloqueos, ¿va el login cifrado en este caso?

Además, voy a poner un caso concreto donde creo que no va cifrado. Microsoft tiene un webmessenger en login.live.com, y por defecto el login se hace sobre http. La web tiene un link de iniciar sesión con seguridad mejorada que te manda a la versión https de la página.

Por eso sospecho que no siempre que iniciamos sesión en el servicio de messenger va cifrado.

Anónimo dijo...

Espero que el "crackeable" no solo se refiera a la posibilidad de usar la contraseña sino que incluye que los "tickets" no pueden ser reutilizados aunque sean snifados.

Anónimo dijo...

Está claro que si tenemos algo delicado que decir no decirlo por Messenger... creo que para el cliente oficial existía el programa SimpLite MSN que las cifraba de manera similar a como lo hace PGP, pero me parece que el proyecto está parado.

Pero total, si hoy en día casi todos cuelgan sus vergüenzas en Tuenti/Facebook... menos algunos pirados que nos da por usar Enigmail+GPG. :P

Yago Jesus dijo...

@Rusty73 Hasta donde yo sé, ningun MSNP soporta cifrado de conversación, de hecho la 'mejora' en seguridad que se ha introducido entre protocolos antiguos y modernos es que antes su auth se parecía a la de Facebook (SASL) y no habia esa capa SSL. Por lo demás siempre han sido sniffables. Por lo demás, estas en lo cierto en que se soportan varias versiones a la vez, pero mas bien por compatibilidad entre sus clientes que como atención a las versiones libres (y sin publicidad de Microsoft)

@fearu No he podido analizar las versiones http pero me lo apunto para un posible update del post.

@Anónimo, como Crackeable entiendo la posibilidad de, tomado un dato X en formato hash tratar de aplicar fuerza bruta con un diccionario hasta conseguir un hash idéntico. Lo otro que mencionas se considera ataques de tipo 'Replay' pero no es el caso en SASL ya que el nonce (string aleatorio que envía el server) siempre debe ser diferente

Busindre dijo...

Para Pidgin hay plugins que pueden resultar interesantes a la hora de querer cifrar conversaciones MSN, como son "OTR" y "Pidgin-Encryption".

Saludos

Rusty73 dijo...

@Yago, gracias por la aclaracion, simplemente debia de estar un poco espeso ese dia o no se debio de enviar.

También seria interesante ver el chat de face... digo tuenti (que como ultimamente se parecen... :P), ya tengo tarea para despues de examenes :P.

Rodrigo Moreno dijo...

Y el MSN no solo se puede snifear sino que vi un tutorial de ettercap que podían reemplazar pedazos de la conversación por otro que el atacante desee...

Esta bueno este estudio... Veré si empiezo a usar más mi Gtalk, obviamente con pidgin!

Unknown dijo...

Si utilizamos el navegador para hablar por gmail no sería posible ver las conversaciones ya que estamos bajos SSL. Sé que no es el software nativo gtalk, pero sigue siendo nativo de google.

Lo comento porque se ha puesto como ejemplo el live de MSN.

NaCl u2

Rigolox dijo...

Si utilizamos el navegador para hablar por gmail no sería posible ver las conversaciones ya que estamos bajos SSL. Sé que no es el software nativo gtalk, pero sigue siendo nativo de google.

Lo comento porque se ha puesto como ejemplo el live de MSN.

NaCl u2

Anonymous dijo...

Está claro que si tenemos algo delicado que decir no decirlo por Messenger... creo que para el cliente oficial existía el programa SimpLite MSN que las cifraba de manera similar a como lo hace PGP, pero me parece que el proyecto está parado.

Pero total, si hoy en día casi todos cuelgan sus vergüenzas en Tuenti/Facebook... menos algunos pirados que nos da por usar Enigmail+GPG. :P