Telegram: Dos clientes por la clave de uno

Telegram es la nueva alternativa a Whatsapp, lanzada a mediados de agosto de 2013. La principal novedad: combina una experiencia de usuario sencilla con un mayor grado de seguridad que sus competidores. Además, sus protocolos de comunicaciones (diseño propio) son libres y la API para comunicar con sus servidores es abierta, de la misma forma que el código de su cliente oficial. Esto facilita enormemente el desarrollo de aplicaciones de terceros, además de fomentarlo. De hecho, aparte de la aplicación oficial (Telegram), disponible para Android e iOS, desde la web de Telegram se enlazan 6 aplicaciones no oficiales para diversos dispositivos y entornos: Linux, Windows, Mac, en fase beta, y otras siete en fase pre-alpha. Esta estrategia sigue al pie de la letra los famosos principios de Kerckhoffs, que básicamente establecen que la seguridad de un sistema en ningún caso debe basarse en mantener secreto el diseño del sistema en sí mismo.

No obstante, como veremos a continuación, esto tiene importantes implicaciones en lo que se refiere al diseño del sistema, ya que hay que tener en cuenta la facilidad del adversario en manipular el sistema.

Se puede acceder a una explicación detallada de lo explicado en este post desde el portal de INTECO.

Descripción del protocolo y del exploit

El protocolo de autorización y autenticación de Telegram consiste en el envío de 6 mensajes, en los que se establece una clave compartida utilizando el protocolo Diffie-Hellman. Típicamente, el primer Data Center con el que contacta el cliente indica las direcciones IP y puertos de otros Data Centers con los que el cliente repite el mismo proceso, estableciendo una clave con cada uno de ellos. Para finalizar el proceso, uno de los Data Centers “le pide” al cliente el número de teléfono móvil al que quiere asociar la clave. El cliente lo introduce, y Telegram envía a dicho móvil un código, vía SMS, que el cliente tendrá que enviar de vuelta para completar la activación del servicio en dicho dispositivo. Este proceso se muestra en la Figura 1. Telegram se refiere a las claves negociadas mediante este protocolo con el nombre de authorization_keys.

Figura 1. Protocolo de autenticación de Telegram.

Este protocolo autentica al cliente. En cuanto al servidor, se autentica incluyendo la huella digital (fingerprint en la figura) asociada a su clave pública. A partir de esto, los aspectos más destacables de la autenticación son los siguientes:

• El cliente comprobará si la fingerprint recibida coincide con alguna de las claves públicas que tiene preinstaladas.
• En caso afirmativo, el cliente usará la clave pública correspondiente para cifrar el segundo mensaje que envía (req_DH_params).
• Este mensaje cifrado contiene un número aleatorio que se utilizará como base para derivar una clave AES temporal, con la que se cifrará el resto de los mensajes del intercambio.
• Dado que el número aleatorio es cifrado con la clave pública de Telegram, únicamente Telegram podrá descifrarlo, realizando su autenticación implícitamente de esta manera.

Entonces, ¿cómo sortear la autenticación? Dado que se utiliza un método de intercambio de claves seguro, como es Diffie-Hellman, esto no parece probable. No obstante, en Telegram promueven el desarrollo de clientes por parte de terceros:

For the moment we are focusing on open sourcing the things that allow developers to quickly build something using our API.

Su API es pública, permitiendo acceso a sus servicios a cualquiera que desarrolle un cliente que siga el protocolo correctamente (sus protocolos también son públicos). Con esto, si un atacante consigue que su(s) víctima(s) instalen un cliente desarrollado por él, con unos cambios mínimos, podrá efectivamente saltarse la autenticación anterior.

Todo se basa en modificar la clave pública preinstalada en el cliente de la víctima, y modificar la dirección IP del Data Center con el que se contacta inicialmente (o llevar a cabo ataques similares que permitan modificar estos valores). Estableciendo ambos a valores controlados por el atacante, este podrá efectuar un Man-in-the-Middle (MITM) entre la víctima y el servidor legítimo de Telegram. Esto no es nuevo, ya ha sido comentado por expertos en seguridad, como se expone por ejemplo en Cryptofails: "They do not authenticate public keys" ("Ellos no autentican las claves públicas").

Siendo la modificación de la clave el punto crítico, esto implica, por ejemplo, que se deba modificar la fingerprint que el servidor envía al cliente en su primer mensaje. La Figura 2 muestra un volcado real (procesado para que sea legible) de dicho mensaje, y del valor que cambia el MITM.

Figura 2. El MITM hace el cambio de la fingerprint.

