WordPressの脆弱性を管理！コア、プラグイン、テーマの脆弱性を検知する方法

はじめに

FutureVulsでは、サーバにインストールされているWordPressのコア、プラグイン、テーマを自動的に取得し、脆弱性を検知できます。
WordPressのスキャンを実行するには、以下の2つのツールが必要です。

1. wpコマンド
   WordPressの管理ツールであり、WordPressのコア、プラグイン、テーマのバージョン情報を取得するために使用されます。
2. WPScanのAPI
   「WPScan」は、WordPress関連の脆弱性データベースを提供するツールで、2万件以上の脆弱性情報を保有しています。
   FutureVulsではWPScanの「API Token」を利用して、バージョンに脆弱性があるかを判定します。
   API Tokenの取得には、WPScan公式サイトの登録が必要です。無料プランでは1日あたりのリクエスト数に制限があるため、法人利用や大規模スキャンを行う場合は、有料プランの契約が推奨されます。

詳細な設定方法については、マニュアルの「WordPressスキャン」に記載していますが、wpコマンドのインストール方法やスキャナの設定手順を、一連の流れとしてまとめたガイドがあると、より分かりやすいのではないでしょうか。
そこで本記事では、WordPressの脆弱性を検知するまでの具体的な設定手順を解説します。

ハンズオン: WordPressスキャンの設定方法

前提

本記事の内容は、以下の環境で実行しました。

# EC2 の AMI名
RHEL-9.4.0_HVM-20240605-x86_64-82-Hourly2-GP3

# WordPressのバージョン
6.5

予め、EC2にWordPressがインストールされていることとします。
EC2の環境構築については「こちら」をご参照ください。

1. スキャナのインストール

グループ設定 > スキャナから、Vulsスキャナのインストールコマンドを取得し、管理者権限で実行します。

詳細はマニュアルの「Linuxへのインストール」をご参照ください。

2. API Tokenの発行と登録

「wpscan.com」よりアカウントを登録して、「API Token」を取得します。
無料プランでは、1日に最大25回のAPIリクエストが許可されています。API上限を超える場合は、有料プラン契約が別途必要です。
FutureVulsでは wpscan.com の代理契約は行いません。お客様にて直接ご契約をお願いします。

次に、FutureVuls画面でグループ設定 > 外部連携 > WordPress Vulnerability Database APIを開きます。

追加を押し、先ほど取得したAPI Token を登録します。
「無効化プラグインも対象」をチェックすると、WordPress 側で無効化されたプラグインやテーマも検知対象に含めることができます。
今回は、チェックを入れずに登録します。

登録が完了しました。

3. wpコマンドのインストール

Vulsスキャナでは、WordPressのソフトウェア情報を取得するためにwpコマンドを利用しています。そのため、事前にwpコマンドをインストールしておく必要があります。
インストール方法の詳細は「こちら」をご参照ください。

以下のコマンドを順に実行します。

# wp-cli.phar をダウンロード
$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
# Phar ファイルの動作確認
$ php wp-cli.phar --info
# 実行権限を付与
$ chmod +x wp-cli.phar
# 環境変数 PATH に登録された場所へ移動
$ sudo mv wp-cli.phar /usr/local/bin/wp

インストールが完了したら、以下のコマンドでバージョンを確認できます。

$ wp --version
WP-CLI 2.11.0

4. スキャナの設定

Vulsスキャナの設定ファイル/opt/vuls-saas/config.toml を編集し、WordPressのみスキャン対象となるように設定します。
詳細はマニュアルの「WordPress のみをスキャンする場合」をご参照ください。

筆者の環境では、以下のように設定しました。

[servers]
  [servers.wpscan]
    user = "vuls-saas"
    host = "localhost"
    port = "local"
    scanModules = ["wordpress"]

  [servers.wpscan.wordpress]
    cmdPath = "/usr/local/bin/wp"
    osUser = "ssm-user"
    docRoot = "/var/www/html"

この設定により、WordPressのソフトウェア情報のみを取得するようになります。

