Facebookの報奨金を2回受賞した方法

2020年3月にパンデミックが始まったので、暇な時間がたくさんありました。それらは賢明に管理する必要があり、私はOSWE認証を取得することにしました。 8月8日に試験に合格した後、私は2週間休みを取り、9月中旬に自分にこう言いました。私の名前は2020年にFacebookの殿堂に表示されませんでしたが、毎年表示されます。この問題を解決する時が来ました！」



Facebookサブドメインの1つに脆弱性を見つけたことがないので、記事を調べて、Facebookサブドメインに関する1つの投稿を見つけました。これは素晴らしい投稿です。読むことをお勧めします： [HTMLからPDFへの変換のバグはFacebookサーバーでRCEにつながる]。



この投稿を読んだ後、私はそのような巨大なWebアプリケーションに多くの脆弱性が見つかることに気づきました。



私の主な目標は https://legal.tapprd.thefacebook.com



、RCE（リモートコード実行）などを実装することでした。



ファジングツールを実行して、このWebアプリケーションのすべてのエンドポイントを見つけ、2時間の昼寝をして、映画を見ました。それから私は自分のコンピューターに戻り、良い結果を見つけました。

403:



/tapprd/

/tapprd/content/

/tapprd/services/

/tapprd/Content/

/tapprd/api/

/tapprd/Services/

/tapprd/temp/

/tapprd/logs/

/tapprd/logs/portal/

/tapprd/logs/api/

/tapprd/certificates/

/tapprd/logs/auth/

/tapprd/logs/Portal/

/tapprd/API/

/tapprd/webroot/

/tapprd/logs/API/

/tapprd/certificates/sso/

/tapprd/callback/

/tapprd/logs/callback/

/tapprd/Webroot/

/tapprd/certificates/dkim/

/tapprd/SERVICES/

この結果は、このアプリケーションの巨大さについての私の理論を確認するのに十分だと思います。それから私は彼が使用してどのような方法でウェブサイト、などが...どのように理解することはJavascriptがあるファイルを、読み始めた



私は上のログインSSOへのリダイレクトのバイパスへの道を見て https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login



、ログインページを分析した後、私はこのエンドポイントが見つかりました：



/tapprd/auth/identity/user/forgotpassword







後ユーザーのエンドポイントで/savepassword



ファジーになり、POSTリクエストを待っている別のエンドポイントを特定し ました。Javascriptファイルを調べた後、ページがどのように機能するか、生成されたトークンとxsrfトークンが必要かどうかなどを理解しました。最初は試してみる価値があると思いました。確認するには、ヘルプを使用して手動で変更するかどうかを確認できます burp suite



が、エラーが発生しました 操作の失敗。



メールアドレスが間違っているのではないかと思いました。管理者のメールを拾ってみましょう。私は任意の電子メールアドレスを書き留め、単語のリストを作成し、次にげっぷを使用して何が起こったかをテストし始めました。



数時間後に戻ったとき、同じエラーに加えて別の結果が表示されました。ログインページへの302リダイレクトでした。うわー、くそーそれは働いた！



ここで何が起こったのかを説明しましょう。クラッカーを使用してCSRFトークンでランダムなリクエストを送信し、新しいエンドポイントパスワード/savepassword



でランダムなメールアドレスを送信しました 。その結果の1つは302リダイレクトでした。





リダイレクト



これで、ログインページに移動し、電子メールと新しいパスワードを入力できます-BOOM、アプリケーションへのログインが成功し、管理パネルにアクセスできました！





以前のRCEがPDFで実装されていることを発見したハッカーのレポートを読みましたが、会社は彼にわずか1000ドルの報酬を与えました。だから私は決めました：わかりました、あなたは良い印象を与え、高いインパクトを得るために完璧なエクスプロイトを書く必要があります。



この脆弱性を悪用する簡単なPythonスクリプトをすばやく作成しました。メールアドレスと新しいパスワードを入力すると、スクリプトによってパスワードが変更されます。





Facebookの従業員が自分の仕事用アカウントでログインしたため、ここでの影響は非常に大きかった。つまり、彼らは独自のFacebookアカウントアクセストークンを使用しており、別の攻撃者がこのエクスプロイトを使用したい場合、一部のFacebook従業員のアカウントにアクセスできる可能



性があります。その後、脆弱性を報告し、レポートを確認しました。 。



10月2日に7,500ドルの賞を受賞しました





