JIRA の脆弱性を利用して米軍の非機密インターネット プロトコル ルーター ネットワークにアクセスする例の分析

以下では、JIRA 脆弱性 CVE-2017-9506 を使用して SSRF 攻撃対象領域を構築し、未分類のインターネット プロトコル ルーターを実現する、米国国防総省 (DoD) のハック ザ ペンタゴン脆弱性公開テスト プロジェクトへの著者の参加について説明します。米軍ネットワーク (NIPRnet) アクセスを利用し、他の脆弱性技術と組み合わせて、国防総省イントラネット システムの一連の機密情報を取得しました。テストのプロセスと内容は機密事項であるため、この記事ではこの点についてのみ触れ、技術的な詳細や詳細なシナリオについてはあまり公開せず、学習と共有のみを目的としていますので、読者の皆様にはご容赦いただければ幸いです。

JIRA は、オーストラリアの Atlassian Company が開発した優れた問題追跡および管理ソフトウェア ツールで、欠陥、タスク、要件、改善など、さまざまな種類の問題を追跡および管理できます。 JIRA は J2EE テクノロジーを使用し、プラットフォーム間で展開できるため、多くの有名企業やオープン ソース ソフトウェア組織が JIRA を使用しています。

最初から始めましょう - DoD の JIRA アプリケーション Web サイトの発見

米国国防総省 (DoD) の脆弱性公開テスト プロジェクトに参加したとき、次の 2 つの特別な Web サイトがあることに気付きました。導入されたプロジェクトの追跡 管理ツール JIRA の予備分析の後、悪用可能な脆弱性はないと考えたので、さらに深く調査しませんでした。

その後、JIRA の脆弱性を悪用して SSRF 攻撃を実行するという投稿を Twitter で見つけました:

##つまり、これは次のことを意味します。 :

JIRA ユーザーの皆さん、気をつけてください!攻撃者は JIRA の脆弱性 CVE-2017-9506 を悪用してイントラネット データを盗む可能性があります。これは未解決のリダイレクト脆弱性ですが、場合によっては、内部 JIRA システムのローカル リンク アドレスにリダイレクトするために悪用され、AWS キーなどの特定の内部リソース情報の漏洩につながる可能性があります。

JIRA 脆弱性 CVE-2017-9506 の説明

オランダのセキュリティ研究組織 Dontpanic は、CVE-2017-9506 脆弱性のおおよその原因を明らかにしました。JIRA には次の内容が含まれています。認証および認可プラグインである Atlassian OAuth プラグインには IconUriServlet と呼ばれるコンポーネントがあり、これはクライアントからパラメータ値 ConsumerUri を持つ GET リクエストを受信するために使用されますが、IconUriServlet コンポーネントを使用して、 JIRA が間接プロキシとして開始したこの種のリクエストは、サーバーによって応答され、その後 JIRA 経由でクライアントに返されます。このプロセス中に、リクエストを構築することにより、サーバーの内部情報が漏洩し、サーバーに返される可能性があります。応答コンテンツ内のクライアント。

Dontpanic による脆弱性検証方法:

https://�sepath%/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google 。 com

ベースパスを JIRA システム Web サイトのリンクに置き換えます。上記のページにアクセスした後、google.com ページが正常に表示されれば、JIRA システムに脆弱性が存在することがわかります。404 ページが表示された場合は、JIRA システムに脆弱性が存在することがわかります。アクセス時に「」と表示される場合は、脆弱性は存在しません。 ConsumerUri の最後に、テストする Web サイトへのリクエストを追加することに注意してください。 ！ ！

国防総省の JIRA アプリケーション Web サイトの脆弱性のテスト

CVE-2017-9506 の説明を注意深く読んだ後、宝物を見つけたような気分になり、すぐに 2 つの国防総省に相談しました。以前に発見したウェブサイトを検索し、この脆弱性悪用技術の実現可能性を検証したいと考えていました。 Web サイトの 1 つをテストした結果、Google ページに正常にジャンプできることがわかりました。これは、Web サイトに脆弱性があることを意味します。

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com

AWS の規制に従って、どのインスタンスも AWS が設定したメタデータ アドレス 169.254.169.254 をリクエストすることで、独自のインスタンス メタデータの例を取得できます (関連する方法については、AWS 公式の手順を参照してください)。この目的を達成するために、リクエストを開始するためのリンク

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http: を作成しました。 //169.254. 169.254/latest/meta-data/local-hostname/

実際に内部ホスト名を確認できます。さて、AWS キーを取得してみましょう:

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http:///169.254.169.254/最新/メタデータ/iam/security-credential