次に、スキャンを実行する際にwpコマンドをパスワードなしで実行できるように/etc/sudoers.d/vuls-saasを編集します。
Vulsスキャナは、wpコマンドを使用してWordPressのソフトウェア情報を取得しますが、デフォルト状態では以下のようにパスワード入力が求められるため、スキャンを実行できません。

# vuls-saasユーザでスキャン実行
$ sudo -H -u vuls-saas /opt/vuls-saas/vuls-saas.sh >/dev/null 2>&1

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for vuls-saas:

これは、Vulsスキャナが sudoコマンドを実行しているために発生します。スクリプトがユーザの介入なしに動作できるようにするために、パスワードの入力を不要にする設定が必要です。
詳細な手順については、マニュアルの「スキャン対象サーバの sudoers への設定追記」をご参照ください。

筆者の環境では、vuls-saasユーザでwpコマンドが実行できるように、以下の順に沿って設定しました。

1. sudoers 設定を確認

現在の/etc/sudoers.d/vuls-saasを確認します。
特に設定していない限り、以下のようなデフォルト設定になっています。

# 差分を示すためcatの結果を改行
$ cat /etc/sudoers.d/vuls-saas | tr " " "\n"
vuls-saas
ALL=(ALL)
NOPASSWD:SETENV:
/usr/bin/stat,
/usr/bin/needs-restarting,
/usr/bin/which,
/usr/bin/repoquery,
/usr/bin/yum
makecache
--assumeyes,
/bin/ls
-l
/proc/*/exe,
/bin/cat,
/usr/bin/lsof
-i
-P
-n,
/usr/sbin/lsof
-i
-P
-n,
/opt/ds_agent/dsa_query,
/usr/bin/test,
/usr/bin/find,
/usr/bin/cat
Defaults:vuls-saas
!requiretty

この状態では wpコマンドが含まれていないため、スキャン実行時にパスワードが求められます。

2. sudoers にwpコマンドの権限を追加

visudoコマンドを使用して sudoers の設定を編集します。

# sudoersを編集
$ visudo /etc/sudoers.d/vuls-saas

以下の内容を追記します。

/bin/bash -c /usr/local/bin/wp cli *, /bin/bash -c /usr/local/bin/wp core *, /bin/bash -c /usr/local/bin/wp theme *, /bin/bash -c /usr/local/bin/wp plugin *

3. 設定変更後の sudoers を確認

変更後の/etc/sudoers.d/vuls-saasは以下のようになります。

$ cat /etc/sudoers.d/vuls-saas | tr " " "\n"
vuls-saas
ALL=(ALL)
NOPASSWD:SETENV:
/usr/bin/stat,
/usr/bin/needs-restarting,
/usr/bin/which,
/usr/bin/repoquery,
/usr/bin/yum
makecache
--assumeyes,
/bin/ls
-l
/proc/*/exe,
/bin/cat,
/usr/bin/lsof
-i
-P
-n,
/usr/sbin/lsof
-i
-P
-n,
/opt/ds_agent/dsa_query,
/usr/bin/test,
/usr/bin/find,
/usr/bin/cat
/bin/bash
-c
/usr/local/bin/wp
cli
*,
/bin/bash
-c
/usr/local/bin/wp
core
*,
/bin/bash
-c
/usr/local/bin/wp
theme
*,
/bin/bash
-c
/usr/local/bin/wp
plugin
*
Defaults:vuls-saas
!requiretty

この設定により、vuls-saasユーザはwpコマンドをパスワードなしで実行できるようになり、スキャンが可能になります。

5. スキャン実行

スキャナのインストール完了後、5分後に自動スキャンが実行されますが、手動でも実行可能です。

# vuls-saasユーザでスキャン実行
$ sudo -H -u vuls-saas /opt/vuls-saas/vuls-saas.sh >/dev/null 2>&1

1. スキャン結果の確認

スキャン結果は以下のログファイルを確認することで、スキャンの成否やエラーの詳細を把握できます。

• /opt/vuls-saas/vuls-saas.log
  scan.logとreport.logの概要