私はこの脆弱性のエクスプロイトがとても好きで、それだけでは不十分で、スクリプトが弱すぎると判断しました。深く掘り下げることは価値があります。



そのため、さらに2つの脆弱性が見つかりました。これについては、記事の後半で説明します。

パート2

では 最初の部分、私は私がFacebookのセキュリティ部門が私に支払っているため、ユーザの介入なしすべての管理者アカウントのパスワードを変更することができ、安全でないAPI、とのアカウントを乗っ取るための能力を発見 $ 7,500。では 第二部、私はクッキーの操作を使用してアカウントをハイジャックする方法を発見しました。それを内部SSRFと組み合わせると 、$ xxxxxの報酬を受け取りました 。はい、5桁の合計...さて、始めましょう。

掲載前に複数の関係者が記事をチェックしており、書面による許可が必要だったため、Facebookやそのパートナーの要請により、名前や情報の一部を変更することができました。

記事の最初の部分から脆弱性を発見したとき、Facebookはレポートを受け取った翌日にそれを修正しました。それから私は歴史burp suite



を研究し始め、 それがどのように機能するかを理解しました。





スクリーンショット（青い背景の番号1）からわかるように、ASPXAUTHはCookieとして使用され ます。理想的には！



私が何をしているのか分かりますか？ ASPXAUTHは80％の確率で脆弱ですが、これには次の情報が必要です。

• validationKey
  
  
  
  (): , .
• decryptionMethod
  
  
  
  (): ( «AES»).
• decryptionIV
  
  
  
  (): ( — , ).
• decryptionKey
  
  
  
  (): , .

これについて詳しくは、MachineKeyクラスをご覧ください 。



どの点についても情報がないのに、なぜここに脆弱性があると思ったのですか？



実際、私はそれを知りませんが、暗号化キーを使用して暗号化されたCookie内のほとんどのASPXAUTHアプリケーション は、通常、電子メールまたはユーザーとCookieの有効期限のみを使用します。私は他のウェブサイトの報奨金プログラムでこの方法を何度も使用しましたが、うまくいきました。



私はこのシステムを回避する方法を見つける必要がありました。少なくとも拷問の試みではありませんでした。私はグーグルに行き、同じアプリケーションを使用する他のウェブサイトを探しました。運が良ければ、同じアプリケーションと同じ暗号化キーを使用しているWebサイトを見つけて、正しい管理者ユーザー名を選択することになっていました。



同じアプリを使用している別のウェブサイトを見つけました。登録がアクティブだったので、Facebook管理者のユーザー名でログインし、リクエストを傍受し、 ASPXAUTHを取得し て、期限切れのFacebookASPXAUTHに置き換えました。何が起こったと思いますか？







私はすでにこのパネルを見逃していましたが、ついにそれに戻りました。それでは、ほとんどの開発者がアプリケーションを安全に保つためにアプリケーションを構築するときに考慮すべきASP.netの監視について少し話しましょう。

• ASPXAUTHはデータベースに保存する必要があり、アプリケーションはそれが正しいかどうかを検証する必要があります。
• 追加のチェックとして、ASPXAUTHにはユーザー名以外のものが含まれている場合があります。
• 各サイトには、一意の暗号化キーと復号化キーが必要です（デフォルトのキーを変更する必要があります）。

結論1：ユーザー名だけを知っていれば、どの管理者アカウントにもログインできました。この脆弱性の複雑さは非常に低く、その影響は大きいと 思い ます。この脆弱性のみを報告した場合、最初の部分と同様に、7,500ドルしか受け取りませんが 、もっと欲しかったのです。



パネルで、私は何か奇妙なことに気づきました。つまり、フォームを作成するオプションと、別のオプションであるAPIトリガーです。私は何かを疑った。おそらく無制限のSSRF（サーバー側要求偽造）の可能性がある。そのため、私はFacebookのセキュリティ部門に手紙を書き、アプリケーションには重大なSSRFの脆弱性のほぼ100％があり、テストの許可を求めていると述べました。答えは私に来ました：





当時、私は最初の部分（アカウントの乗っ取り）からの報告について、最初の1週間後にこれらの脆弱性を報告したため、まだ彼らと話し合っていました。ご覧のとおり、Facebookのセキュリティ部門は、脆弱性を証拠で説明した後も、私が別の認証バイパスとSSRFを要求していると信じ続けていました。これから判断して、SSRFをテストする許可が与えられました。