A ojos de la víctima, estará comunicándose con Telegram y, a ojos de Telegram, la comunicación será con un cliente legítimo. El MITM sólo tendrá que interceptar los mensajes que van en un sentido, cambiar unos valores específicos, volver a cifrarlos y reenviarlos a su destinatario final.

Posible impacto

La explotación de este ataque daría a un atacante control total sobre la cuenta de Telegram de la víctima. En concreto, permitiría:

• Acceder de forma silenciosa a toda la información intercambiada, excepto conversaciones cifradas que no hayan sido interceptadas. Esto incluye también acceso al histórico de mensajes (que no hayan sido borrados).
• Suplantar la identidad de la victima modificando mensajes recibidos y enviados al vuelo. Así mismo, es posible enviar mensajes sin conocimiento del usuario afectado, excepto en el caso de las conversaciones cifradas.
• Bloquear mensajes.
• Abrir nuevos chats.
• Aceptar y abrir nuevas conversaciones cifradas.
• Obtener el listado de contactos que la víctima tiene en Telegram, junto con sus respectivos números de teléfono.
• Denegar temporalmente el acceso a Telegram a la víctima desde otros dispositivos si ejecuta la opción "Cerrar todas las otras sesiones".

En muchos de estos casos, las acciones del atacante pasarían totalmente desapercibidas para la víctima y sus interlocutores dado que el comportamiento del cliente modificado es exactamente el mismo que el de un cliente legítimo. No sería así, por ejemplo, si el atacante abre una nueva conversación o cierra las otras sesiones, ya que esto levantaría sospechas pese a ser posible. Peor aún, dado que las authorization keys tienen una vida útil larga (a menos que el usuario las revoque) la persistencia de este ataque es también elevada.

Figura 3. Ejemplo de consulta de contactos.

Requisitos para el ataque

Como se ha mencionado, es necesario modificar la clave pública y las direcciones IP que el cliente tiene preinstaladas o configuradas como correspondientes a Telegram. Esto puede parecer demasiado restrictivo y posiblemente así sea en muchos casos. No obstante, como también se ha dicho, Telegram fomenta el desarrollo por parte de terceros, lo cual facilita la tarea enormemente. Por un lado, estas aplicaciones no oficiales probablemente no hayan sido sujetas a auditorías de seguridad o a buenas prácticas de programación segura que prevengan satisfactoriamente la explotación de este problema. Por otra parte, a partir de los clientes existentes, es trivial crear un cliente modificado de la forma necesaria para activar el ataque.

Finalmente, además de los clientes no oficiales referenciados desde la web de Telegram, también existen clientes no incluidos en esa lista. Ejemplos son la versión en portugués de Webogram Chrome App (que no parece desarrollada por la misma persona) o una versión para Ubuntu Touch. Por supuesto, que las aplicaciones no estén referenciadas desde la web de Telegram no significa que sean maliciosas. No obstante, pone de manifiesto que existen métodos alternativos para obtener clientes de Telegram y que, probablemente, por dichas vías se puedan introducir clientes maliciosos que pasen más inadvertidos.

Proof Of Concept y estado actual de la investigación

Como prueba de esta debilidad en el protocolo de autenticación de Telegram, se ha desarrollado una prueba de concepto (PoC). Esta PoC está basada en el cliente de Telegram para Linux, CLI. Está compuesta por un cliente modificado (que incluye una clave pública distinta a la legítima y tiene la dirección IP del servidor alterada); y en un MITM que actúa de servidor de cara a la víctima, y de cliente de cara al servidor de Telegram. La PoC realiza el proceso de autenticación completo hasta el punto en el que el servidor de Telegram envía el SMS, la víctima lo introduce y el servidor notifica que la autenticación ha terminado con éxito. Con el fin de evitar el uso de esta aplicación directamente para distribuir clientes maliciosos, en este punto, el programa se detiene. La PoC está disponible en GitHub.

En cuanto al proceso de la investigación y la notificación a Telegram:

1. El día 7 de marzo de 2014 se contactó con Telegram por primera vez, informándoles de los resultados del estudio.
2. El 10 de marzo de 2014, Telegram respondió a este primer email, informando que un cliente modificado se escapa de su modelo de seguridad. La solución propuesta por Telegram para conseguir la máxima seguridad, pasa por utilizar únicamente el cliente oficial o clientes con código abierto verificados exhaustivamente.
3. El día 11 de marzo de 2014 se remitió a Telegram la PoC mencionada anteriormente.
4. El día 28 de abril de 2014, el 52º día después del primer contacto y tras varios emails enviados a Telegram, sin respuesta, los resultados del estudio se hacen públicos en el portal web de INTECO.

Se puede acceder a una explicación detallada de todo el proceso en la sección de guías y estudios del portal de INTECO.