• /opt/vuls-saas/scan.log
  スキャンの成否
• /opt/vuls-saas/report.log
  レポートの詳細、FutureVulsへのアップロードエラー等

筆者の環境では、スキャンとアップロードが成功しました。

$ cat /opt/vuls-saas/vuls-saas.log
[2025/02/17 06:01:01] "INFO": Start to scan.
[2025/02/17 06:01:02] "SUCCESS": Refresh scanner. [/opt/vuls-saas/vuls   type: linux_x86_64]
[2025/02/17 06:01:07] "SUCCESS": Complete vuls scan.
[2025/02/17 06:01:08] "SUCCESS": Complete vuls upload.

スキャンが成功すると、config.tomlが更新され、FutureVuls画面にスキャン結果が「サーバ」に登録されます。

2. FutureVulsでのサーバ確認

FutureVuls画面のサーバ > サーバ詳細タブから、サーバが登録されているかを確認します。

サーバが登録されていることを確認できました。
次に、このサーバがスキャン対象のEC2と一致しているか、双方のUUIDを照合します。UUIDはFutureVulsでサーバを識別するためのIDです。

サーバ詳細タブのサーバ情報からUUIDを確認します。

FutureVuls画面で表示されているサーバのUUIDは31b9c9b3-68e8-79cf-632e-55615a150912でした。

次に更新されたconfig.tomlを確認し、UUIDが一致しているかを確認します。

$ cat /opt/vuls-saas/config.toml
# See README for details: https://vuls.io/docs/en/config.toml.html

version = "v2"

[saas]
  GroupID = XXXX
  Token = "XXXXXXX"
  URL = "https://auth.vuls.biz/one-time-auth"

[default]

[servers]

  [servers.wpscan]
    user = "vuls-saas"
    host = "localhost"
    port = "local"
    scanModules = ["wordpress"]
    [servers.wpscan.uuids]
      wpscan = "31b9c9b3-68e8-79cf-632e-55615a150912"
    [servers.wpscan.windows]
      serverSelection = 0

  [servers.wpscan.wordpress]
    cmdPath = "/usr/local/bin/wp"
    osUser = "ssm-user"
    docRoot = "/var/www/html"

UUIDが一致しているため、FutureVulsに登録されたサーバが、スキャン対象のEC2であることを確認できました。

3. WordPressのソフトウェア情報の確認

スキャンを通して、WordPressのコア、プラグイン、テーマが登録されているかを確認するため、ソフトウェアタブを開きます。

正しく登録されていることを確認できました。
これらが、EC2上のWordPressのソフトウェア情報と一致しているかをwpコマンドを用いて確認します。

# コアのバージョン確認
$ wp core version --path=/var/www/html
6.5

# プラグイン一覧
$ wp plugin list --path=/var/www/html
+---------+----------+-----------+---------+----------------+-------------+
| name    | status   | update    | version | update_version | auto_update |
+---------+----------+-----------+---------+----------------+-------------+
| akismet | active   | available | 5.3.6   | 5.3.7          | off         |
| hello   | inactive | none      | 1.7.2   |                | off         |
+---------+----------+-----------+---------+----------------+-------------+

# テーマ一覧
$ wp theme list --path=/var/www/html
+-------------------+----------+-----------+---------+----------------+-------------+
| name              | status   | update    | version | update_version | auto_update |
+-------------------+----------+-----------+---------+----------------+-------------+
| twentytwentyfive  | active   | available | 1.0     | 1.1            | off         |
| twentytwentyfour  | inactive | none      | 1.3     |                | off         |
| twentytwentythree | inactive | none      | 1.6     |                | off         |
+-------------------+----------+-----------+---------+----------------+-------------+

各ソフトウェアのバージョン情報が一致していることを確認できました。

4. 検知された脆弱性の確認

脆弱性×タスクタブを開くと、検知された脆弱性が表示されます。

スキャン結果では、以下の4件の脆弱性が検知されました。

