[BugBounty]プライベートテレグラムチャットへの500万リンクの開示および記事telegra.phの編集機能

1年以上もの間、私はTelegramメッセンジャーを使用しています。それは便利で、思った限りでは完全に機密です。 私はWebアプリケーションのセキュリティ研究者であるため、対応するバージョンのアプリケーションの脆弱性を確認する必要がありました。 メッセンジャーが「最も保護されている」との評判のため、私はこの緊急の必要性を見ませんでした。 時間を無駄にして何も見つからないと思った。 しかし最近、t.meドメインとやり取りする1つのサイトをテストしているときに、Telegramのセキュリティを疑う機会があり、脆弱性をチェックする決意が急速に高まりました。



すべては、以前に暗号通貨購入の推奨事項のサブスクリプションを購入したクラブのWebサイトの脆弱性をチェックしたという事実から始まりました。



サイトへの登録は、紹介（招待）リンクを介してのみ利用でき、キュレーターexample.com/profile#curatorにメッセージを送信するセクションもあります 。 テスト後、csrf、xss、その他の脆弱性はありませんでした。 しかし、メッセージセクションexample.com/messagesには特別な注意が払われました。そこでは、私のキュレーターexample.com/msg132591との通信が提示されました。 IDを1ポジション増やして、このURLでiDORの脆弱性を確認することにしました。脆弱性が確認されました-別のユーザーの個人データを見ました。 サイトには他のユーザーにメッセージを送信する機能がなかったため、iDOR +開示情報について正確に話すことができます。







先に進みます -製品を購入し、購入が成功するとこのURLへのリダイレクトexample.com/?pay_act=success&text=You%20successfully%20%20 buy％20productが発生しますが、テキストは編集できます-基本的にキャラクターはフィルターされますが、場所がありますテキストが該当する場所で、フィルタリングはありません。 ここにそのようなペイロード<iframe / onload = alert（document.domain）>を記述し、PoCをリソースの所有者に送信します。 Server Side Includeのヒントもありましたが、exec cmdは無効になっており、このペイロードで--#exec cmd="ls" -->