しばらくして、私は小さなスクリプトを書き、それを彼らのエディターにアップロードしました。このスクリプトを使用すると、任意のデータ（GET、POST、PUT、PATCH、HEAD、OPTIONS）を含む任意のリクエストを、内部と外部の両方の任意のURLに送信できました。





スクリプトのバックエンドから、リクエスト方法や送信するデータなどを変更できます。



この段階で、この脆弱性をRCE、おそらくLFI（ローカルファイルインクルード、ローカルファイルの追加）に拡張できます。もう少し先に進むと（ これについては完全にはわかりませんが、後でFacebookにリバースエンジニアリングの許可を求めました）アプリケーションですが、彼らは拒否し、私が攻撃を拡大できるとは思わないと述べました）。



それから私はカナリアスクリプトでFacebookを攻撃しようとしました。何が再び起こったと思いますか？





カナリアトークンを受け取りました。次は何ですか？上で述べたように、スクリプトやPoC（概念実証）を含むすべての詳細を含む新しいレポートを作成する必要があります。



結論2：任意のリクエストを送信するスクリプトを作成することで、内部SSRFを取得 し、内部Facebookネットワークへのアクセスを提供できました。この攻撃の難易度は低く、影響は重大だと思い ます。

Impact SSRF:



SSRF- Facebook, , -, . SSRF .



SSRF-, , , , , .

SSRFの脆弱性の詳細については、portswiggerの記事を参照して ください。



最後のポイント：両方の脆弱性をFacebookイントラネット（SSRF）にアクセスできるように連鎖させ、アカウントの乗っ取りを使用してアプリケーション内のアップロードされたスクリプトにアクセスし 、必要な任意のリクエストを送信しました。



私が発見した脆弱性チェーンで何が達成できるかについて話しましょう：

• 法務部門のダッシュボードでFacebookの従業員のアカウントにアクセスできます。
• ログイン後に攻撃者が取得できる情報の重要性を説明する必要はありません。
• SSRFを使用してFacebookイントラネット（intern.our.facebook.com）にアクセスできます。
• もう少し努力すれば、この脆弱性を拡張して、内部ネットワーク/サーバーをスキャンするために使用できると思います。

特に周波数が制限されていない場合、SSRFがいかに重要であるかは誰もが知っています 。コンテンツタイプとリクエストメソッドを簡単に変更できます。Facebookの支払いガイドによると、 リクエストのコンテンツタイプとリクエスト方法を変更できる場合、この脆弱性は$ 5,000のボーナス で$ 40,000で報われるはず です。



長い間待った後、Facebookから次のメッセージを受け取りました。





受信$、40,000のFacebookから賞を プラス $、2,000ボーナス（からのアップが期待される $ 7,000）。



フルコントロールボーナス（$ 5,000）を受け取らなかった理由について質問し、 次の回答を受け取りました。







合計で、最初の脆弱性で、これは54,800ドルに達しました 。



この脆弱性は、脆弱性レポートの最初の部分の数日後に報告しました。



レポートの年表：

• 2020年9月9日水曜日-脆弱性レポートが送信されました。
• 2020年10月26日（月曜日）は- Facebookは新しいレポートを開くために私に尋ねました。〜取られた是正措置。
• 2020年10月26日月曜日-レポートのレビュー。
• 2021年2月25日木曜日-問題は解決され、報奨金が支払われました。 約半年、ええ。
• 2021年3月5日金曜日-5,300ドルのボーナスが支払われました。

バグハンターに貴重なアドバイスをしたいと思います。ASPXAUTHが表示されたら、同じアプリケーションを使用して別のWebサイトからCookieを取得し、私のものと同じ方法をテストしてみてください 。

• 別のWebサイトから新しいASPXAUTHCookieを作成します。
• 調査中のWebサイトでCookieが機能するかどうかを確認してください。

私はこのプロセスが好きでしたが、6か月待って、不合理な理由でレポートを閉じるのは面倒でした。私は感謝していますが、一生懸命働かなければならず、これが私が見つけた唯一のSSRFではありません。実際、もっと興味深いものを見つけましたが、Facebookは、レポートを確認してから数週間後にサプライヤーと契約を結んだため、レポートを「有益」として閉じました。結局、これは私の問題ではないので、この経験は楽しいものではありません。



最後に、不明な点がありましたらお詫び申し上げます。第二部の発行には少し時間がかかりました。前述のように、私は書面による許可と報告書の改訂を待っていました。したがって、第三者の機密性を保持するために、多くの側面が削除または検閲されています。