ソース：
脆弱性：SSRF
訳：
私がこの投稿を共有したかったのは、これが斬新でユニークな攻撃だからではなく、この特定の機能を攻撃する思考プロセスを示し、何が機能するのか、何が機能しないのかを特定するためにシステムがどのように動作するかを理解することを主な目的としていました。 )
のバグを取り上げます SSRF (サーバー サイド リクエスト フォージェリ この投稿では、発見して悪用するのが本当に楽しかった 。
それを見つけ出し、最終的に活用するまでには多大な労力がかかりました。
突くために私に送られたものです このエンドポイントは、実際には、別のバグハンター仲間であるIbram が (私たちが同じプログラムを使用していることに気づいた後) 。
初めてのコラボレーションでしたが、結果的に興味深いものがたくさん見つかりました。
私たちは二人とも、アプリケーションがどのように動作しているかについて調査し、結果を共有しました。
これは非常に役に立ちました。 から数回 (約 15 のサブドメイン上で) ポップアップしていることにも気付きました また、このエンドポイントがWayback Machine 。
この機能は、SSRF に対するすべてのバグハンターの夢でした。
これは、クライアントが URL を提供できるようにするプロキシ エンドポイントで、サーバーは HTTP リクエストを作成し、その応答を (HTML で) ユーザーに直接表示します。
エンドポイントは https://company.com/proxy のようなものでした。
インスタンスを与えて、 私が最初に試みたのは、 Burp Collaborator 私のインスタンスをフェッチするかどうかを確認することでした。
ここではホワイトリスト機能が使用されていました。
「信頼できる」リストからのみホストを取得します。
いろいろ試してみた company.comドメインを検索し、すべて機能していることに気付きました。
それで私たちはそれを認識することができました *.company.comこのホワイトリストでは許可されていました。 次に私たちが行ったのは、オープンなリダイレクトまたはサブドメインの引き継ぎを見つけようとしたことです。 *.company.com。
これは、オープン リダイレクトを使用して、信頼できる/許可されたドメインを攻撃者が制御するドメインまたは内部のドメインにリダイレクトするか、サブドメインの引き継ぎを使用して信頼できるドメインから独自のコンテンツを提供する必要があったためです。
これらを見つけようとして、いくつかのサブドメインの検出を実行しました。 *.company.comを使用して Findomain を使用してライブ ホストを検索し 、次にhttprobe を使用して Wayback Machine から見つかったすべての URL をプルバックしました 、最後にWaybackurls 。
これにより、オープンなリダイレクトまたはサブドメインの乗っ取りを見つけるために検索する数十万の URL のリストが得られました。
まず、オープン リダイレクトの可能性があるものを求めて waybackurls の出力を grep することで、オープン リダイレクトから始めました。
grep "=http" wayback.txthttp、URL がその場所にあることを示しており、オープン リダイレクトや SSRF を検出するのに最適です。
最終的に、開いているリダイレクトをいくつか簡単に見つけることができました。
ここで、Burp Collaborator インスタンスを指すようにこのオープン リダイレクトを使用してテストに戻ります。
残念ながら、リダイレクトするとデフォルトのエラー ページへの 302 が発生し、リダイレクトに従わないことがわかりました。
ここでいくつかの異なることを試しましたが、最終的には、サーバーが単一の URL を取得して応答を返すだけであるため、リダイレクトは機能しないことがわかりました。
結局、200 以外の応答があると、アプリケーションは 302 応答をスローするということに気づきました。 サブドメインの乗っ取りをもう少し探しましたが、見つかりませんでした。
私の目標はオープンなリダイレクトを見つけることでしたが、残念ながらそれはもはや実行可能な選択肢ではありませんでした。
URL パーサー/ホワイトリスト ロジックをさらに深く掘り下げる前に、以前に発見したサブドメインのリストを見て、それを urlパラメータ。
そのアイデアは、解決されなかったドメイン、または内部的にアクセスできる可能性が高いためタイムアウトになったドメインを取得し、それをパススルーして、サーバーがアクセスできる隠しコンテンツを取得できる可能性があるということでした。
一部のドメインではこれが機能すると期待していましたが、残念ながら興味深いものは何も表示されませんでした。
私もチェックしました *.company.comを指す DNS レコードの場合 localhostまたは 127.0.0.1このドメインは許可されたドメインのリストに含まれていますが、内部的にアクセス可能なサービスを指しているため、このドメインを内部リソースにアクセスするために使用できる可能性があります。
残念ながら、このような DNS レコードを持つドメインは見つかりませんでした。
さて、選択肢が限られているので、URL パーサー ロジックをバイパスして、ホワイトリストから任意の URL を取得することにしました。
私はほぼすべての特殊/奇妙な文字、さまざまなリダイレクト/SSRF バイパス手法、および公開されている単語リストにあるすべての文字を調べましたが、うまくいきませんでした。
IP アドレスまたは 10 進数でエンコードされたバージョンでは、一般的なエラーが発生します。 この一連のテストの後、パーサー ロジックは非常に強力であるように見えました。
結果として、URL ホワイトリストをバイパスすることはおそらく機能しないでしょう。そこで、このホワイトリストが過度に寛容かどうかを確認することにしました。
のリストを取得し 私は Github で見つけた上位 1000 ドメイン 、それを urlパラメータ。
当初考えられていたほど制限されていなかったことが判明しました。 amazonaws.com許可されたドメインとしてポップアップ表示されます。
馴染みのない方のために、 amazonaws.comは、S3 や EC2 などの多くの人気サービスに関連付けられている AWS のドメインであり、顧客は独自のエンドポイントまたはサブドメインを取得します。
ついに！ AWS リソースから独自のコンテンツを提供できます。
これをテストするために、S3 で XSS HTML ファイルをホストしました。
予想通り、うまくいきました！ 最悪のケースとして、報告できる XSS が得られました。 XSS は特定のシナリオでは大きな影響を与える可能性がありますが、これはより脆弱であることがわかっている機能の 1 つであるため、私は推進し続けたいと考えました。 サーバーに HTML または JavaScript を実行させて、iFrame や機密コンテンツの画像を読み込ませるなど、いくつかの異なることを試しました。
AWS メタデータ サービス : <iframe src="http://169.254.169.254/latest/meta-data/"></iframe>
ローカルファイル: <img src="file:///etc/passwd">
残念ながら、以前の動作で示されているように、サーバーは実際にはターゲット URL 上のコンテンツを実行しておらず、単にコンテンツをフェッチして返しているだけでした。 コンテンツを S3 にアップロードする代わりに、より動的なコンテンツを提供できるように EC2 インスタンスを起動することにしました。 私は簡単なサーバーを起動し、 いくつかの単純なFlask さまざまなコンテンツを提供したり、リダイレクトを実行したり、その他いくつかのことを行うための エンドポイントを作成しました。 もっと興味深いものを見つけるためにコンテンツ/ファイルを提供しようとした後、リダイレクトを再検討することにしました。 リダイレクトで特定の応答コードを渡すことができれば、うまくいくのではないかと思いました。 を受け入れるための簡単な Flask エンドポイントを書きました。 urlそして codeクエリ パラメータを使用すると、すべての HTTP ステータス コードを簡単に反復できるようになります。 アプリケーションは同じ URL からの応答をキャッシュしているため、各 URL は異なる必要があることに気付きました。 各リクエストに次のような一意のクエリ文字列を追加することで、この問題を簡単に回避できました。
https://my-ec2.amazonaws.com/redirect?1&url=...&code=302
https://my-ec2.amazonaws.com/redirect?2&url=...&code=302
ここでもまた運が悪かった。 この時点で、私は少し絶望的になったので、何かないか探してみました *.amazonaws.comを指す DNS レコードを持つドメイン localhost , 127.0.0.1、またはメタデータ サービス 169.254.169.254。 予想通り、運はありませんでした。 多くの試行錯誤の後、URL パーサー ロジックをテストしているときに、URL が許可されていない場合、またはターゲット URL が単に 200 応答を返さなかった場合、アプリケーションは異なる応答を返すことに気付きました。 ホワイトリストが実際にはそうではないことがわかりました *.company.com、しかし実際にはそうでした *company.com。 その時はリクエストが失敗していたため気付かなかったのですが、ドメインが存在しないだけであることを思い出しました。 私は今、家に帰りながら、携帯電話で AWS でドメインを購入しています。 neemacompany.com、および DNS レコードの設定 md.neemacompany.com指す 169.254.169.254そして local.neemacompany.com指す 127.0.0.1 .
最終的にドメインが登録され、DNS レコードが伝播されるまでに、私はラップトップを取り出し、すぐに AWS メタデータ サービスと BAM を指す DNS レコードにアクセスしようとしました。
ついに！ 不足している部分を見つけましたが、予想どおり、この機能は実際に脆弱でした。 馴染みのない方のために説明すると、AWS メタデータ サービスを使用すると、認証情報に付与されているアクセス許可に応じて、一時的な AWS 認証情報を取得し、会社の AWS 環境にアクセスできます。 私も試してみました local.neemacompany.comそして、（他の内部サービスを使用して）ローカルホストにもアクセスできることを確認しました。 達成感を感じて、レポートを書いて提出しました。 これで夜も安心して休めます！
ほぼ 1 年前のレポートの重複です。 これには多くの作業とテストが費やされたため、それを見て笑ってしまいました。 1 年経っても修正されていないという事実から、元のレポートでは大きな影響が示されていないのではないかと疑うほどでしたが、それを確認することはできません。 良いバグがだまされるのを見るのは残念ですが、正直に言って、今回の場合は、このバグを解明できたことにほとんど満足していました (たとえこのバグにより、最終的にドメイン購入のために 12 ドルを失うことになったとしても)。 これは、解決しなければ気が狂ってしまうようなバグの 1 つでした。そのため、解明して悪用するのはとても楽しかったので、このプロセス全体をやり遂げることにやりがいを感じました。 と協力できたことも素晴らしかったです。Ibram また、別のバグ ハンターであるIbram は、この特定のターゲットで本当に素晴らしいバグと興味深い手がかりを見つけてきました。
ほなほな。
