Hacking NASA: Critical SSRF + Subdomain Takeover + XSS から学ぶ - The light of hope to the other side of the tunnel

ソース：

nickguitar.medium.com

脆弱性：SSRF, Subdomain, XSS

訳：

私はまず偵察を行い、できる限り多くのサブドメインを列挙して。
当時、プログラムの対象となるドメインは 6 つほどありましたが、私は次のことに焦点を当て。
globe.gov、これは NASA が所有するドメインで、前の週に追加され。これまで他のハッカーによってテストされていなかったので、魅力的なものが見つかる可能性が高いだろうと思って。

ここでは、特別なことは何もせず。
さまざまなツールとメソッドを実行して、たくさんのサブドメインを収集しようと。

amass enum -passive -d globe.gov
amass db -names -d globe.gov
sublist3r -d globe.gov
subfinder -d globe.gov
crt.sh globe.gov
ffuf -u https://FUZZ.globe.gov -w /usr/share/wordlists/dirb/common.txt -p 1
ffuf -u https://globe.gov -w /usr/share/wordlists/dirb/common.txt -H "Host: FUZZ.globe.gov"

かなりの量 (約 60) のサブドメインを収集した後、 globe.gov それらを target.txt に保存し、次のスイッチを使用して、デフォルトのテンプレートを使用してニュークリアスを実行することにしました。

-l: specify a list of targets as input
-fr: follow redirects
-headless: enable templates that require headless browser support
-sa: scan all the IP's associated with DNS record
-o: output file

nuclei -l targets.txt -fr -sa -headless -threads 100 -o nuclei.out -user-agent "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6284.218 Safari/537.36"

同時に、次のスイッチを使用して httpx を実行し、これらのサブドメインで実行されている基盤となるテクノロジーに関する情報を取得して。

-l: specify a list of targets as input
-sc: display response status code
-location: display response redirect location
-title: display page title
-server: display server name
-td: display technology in use based on wappalyzer dataset
-ip: display host ip
-t: threads
-o: output file

httpx -l targets.txt -sc -location -title -server -td -ip -t 100 -o httpx.out

これらの数十のサブドメインを何時間も手動でチェックした結果、次のものが見つかり。
これらはすべて AWS でホストされていて。

(part of httpx output):

https://vis.globe.gov [200] [] [Apache] [54.88.107.180] [vis-prd8-alb-330099320.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://vis.globe.gov [200] [] [Apache] [34.202.212.250] [vis-prd8-alb-330099320.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://visdev.globe.gov [200] [] [Apache] [54.212.156.208] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://visdev.globe.gov [200] [] [Apache] [54.71.79.52] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS]
https://visstaging.globe.gov [200] [] [Apache] [54.167.243.237] [Apache HTTP Server,HSTS]
https://visstaging.globe.gov [200] [] [Apache] [52.21.90.127] [Apache HTTP Server,HSTS]
https://visdev72.globe.gov [301,200] [] [Apache] [54.71.79.52] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS] https://visdev.globe.gov/
https://visdev72.globe.gov [301,200] [] [Apache] [54.212.156.208] [vis-dev-alb-1057329347.us-west-2.elb.amazonaws.com] [Apache HTTP Server,HSTS] https://visdev.globe.gov/
https://visstaging7.globe.gov [301,200] [] [Apache] [52.21.90.127] [vis-stg7-alb-2086148035.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS] https://visstaging.globe.gov/
https://visstaging7.globe.gov [301,200] [] [Apache] [54.167.243.237] [vis-stg7-alb-2086148035.us-east-1.elb.amazonaws.com] [Apache HTTP Server,HSTS] https://visstaging.globe.gov/

これらはすべて、異なる環境 (開発、ステージング) で実行されている実質的に同じページで。
ページは次のようになります (現在と同じ)。

次に、核ログをチェックして、何か興味深い点がないかどうかを確認。 vis.globe.govそして驚いたことに、これを見つけました（同じことが他のすべての製品にも存在しました） vis*.globe.gov)。

[geoserver-login-panel] [http] [info] https://visdev.globe.gov/geoserver/web/ [2.20.4]
[CVE-2021-40822] [http] [high] https://visdev.globe.gov/geoserver/TestWfsPost

私はすぐにその「高い」発見に焦点を当て、CVE-2021-40822 に関する調査を開始し。

サーバー側のリクエスト偽造

このサブドメインでは、GeoServer のインスタンスが実行されて。
GeoServer は、衛星画像、気候データ、森林、水資源などの地理空間データを共有するために使用される Java で書かれたオープンソースソフトウェアで。
このデータは、Google マップ、MapBox、およびその他の同様の地図エンジンで表示。

このバージョンの GeoServer には、CVE-2021–40822 として特定される既知のサーバーサイドリクエストフォージェリ (SSRF) の脆弱性が存在していたことが判明しました。この脆弱性は私の同胞によって発見されて。

ウォレソン・モウラ {phor3nsic}

。で詳しく説明しています　彼はこの脆弱性について記事 (これを書いている時点では、Google キャッシュ経由でのみアクセスできます)。

彼はまた、概念実証エクスプロイトを作成し、GitHub で公開して。
悪用は非常に簡単で。
スクリプトは POST リクエストを実行しようとします。
example.com/geoserver/TestWfsPostパラメータ「url」は攻撃者の URL を指し、「Host」ヘッダーも別の URL を指します。
いずれかの URL が取得されると、その内容が応答に反映され、ターゲットが SSRF に対して脆弱であることが示されて。

次に、その visdev サブドメインでこの PoC を作成しようとしました。
POST パラメータ「url」を、ログを確認できるドメインと Host ヘッダーを指定したところ、次のような結果になり。

webcache.googleusercontent.com

github.com

