The "P" in Telegram stands for Privacy

Summary: While understanding the implementation of various security and privacy measures in telegram, I identified that telegram fails again in terms of handling the users data. My initial study started with understanding how self-destructing messages work in the secret chats option, telegram says that "The clock starts ticking the moment the message is displayed on the recipient's screen (gets two check marks). As soon as the time runs out, the message disappears from both devices." 

 

Telegram which has 500 million active users suffers from a logical bug exists in telegram for macOS (7.3 (211334) Stable) which stores the local copy of received message (audio/video) on a custom path even after those messages are deleted/disappeared from the secret chat.

Technical analysis: Open telegram for macOS, send a recorded audio/video message in normal chat, the application leaks the sandbox path where the recorded message is stored in ".mp4" file.

In my case the path was (/var/folders/x7/khjtxvbn0lzgjyy9xzc18z100000gn/T/). While performing the same task under secret chat option the MediaResourceData(path://) URI was not leaked but the recorded audio/video message still gets stored on the above path.

 
In the video proof-of-concept the user receives a self-destructed message in the secret chat option, which gets stored even after the message is self-destructed.

 

Bonus: The above mentioned version of telegram for macOS stores local passcode in plain text, below is the video proof-of-concept.

 

Both the vulnerabilities was patched in version 7.4 (212543) Stable and 3000 EURO bounty was awarded. In past I've identified multiple vulnerabilities under Telegram you can read them here. Later today Fri 12 Feb 12:15 PM, CVE-2021-27204 & CVE-2021-27205 was assigned. What next?

Use Signal

— Elon Musk (@elonmusk) January 7, 2021

Read More

Telegram addresses another privacy issue

Summary: This is not a security vulnerability its a privacy issue. As I understand Telegram a messaging app focuses on privacy which has over 10,00,00,000+  downloads in Playstore. In this case, we are abusing a well-known feature of deleting messages, which allows users to delete messages sent by mistake or genuinely to any recipient. It was observed that once the message (image) is sent to the recipient, it still remains in the internal storage of the user which is located at  `/Telegram/Telegram Images/`path.

Technical analysis: I found this bug when I was researching about Telegram and MTProto protocol. To demonstrate this bug let's assume two people here, Bob and Alice.

Assume a scenario where Bob sends a message which is a confidential image and was mistakenly sent to Alice, Bob proceeds to utilize a feature of Telegram known as "Also delete for Alice" which would essentially delete the message for Alice. Apparently, this feature does not work as intended, as Alice would still be able to see the image stored under `/Telegram/Telegram Images/` folder, concluding that the feature only deletes the image from the chat window.

The highlighted issue is valid when we talk about Telegram "supergroups" as well, assume a case wherein you're a part of a group with 2,000,00 members and you accidentally share a media file not meant to be shared in that particular group and proceed to delete, by checking "delete for all members" present in the group. You're relying on a functionality that is broken since your file would still be present in storage for all users.
Aside from this, I found that since Telegram takes `read/write/modify` permission of the USB storage which technically means the confidential photo should have been deleted from Alice's device or storage.

Comparison: A compete, app for Telegram which is WhatsApp also has the same feature to "Delete for everyone". If you perform the following steps mentioned above in WhatsApp it deletes the confidential photo from Alice's `/Whatsapp/Whatsapp Media/Whatsapp Images/` folder and maintains the privacy however Telegram fails. WhatsApp takes the same permission when it comes to storage which is `read/write/modify`.

This issue could have a bigger impact and I am not sure how far this was in place; the word privacy of Telegram fails here again, and users trust against the Telegram is at risk.

Video PoC:



Affected version: I have tried this with the latest stable version (5.10.0 (1684)) of Telegram for Android. I haven't tried this with Telegram for iOS and Telegram for Windows but assuming this issue would exist on other these platforms.

Responsible disclosure: I submitted this to Telegram sec-team via security[at]telegram[dot]org and a fix was pushed in the latest version of Telegram 5.11. Also €2,500 was awarded by Telegram.

Other Workaround: The alternative solution would be to utilize the feature of "New Secret Chat" in Telegram where no such traces are left.

References: Picture used above credit and source[1]. Download the PDF version of this article[2]. Later CVE-2019-16248 was assigned to this issue.

Read More

Telegram anonymity fails in desktop - CVE-2018-17780

Hi Internet,

Summary: Strangely tdesktop 1.3.14 and Telegram for windows (3.3.0.0 WP8.1) leaks end user private and public IP address while making calls. This bug was awarded €2000 by Telegram security team. (Sweeet..)

Img Src: https://telegram.org/img/tl_card_synchronize.gif

Telegram is supposedly a secure messaging application, but it forces clients to only use P2P connection while initiating a call, however this setting can also be changed from "Settings > Privacy and security > Calls > peer-to-peer" to other available options. The tdesktop and telegram for windows breaks this trust by leaking public/private IP address of end user and there was no such option available yet for setting "P2P > nobody" in tdesktop and telegram for windows.

PS: Even telegram for android will also leak your IP address if you have not set "Settings > Privacy and security > Calls > peer-to-peer > nobody" (But Peer-to-Peer settings for call option already exists in telegram for android).

To view this in action in tdesktop:

1. Open tdesktop,

2. Initiate a call to anyone,

3. You will notice the end user IP address is leaking.

 

Other scenario:

1. Open tdesktop in Ubuntu and login with user A

2. Open telegram in windows phone login with user B
3. Let user B initiate the call to user A
4. While user A access log will have public/private IP address of user B.

Not only the MTProto Mobile Protocol fails here in covering the IP address, rather such information can also be used for OSINT. This issue was fixed in 1.3.17 beta and v1.4.0 which have an option of setting your "P2P to Nobody/My contacts", Later CVE-2018-17780 was assign to this vulnerability.

Regards

Dhiraj

Read More

Telegram uses SOCKS5 to share user/creds

Hi Internet,

Summary: Telegram is supposedly is a secure messaging application but it uses SOCKS5 to transmit user credential's, neither traffic nor credentials are encrypted in the SOCKS5 protocol, but this is how the SOCKS protocol works (see https://tools.ietf.org/html/rfc1929), SOCKS5 carries passwords in cleartext. Telegram team is aware with this and says its working has intended.

Img Src: https://telegram.org/img/tl_card_open.gif

Product affected: tdesktop 1.3.16 alpha, Browser Info: Firefox 62.0 (64 bit), Tested on: Ubuntu 18.04 LTS x64

Steps to reproduce the issue:
1. Open tdesktop
2. Go to Settings > Advanced Settings > Connection type
3. Open "Proxy Settings" check "Use proxy"
4. Put some random Hostname, Port, Username and Password
5. tdesktop tries to connect it, while it connects click on that line which is made of 3 small spots (On right hand side)
6. Click share, the link gets copied.

Example Link: https://t.me/socks?server=inputzero.io&port=22&user=dhiraj&pass=MystrongPassw0rd 

The link which gets generated have the password in plaintext, SOCKS5 is a transport protocol and by itself it is not encrypted. Requests transmitting such  credentials in plain text are considered as a bad security practice.

However, the URL which gets generated via telegram is in HTTPS but, URI producers should not provide a URI that contains a username or password that is intended to be secret.  URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies).

Read this on oss sec-lists. Later CVE-2018-17613 was assigned to this issue.

Regards

Dhiraj

Read More