Disclosure of 5 million links to the Telegram private chats and the possibility of editing any article on Telegra.ph

Introduction

For more than a year, I’ve been using Telegram messenger: it is convenient and, as far as it seemed to me, confidential. Since I am a security researcher of web applications, I had to check the appropriate application’s version for vulnerability. I have not seen this in urgent need because of the reputation of the messenger as “the most protected.” I thought I would spend my time and not find anything. But recently, testing one site that interacted with the t.me domain, I had a chance to doubt the safety of Telegram, and the determination to check it for vulnerability quickly increased.

Investment club app’s vulnerabilities

Access Control bug

It all started with testing my investment club’s site for vulnerabilities, where I had previously bought a subscription to recommendations for purchasing cryptocurrency.

Registration in the app is available only on referral (invitation) links, and a form is also presented for sending a message to the referee at example.com/profile#curator. After brief testing, there was neither CSRF, XSS, or any other vulnerability. But the page with the messages at example.com/messages, where the endpoint for correspondence with my referee is example.com/msg132591, gave me a hint of vulnerability, and I decided to pay close attention to it. I checked an endpoint for the IDOR bug by incrementing the ID, and the bug was confirmed - I saw another user’s data. There was no functionality for sending messages to other users on the site. Still, even without sending messages, there’s an impact - we can precisely identify that IDOR discloses PII such as email, phone number, name, social media links, etc.

Reflected XSS

We move further - after the successful purchase of a package in the investment club’s application, a redirect occurs to the following URL example.com/?pay_act=success&text=VAY%20 ,%20%20COUSED. For most of the page, all the potentially dangerous symbols are filtered, but there is one place where the filtration wasn’t implemented. By using iframe payload <iframe/onload = alert (document.domain)>, we discover that there’s a classic Reflected XSS. There was also a hint for Server Side Include bug, but I couldn’t pull out code execution - if we use a payload <!--#exec cmd="ls" --> -#exec cmd = "ls" ->, there’ll be an error swal(' ', '"-->\'-->–>an error occurred while processing the directive`.

SQL injection

Also, I noticed that a page with products at example.com/?pageid=13156 contains a parameter often vulnerable to SQL injections; it turned out there was a blind SQL Injection. As proof of impact, the developers asked me to provide the name of the database and tables. It’d take quite a long time to enumerate databases and tables by hand since it’s a blind injection, so SQLmap came to the rescue:

SQLmap output

Other bugs

After these three vulnerabilities, I also discovered:

  • CSRF in personal data changing, which led to account takeover via email changing;
  • Stored XSS;
  • A minor bug that allowed buying the products for a price twice less than its announced cost - there were hidden products that developers used for testing purposes. In my opinion, the main danger of the mentioned client-side vulnerabilities is revealed in the chain. Sending letters to leaked email addresses containing links to a page with js code insertion that triggers a request for email changing would lead to the withdrawal of users’ money to the attacker’s wallets.

Telegram vulnerabilities

Access control bug

After all these bugs, I found a vulnerability that made me doubt the safety of Telegram for Web. In the application settings, a button for connecting the bot allows receiving recommendations for cryptocurrency buying. The button is tied to a link that looks like t.me/anometer_bot?start=Code.

Having the habit of constantly checking the displaying of sensitive data in the URLs provided by search engines (for example, I found Twitter DORK), this time, I checked t.me. I wrote a search term: site:t.me inurl:Another_bot?start= and got the login code belonging to another user. After successfully logging in to the bot in Telegram, I began receiving free information worth $500 per year. In addition, it was possible to see the users’ names and account balances.

Considering that the telegram code appeared in the search engine, t.me has problems with the prohibition of indexing content containing confidential data. This is because search engines were allowed to index such content. And they are allowed to do so because there are no restrictions in the robots file. If you try to view the file, you’ll find out it doesn’t exist - all the pages under t.me serve as “hosting” for Telegram usernames; therefore, t.me/robots.txt redirects to the user page.

Due to the absence of the robots.txt file, occurs an Information Disclosure vulnerability. Let’s craft some DORKs to show the impact of a bug:

  1. Some users use email as a name or username. All this information falls into the search engines whether users want this or not https://www.google.com/search?q=site:t.me+%40gmail.com. Currently, 11600 Gmail addresses, 1500 Yahoo, Hotmail, and QQ.com addresses, are revealed. But such disclosure is controversial evidence of impact because this is primarily public information.

  2. 5,000,000 links for access to private chats and channels are revealed. Moreover, every day the number is growing since there is no robots.txt. https://www.google.com/search?q=site%3at.me+join.

DORK&rsquo;s output

The first problem is that links to private chats/channels will remain in search engines forever; they will not be removed. But many people trust Telegram and don’t change links for access for a long time. Possibly, they will never rotate the links, thinking that their correspondence/URL for entry is entirely confidential. But it is not: anyone can read the correspondence of employees, the security forces can find out about the conspiracy of the terrorists, and your girlfriend could guess that Emily from the neighborhood is not just “an old friend from childhood.” Disclosing many access links “reduces the concept of private chats to public.”

