Message-ID: <CAJB2JztiEqxSfLHZOF6vBof44Jvs+C67iVWjX+H-4ubn4Y4_qw@mail.gmail.com>
Date: Tue, 29 Apr 2014 12:07:02 +0200
From: Mario Vilas <mvilas@...il.com>
To: jdiaz@...t.inteco.es
Cc: fulldisclosure <fulldisclosure@...lists.org>
Subject: Re: [FD] Telegram authentication bypass

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@...t.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/

Powered by blists - more mailing lists