しかし、うまくいかないようです。 AWS の公式ドキュメントを注意深く読んだ後、次のリンクを再利用してインスタンス ID、プライベート IP アドレス、その他の情報を取得しました:

https://website.mil/plugins/servlet/oauth/users / icon-uri?consumerUri=http://169.254.169.254/latest/dynamic/instance-identity/document

非常に良いです。応答を正常に取得できます。

この時点では、問題を説明できるはずだと思い、脆弱性レポートを作成し、それ以上のテストは行わずに提出しましたが、その後、国防総省のプロジェクト分類担当者がこの脆弱性を中リスクの脆弱性として分類しました。しかし、これは間違いなく深刻な高リスクの脆弱性であると思います。国防総省と協議した後、私はこの脆弱性の最終的な影響をテストするための詳細なテストの許可を要求しました。

#詳細なテスト - 非機密インターネット プロトコル ルーター ネットワーク (NIPRnet) へのアクセスを実現し、その他の機密情報を取得します

#予備偵察による発見

まず、基本的なポート検出から開始し、ターゲット システムがポート 21、22、80、443、および 8080 を開いていることがわかりました。これらのポート情報を使用して、さまざまなエラー メッセージが返されることをテストし、ターゲットを判断できます。以下に示すように、システム内のサーバーとネットワークの配置は、ターゲット システムのポート 8080 に対してリクエストが行われた後の応答情報です。 , gopher ファイル ディレクトリ内のプロトコルと DICT 辞書を確認しました。サーバー プロトコル、FTP プロトコル、LDAP 軽量ディレクトリ アクセス プロトコル、その他のプロトコルがリクエストに対してテストされました。たとえば、システムは LDAP をサポートしていない次の応答を返しました。

包括的な使用状況の検出

この情報を記録するときに、私は次のように考えました。 PortSwigger の主任研究員 James Kettle が、米国 2017 Black Hat Conference で自身の研究「Cracking the Lens: Targeting HTTP's Hidden Attack-Surface (レンズのクラッキング: HTTP の隠れた攻撃面をターゲットにする)」を公開しました。James Kettle は、ターゲット システムでの HTTP サービスの隠蔽の概要を示すために、悪意のある HTTP リクエストとヘッダー ヘッダー情報を構築しました。 . 攻撃面、最終的に、彼はこのテクノロジーを米国国防総省の内部 IP ID として「偽装」するために使用し、国防総省の制限された内部ネットワーク システムと関連リソースへの侵入とアクセスに成功しました。 Kettle 氏の共有の中で、彼が侵入テストに使用した 2 つの国防総省内部 Web サイトも示したことを覚えています: (Web サイト情報ソース Defensecarry.com)

https://safe.amrdec .army.mil /safe/

https://dots.dodiis.mil/

James Kettle 氏が言及したこれら 2 つの国防総省内部 Web サイトを結合し、「見つけた 2 つの国防総省 JIRA Web サイト」と「目的は、James Kettle 氏が言及した 2 つの国防総省内部 Web サイトへのアクセスがこの方法で達成できるかどうかをテストすることでした。最後に、JIRA サイトの 1 つを使用して、James Kettle 氏が言及した 2 つの国防総省内部サイトにリクエストを行ったところ、そのうちの 1 つでリクエストのタイムアウトが表示されました。

#このテスト プロセス中に、他の国防総省内部 Web サービスも発見しました。この内部 Web サービスを通じて、私は実際、機密レベル以下の機密情報を処理するために国防総省内部で使用されている米軍の非機密プロトコル ルーティング ネットワーク (NIPRnet) へのアクセスに成功しました。具体的な方法や方法については秘密保持の原則からここでは詳しく公開しません。

応答内容を判断して内部機密情報を取得する

2 番目の JIRA Web サイトを使用して、James Kettle 氏が言及した 2 つの国防総省内部 Web サイトへのリクエストを開始した後、返された応答情報は次のとおりでした。基本的に提供できるものは何もありません。

テストの結果、最終的に国防総省内部システム ポートのオープンを応答時間に基づいて評価できることがわかりました。たとえば、内部システムからポート 22 を要求した場合、応答には 1,000 ミリ秒かかりますが、ポート 21 を要求した場合、応答には 10,000 ミリ秒近くかかり、この時間差からポートの状態を推測することができます。さらに、詳細なエラー メッセージの応答がないため、システム内の特定のプロトコルについて判断することはできませんが、この記事の焦点は次のとおりであることを強調したいと思います。内部 Web サーバーを通じて、国防総省のサーバーにアクセスできます。非機密プロトコル ルーティング ネット (NIPRnet)!また、Burp の Collaborator プラグインを使用して、Web サーバーへのリクエストが開始された後、サーバーとリクエスターの間のデータ交換中の情報漏洩を検出しました。

