chushpan
Professional
- Messages
- 559
- Reaction score
- 389
- Points
- 63
Recently I came across a post that said something like this: "A new vulnerability has been discovered in Telegram related to video uploads." The post included a demo: the user receives a video, and when they tap on it, Telegram tries to install a third-party application. However, the problem didn't attract much attention. I decided to figure out if the method works and write an exploit for it.
First, we see a command line where the attacker enters the bot and sending parameters: bot token, chat ID, path to the APK file for downloading, and path to the image (preview). It is also suggested to enter a message and hide it as a spoiler. All keys and IDs are blurred in the video.
After entering the parameters, the attacker sees confirmation of successful sending. The victim receives a message that looks like a regular video file.
When you click on it, a message appears that the video file cannot be played and an additional player is required. If the user agrees, the sent file itself is installed using the standard tool for installing APK in Android.
Next, the user sees the standard requests that applications make during installation: grant access rights to contacts, microphone, and so on. The requests themselves depend on the phone model, Android version, and what the developer wants to get.
And at the end, the video shows a "tap" on the Trojan control panel and the ability to access private data and remotely control the smartphone. We can also indirectly confirm from the video that the author is from Turkey, since this country appears in the panel, and the local IP is indicated next to it.
In the meantime, I thought hard about how the bug I found works and how it can be reproduced.
From all of the above, it follows that it is enough to transfer any file - the main thing is that the Telegram client recognizes that it is a video. "So the problem lies in sending files!" - I decided and delved into studying the Telegram API, or more precisely, the part where we send files. Of course, we pay special attention to videos.
Everything seems to be in order: an API like an API. But my gaze catches on the inconspicuous thumbnail field, in which the picture for the video is transferred. As we remember, an image was attached to the video. This is unlikely to be a coincidence. For some reason, the mime type is also transferred... In the video sending function, for some reason we have to report that we are sending a video. Suspicious!
A MIME type consists of two parts: a main type and a subtype, separated by a slash (e.g. type/subtype).
Examples of some common MIME types include:
MIME types indicate how to interpret the transferred content, which helps programs correctly process and display files.
If we say that the type is "video", does that mean we can send non-video at the same time? And if so, then we will probably get the behavior we saw in the demo video: Telegram will try to run our "non-video", it will fail, and it will want to install a "video player" for this file type. Everything fits together, except for one thing: it is not clear how to pass this most suitable video player for installation. Well, or, in security terms, "payload". Not everything is clear yet, but we are clearly on the right track.
These were my thoughts at that moment. And of course, my hands were burning to reproduce the vulnerability myself.
We already have enough input data to test the hypothesis, so let's start coding.
The first step is to make a bot using BotFather and get a token. It's easy to do:
Next, we throw the simplest code on Node.js that will send the video. And of course, we use the strange parameters we discovered. Let's try to send the APK file, but with the MP4 MIME type. In the third line, we insert the token received from BotFather.
Here /video is the command our bot will wait for to respond with an "exploit".
Select the APK (I stupidly made touch VIDEO.apk to create it) and specify the path to the file we want to send or run.
Launch the bot daemon and pass it the /video command. In response, it returns a message with our APK under the guise of video.
The result is in the screenshots below. An empty file is displayed as a white square that you can tap.
Tap to see what happens.
Holy shit! We are offered to install the application! And what happens if we tap "Open"? In this case, Telegram is trying to install the file sent to it for some reason. The load is the file we sent. Fantastic!
How? Why? Why? I'll say right away, this remains a mystery to me: Telegram is trying to install the file as a player for itself for some reason. That is, you sent the file "romashka.avi" and Telegram can try to open it in "romashka.avi" to view it. There are many questions for the author of such code (including where he gets drugs), but what is important for us is that the exploit works.
Great news! We can also earn a couple dozen evergreens on this, because this problem is the second largest in scale after the recent one related to a typo in the file extension. “What if there’s enough for some used video card, we can play with AI!” I thought inadvertently. I enthusiastically write a letter to Telegram, attaching a draft of this article and the exploit we made above. I send it and wait... A couple of days later, I see that the client’s behavior has changed: now the file arrives simply as an APK without an image. A couple of days later, I receive a response, it’s below on the screen.
Disappointment: Telegram representatives responded that the bug had been fixed before my report and that some measures had been taken on the backend. And that's it. No thanks or certificates of honor, not to mention a mug of juice. "We fixed everything on July 9, stay healthy!" Well, just without wishing me good health.
Well, say what you want, but I observed the bug after July 9. On the other hand, I really can't take credit for it, although a video card would have been nice. So all that's left is to remember the joke about the guy who doesn't give a damn.
I think the statements that everything was fixed on the same day are made simply to maintain reputation. Well, the problem of "someone submitted the bug earlier" happens even on projects where you actually found the vulnerability yourself, and here I only noticed it in a public blog. As it turned out later, the exploit appeared on sale a month earlier, on June 6, on a site with open registration. So it’s unlikely that this day can be considered the day the exploit was discovered, since by that time someone had not only made a PoC, but also assembled a product for sale.
Remy Vaughan wrote to us and introduced himself as a Telegram employee. Below is a translation of his letters and my response from English:
Which is what I took advantage of to ask a question about the time discrepancies.
To which I received the following response.
All we can do here is shrug:
However, is it that much? After the fix, APKs sent can no longer be disguised as videos, but they can still be sent. When you click on them, Android will still offer installation (if it is allowed in the settings) or advise you to enable the ability to install APKs. If you make the file small, the client will also automatically download it, which will reduce the extra step of the attack. By playing with the file name, shading the extension, the attacker can further increase their chances of success. So it is too early to completely bury this attack vector.
Source
Demonstration of vulnerability
First, let's take a closer look at what's happening in the video that demonstrates the bug's operation.First, we see a command line where the attacker enters the bot and sending parameters: bot token, chat ID, path to the APK file for downloading, and path to the image (preview). It is also suggested to enter a message and hide it as a spoiler. All keys and IDs are blurred in the video.
After entering the parameters, the attacker sees confirmation of successful sending. The victim receives a message that looks like a regular video file.
When you click on it, a message appears that the video file cannot be played and an additional player is required. If the user agrees, the sent file itself is installed using the standard tool for installing APK in Android.
Next, the user sees the standard requests that applications make during installation: grant access rights to contacts, microphone, and so on. The requests themselves depend on the phone model, Android version, and what the developer wants to get.
And at the end, the video shows a "tap" on the Trojan control panel and the ability to access private data and remotely control the smartphone. We can also indirectly confirm from the video that the author is from Turkey, since this country appears in the panel, and the local IP is indicated next to it.
One-tap exploit
So, we have a one-tap exploit (or one-click exploit) before us. This is a type of vulnerability that allows an attacker to gain control over the victim's device or account if the victim makes just one click. These exploits are less dangerous than, say, RCE, since they require minimal, but still action from the user: usually, just clicking on a malicious link is enough. A good well-known example of such a vulnerability is XSS.In the meantime, I thought hard about how the bug I found works and how it can be reproduced.
How vulnerability works
I rewatched the video and tried to gather as much information as possible. Maybe some details are important or maybe I'll come across working pieces of code? We carefully watch the preparation process: a picture for the video is specified, the file itself that should be installed, the bot ID and the victim's TGID.From all of the above, it follows that it is enough to transfer any file - the main thing is that the Telegram client recognizes that it is a video. "So the problem lies in sending files!" - I decided and delved into studying the Telegram API, or more precisely, the part where we send files. Of course, we pay special attention to videos.
Everything seems to be in order: an API like an API. But my gaze catches on the inconspicuous thumbnail field, in which the picture for the video is transferred. As we remember, an image was attached to the video. This is unlikely to be a coincidence. For some reason, the mime type is also transferred... In the video sending function, for some reason we have to report that we are sending a video. Suspicious!
What is MIME
A MIME type (Multipurpose Internet Mail Extensions) is a standard used to describe the content type of various files transferred over the Internet. Originally developed for email, MIME types are now used in various Internet protocols, including HTTP, to indicate the type of content being transferred.A MIME type consists of two parts: a main type and a subtype, separated by a slash (e.g. type/subtype).
Examples of some common MIME types include:
- text/plain — a regular text file;
- text/html — HTML document;
- image/jpeg — image in JPEG format;
- application/json — data in JSON format;
- application/pdf — document in PDF format.
MIME types indicate how to interpret the transferred content, which helps programs correctly process and display files.
If we say that the type is "video", does that mean we can send non-video at the same time? And if so, then we will probably get the behavior we saw in the demo video: Telegram will try to run our "non-video", it will fail, and it will want to install a "video player" for this file type. Everything fits together, except for one thing: it is not clear how to pass this most suitable video player for installation. Well, or, in security terms, "payload". Not everything is clear yet, but we are clearly on the right track.
These were my thoughts at that moment. And of course, my hands were burning to reproduce the vulnerability myself.
Writing PoC
Proof of Concept (PoC) is, if we are talking about security, a demonstration of the ability to exploit a vulnerability. PoC shows that the bug is real and an attacker can use it for their own purposes.We already have enough input data to test the hypothesis, so let's start coding.
The first step is to make a bot using BotFather and get a token. It's easy to do:
- knocking at @BotFather's door;
- we execute the commands /start and /newbot in turn;
- we enter the data that the father bot requests from us (the name of the new bot, etc.);
- After completing the quiz, we receive a botTokenTG for a new bot.
Next, we throw the simplest code on Node.js that will send the video. And of course, we use the strange parameters we discovered. Let's try to send the APK file, but with the MP4 MIME type. In the third line, we insert the token received from BotFather.
Code:
const fs = require("fs");
const TelegramBot = require("node-telegram-bot-api");
const token = "botTokenTG";
const bot = new TelegramBot(token, { polling: true });
bot.onText(/\/video/, (msg) => {
const chatId = msg.chat.id;
bot.sendVideo(
chatId,
fs.readFileSync("/путь/к/файлу.apk"),
{
width: 300,
height: 300,
duration: 30,
}, {
filename: "VIDEO.apk",
contentType: "video/mp4"
}
);
});Here /video is the command our bot will wait for to respond with an "exploit".
Select the APK (I stupidly made touch VIDEO.apk to create it) and specify the path to the file we want to send or run.
Launch the bot daemon and pass it the /video command. In response, it returns a message with our APK under the guise of video.
The result is in the screenshots below. An empty file is displayed as a white square that you can tap.
Tap to see what happens.
Holy shit! We are offered to install the application! And what happens if we tap "Open"? In this case, Telegram is trying to install the file sent to it for some reason. The load is the file we sent. Fantastic!
How? Why? Why? I'll say right away, this remains a mystery to me: Telegram is trying to install the file as a player for itself for some reason. That is, you sent the file "romashka.avi" and Telegram can try to open it in "romashka.avi" to view it. There are many questions for the author of such code (including where he gets drugs), but what is important for us is that the exploit works.
Communication with Telegram
As a white-hat researcher (and even more so, the author of a book on digital security, a philanthropist, and, God willing, a millionaire), I naturally considered it my duty to notify the Telegram security team. Fortunately, they are doing well with this, and the first Google search brought me to the address security@telegram.org.
Great news! We can also earn a couple dozen evergreens on this, because this problem is the second largest in scale after the recent one related to a typo in the file extension. “What if there’s enough for some used video card, we can play with AI!” I thought inadvertently. I enthusiastically write a letter to Telegram, attaching a draft of this article and the exploit we made above. I send it and wait... A couple of days later, I see that the client’s behavior has changed: now the file arrives simply as an APK without an image. A couple of days later, I receive a response, it’s below on the screen.
Disappointment: Telegram representatives responded that the bug had been fixed before my report and that some measures had been taken on the backend. And that's it. No thanks or certificates of honor, not to mention a mug of juice. "We fixed everything on July 9, stay healthy!" Well, just without wishing me good health.
Well, say what you want, but I observed the bug after July 9. On the other hand, I really can't take credit for it, although a video card would have been nice. So all that's left is to remember the joke about the guy who doesn't give a damn.
I think the statements that everything was fixed on the same day are made simply to maintain reputation. Well, the problem of "someone submitted the bug earlier" happens even on projects where you actually found the vulnerability yourself, and here I only noticed it in a public blog. As it turned out later, the exploit appeared on sale a month earlier, on June 6, on a site with open registration. So it’s unlikely that this day can be considered the day the exploit was discovered, since by that time someone had not only made a PoC, but also assembled a product for sale.
From the editors: correspondence with Telegram
In cases where the author says one thing and the company's representatives say another, it's up to the editors to send an official request and present the other side's arguments. We were lucky: a Telegram representative contacted us himself, responding to a recent publication. The same bug described in this article was reported by ESET, and the news about it appeared on Hacker on July 23.Remy Vaughan wrote to us and introduced himself as a Telegram employee. Below is a translation of his letters and my response from English:
Which is what I took advantage of to ask a question about the time discrepancies.
To which I received the following response.
All we can do here is shrug:
- The insistence that the vulnerability was fixed on July 9 still sounds dubious. The author of the article insists that he learned about the vulnerability on July 10, and provides screenshots where exploitation occurs on July 11 - with a completely new file. Some server fix may have taken place, but its effectiveness is questionable. In this case, when discussing file copies, Mr. Vaughn is passing off wishful thinking here.
- Vulnerabilities often imply conditions for exploitation and do not cease to be vulnerabilities. And permission to install APKs is not at all uncommon. So, despite protests from Telegram, this, in our opinion, can be considered a one-click bug.
Conclusions
In my opinion, the temptation to trade such bugs on the darknet should disappear thanks to bug bounty programs, and if they work poorly and reluctantly, then they will hand over bugs in the same way. Taking this opportunity, I recommend using Jabber and Tox for secure correspondence . As for Telegram, I'm glad if it was possible to make it (and therefore the world) a little safer.However, is it that much? After the fix, APKs sent can no longer be disguised as videos, but they can still be sent. When you click on them, Android will still offer installation (if it is allowed in the settings) or advise you to enable the ability to install APKs. If you make the file small, the client will also automatically download it, which will reduce the extra step of the attack. By playing with the file name, shading the extension, the attacker can further increase their chances of success. So it is too early to completely bury this attack vector.
Source