[BugBounty] Disclosing 5 million links to private Telegram chats and the ability to edit any article telegra.ph

For more than a year now I have been using Telegram Messenger: it is convenient and, as far as I thought, completely confidential. Since I am a web application security researcher, I had to check the appropriate version of the application for vulnerabilities. I did not see an urgent need for this because of the reputation of the messenger as “the most protected”. I thought I was wasting my time and won’t find anything. But recently, testing one site that interacted with the domain t.me, I had a chance to doubt the security of Telegram, and the determination to test it for vulnerabilities quickly increased.

It all started with the fact that I checked the site of my club for vulnerabilities, where I had previously purchased a subscription to recommendations for buying cryptocurrency.

Registration on the site is available only through referral (invitation) links, as well as there is a section for sending a message to the curator example.com/profile#curator . After testing, there was neither csrf, nor xss, nor any other vulnerability. But special attention was attracted by the section with messages example.com/messages , where correspondence with my curator example.com/msg132591 was presented. I decided to check this url for iDOR vulnerability, increasing the id by one position, and the vulnerability was confirmed - I saw the personal data of another user. Since the site did not have a function for sending messages to other users, we can talk with accuracy about iDOR + Disclosure Information.
')


Moving on - we buy the product, after its successful purchase there is a redirect to this url example.com/?pay_act=success&text=You% 20 successful% 20% 20 bought% 20 product, while the text can be edited - mostly, the characters are filtered, but there is a place where the text gets into and there is no filtering. We write this payload <iframe / onload = alert (document.domain)> and send PoC to the owners of the resource. Also there was a hint of Server Side Include, but exec cmd is disabled, with this payload --#exec cmd="ls" --> (<! At the beginning, Habr does not show this payload) swal(' ', '"-->\'-->`-->[an error occurred while processing the directive](none) out the error swal(' ', '"-->\'-->`-->[an error occurred while processing the directive](none) .

Also, I noticed a page with the goods of example.com/?pageid=13156 , there was found a blind sql injection. As evidence of the danger I was asked to provide the names of the database and tables. Hands to unleash the blind Scully for a very long time, so the sqlmap program came to the rescue:



After these three vulnerabilities, CSRF was found to change personal data, which led to account seizure by email recovery, Stored XSS, as well as a minor bug that allowed to buy goods for a price two times less than its announced value. The main danger of all these vulnerabilities (not counting sql injection), in my opinion, was sending to sparsen email-addresses, links to xss in conjunction with csrf and displaying referral charges on the intruder’s details. Then that vulnerability was found that made me doubt the security of the telegram for the web.

Usually, in the settings section there is a button to connect the bot, with which you can get recommendations for cryptocurrency trading. The button is tied to such a link t.me/Another_bot?start=CODE .

Having the habit of constantly checking sensitive data in a url for search engine placement (for example, I found twitter or exchangers ), this time I checked t.me. Dork turned out this: site: t.me inurl: Another_bot? Start =. I received one code, and having successfully logged into the bot, I began to receive insiders worth $ 500, I was able to see the name of partners and the account balance.




Judging by the fact that the code for the telegram-bot appeared in a search engine, t.me has obvious problems with the prohibition of indexing confidential content. This is due to the fact that the search engines are allowed. And they are allowed to do this because there are no bans in the robots file. When you try to view it t.me/robots.txt is redirected to the user's page, that is, this file does not exist.

Due to the lack of a robots file, a Disclosure Information vulnerability appears. Crafted tracks in order to show the danger of vulnerability:

1) Some users use email as a name or username. All this information gets into the search engine, whether users want it or not https://www.google.com/search?q=site:t.me+%40gmail.com . It reveals 11600 gmail addresses, 1500 yahoo, as well as mail.ru, hotmail and qq.com. But such disclosure is a controversial proof of the danger, because it is public information.

2) 5,000,000 links are revealed for access to private chat rooms and channels. Moreover, every day this figure grows, because there is no robots.txt. https://www.google.com/search?q=site%3At.me+join .



The first problem, in my opinion, is that links to private chat rooms / channels will remain in search engines forever, they can not be deleted. But many people trust Telegram for a long time without changing the links for access. And maybe they will never change, thinking that their correspondence is completely confidential. But this is not so: now any person can read the correspondence of employees, the security official can learn about the plot of terrorists, and your girlfriend that Lenka from the neighboring yard is not just "an old friend from childhood." The very fact of draining such a large number of links for access "reduces the concept of private chat to nothing."

