Hello there, ('ω')ノ
初めてのDirsearchを使ったSSRF事件を。
脆弱性：
SSRF
記事：
https://goziem.medium.com/my-first-case-of-ssrf-using-dirsearch-b916f0f1e94b
今回は、Dirsearchを使って初めてSSRF脆弱性を見つけた体験と
それを発見するために取った手順を説明を。
サーバーサイドリクエストフォージェリ（SSRF）は、攻撃者がサーバから
第三者のドメインにHTTP/HTTPSリクエストを送信できる
Webアプリケーションの脆弱性であり、機密データの開示や
遠隔コード実行につながる可能性があり。
Subfinderを使って、対象のすべてのサブドメインを取得し始めて。
subfinder -d target.com | tee target.txt
GithubでDirsearchの使用方法を調べているときに、
Dirsearchで以前使用したことのないオプション、
つまり、deep-recursiveを見つけ。
そのオプションを使用することに決めて。
python3 dirsearch.py -l target.txt --deep-recursive
300を超えるサブドメインをファズする必要があったため、
時間がかかりましたが、次のようなディレクトリを見つけて。
targetconnect-dev.target.com/proxy.stream
しかし、deep-recursiveオプションを使用したため、Dirsearchは
proxy.streamパラメータで別のファズを実行し。
その結果、次のパラメータが見つかり、完全なURLは次のようになり。
targetconnect-dev.target.com/proxy.stream?origin=https://google.com
URLにアクセスして、google.comをレンダリングし。
それで、ホワイトリストが関係していないことを確認するために、
他のURLをレンダリングすると、レンダリングされ。
そこで、BurpSuite CollaboratorのようなOut Of Band Interaction Tester（OOB）を
使用しようとしましたが、持っていなかったので、代替案を使用すると
pingbackを受け取って。
次にGoogleでパラメータを検索し、誰かがAWS Metadata URLを
使用しようとしたツイートを見つけたので、それを試してみると
驚くべきことに、それは機能してAWS Metadataの資格情報を
表示することができて。
すぐに nuclei テンプレートを作成し、同じバグタイプの
他のサブドメインをテストし。
そして、proxy.stream?originパラメータを介してSSRFに対して
脆弱な別のサブドメインを見つけて。
Best regards, (^^ゞ
