WordPressプラグイン「LiteSpeed Cache」にサーバーサイドリクエストフォージェリ（SSRF）の脆弱性

サーバーからの意図しない通信

サイトのサーバーが、攻撃者の指定した宛先へ通信します。宛先には、インターネットから直接アクセスできないサーバー内部の窓口や、同じネットワーク内にある機器も指定できます。

これらの宛先は、外部からのアクセスを前提としていない場合があります。サイトのサーバーを経由して到達できること自体が、本来想定されていない状態です。

サイト内の画像ファイルの差し替え

通信で取得した内容は、最適化済みの画像としてサイト内に保存されます。このとき、取得した内容が実際に画像であるかどうかの確認は行われていませんでした。

そのため、最適化の対象となっていた画像が、攻撃者の用意した内容に置き換わる可能性があります。

確認されている影響の範囲

通信の応答内容が、そのまま攻撃者へ返される仕組みにはなっていません。また、本脆弱性の処理によって、WordPressのデータベースの内容が読み取られたり、管理者の権限が奪われたりすることはありません。

前提：画像最適化の流れ

LiteSpeed Cache の画像最適化は、サイト内の画像を外部のサービスへ送り、軽量化された画像を受け取って差し替える機能です。処理は次の3段階に分かれています。

• サイトが、最適化したい画像をサービスへ送る
• サービスが、最適化の完了をサイトへ通知する（このとき、最適化済み画像の置き場所が伝えられます）
• サイトが、通知された置き場所へ接続し、画像を取得して保存する

今回の問題は、2段階目の受付と、3段階目の取得の両方に関わっています。なお、通知を受け取った時点では置き場所が記録されるだけで、実際の通信は3段階目の取り込み処理が動いたときに発生します。

原因1：通知の受付が、送信元のIPアドレスの確認だけだった

通知を受け取る窓口は、送信元のIPアドレスがサービスのものかどうかだけで受付の可否を判断しており、通知の内容そのものが正規のサービスから送られたものかを確かめる仕組みは用意されていませんでした。

IPアドレスが一致することは、送信元が正規のサービスであることまでを保証するものではありません。

原因2：通知された置き場所の確認が、文字列の末尾の一致だけだった

通知には、最適化済み画像の置き場所がインターネット上のアドレスとして含まれます。プラグインは、このアドレスがサービスのものかを、アドレスの文字列が特定の文字列で終わっているかどうかで判定していました。

アドレスのうち「どこへ接続するか」を表す部分を取り出して確認する処理は行われていなかったため、実際の接続先がまったく別の宛先であっても、文字列の末尾を整えるだけで判定を通過する状態でした。

原因3：取得処理が、内部の宛先を遮断する仕組みを通っていなかった

WordPressには、外部へ通信する際に、サーバー内部や同じネットワーク内の宛先への接続を遮断する機能が用意されています。

プラグインの取り込み処理には、この機能を使う手順と使わない手順の2つが用意されており、通常の環境では使わないほうの手順が動作していました。あわせて、接続先が本物であることを証明書で確認する処理も無効にされていました。

原因4：取得した内容の確認が、通知に含まれる照合値との一致だけだった

取り込み処理は、取得した内容が通知どおりのものかを、通知に含まれる照合値（内容が少しでも違えば値も変わる、指紋のような短い文字列）と突き合わせて確認していました。

しかし、この照合値は置き場所と同じ通知に含まれているため、通知を送る側が両方をあわせて指定できます。取得した内容が画像であるかどうかの確認や、受け取る大きさの上限も設けられていませんでした。

対策版での修正

• 通知の受付を、送信元のIPアドレスの確認から電子署名による確認へ変更。照合に使う鍵はプラグイン内に組み込まれ、通知一件ごとに短い有効期限と使い捨ての識別子を設定
• 置き場所のアドレスは、接続先を表す部分を取り出したうえで判定するよう変更。暗号化された通信に限定し、別のアドレスへの転送（リダイレクト）にも追従しないよう修正
• 取り込み処理を、内部の宛先を遮断する仕組みを通る方式に統一。接続先の証明書の確認も有効化
• 取得した内容について、画像ファイルとしての形式の確認と、受け取る大きさの上限を追加。保存先も、サイトの画像を置く場所の範囲内に限定

なお、対策バージョンには、本脆弱性以外のセキュリティ修正も含まれています。