Hello there, ('ω')ノ
SSRF から .GOV ドメインの RCE への物語を。
脆弱性：
SSRF
RCE
記事：
https://medium.com/@tobydavenn/the-tale-of-ssrf-to-rce-on-gov-domain-191185b32b37
SSRF はサーバ側のリクエスト フォージェリで。
これは、影響がある場合、高／重大な脆弱性で。
SSRF では、サーバがリクエストを行っている場合、攻撃者が内部ページを。
リクエストしてアクセスする可能性があり。
多くの場合、SSRF は順風満帆ではなく、IP アドレスのブラックリスト、ページの 。
URL エンコーディング、DNS の改ざんなど、さまざまなバイパスを。
利用する必要がありますが、この脆弱性の場合は非常に簡単で。
この脆弱性をどのように見つけたか。
Waybackurls
GAU
waybackurls >> GAU >> combined.txt
gospider | tee gospider.txt
gospider.txt >> combined.txt
https://www.kali.org/tools/getallurls/
https://github.com/jaeles-project/gospider
ファイルを手動で調べて、興味深いエンドポイントを探し。
「/proxy」というエンドポイントに出会い。
これは、読み込まれたときに空白のページで。
ソースを調べると、リクエストに追加できる var パラメータが明らかになり。
このパラメータは、URL のリクエストに使用されて。
このパラメータをエンドポイントに追加し、Burp コラボレータのリンクを。
リクエストすると、サーバの IP から HTTP リクエストを受け取ることができて。
Burp コラボレータのリンクを削除して「https://127.0.0.1」を追加し・
リクエストを送信しても応答がなかったのは興味深いことで。
IP を変更して https://127.1 を送信すると、画面にレンダリングされた内部ページで。
200 OK が受信され、リダイレクト URL が表示され。
あまり興味深いものはありませんが。
すべての URL で制限されたフィルタリングが表示されて。
ここから AWS 内部 IP 169.254.169.254/metadata を試してみたところ。
十分なメタデータが表示され。
これで、会社の AWS に完全にアクセスできるようになり。
周りを見渡してキーやその他の情報を収集できるようになって。
リクエストを受け取り、ファイル パスを試して。
ここから、内部 IP 範囲を理解するためにホスト ファイルを要求できて。
メモを取り、リクエストをBurpリピータに送信し。
内部アドレス空間をスキャンして。
ポート 8080 または URL /admin で興味深いページを探して。
PortSwiggerラボから、ユーザエージェントを介して悪用される可能性のある。
RCE の脆弱性である shellshock について学び。
Google で検索すると、ペイロードが表示され。
このペイロードをイントルーダの要求に追加し、内部範囲全体を再スキャンして。
案の定、内部ホストが脆弱であることを確認する ping が返ってきて。
外部から内部への完全な内部アクセスとリモート コード実行が可能になって。
ポイント：
情報収集と偵察がカギ
隠しパラメータのソース コードを常にチェック
Best regards, (^^ゞ
