Why self-destructing photos / videos on Telegram are not safe
Most recently, I saw an article that talked about the introduction of self-destructing messages in the WhatsApp messenger. It will have similar functionality to Telegram, but if in Durov’s messenger the deletion applies to ordinary messages (secret chats), they can also be used on photos in ordinary chats. That is, after sending, suppose the photo, the interlocutor will be able to view it for a limited amount of time, and after, in theory, it will be deleted from both interlocutors (preferably from the server too), then WhatsApp plans to introduce the deletion of regular messages (and so far it has been done) .
But today we’re not talking about WhatsApp (because I don’t use it at all), but about Telegram. The very idea of self-destructing messages is hardly in great demand, but there are those users who use them, for example, when sending documents or photos that can only be seen once (ahem).
For those who are too lazy to read, self-destructing messages on Telegram are neither safe nor confidential. Do not think that if you send an important document to someone you talk to in this way, he will not be able to save it (and I'm not talking about a quick screenshot or photographs of phone screens, God forbid) - use secret chats for this. And for those who are interested in the very implementation of these messages, you can continue reading.
I also used them, though not often and rather they were just “entertainment” and I didn’t especially watch them. In the month of June this year, while researching the UserAPI Telegram , I tested sending photos and receiving them. Had fun, no more. And interest appeared in viewing the “view” of sending messages, and how they are generally displayed in the response. I was wondering how this function is implemented “from the inside”, whether files are deleted from the Telegram server or can they be encrypted somehow.
And to my surprise, these messages are practically no different from the usual ones. Straight at all. They have the same file_id as ordinary photos, with which you can get the file itself. And even if you viewed the message and it disappeared in the chat, you can safely save / send / forward it and do the same thing that you could do with ordinary photos / videos. That is, it is not deleted from the Telegram server itself.
I repeat, such messages do not apply to secret chats, where the correspondence is on two devices, and from another client I can’t access them. This feature is designed for regular chats and seems to be considered "safe." But here it’s interesting, I haven’t found a detailed description of these self-destructing messages anywhere. That is, Telegram does not seem to tell us that these messages are so safe in terms of access (if you have access to the account itself) like for example the same secret chats. The only thing I saw was that Telegram itself said that no messages, even secret chats, have 100 percent security and that everyone is responsible for the messages that he sends, but ...
I admit, it would be implemented in some WhatsApp / Viber / VK, I would not even pay attention to it, but Telegram is a very convenient messenger, which I love very much, but what I hate is its support filled with volunteers.
In the same month of June, I wrote to support@telegram.org, where I wrote a whole letter in two languages. It said not only about self-destructing messages, but also about ordinary ones and that Telegram does not set any limits on forwarding, but more on that later.
Two months later, they did not answer me, so I had to write to that very “support” Telegram about explaining what to do and where to write when finding this kind of “Vulnerability”.
There, they surprisingly answered me three hours later, where they told me that it was necessary to write about serious vulnerabilities in the protocol at security@telegram.org or to share the details here. I enclose the original response text from the support:
July 5, support response
Hey. You can share the details here or write to security@telegram.org if we are really talking about some kind of vulnerability in our applications or protocol.
I decided to write to the support itself about the "details" of vulnerabilities, applying the video, the script itself and solutions to the problem (below is my message), but until now I have not been answered, either by mail or in the support itself. Apparently so far, this does not bother them.
In addition to the option with self-destructing messages, I also noticed that any message that was deleted, for example, in a private chat, group, channel, is also easy to intercept. This is done using the usual forward of all messages , for example, in a separate group, and after getting them using the ID of the deleted message (now the libraries have handlers on them).
I also described the whole process in my letter (although in fact it is simple), with a solution to the problem in the form of limiting the forwards of the messages themselves. And if you do not completely limit, then prohibit the constant forward of all messages. I think the development team will be able to make some anti-flood from the forwards.
And with self-destructing ones, just delete them from the server. This will not solve the problem, messages can still be intercepted exactly at the time they are received. For complete elimination, the entire algorithm for reading them should be reworked. For example, to make an access key to each message and when using this key, the image / video will be available only for a certain time. It’s hard for me to come up with the whole algorithm for the development team, I admit, I myself am not able to think through all the aspects and in any case, there is a way to intercept them. But at the moment, they are implemented just awfully, the developer (s) who were engaged in this function should be more responsible for the development of this kind of function. Well, or in extreme cases, just write, in red, bold letters, that self-destructing messages are easy to intercept and this is nothing more than a toy.
I’ll tell you about myself, a 15-year-old student, recently fond of developing in Python, dabbled in the User API and found this kind of "flaw / vulnerability." The more that infuriated and forced me to write all this here - a terrible implementation of Telegram support, which simply ignored me three times in 4 months.
For some, this function will not be useful, it will not find anything bad in the poor implementation of such messages, but I think that since Telegram itself is not interested in improving the current functions, it will be useful for others to just take this into account.
I’m writing articles for the first time, I could leave mistakes somewhere, but I hope that they will correct me in the comments, indicating. Or, in general, they will tell me that everything is wrong and ignoring support was a good solution and I will finally calm down. I also attach my message:
Support message for which no reply was received
Hello, my name is Khamidov Amal.
Recently, I wrote a user experience for my project. At some point, I noticed how my friend sent me a self-removing photo. I looked at it on my Android client and it was removed as it should be after 10 seconds.
But I wondered how such messages are encrypted and how they are stored on the go. After all, it turns out that the telegram client first uploads the photo to the phone, and after reading it must remove it.
I wrote a small python script using the Pyrogram library and wanted to see how they came to the client.
I was surprised when I saw that these "self-deleting photos" look just like regular ones (what?).
That is, if I sent a regular photo, it was no different from the “self-deprecating".
After that, I wrote a script that sends this photo on the file, and at that moment, the photo went to my test channel like a normal photo. And on the phone from which I sent this most "self-extracting" photo, it was not even read.
It also allowed me to view the photo on my desktop client. That is, this script bypasses the most important essence of the "Self-extracting" photo.
I consider it a vulnerability, and I consider it a solution to reconsider the method of sending "self-deleting" messages and process them on the server and not on the device.
Also, I found the second one (almost a vulnerability), which was created using the API's telegram itself and is not prohibited at all.
So, we are talking about ordinary messages.
I also wrote a regular script that sends (forward) all messages from the chat to my group and marks them by their ID.
I added a handler to this script that responds to all deleted messages and gives the ID of these deleted messages (hello pyrogram).
After that, I added a script and now, when the handler responds to all deleted messages, it checks them with the messages from the group (which contains all the messages) and looks for this message by ID.
On the one hand, this does not violate anything, because telegrams have an open code, everyone can write their userbots. but on the other hand (russian is good), in the last update you added the function of deleting your own and others' messages for the sake of security, but such simple scripts written by a 15-year-old schoolboy seem to bypass this very security.
I understand that everyone responds in response that he sends, but a person can send important files to an unnecessary person by mistake and at this moment he will delete the message (While the interlocutor has not read) without knowing that all these messages can be compromised and most importantly, that messages are not marked read.
The decision, I think, is to add limits on forward messages and review the way of “reading” messages.
In the second video I attached how can I save all deleted messages without reading them.
I attach the video and script that I wrote to clearly show how it works.
Recently, I wrote a user experience for my project. At some point, I noticed how my friend sent me a self-removing photo. I looked at it on my Android client and it was removed as it should be after 10 seconds.
But I wondered how such messages are encrypted and how they are stored on the go. After all, it turns out that the telegram client first uploads the photo to the phone, and after reading it must remove it.
I wrote a small python script using the Pyrogram library and wanted to see how they came to the client.
I was surprised when I saw that these "self-deleting photos" look just like regular ones (what?).
That is, if I sent a regular photo, it was no different from the “self-deprecating".
After that, I wrote a script that sends this photo on the file, and at that moment, the photo went to my test channel like a normal photo. And on the phone from which I sent this most "self-extracting" photo, it was not even read.
It also allowed me to view the photo on my desktop client. That is, this script bypasses the most important essence of the "Self-extracting" photo.
I consider it a vulnerability, and I consider it a solution to reconsider the method of sending "self-deleting" messages and process them on the server and not on the device.
Also, I found the second one (almost a vulnerability), which was created using the API's telegram itself and is not prohibited at all.
So, we are talking about ordinary messages.
I also wrote a regular script that sends (forward) all messages from the chat to my group and marks them by their ID.
I added a handler to this script that responds to all deleted messages and gives the ID of these deleted messages (hello pyrogram).
After that, I added a script and now, when the handler responds to all deleted messages, it checks them with the messages from the group (which contains all the messages) and looks for this message by ID.
On the one hand, this does not violate anything, because telegrams have an open code, everyone can write their userbots. but on the other hand (russian is good), in the last update you added the function of deleting your own and others' messages for the sake of security, but such simple scripts written by a 15-year-old schoolboy seem to bypass this very security.
I understand that everyone responds in response that he sends, but a person can send important files to an unnecessary person by mistake and at this moment he will delete the message (While the interlocutor has not read) without knowing that all these messages can be compromised and most importantly, that messages are not marked read.
The decision, I think, is to add limits on forward messages and review the way of “reading” messages.
In the second video I attached how can I save all deleted messages without reading them.
I attach the video and script that I wrote to clearly show how it works.
And how it looks in the code (used the Telethon library, on Pyrogram it's almost the same):
The most important part of the code. The rest is just an indication of the account, phone number, etc.
@client.on(events.NewMessage(func=lambda e: e.is_private and getattr(e, 'photo'))) async def handler(event: message.Message): # event.input_chat may be None, use event.get_input_chat() chat: InputPeerUser = await event.get_input_chat() sender: User = await event.get_sender() photo: Photo = event.photo await client.send_message(img_channel, file=MessageMediaPhoto(photo), message=f'<code>{chat.user_id}</code>\n' f'<code>{sender.first_name}</code>\n', parse_mode='HTML') More posts:
All Posts