Hello there, ('ω')ノ
本当にクールなSSRFバグの話を。
脆弱性：
SSRF
記事：
https://infosecwriteups.com/story-of-a-really-cool-ssrf-bug-cf88a3800efc
今回は、ターゲット企業のAWSのメタデータにアクセスすることを可能にした。
SSRFの脆弱性に関するもので。
ターゲットのWebアプリは、多くの機能を備えた。
ソーシャルメディアプラットフォームのようなもので。
www.target.comと仮定することに。
発見：
ターゲットには多くの機能が含まれていたため、偵察を行うのではなく。
最初にメインのWebアプリをテストすることにして。
そこで、Burp Suiteを起動し、ターゲットをスコープに追加して。
Webアプリのスパイダーを開始して。
スパイダーが実行されている間、Webアプリのさまざまな機能をテストし始めまて。
XSS、IDOR、SQLi、レート制限攻撃、ビジネスロジックエラーなどの。
さまざまな脆弱性を見つけようとしましたが、うまくいかず。
そのターゲットをあきらめようとしていたところ。
Webアプリをスパイダーし始めたことを思い出したので。
Burp Suiteでターゲットタブに移動して。
多くのページがクロールされ、多くの新しいパラメータがあったので。
それから興味深いパラメータを探し始めて、５分後に次の要求を受け取って。
GET /proxy/proxy.php?url=some_URL
そのリクエストを見た後、すぐにBurpのコラボレータを起動し。
ペイロードを生成し、それをurl= parameterに入力してリクエストを送信して。
そして、DNSとHTTPの両方のリクエストを使用して。
Burpコラボレータでコールバックリクエストを受け取って。
次に、localhost（127.0.0.1）と/etc/passwdファイルにアクセスしようとしましたが。
今回は何も応答せず。
そこで、Burp Suiteのコラボレータから取得したIPをコピーし。
Whoisを使用してコマンドを掘り下げると。
そのIPがターゲット企業のAWSインスタンスに属していることを知って。
そこで今回は、Amazon EC2やその他の。
クラウドコンピューティングプラットフォームでメタデータを。
クラウドインスタンスに配信するために使用されているIP169.254.169.254に。
アクセスしようとしたので、私は次のリクエストをして。
GET /proxy/proxy.php?url=http://169.254.169.254/latest/meta-data
すると、次の応答を得て。
その後、AWSのSecretAccessKeyにアクセスして。
このSSRFの影響を示し、次のリクエストを行うと。
GET /proxy/proxy.php?url=http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/
応答でAWSのSecretAccessKeyを取得して。
下記が、SSRFからAWS-metadataへのアクセスで。
Best regards, (^^ゞ
