Inicio / Blog / Telegram: Two clients for the key of one

Telegram: Two clients for the key of one

Publicado el 28/04/2014, por Jesús Díaz (INCIBE)
Telegram: Two clients for the key of one

Telegram, launched in mid August, 2013, is the new alternative to WhatsApp. Its main novelty: it combines an easy user experience with a security level higher than that of its competitors. Moreover, its communication protocols (designed by themselves) are free, and the API for interacting with their servers is open, just like the code of the official client. This enormously eases the development of third party applications, and endorses it. In fact, besides the official application (Telegram), available for Android and iOS, from Telegram’s website, 6 unofficial applications for several devices and environments: Linux, Windows, Mac, in beta stage, and another seven in a pre-alpha state. This strategy follows to the letter the well-known Kerckhoffs principles, stating that the security of a system must never rely in keeping it secret.

Nevertheless, as we will see below, this carries important implications concerning the design of the system, since it is mandatory to take into account the ease to manipulate it.

A more detailed explanation of what is described here is available at INTECO’s website (PDF file available in English and Spanish).

Protocol description and exploit

Telegram’s authorization and authentication protocol is composed by 3 message exchanges by means of which a shared key is negotiated using the Diffie-Hellman protocol. Typically, the first Data Center with which the client establishes contact indicates the IP addresses and port numbers of other Data Centers. The process is then repeated with these new Data Centers, setting a different shared key with each of them. To complete the process, one of the Data Centers “asks” the client for the cell phone number to which this key is to be associated with. The client introduces the number and Telegram sends a code, via SMS, that the client has to send back in order to complete the activation of the service in the new device. This process is depicted in Figure 1. Telegram refers to the keys negotiated by means of this protocol as authorization_keys.

telegram_auth

Figure 1. Telegram’s authentication protocol.

This protocol authenticates the client. As for the server, it is authenticated by including the fingerprint of its public key. The main points of this process are:

  • The client checks that the received fingerprint matches one of the preinstalled keys (included by default in the software).
  • If affirmative, the client will use the associated public key to cipher the second message he sends (req_DH_params).
  • This encrypted message contains a random number, used as a base to derive a temporary AES key that will be used to encrypt the remaining messages of the protocol.
  • Given that this random number is encrypted with Telegram’s public key, only Telegram will be able to decrypt it. This actually acts as an implicit server authentication.

But then, how could someone bypass this authentication? Since a secure key exchange method is being used (Diffie-Hellman), this does not seem possible. However, we must recall that Telegram promotes the development of third party clients, fact that changes the scenario:

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

Moreover, their API is public, allowing access to their services to anyone who develops a client that correctly follows their protocols (also public). With this, if an attacker develops a client and gets a victim to install it, using minimal modifications, the attacker could actually circumvent the previous authentication.

Everything is based on modifying the public key preinstalled in the victim’s client, and modifying the IP address of the first Data Center to contact with (or perform attacks with similar effects on an unmodified client). By setting a public key and IP address controlled by the attacker, a Man-in-the-Middle (MITM) attack is enabled. This is not new, and has already been pointed out by security experts, like it is stated (for instance) in Cryptofails: "They do not authenticate public keys".

Being the key the critical point, this implies that the fingerprint sent by the server to the client also needs to be modified. Figure 2 shows a real dump (processed to make it readable) of this message, and the value set by the MITM.

telegram_mitm_auth_dump

Figure 2. The MITM switches the fingerprint.

Possible impact

A successful exploitation of this attack would give an attacker full control over the victim’s Telegram account. Specifically, it would permit:

  • Transparent access to all exchanged information, except secret chats that have not been intercepted. This also includes the message history (for those messages that have not been deleted).
  • Impersonate the victim, by modifying the received and sent messages on the fly. Additionally, it is possible to send messages without knowledge of the victim, except for secret chats.
  • Block messages.
  • Open new chats.
  • Accept and open new secret chats.
  • Obtain the Telegram’s contact list of the victim, along with their cell phone numbers.
  • Temporarily deny access to Telegram through other devices in which the victim has also set up Telegram by executing the option "Close all other sessions".

In many of these cases, the actions performed by the attacker would go completely unnoticed to the victim and his interlocutor, since the behaviour of the client is exactly the same than that of a legitimate one. This would not be the case if the attacker opens or closes new chats, since this would raise suspicion (despite being possible). But even worse, since the authorization keys have a long lifespan (unless the user revokes them) the persistence of this attack is also high.

telegram_contact_list

Figure 3. Contact list query example.

Attack requirements

As has been already mentioned, it is necessary to modify the public key and IP addresses associated to Telegram that are preinstalled in the client. This may seem too restrictive, and it may be so in many situations. However, as has also been said, Telegram promotes the development of third party clients, fact that enormously eases these attacks. First, unofficial applications probably have not been subject to comprehensive security auditing nor programming good practices preventing this issue. Additionally, from already existing clients, is trivial to create a modified client that enables the attack.

Finally, besides the unofficial clients referenced from Telegram’s website, there are also clients not included in this list. For instance, the portuguese version of Webogram Chrome App (which does not seem to be developed by the same person) or a version for Ubuntu Touch. Of course, the fact of these applications not being referenced from Telegram’s website does not mean that they are malicious. Nevertheless, it shows that there exist alternative means to obtain Telegram clients and that, through these means, malicious clients would not probably be detected.

 

Proof Of Concept and current state of the research

As proof of this issue in Telegram’s authentication protocol, we have developed a Proof of Concept (PoC). This PoC is based on Telegram’s Linux client, CLI. It is composed by a modified client (including a public key different than the legitimate one and with the server IP address also modified); and a MITM that acts as server to the eyes of the victim, and as client to the eyes of Telegram. This PoC performs the complete authentication process, allows the victim to receive the SMS and send back the activation code. Finally, the server informs of a successful authentication. In order to prevent a direct use of this PoC for the distribution of malicious clients, the program stops at this point. The PoC is available in GitHub.

As for the research process and notification to Telegram:

  1. 7 March 2014: initial contact with Telegram informing them of the obtained results.
  2. 10 March 2014: Telegram response to the first email, informing that the weaknesses in the authentication mechanisms presented through a modified client are out of the scope of their security model. Their proposed solution, in order to achieve maximum security, is to use only the official client or open source clients that have been comprehensively verified.
  3. 11 March 2014: submission of the PoC to Telegram.
  4. 28 April 2014: 52nd day after first contact and after several unanswered mails, the results of this study are made public at INTECO’s website.

A detailed explanation of the complete process can be obtained in the guides and studies section of INTECO’s website.