Full Disclosure mailing list archives
Re: Telegram authentication bypass
From: Mario Vilas <mvilas () gmail com>
Date: Tue, 29 Apr 2014 12:07:02 +0200
Hi, I'm afraid I have a few questions and some criticism. My responses inline: On Tue, Apr 29, 2014 at 10:26 AM, <jdiaz () cert inteco es> wrote:
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 ).
If the client has an embedded key, why would it need any authentication? The only way to bypass that is to modify the client. The same would apply to every other encrypted service on the planet (as someone pointed out, you could do the same thing with Mozilla Firefox).
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.
I pretty sure the Telegram developers were just trying to be polite when they mentioned their security model instead of just blowing you off. :) The attack you're describing requires the ability to modify the client software. There is no vulnerability because you're not crossing any security boundaries - encryption can only let you communicate securely between two points over an insecure channel, but it cannot protect you against someone compromising *your own* endpoint! If it was possible to "fix" this vulnerability, all computers in the world could be made immune to all kinds of malware. For this reason, the scenario you describe is not contemplated in *any*security model, not just Telegram's.
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).
I'm afraid I do not understand this sentence. :( How is this any different from modifying Mozilla's certificates? Why is it important that the protocol is tied up to a specific service? (And aren't most protocols like that anyway?) What do you mean by "maintain a security model" and how does a service "maintain" it?
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."
The Wikipedia quotation was completely unnecessary ;) It would be nice to have clients authenticate through OAUTH and let users revoke the authentication, we can agree on that. It would impact on usability though, which is probably why they rely on other means. You could say (you didn't) that in the event of a compromise there is no mitigation available for the user, and that would be something that needs fixing. But how does it affect the issue you describe *at all*? If malware can change the certificates, can't they also sniff all the traffic? And if they can, how does OAUTH help? I'm sorry, but this paragraph seems completely unrelated to the rest of the email... in fact, both here and in the advisory you keep mixing up the concepts of authentication and encryption, which seems puzzling to me.
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.
I'm afraid *unless you can provide a scenario where an actual security boundary is being bypassed*, all you're saying is you can install malware on your own phone, albeit in a roundabout way. There is nothing applications can do about that. The operating system may help to some degree by preventing applications from modifying each other and only allowing users to install pre-approved applications, but that's pretty much it, and it's completely generic - not something that affects Telegram in particular, nor something its developers can do anything about. This topic would make a nice blog entry :) but unless there's more information that you're not sharing, I simply don't see this as a vulnerability at all, it's a post exploitation technique valid for pretty much anything that uses cryptographic protocols. Regards, -Mario -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” _______________________________________________ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Current thread:
- Telegram authentication bypass jdiaz (Apr 28)
- Re: Telegram authentication bypass Dominik Schürmann (Apr 28)
- Re: Telegram authentication bypass jdiaz (Apr 29)
- Re: Telegram authentication bypass Mario Vilas (Apr 29)
- Re: Telegram authentication bypass Tony Arcieri (Apr 29)
- Re: Telegram authentication bypass jdiaz (Apr 29)
- Re: Telegram authentication bypass Hanno Böck (Apr 28)
- Re: Telegram authentication bypass Dominik Schürmann (Apr 28)