The second, no less exciting problem, is that developers are absolutely “carefree” about this vulnerability, and the number of links increases every day. If during my report (January 7) Google had 900,000 such links , now there are 5,000,000 of them ! I agree that among all these links there are “click-through” telegrams channels that in advertisements use the links t.me/joinchat/************** to “ fill the number of subscribers, but there are also a lot of private chats and other channels. Until now, the developers have not added robots.txt to t.me (more than three months have passed since the report), and, I think, they will never add it again. There would be a desire, they would add immediately, it’s not at all difficult - just upload a txt file to the site index.

Looking through the dorks, I found such an interesting url https://www.t.me/iv?url=https://www.yashahid.com/9173/ . The interesting thing here is that this is not a link to a channel / person, but a direct redirect to the ISIL site (most likely), and only this site uses / iv? from 2015 to today. Contacts also contain a link www.t.me/iv?url=https : //www.yashahid.com/9173.

We substitute another site in url = for testing t.me/iv?url=https : //securityz.net, everything worked - this is the second vulnerability in Telegram - Open Redirect, can be used as a proof of concept, Open Bug Bounty has confirmed the presence and removal . Vulnerability allows you to make a direct redirect from t.me to any phishing site, download a trojan, malicious js (for example, js miner or use the last 0-day in intel processors), etc.

After that, I moved to the article creation service from Telegram - telegra.ph. There is no way to edit someone else’s records, xss isn’t (probably, bo0om found everything), there are only one subdomains, the directories just didn’t brute them. I created a test article and tried to edit it - in response to this action, this request is sent

 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-- 

Judging by this request, in order to edit the article on the telegraph, only the page_id page number is needed and the author of the article follows the link of our exploit. That is, there is simply no protection, for example, csrf tokens.

The third vulnerability is CSRF. I found out that the token is in the source of the article, for example, the article telegra.ph/Durov-01-22 belongs to 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, we just find out the page id, make an automatic exploit and successfully change the record.

Video


C using telegra.ph creates a large number of articles, so this vulnerability will be very valuable for intruders, as it allows you to change, for example:

• - an article with important news;
• - article with the update of the cryptocurrency wallet (and any other site);
• - an article where there is a ref. links, replacing them with your own - on this, by the way, you can earn a lot of money - in my article habrahabr.ru/post/343152 I talked about how a certain investor earned on publishing his ref. the links are $ 300,000, and, since his contacts are known to everyone, it would have been possible to reset his exploit, replace the ref link, and this action would have been imperceptible.

I sent these vulnerabilities to security@telegram.org, as stated in their bug bounty report , also, the mention of bug bounty is on the BugCrowd site.



For a long time I did not receive a response. Then I wrote to Pavel Durov (it was stupid, I agree, because he, besides me, is written by many people, and he does not read private messages), and also asked friends to share the developers' contacts. I sent a message to the developer t.me/dmitry, but he didn’t care about the vulnerability, he just read and ignored the letter. Then he sent a letter to vk.com/antanubis. He told me to check the box and accept my vulnerabilities. Already 9 days after the report I was answered.

On the first vulnerability, I received this response:

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

At the same time, the developer declined to respond to the message about the disclosure of private links. After I showed private access links a second time, they said that they would fix the vulnerability and pay € 50. But, as already mentioned, even after 3.5 months there is no correction. On the contrary, the situation has worsened.

As you yourself understand, the reward of € 50 for such a vulnerability is scanty and, one might even say, unfair. But this is Bug Bounty, and they decide how much to pay. I did not discuss further and just agreed with the amount. But for the last vulnerability, I received a fairly generous reward, and, precisely because of such "swing", it is difficult to draw any conclusion about this Bug Bounty, unlike vk.com , for example.

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

Search for vulnerabilities on the club website

1. Blind Sql Injection - $ 4000.
2. Vulnerability, revealing codes to the bot - $ 1000.
3. Everything else is $ 1500.

Telegram

1. Disclosure Information - € 50.
2. Open Redirect - € 100.
3. CSRF telegra.ph - € 1,400 ($ 1,750).

Conclusion from the article:

• Always add robots.txt to your site with rules that prohibit indexing of sensitive content. It can be email, login, phone, link with receipt, link for autologin, etc.
• If you have created a private chat, add someone you need and do not pass the link, because the link for access will sooner or later become public and can be seen in a search engine.

UPD: Link disclosure vulnerability no longer works. Open Redirect and CSRF have long been fixed.

PS: To keep abreast of my latest articles, I recommend to subscribe to a telegram / twitter, links below.
Previous article: How I hacked cryptocurrency-related companies and earned $ 60,000 from this.