The second, no less disturbing problem is that the developers are absolutely “carefree” regarding this vulnerability, and the number of links increases every day. If during the sending of my report (January 7) there were 900,000 such links in Google, now there are 5,000,000 of them! I agree that among all these links, there are “clickbait” telegram channels that use t.me/joinchat/************** URLs to increase the number of subscribers, but there are also a lot of private chats and other “non-public” groups. Until now, the developers have not added robots.txt file on t.me. Since more than three months have passed since the report, I doubt they will add it.

Open redirect

Looking through the DORK, I found such an engaging URL https://www.t.me/iv?url=https://www.yashhyd.com/9173/. Interestingly, this link doesn’t lead to the channel or person but is a direct redirect to the ISIS website (most likely), and only this website uses /iv? on t.me domain from 2015 to today.

If we substitute another site in the url parameter, the redirect will occur without any problem. This is the second bug on t.me - Open Redirect. Such a vulnerability can be used for phishing, chaining with other bugs, malware downloading, etc.

CSRF

Next, I moved to the service that hosts articles from Telegram and is made by the Telegram team - Telegra.ph. You can’t edit other people’s articles; there’s no XSS, only one subdomain doesn’t look promising, and brute force of directories didn’t give any result. I created a test article and tried to edit it - in response to this action such a request was triggered:

POST /save HTTP/1.1
Host: edit.telegra.ph
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Referer: http://telegra.ph/img-srcx-onerrorprompt1qw22qw-01-18
Content-Type: multipart/form-data; boundary=---------------------------TelegraPhBoundary21
Content-Length: 1273
Origin: http://telegra.ph
Cookie: tph_uuid=80SI6VtGetOhKd5LaFjBRtK7I6EsdW0lWS21LvFZWt
Connection: close
-----------------------------TelegraPhBoundary21
Content-Disposition: form-data; name="Data";filename="content.html"
Content-type: plain/text
[{"tag":"p","children":[{"tag":"br"}]},{"tag":"figure","children":[{"tag":"div","attrs":{"class":"figure_wrapper"},"children":[{"tag":"img","attrs":{"onerror":"alert(1)"}}]},{"tag":"figcaption","children":[""]}]},{"tag":"p","children":[{"tag":"br"}]},{"tag":"figure","children":[{"tag":"div","attrs":{"class":"figure_wrapper"},"children":[{"tag":"video","attrs":{"src":"<a href="http://telegra.ph/file/a805d892df19325688e25.mp4">http://telegra.ph/file/a805d892df19325688e25.mp4</a>","preload":"auto","autoplay":"autoplay","loop":"loop","muted":"muted"}}]},{"tag":"figcaption","children":[""]}]},{"tag":"p","children":["\"><img s>qw{{2+2}}qw"]}]
-----------------------------TelegraPhBoundary21
Content-Disposition: form-data; name="title"
"><img >
-----------------------------TelegraPhBoundary21
Content-Disposition: form-data; name="author"

-----------------------------TelegraPhBoundary21
Content-Disposition: form-data; name="author_url"

-----------------------------TelegraPhBoundary21
Content-Disposition: form-data; name="page_id"
3b25803ca519a088c0c75
-----------------------------TelegraPhBoundary21--

By looking at the request, to edit the article on Telegraph, you only need page_id and a click of the article’s author on our link. No CSRF protection is presented in the request. It looks like a classic simple CSRF vulnerability. I found out that the ID of an article can be obtained from the source code of the article; for example, the article telegra.ph/Durov-01-22 has an ID 7f0d501375c9e2acbd1ef:

<script> var T={"apiUrl":"https:\/\/edit.telegra.ph","datetime":1516653676,"pageId":"7f0d501375c9e2acbd1ef"};(function(){var b=document.querySelector('time');if(b&&T.datetime){var a=new Date(1E3*T.datetime),d='January February March April May June July August September October November December'.split(' ')[a.getMonth()],c=a.getDate();b.innerText=d+' '+(10>c?'0':'')+c+', '+a.getFullYear()}})(); </script>

Since the article can still be edited for a very long time, all we should do to change other person’s article is the knowledge of the page’s ID, generation of a CSRF exploit, and a source of interaction with a victim.

With the help of Telegra.ph, a large number of articles are created, so this vulnerability will be precious for attackers, as it allows you to change:

  • Article with important news from trustworthy media;
  • Article with the update of the cryptocurrency wallet (and any other app);
  • Article containing referral links; by replacing them with your own, a lot of money can be earned - in my previous article, I talked about how a particular investor earned $300 000 just by publishing a referral link. Since the investor’s contacts are known to everyone, it was possible to drop him a link to the exploit and replace the referral link in the article, and this action most likely would be invisible.

I sent these vulnerabilities to security@telegram.org, as stated in their FAQ message; Bug Bounty is also mentioned on the Bugcrowd’s Bug Bounty list.

Telegram Bug Bounty

After I sent my reports, I didn’t receive an answer for a long time. Then I wrote to Pavel Durov (it was short-sighted of me, I agree, because he doesn’t read DMs), and I also asked friends if they might know the contacts of developers. I sent a message to the developer t.me/dmitry, but he didn’t answer. Then I sent a DM to vk.com/antanubis; he asked the Telegram team to check a security mailbox and review my vulnerabilities. In nine days, I got the first response to my reports.

Regarding the first vulnerability, I received such an answer:

“Everything displayed on the t.me pages- usernames, bio, posts from public channels is considered public information.”

At the same time, the developer evaded a response to a message about the disclosure of private links. After I showed the case with access to links for private chats, developers replied that they would fix the vulnerability and pay €50. But, as already mentioned, after 3.5 months, there is no fix.

As a result of my research, I received such awards for the vulnerabilities I sent:

Investment club’s application:

  • Blind SQL Injection - $ 4000;
  • The vulnerability that reveals the codes for the bot - $1000;
  • Everything else - $1500.

Telegram:

  • Information Disclosure - € 50.
  • Open Redirect - € 100.
  • CSRF on Telegra.ph - € 1400.

Conclusions

Always add Robots.txt to your web application with rules that forbid indexing content containing personal data. It can be emails, logins, phones, pages with receipts, links for autologin, etc. If you have created a private chat, add someone you need there, and do not send/publish the link because the link for access will sooner or later be indexed by search engine bots and will end up in search results.

UPD: Vulnerability with the disclosure of t.me links no longer works. Open Redirect and CSRF were fixed at the time of article publishing.