たとえば、内部 IP はリクエスト ヘッダーの 'X-Forwarded-For' から取得できます。私は Burp の Collaborator プラグインを使用してすべてのインタラクティブな内部 IP をクエリしましたが、内部 IP および関連するネットワーク サービス情報は含まれますが、AWS メタデータの取得は Web サーバーでは実行できません。

最終的に、関係する 2 つの脆弱性を国防総省に提出したところ、両方の脆弱性が緊急と評価されました。このことから、私は今年の初めに国防総省に報告した 2 つの SSRF 脆弱性を思い出しました。この SSRF 手法を使用して上記の脆弱性を徹底的に悪用できるかどうかを確認します。

JIRA SSRF の徹底的な活用

今年の初めに私が報告した 2 つの SSRF 脆弱性は、特定の Web アプリケーション フィルターを使用して特定の IP アドレスへの HTTP 接続リクエストを開始できるというものです。たとえば、CONNECT IP リクエストを送信して、ターゲット システム内のアプリケーション サービスを列挙します。さらに、ホスト ヘッダー情報を変更することで、検証済みのリクエスト情報をターゲット システムの内部 IP または外部 IP に送信することもできます。 Militarywebsite.mil@internal_IP として。これら 2 つの JIRA Web サイトでこの SSRF メソッドをテストしたところ、以前にタイムアウト、SSL エラー、その他の応答を要求していたリクエスト環境では、ブラインド SSRF メソッドを使用して内部 IP およびネットワーク サービスを列挙することもできることがわかりました。したがって、この時点での SSRF 脆弱性エクスプロイトは、最終的に国防総省によって中リスクと評価されました。

JIRA SSRF の脆弱性を悪用するその他のテクニック

上記の脆弱性を包括的にテストしたところ、場合によってはスタック エラーが不可解に発生し、さまざまな機密情報が漏洩することがわかりました。不完全な HTTP ヘッダー情報 http:// または http://[::] を使用しています。このスタック エラー中に漏洩した機密情報には、データベース IP、データベース バージョン、アプリケーション プラグイン、オペレーティング システム アーキテクチャ、その他のシステムが含まれます:

スタック エラーが発生した場合でも、ターゲット Web サイトから詳細な情報を引き続き取得できます。たとえば、ターゲット Web サイトが他の Altassian インスタンスをポイントしている場合があることがわかりました。ある時、テスト中に Altassian の Confluence インスタンスが対象サイトのサブドメイン名にデプロイされていることが分かり、これらのインスタンスも情報漏洩の脆弱性の影響を受けることが判明しました。

要約とレビュー

著者は、米国国防総省の脆弱性公開テスト プロジェクトに参加中に発見された JIRA の脆弱性について説明し、脆弱性悪用テストのプロセス全体を簡単に紹介します。 :

1 JIRA インスタンスがデプロイされている国防総省 Web サイトのうち 2 つには、認証プラグインの脆弱性 CVE-2017-9506 があります。攻撃者はこの脆弱性を利用して、ターゲット Web サイト システムの内部リソース情報を取得し、 SSRF 攻撃対象領域を形成します。;

2 CVE-2017-9506 悪用手法と組み合わせて、脆弱な国防総省 Web サイトから JIRA インスタンス ID、プライベート IP アドレス、一連のエラー応答、およびその他の情報を取得しました。

3 総合 PortSwigger の主任研究員 James Kettle は、言及された 2 つの国防総省 Web サイトを共有しました。CVE-2017-9506 リクエスト メソッドを使用すると、要求された国防総省 Web サイトが有効な USG (政府警告) 情報を返したことが判明しました。

4 プロセスのステップ 3 で、発見した内部 Web サービスと CVE-2017-9506 エクスプロイト手法を組み合わせて、国防総省非機密性プロトコル ルーティング ネットワーク (NIPRnet) へのアクセスを実現しました。

5 CVE-2017-9506 エクスプロイトとの組み合わせ この方法は、脆弱な国防総省 Web サイトに対する SSRF 攻撃を再現し、内部 IP およびネットワーク サービスの列挙を実装し、後続のスタック エラーが発生した場合に機密情報を取得しました。

以上がJIRA の脆弱性を利用して米軍の非機密インターネット プロトコル ルーター ネットワークにアクセスする例の分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。