• WP < 6.5.2 - Unauthenticated Stored XSS
• WordPress < 6.5.5 - Contributor+ Stored XSS in HTML API
• WordPress < 6.5.5 - Contributor+ Stored XSS in Template-Part Block
• WordPress < 6.5.5 - Contributor+ Path Traversal in Template-Part Block

さらに、ソフトウェアタブを開き、これらの脆弱性がどのソフトウェアに関連しているかを確認します。

WordPressのコアに関する脆弱性が検知されていました。
この結果が、正しいかどうかを検証するため、WPScanのAPIを用いて以下のコマンドを実行し、WordPressのコアバージョン6.5の脆弱性情報を取得します。

$ curl -X GET "https://wpscan.com/api/v3/wordpresses/65" -H "Authorization: Token token=XXXXXXXXXX" | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1971    0  1971    0     0   1405      0 --:--:--  0:00:01 --:--:--  1404
{
  "6.5": {
    "release_date": "2024-04-02",
    "changelog_url": "https://wordpress.org/documentation/wordpress-version/version-6-5/#changelog",
    "status": "insecure",
    "vulnerabilities": [
      {
        "id": "1a5c5df1-57ee-4190-a336-b0266962078f",
        "title": "WP < 6.5.2 - Unauthenticated Stored XSS",
        "created_at": "2024-04-10T13:11:17.000Z",
        "updated_at": "2024-04-11T05:48:47.000Z",
        "published_date": "2024-04-09T00:00:00.000Z",
        "vuln_type": "XSS",
        "references": {
          "url": [
            "https://wordpress.org/news/2024/04/wordpress-6-5-2-maintenance-and-security-release/"
          ]
        },
        "verified": true,
        "poc": null,
        "description": null,
        "cvss": null,
        "fixed_in": "6.5.2",
        "introduced_in": null
      },
      {
        "id": "2c63f136-4c1f-4093-9a8c-5e51f19eae28",
        "title": "WordPress < 6.5.5 - Contributor+ Stored XSS in HTML API",
        "created_at": "2024-06-25T07:32:39.000Z",
        "updated_at": "2024-06-25T07:32:39.000Z",
        "published_date": "2024-06-24T00:00:00.000Z",
        "vuln_type": "XSS",
        "references": {
          "url": [
            "https://wordpress.org/news/2024/06/wordpress-6-5-5/"
          ]
        },
        "verified": true,
        "poc": null,
        "description": null,
        "cvss": null,
        "fixed_in": "6.5.5",
        "introduced_in": null
      },
      {
        "id": "7c448f6d-4531-4757-bff0-be9e3220bbbb",
        "title": "WordPress < 6.5.5 - Contributor+ Stored XSS in Template-Part Block",
        "created_at": "2024-06-25T07:32:43.000Z",
        "updated_at": "2024-06-25T07:32:43.000Z",
        "published_date": "2024-06-24T00:00:00.000Z",
        "vuln_type": "XSS",
        "references": {
          "url": [
            "https://wordpress.org/news/2024/06/wordpress-6-5-5/"
          ]
        },
        "verified": true,
        "poc": null,
        "description": null,
        "cvss": null,
        "fixed_in": "6.5.5",
        "introduced_in": null
      },
      {
        "id": "36232787-754a-4234-83d6-6ded5e80251c",
        "title": "WordPress < 6.5.5 - Contributor+ Path Traversal in Template-Part Block",
        "created_at": "2024-06-25T07:32:48.000Z",
        "updated_at": "2024-06-25T07:32:48.000Z",
        "published_date": "2024-06-24T00:00:00.000Z",
        "vuln_type": "TRAVERSAL",
        "references": {
          "url": [
            "https://wordpress.org/news/2024/06/wordpress-6-5-5/"
          ]
        },
        "verified": true,
        "poc": null,
        "description": null,
        "cvss": null,
        "fixed_in": "6.5.5",
        "introduced_in": null
      }
    ]
  }
}

Futurevulsに表示された脆弱性4件が、WPScanのデータベースにある脆弱性情報と一致していました。