（<！最初は、ハブはこのペイロードを表示しません）、 swal(' ', '"-->\'-->`-->[an error occurred while processing the directive](none)



。



また、製品ページexample.com/?pageid=13156に気づきました。ブラインドSQLインジェクションがありました。 危険の証拠として、データベースとテーブルの名前を提供するように頼まれました。 手を使って非常に長い時間盲目頬骨を回転させたので、sqlmapプログラムが助けになりました。







これら3つの脆弱性の後、CSRFは、電子メールによるアカウントハイジャック、Stored XSSリカバリ、および製品を発表された価格の半分の価格で購入できるようにするマイナーバグにつながる個人データの変更で検出されました。 私の意見では、これらすべての脆弱性（SQLインジェクションを除く）の主な危険性は、まばらな電子メールアドレスへの送信、csrfと連動したxssへのリンク、攻撃者の詳細への紹介料の出力でした。 次に、Webの電報のセキュリティを疑う脆弱性が見つかりました。



通常、設定セクションにはボットを接続するためのボタンがあり、これを使用して暗号通貨取引の推奨事項を取得できます。 ボタンはそのようなリンクt.me/Another_bot?start=CODEに関連付けられています。



検索エンジンに配置するためにURLの機密データを常にチェックする習慣があるため（たとえば、 twitterの dorksやexchangesが見つかりました）、今回はt.meをチェックしました。 Dorkは次のようになりました：site：t.me inurl：Another_bot？Start =。 1つのコードが与えられ、ボットに正常にログインすると、500ドル相当のインサイダーを受け取り始め、パートナーの名前と口座残高を確認することができました。









テレグラムボットのコードが検索エンジンに登場したという事実から判断すると、t.meには機密コンテンツのインデックス作成の禁止に関する明らかな問題があります。 これは、検索エンジンが許可されているという事実によるものです。 また、ロボットファイルには禁止事項がないため、許可されています。 t.me/robots.txtを表示しようとすると、ユーザーのページへのリダイレクトが発生します。つまり、このファイルは存在しません。



robotsファイルがないため、 開示情報の脆弱性が発生します 。 脆弱性の危険性を示すために、私たちはドークを作ります：



1）一部のユーザーは、メールを名前またはユーザー名として使用します。 ユーザーがhttps://www.google.ru/search?q=site:t.me+%40gmail.comを必要としているかどうかにかかわらず、この情報はすべて検索エンジンに渡されます 。 11,600のGmailアドレス、1,500ヤフー、mail.ru、hotmail、およびqq.comが表示されます。 しかし、そのような開示は公開情報であるため、論争の的になる危険の証拠です。



2） 5,000,000のリンクが開かれ、プライベートチャットとチャンネルにアクセスできます。 さらに、robots.txtがないため、この数字は毎日増加しています。 https://www.google.com/search?q=site%3At.me+join







私の意見では、最初の問題はプライベートチャット/チャンネルへのリンクが検索エンジンに永久に残り、それらを削除することは不可能だということです。 しかし、多くの人々は、アクセスリンクを変更せずにTelegramを長い間信頼しています。 そして、彼らの通信は完全に機密であると考えて、彼らは決して変わらないでしょう。 しかし、これはそうではありません。今では誰でも従業員の通信を読むことができ、警備員はテロリストの陰謀について知ることができます。そしてあなたのガールフレンドは、隣の庭のレンカは「子供時代からの古い知り合い」ではないと言います。 このような多数のアクセスリンクが流出したという単なる事実は、「プライベートチャットルームの概念を無効にします」。



2番目の、エキサイティングな問題は、開発者がこの脆弱性について絶対に「気まま」であり、リンクの数が日々増加していることです。 私のレポート（1月7日）でGoogleにこのようなリンクが900,000あった場合、現在5,000,000があります ！ これらすべてのリンクの中に、広告投稿でt.me/joinchat/****************リンクを使用するclickbaitテレグラムチャネルがあることに同意します。 「チャンネル登録者の数だけでなく、プライベートチャットやその他のチャンネルもたくさんあります。 これまでのところ、開発者はrobots.txtをt.meに追加しておらず（レポートから3か月以上経過しています）、追加されることはないと思います。 それは願いであり、彼らはすぐにそれを追加するでしょう、それはまったく難しくありません-サイトのインデックスにtxtファイルをアップロードするだけです。



暗闇の中を見ると、ここでそのような興味深いURL https://www.t.me/iv?url=https://www.yashahid.com/9173/が見つかりました。 ここで興味深いのは、このリンクがチャンネル/人へではなく、ISISサイトへの直接リダイレクト（ほとんどの場合）であり、このサイトのみが/ ivを使用しているということです。 2015年から今日まで。 連絡先には、リンクwww.t.me/iv?url=https：//www.yashahid.com/9173も含まれています。



t.me/iv?url=httpsをテストするためにurl =の別のサイトに置き換えます：//securityz.net、すべてが機能しました-これはTelegramの2番目の脆弱性です -Open Redirect、概念実証として使用できます、 Open Bug Bountyは存在と排除を確認しました。 この脆弱性により、t.meから任意のフィッシングサイトへの直接リダイレクト、トロイの木馬のダウンロード、悪意のあるjs（たとえば、jsマイナーまたはIntelプロセッサで過去0日間の使用）などが可能になります。



その後、私はTelegramの記事作成サービスtelegra.phに移動しました。 他の人のレコードを編集することはできません。xssはありません（おそらくbo0omはすべてを見つけました）。サブドメインは1つだけです。ブルートディレクトリも何も提供しませんでした。 テスト記事を作成して編集しようとしました-このアクションに応じて、そのようなリクエストが送信されます

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリクエストから判断すると、電信の記事を編集するには、page_idページ番号が必要であり、記事の作成者がエクスプロイトのリンクをたどるだけです。 つまり、単にcsrfトークンなどの保護はありません。



3番目の脆弱性はCSRFです。 トークンが記事のソースにあることがわかりました。たとえば、記事telegra.ph/Durov-01-22は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>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

記事は非常に長い間編集できるため、ページIDを認識し、自動的に悪用してレコードを正常に変更します。



映像





多数の記事がtelegra.phを使用して作成されているため、この脆弱性は、たとえば次のように変更できるため、攻撃者にとって非常に価値があります。

• -重要なニュースを含む記事。
• -暗号通貨ウォレット（およびその他のサイト）の更新を含む記事。
• -参照がある記事。 リンク、あなた自身でそれらを置き換える-ちなみに、あなたはたくさんのお金を稼ぐことができます-私の記事habrahabr.ru/post/343152私は彼のrefを公開することによって特定の投資家がお金を稼ぐ方法について話しました。 は30万ドルをリンクし、彼の連絡先はすべての人に知られているため、彼のエクスプロイトをリセットし、参照リンクを置き換えることが可能で、このアクションは表示されません。

バグバウンティメッセージに記載されているように、これらの脆弱性をsecurity@telegram.orgに送信しました。バグバウンティはBugCrowdサイトでも言及されています。







長い間、私は答えを受け取りませんでした。 それから私はパベル・デュロフに手紙を書きました（私は他の人にたくさんの人を書いて、個人的なメッセージを読まないのでバカでした、同意します）。また、友人に開発者の連絡先を共有するように頼みました。 開発者t.me/dmitryにメッセージを送信しましたが、彼は脆弱性を気にせず、手紙を読んで無視しました。 それから彼はvk.com/antanubisにメールを送りました。 彼はボックスをチェックし、私の脆弱性を受け入れるために引き渡しました。 報告から9日後、彼らは私に答えた。



最初の脆弱性で、私はこの答えを受け取りました：

「t.meページに表示されるものはすべて、ユーザー名、略歴、公開チャンネルからの投稿-公開情報です」

同時に、開発者はプライベートリンクの開示に関するメッセージへの回答を拒否しました。 2回目にアクセス用のプライベートリンクを見せた後、彼らは脆弱性を修正して50ユーロを支払うと答えました。 しかし、すでに述べたように、3.5か月後でも修正はありません。 それどころか、状況はさらに悪化しています。



あなた自身が理解しているように、このような脆弱性に対する50ユーロの報酬はわずかであり、不公平とさえ言えるかもしれません。 しかし、これはバグバウンティであり、彼らはいくら支払うかを決定します。 私はこれ以上議論せず、金額に単純に同意しました。 しかし、最後の脆弱性については、かなり寛大な報酬を受け取りました。まさにそのような「揺れ」のせいで、たとえばvk.comとは異なり 、このバグバウンティに関する結論を引き出すことは困難です。



その結果、送信された脆弱性に対してこのような賞を受賞しました。



クラブのWebサイトで脆弱性を検索する

1. ブラインドSQLインジェクション-4000ドル。
2. ボットコードを明らかにする脆弱性は1000ドルです。
3. それ以外はすべて1,500ドルです。

電報

1. 開示情報-50ユーロ。
2. オープンリダイレクト-100ユーロ。
3. CSRF telegra.ph-€1,400（$ 1,750）。

記事からの結論：

• 機密コンテンツのインデックス作成を禁止するルールを使用して、robots.txtを常にサイトに追加します。 これには、電子メール、ログイン、電話、領収書付きのリンク、自動ログインのリンクなどがあります。
• プライベートチャットを作成した場合は、必要な人を追加し、リンクを渡さないでください。アクセスリンクは遅かれ早かれ公開され、検索エンジンで表示されるためです。

UPD：リンク開示の脆弱性は機能しなくなりました。 オープンリダイレクトとCSRFは長い間修正されています。



PS：最新の記事に遅れないようにするために、 電報 /ツイッター、以下のリンクを購読することをお勧めします。

前の記事： 暗号通貨会社をハッキングし、そこから60,000ドルを稼いだ方法