WordPressプラグイン「WPLP Cookie Consent」に任意ファイルアップロードの脆弱性

公開フォルダーへの任意のファイル設置

サーバー上の公開フォルダー（画像などが保存される wp-content/uploads 配下）に、種類を問わずファイルが保存されるおそれがあります。保存されたファイルは、インターネットからそのまま参照できる場所に置かれます。

保存するファイルの種類を制限する仕組みが無いため、サーバー側でプログラムの実行が許可されている構成では、設置されたファイルを通じてサーバー上でプログラムが実行される状態に至る可能性があります。

プラグインの連携情報の書き換え

攻撃を受けた場合、プラグインが保持しているクラウドサービスとの連携情報が上書きされます。その結果、連携状態の表示が実際と異なるものに変わったり、連携が切れたりする可能性があります。

被害発生の条件

本脆弱性の悪用が成立するには、以下の条件が重なる必要があります。

• 該当バージョン（4.4.1 以下）のプラグインが有効化されていること
• サイトから外部への通信が可能な環境であること（認証情報の検証を、サイト側から外部のクラウドサービスへ問い合わせる方式のため）
• サイト管理者のログイン名またはメールアドレスが攻撃者に知られていること。
  これらはサイトの公開情報から取得できる場合があるため、実質的な障壁にはなりにくい条件です

原因1：認証・認可の処理が、本人確認として機能していなかった

連携用のAPIでは、リクエストに含まれる利用者名をもとに、その名前の利用者がサイトの管理者権限を持つかどうかを検証していました。しかし、検証していたのはその一点のみで、リクエストの送信者がその利用者本人であるかは検証されていませんでした。利用者名はリクエストに任意の値を指定できるため、管理者の名前を指定するだけで検証を通過できる状態でした。

あわせて行われるアクセストークン（利用者を識別するための認証情報）の検証も、提供元のクラウドサービスへ問い合わせる方式で、そのトークンが当該サイトの利用者のものであるかまでは検証していませんでした。

原因2：連携用の認証キーが、外部から書き換え可能だった

一部のAPIは、より強い検証として、サイト側に保存されている連携用の認証キーとの一致を求める作りになっていました。ところが、原因1のAPIを通じてこの認証キー自体を書き換えられるため、攻撃者は自ら設定した値を用いて、後続の検証を通過できてしまいます。

送信元を確かめるための検査も、リクエストに含まれる値どうしを比較しているだけで、実際の送信元を確認するものではありませんでした。

原因3：アップロードされたファイルの種類を検証していなかった

ロゴ画像の登録処理では、受け取ったデータをそのまま公開フォルダーへ書き出していました。ファイル名から不正な文字を取り除く処理は行われていましたが、これはファイル名を整形するための処理であり、拡張子を制限するものではありません。また、受け取ったデータが実際に画像であるかの検証も行われていませんでした。

対策版での修正

• ロゴ画像を登録するAPIそのものを廃止
• 残る画像登録処理に、拡張子の許可一覧（JPEG・PNG・GIF・WebP）による制限、データが拡張子どおりの画像であることの検証、サイズ上限を追加
• 連携用のAPIに、サイトごとに生成される秘密鍵を用いた署名検証と、有効期限によるリクエストの使い回し防止を追加
• アクセストークンが当該サイトの利用者のものであるかの検証を追加