lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Apr 2014 10:26:09 +0200
From: jdiaz@...t.inteco.es
To: Dominik Schürmann <dominik@...inikschuermann.de>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Telegram authentication bypass

Hello,

Thanks for your response.

Telegram actually promotes the development of unofficial apps by providing
a free API which allows anyone to interact with their services, and easily
develop and distribute an unofficial client. Moreover, they do not provide
any mechanism at all to verify the authenticity of their public key (fact
that was already known, see e.g.
http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest).

Thus, in this case, the development of such malicious client is not out of
their security model and it is an actual design flaw. By definition,
something that it is not outside your security model and allows to
circumvent or reduce some of the allegedly provided security properties,
is an attack.

The same does not apply to other protocols, as long as the protocols are not
tied up to providing a specific service (since in that case, it is the
service who needs to worry to maintain the same security model).

Moreover, despite being aware of this issue, Telegram does not provide any
means to effectively revoke access to specific applications (nor to look up
which applications have access to your account at all!). Hence, Telegram
users are completely blinded and unprotected in this issue. For that
matter, and for instance, an OAUTH-like approach would mitigate the risk.
Quoting Wikipedia:

"OAuth provides client applications a 'secure delegated access' to server
resources on behalf of a resource owner. It specifies a process for
resource owners to authorize third-party access to their server resources
without sharing their credentials."

Finally, while we have developed the PoC by making use of a modified
client, there are other attack vectors. For instance, a third party
malware that modifies the public key used by the (official or unofficial)
client, silently trojanizing it.

Best,

Jesus

> Hello,
>
> like Telegram said, this is definitely out of normal security models!
> You assume that the client app has been compromised, e.g. by downloading
> an unofficial one.
> If you assume that, every crypto protocol out there is broken! What
> about downloading a forked Firefox version? Maybe it includes some MitM
> certificates...
> Nothing protects you against your attack...
>
> Regards from a suprised
> Dominik
>
> On Mon, 2014-04-28 at 11:17 +0200, jdiaz@...t.inteco.es wrote:
>> Hello,
>>
>> A security issue affecting Telegram instant messaging service has been
>> made public by INTECO-CERT. Further details follow.
>>
>> ----------------------------------
>> Affected products and services:
>> ----------------------------------
>>
>> Telegram instant messaging service.
>>
>>
>> ----------------------------------
>> Overview:
>> ----------------------------------
>>
>> Telegram authentication mechanism may be circumvented, since there is no
>> way to verify the legitimacy of Telegram’s public keys and thus if the
>> client is communicating with a legitimate server. This may allow an
>> attacker leveraging this issue (e.g. by distributing a slightly modified
>> client) to obtain almost full control of the victim's account. Further,
>> the behavior of the victim’s client is exactly the same than the
>> behavior
>> of a legitimate client.
>>
>> For a detailed analysis, including a PoC, visit:
>> http://www.inteco.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios/telegram_authentication
>> (blog post with extended abstract) or
>> http://cert.inteco.es/extfrontinteco/img/File/intecocert/EstudiosInformes/INT_Telegram_EN.pdf
>> (detailed research results).
>>
>> ----------------------------------
>> Timeline:
>> ----------------------------------
>>
>> 2014.03.07 - Initial contact with Telegram security team.
>> 2014.03.10 - Telegram response informing that this issue is out of their
>> security model.
>> 2014.03.11 - Submission of PoC to Telegram security team.
>> 2014.04.28 - Publication of research results.
>>
>>
>> Sincerely,
>>
>> Jesus Diaz
>>
>>
>>
>> _______________________________________________
>> Sent through the Full Disclosure mailing list
>> http://nmap.org/mailman/listinfo/fulldisclosure
>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/



_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