Exploiting Out-of-Band XXE in the Wild から学ぶ

ソース:

medium.com

脆弱性:XXE

 

訳:

フェーズ 1 → 偵察:

私は shodan が好きで、そこから redacted.com というターゲットに関連する IP のリストを収集しIP を列挙するので。
その後、rustscan (naabu などお好みのものを使用できます) で完全なポート スキャンを実行し、HTTP プローブを作成して、8443、8080、8888、9180、9000 などの異常なポートのチェックを開始して。
そして確かにすべてのリクエストを Bupr Suite に渡しましたが、 9180オープンポートを持つIPに遭遇しました、この IP はいくつかを使用しています xmlという内容だったので、作ってみました POSTとのリクエスContent-Type: application/xmlそれからいくつかのエラーが発生しました! 読んで実践できる XXE をテストすることにして。

 

フェーズ 2 → 分析:

脆弱性の検出に使用されたペイロードを試しましたが、応答にはエラーのみが含まれていたため、ローカル ファイルを直接取得しようとしたため、従来のペイロードを使用し。

 

 

しかし何も得られず。

 



その後、他のペイロードをいくつか試しましたが、同じエラーが発生して。

その後、XXE ペイロードを検索して使用し始め、一部を変更して応答の違いを比較し始めましたが、コンテンツの長さはいくつか異なりましたが、何も理解できず。
すべての応答にはエラー、エラー、エラーが含まれていて。

 

フェーズ 3 → SSRF:

それで、これでは P1 を取得できないと思い、Burp Collaborator (SSRF) に対して HTTP リクエストを実行しようとし。
そこで、もう一度Burp を起動し、XXE から SSRF を実行するペイロードを試し。
このペイロード:

 

 


同じ結果で失敗し。
その後、SSRF を実行するためにいくつかのペイロードを試しましたが、何も得られませんで。
そこで、次のペイロードに出会うまで、古い記事を検索して読み始め。 
 

 

SYSTEM エンティティも使えます、ほぼ同義語で。

 

 

 

 

ペイロードにPUBLIC を使うことにして。

 

 

HTTPインタラクションなので、今私は P4 を提出しています。
HTTPこの時点で、単純なポート スキャンを使用して P3 にエスカレーションするのはどうだろうと考え。
そこで私は簡単なリクエストをhttp://127.0.0.1:9180 に送信し、私はその 9180ポートが開いているのを知っていて、そしてhttp://127.0.0.1:333 のようなランダムなポートに別のリクエストが送信され。
そして、Burp comparer で 2 つの応答を比較し。

 

 

 

そして予想通り、Connection refused をポート 333 から得て。
これは珍しいポートなので、開かないのではないかと思ってて。

 

 

そこで、トップ10000の簡単なポートスキャンを作成しポートを検索し、次の内容を含む応答をフィルタリングします、 Connection refused
そしていくつかのポートが開いています。

Filter responses that contain Connection refused

 

 

そして今、私は有料 BB プログラムでジューシーな P3 を持っています。
実際、それを報告しようとしていましたが、P1 である XXE を検索していたことを思い出したので、いくつかのアイデアが頭に浮かび。
それは、もう一度試してみてはどうですか? XXEを取得します。
しかし、その時はOOBかもしれないと思ったので、 /etc/passwd複数行のファイルなので無理かもしれませんが、 /etc/hostname大丈夫ですから、やってみましょう。 

 

フェーズ 4 → OOB XXE:

そして今のところ、SSRF を作成できるため、アウトオブバンド XXE をテストする時期だと考え。
悪意のある DTD ファイルをホストして SSRF を実行し、サイトに悪意のある DTD ファイルを強制的にリクエストさせれば、XXE を達成できるかもしれません。
ところで、これがこの XXE を手に入れる最後の試みだと自分に言い聞かせました。
ただし、悪用する前に、OOB XXE とは何か、そしてそれがどのように機能するかを理解する必要があります。

次の図は、OOB XXE がどのように機能するかを示しています。

 

https://www.synack.com/blog/a-deep-dive-into-xxe-injection/

 

したがって、ローカル ファイルを要求する悪意のある DTD ファイルが必要なので、これを使用し。 

 

 

そしてポート上にHTTPサーバーを作成する必要があります 8080(または任意のポート) 

 

 

Q: では、このエクスプロイトによって何が得られると予想されますか? 

  1. サイトが悪意のある DTD ファイルを要求しました
  2. 悪意のある DTD リクエス/etc/hostnameファイルを作成して私の IP に送信します 1337ポート
  3. 私のリスナーは次のリクエストを受け取るはずです /etc/hostnameファイルの内容

 

ホスト名 XD のリスナーで結果を取得し。

しかし実際には、次のような複数行のファイルは取得できませんでした。
/etc/passwdまたは /etc/hostsファイルは1行でしか取得できなかったので、PoCとしては十分で報告もできると思っていましたが、正直、取得したかったので。
/etc/passwd 大きなファイルの内容を取得できないことで、影響と重大度が P2 以下に軽減されるのではないかと考えたためです。(正しいか間違っているかはわかりませんが)、大きなファイルの内容を取得してみることにしました。
Burp に戻り。

 

フェーズ 5 → XXE 最終活用:

この段階では、私は OOB XXE 攻撃で知っていることを実行して、base64FTP などの大きなファイルのコンテンツを取得したり、FTP 経由でデータを取得するために使用されるツールを使用したりすることも始めましたが、これらすべての方法で失敗して。
しかしエラーメッセージを介して大きなファイルの内容を取得するのはまだ試してみる必要がありますが、どうなるでしょうか?

 

1. 悪意のある DTD ファイルをホストすると、次の 2 つのことが行われます。

  • /etc/passwdファイル の内容を含む定義済みの XML パラメータ エンティティがあります。
  • 別の XML パラメータ エンティティの動的宣言を含む定義済みの XML パラメータ エンティティがあり、これは、上で定義した事前定義エンティティを名前に含む存在しないファイルをロードすることによって評価され、今度はその /etc/passwdコンテンツが取得され。

2. そのため、サイトが私の DTD ファイルをリクエストすると、名前に/etc/passwd のように定義したエンティティを含む存在しないファイルを取得しようとし。
そのため、存在しないファイルに関するエラーが表示され、このエラーの後、次のことがわかります、/etc/passwd。
詳細と実践については、以下を参照。

 

portswigger.net

リクエストを含む詳細な説明:

 

存在しないファイルを要求する悪意のある DTD ファイルをホストして。
このペイロードを使用して、エクスプロイトがどのように機能するかを理解し。

 

 

応答にはXMLパラメータエンティティの値が含まれている必要があり、 %secret 。

 

 

ご覧のとおり、リクエストを送信したときの値は、 %secret応答に反映されるので、 %secretに値を付ける /etc/passwdファイルの内容が応答に反映されるので、見てみましょう!!

悪意のある DTD ファイルは次のように。

 

 

以前と同じことを行い、応答に /etc/passwd内容か否か!

 

 

そして最後に、アウトオブバンド XXE を介してジューシーな P1 を取得することができ。
これにより、大きなファイルも含めてすべてのファイルの内容を読み取ることができ、それをセキュリティチームに報告したところ、P1 送信として受け入れられました。

 

ほなほな。