このように、FutureVulsでは、WordPressのコア、プラグイン、テーマの脆弱性をWPScanのデータベースと連携して直接取得し、検知・管理できます。

6. CPE登録

Vulsスキャナは、OSやミドルウェアのパッケージ、アプリケーションの依存ライブラリの脆弱性が検知対象のため、以下のようなソフトウェアは検知対象外です。

• Oracle Database, Oracle WebLogicなどの商用ミドルウェア
• ベンダの公式サイトからダウンロードしたソフトウェア

これらを脆弱性管理の対象とするには、CPE形式で登録する必要があります。
詳細は、マニュアルの「CPEスキャン」をご参照ください。

今回のwpコマンドは、パッケージ管理ツール（yum, dnf, apt）を用いず、ベンダの公式サイトからダウンロードしたため、Vulsスキャナでは検知対象外となり、CPE登録が必要になります。

FutureVulsでCPE追加の方法はいくつかありますが、ここでは「CPE入力機能」を使用して、バージョン2.3形式で追加します。

wpコマンドは「NVD」にて、以下フォーマットのCPE名が指定されております。

cpe:2.3:a:wp-cli:wp-cli:*:*:*:*:*:*:*:*

こちらをCPEスキャン対象として登録することにより、wpコマンドの脆弱性管理が可能となります。

# バージョン確認
$ wp --version
WP-CLI 2.11.0

確認したバージョンをCPE形式(バージョン2.3)に変換します。

# バージョン2.3形式(Formatted String形式)に変換
cpe:2.3:a:wp-cli:wp-cli:2.11.0:*:*:*:*:*:*:*

FutureVuls画面のサーバ > ソフトウェア > CPE追加から、CPEを登録します。

ダイアログの「和製ソフトウェアの脆弱性をJVNで検知する」は選択せずに送信をクリックします。
その後、CPEが追加されていることを確認します。

CPEの追加が完了しました。

次に、サーバ詳細タブから「手動スキャン」を実行し、脆弱性が検知されるかを確認します。
また「スキャン履歴」をクリックすると、スキャン結果を確認することができます。

wpコマンドに関する脆弱性は検知されませんでした。
FutureVulsのCPEスキャンは、「NVD」と「JVN」の情報を基に、脆弱性を検知します。

脆弱性が検知されなかった結果が正しいかどうかを検証するために、NVDでCPEを検索してみます。
NVDでのCPE検索は「こちら」から行えます。


検索結果から、WP-CLI 2.11.0に関する脆弱性は見つかりませんでした。
このように、該当のCPE名で検索することで、CPEスキャン結果の妥当性を確認することができます。

おわりに

本記事では、WordPressの脆弱性スキャン手順を紹介しました。最後に、WordPressの脆弱性管理を行う際に、FutureVulsを活用する場合とそうでない場合の違いを以下にまとめます。

• FutureVulsを使用しない場合

  • 手動でスキャンが必要
    WPScanをローカル環境や別途用意したスキャナサーバで実行するために、設定やスキャンの実施を手動で行う必要がある。
  • 脆弱性情報を手動で収集
    公式サイトを定期的に確認し、最新の脆弱性情報を手動で取得する必要がある。
  • 運用負荷の増加
    手動で脆弱性を管理するため、セキュリティ管理の負担が増加する。

• FutureVulsを使用する場合

  • 自動でスキャンが可能
    一度設定すると、定期的にVulsスキャナがサーバ上にインストールされているWordPressコア、プラグイン、テーマの一覧を自動取得し、脆弱性を検知ができる。
  • 脆弱性情報を自動で収集
    WPScanのAPIをFutureVulsに登録することで、最新の脆弱性情報を自動で取得できる。
  • 運用負荷の軽減
    脆弱性の検知と管理が自動され、セキュリティ管理の負担が軽減する。

このように、FutureVulsを導入することで、WordPressのセキュリティ管理をより効率的に行うことが可能になります。
本記事が、WordPressの脆弱性管理のお役に立てれば幸いです。

FutureVulsの詳細な説明やデモのご要望は「こちら」からお気軽にお問い合わせください。