visdev サーバーから ping を受信しましたが、サーバーにインストールされている Java のバージョンがユーザーエージェントですでに漏洩していました。つまり、サーバーは実際に SSRF に対して脆弱であることが確認されました。かなり朗報です（私にとって）！

httpx が、これらすべてのことを私たちに示したことを思い出して。 vis*.globe.govサブドメインは AWS でホストされていましたか?
AWS インフラストラクチャ上の SSRF が壊滅的な影響を与える可能性があることはよく知られています。
これは、すべての EC2 インスタンスが IP アドレス 169.254.169.254 の特定の AWS サーバーにアクセスできるためで。
この IP は、AWS などのさまざまなクラウドサービスプロバイダーによって、インスタンスにメタデータを提供するために使用され。
インスタンス ID、タイプ、ユーザーデータ、セキュリティグループに関する情報などのデータを返すことができて。

私のドメインには、このメタデータサーバー (aws.0x7359.com -> 169.254.169.254) を指すように設定されたサブドメインがすでにあって。
そこで、これを「url」パラメータと「Host」ヘッダーの両方の値として使用し。
結果は予想どおりで、メタデータサービスのすべてのバージョンがリストされ。

ディレクトリを参照してデータを読み取ることができます。ホスト名を読み取ると、このインスタンスの内部 IP が漏洩し。

を閲覧するとき /latest/meta-data/identity-credentials/ec2/security0credentials/ec2-instance、AccessKeyId、SecretAccessKey、Token などの非常に重要な情報を取得することができ。

この情報を使用すると、AWS CLI で認証して悪用を続けることが可能になり、アクセス許可とセキュリティ設定に応じて RCE (リモートコード実行) やインフラストラクチャの完全な乗っ取りを実現できる可能性があり。

私はこれらの資格情報をテストしようともしませんでした。
これが範囲内であるかどうかがわからず、FBI のリストに載るのが嫌だったからで。
私は手持ちの証拠をすべて集めて報告書を書き始め。

サブドメインの乗っ取り

上の NASA の脆弱性公開プログラムに提出してから数時間後 SSRF レポートを作成して、 BugCrowd 、核の結果に戻り。
*.globe.gov そしてまた別の「高い」項目に遭遇し。

[meteor-takeover] [http] [high] http://annualmeeting2022.globe.gov
[tech-detect:meteor] [http] [info] https://annualmeeting2022.globe.gov/                                                                                 new_targets/nuclei_new_targets.txt:[meteor-takeover] [http] [high] http://annualmeeting2022.globe.gov                                                                                       new_targets/nuclei_new_targets.txt:[tech-detect:meteor] [http] [info] https://annualmeeting2022.globe.gov/

「乗っ取り」と書かれているので、すぐに DNS を解決してどこを指しているのかを確認して。

us-east-1.galaxy-ingress.meteor.com を指していましたが、この DNS は機能していませんでした。そのドメインでホストされている Web ページはありませんでした。 Google で簡単に検索すると、この記事とこの記事が見つかりました。
この買収について説明した。

要約すると、meteor.com でアカウントを作成した場合、これを再利用できます。 galaxy-ingress のホスト名 us-east-1リージョンを選択すると、そのページに必要なものをすべて配置できるようになり。
サブドメインなので annualmeeting2022.globe.gov それを指していました galaxy-ingress ホストの場合、そのページの内容が反映され、私の制御下にあって。

したがって、前述の記事に従い、meteor.com でアカウントを作成し、Docker コンテナを起動し、すべてをセットアップした後、そのホスト名とリージョンで Web サーバーを起動することができ。

アプリケーションは次の場所に正常にデプロイされました。
us-east-1.galaxy-ingrss.meteor.com、そして私はそれを完全に制御でき。
以来 annualmeeting2022.globe.gov がそれを指していたため、私はこの NASA サブドメインで提供されているものを制御することもでき。

そのとき、概念実証 (PoC) を含む Index.html をアップロードしました。アクセスすると、これが表示され。 annualmeeting2022.globe.gov:

ああ、実際には、meteor.com でそのページを作成するには、アカウントにクレジットカードを追加して 1 ドルを支払う必要がありましたが、アカウントを無効にしてから数日後に返金され。

XSS

あれから数日後、私はまた戻ってきました。
visdev.globe.gov、まだテストしていない入力がまだたくさんあったためで。

すべてをクリックし始め、すべての入力を使用し、登録とログインを試み、次のような一般的だが古いものをいくつかテストしました。 ' or 1=1、いくつかの XSS など。

同時に、私の友人が同じページをテストしており、特定の GET パラメーターに XSS 脆弱性を見つけることができました。彼はペイロードを使用しました /?no_welcome=a'-alert(1)//、一見すると少し奇妙に見えましたが、ソースコードを見るとすべてが理解できました。

このパラメータの値は、JavaScript コード内の変数の値として使用されていました。変数のコンテキストからエスケープして、URL から直接任意の JavaScript コードを記述することが可能でした。この動作は他の多くの変数にも同様に存在することがわかり。

結果はこうなって。

XSS の PoC としてはこれで十分だと思いましたが、もう少し進めて、より汎用性の高いペイロードで攻撃を武器化することにし。
このペイロードにより、複雑な悪意のある JavaScript ルーチンを作成し、それらをどこかにアップロードして、HTML コードにインポートすることが可能になり。

にリクエストが作成されこれにより、 https://n.0x7359.com/xss.js 、次のコードが実行されます。

これを縮小して JavaScript に追加すると、次のようになります。

最終的な結果は次のとおりです。

攻撃者はこのリンクをソーシャルエンジニアリング攻撃に使用し、ターゲットのブラウザ上で実行される JavaScript コードを完全に制御し、リアルタイムでコードを変更できるようになります。

ほなほな。