WordPressの脆弱性「wp2shell」の影響を受ける6.9.0〜6.9.4、7.0.0〜7.0.1は、修正版への更新が必要です。7.0系は7.0.2、6.9系は6.9.5へ更新してください。
「wp2shell」と呼ばれる今回の脆弱性は、ログインしていない第三者がWordPressのREST APIを経由し、最終的にサーバー上で任意のコードを実行される可能性がある問題です。WordPress本体の標準機能が対象であり、特定のプラグインを使っていないサイトも無関係ではありません。
更新できない場合は、WAFによる対象APIの遮断などで一時的に防御します。ただし、これらは更新までの暫定対策です。WAFやBasic認証が有効でも、修正版への更新が不要になるわけではありません。
最初にWordPressのバージョンを確認する
WordPress管理画面の「ダッシュボード」または「更新」画面で、現在のバージョンを確認します。
今回公表された2件の脆弱性と修正版の関係をまとめます。
| 使用中のバージョン | 今回公表された脆弱性の影響 | 対応 |
|---|---|---|
| 7.0.0〜7.0.1 | 2件とも対象 | 7.0.2へ更新 |
| 6.9.0〜6.9.4 | 2件とも対象 | 6.9.5へ更新 |
| 6.8.0〜6.8.5 | SQLインジェクションのみ対象 | 6.8.6へ更新 |
| 6.8より前 | 今回公表された2件は対象外 | 別の脆弱性と保守状況を確認 |
WordPress 6.8系は、wp2shellの任意コード実行につながる攻撃チェーンの対象ではありません。ただし、同時に公表された別のSQLインジェクション脆弱性があるため、6.8.6への更新が必要です。
6.8より前のバージョンは、今回公表された2件の対象外です。しかし、古いWordPressには別の脆弱性や、保守が止まったテーマ・プラグインが残っている可能性があります。「wp2shellの対象外」と「安全」は同じ意味ではありません。
wp2shellはREST APIを入口とする攻撃
wp2shellは、WordPress REST APIのバッチ処理にある問題と、SQLインジェクションの脆弱性を組み合わせた攻撃です。
REST APIは、WordPressの投稿や設定などのデータをHTTP経由で取得・更新する仕組みです。外部サービスとの連携だけでなく、WordPressのブロックエディターなどでも利用されています。
攻撃の流れを簡略化すると、次のようになります。
未認証のHTTPリクエスト
→ WordPress REST APIのバッチ処理
→ 本来とは異なる処理への到達
→ SQLインジェクション
→ 任意コード実行につながる可能性入口として使われるのは、次のバッチAPIです。
/wp-json/batch/v1
?rest_route=/batch/v1攻撃者はWordPressのログイン情報を必要としません。影響を受けるバージョンでは、標準構成のWordPressに匿名のリクエストを送ることで攻撃が始まります。
恒久対策は修正版への更新
該当するWordPressは、修正版へ更新するのが基本です。
更新前には、WordPressファイルとデータベースの両方をバックアップします。バックアップは、復旧時に確実にアクセスできる場所へ保存してください。
現在のバージョンからメジャーバージョンをまたぐ場合は、本番サイトを直接更新せず、検証環境で先に確認します。WordPress本体だけでなく、次の項目も確認が必要です。
- 使用中のPHPとデータベースのバージョン
- テーマとプラグインの対応状況
- お問い合わせフォームの送信
- 投稿の作成・編集・保存
- ブロックエディターの動作
- 画像のアップロード
- 外部サービスとの連携
自動更新が設定されていても、実際のバージョンは管理画面で確認してください。サーバー環境や個別設定により、自動更新が実行されていない場合があります。
すぐに更新できない場合の暫定対策
発見元のSearchlight Cyberは、更新できない場合の緊急措置として、未認証ユーザーからのREST APIアクセスを遮断する方法を示しています。
具体的には、次のどちらかです。
- 未認証ユーザーからREST API全体へのアクセスを遮断する
- WAFで
/wp-json/batch/v1と?rest_route=/batch/v1を遮断する
どちらも正規機能へ影響する可能性があります。設定後は、投稿の編集・保存、フォーム、外部連携などの動作確認が必要です。
WAF
WAFで対象のバッチAPIを遮断すれば、攻撃リクエストがWordPressへ到達する前に止められます。SQLインジェクションを検知するルールも防御に役立ちます。
ただし、「WAFが有効」という表示だけでは判断できません。次の条件によっては、攻撃を通す可能性があります。
- 検知のみで、遮断モードになっていない
- 対象APIのルールが適用されていない
- JSONのリクエスト本文を検査していない
- WordPressやREST APIが検査対象から除外されている
- CDNやWAFを通さず、サーバーへ直接アクセスできる
WAFは更新までの防御を補う仕組みです。修正版への更新の代わりにはなりません。
Basic認証
ApacheやNginxなどのWebサーバー側でサイト全体にBasic認証を設定している場合、認証情報を持たないリクエストはWordPressより前で拒否されます。一般公開が不要な検証サイトや閉鎖中のサイトでは有効です。
WordPressプラグインで認証する方式は、認証処理より先にWordPressが動きます。wp2shellへの緊急対策として使う場合は、Webサーバーやホスティングサービスの管理画面で設定するBasic認証を選びます。
また、認証が一部のURLにしか適用されていないと、REST APIだけが外部から利用できる場合があります。HTTPとHTTPS、wwwの有無、サブドメイン、サーバーへの直接アクセスを含め、すべての経路で認証されることを確認してください。
REST APIの遮断
未認証ユーザーからのREST APIアクセスだけを拒否する設定であれば、ログイン中のブロックエディターは通常どおり動作します。管理画面からの通信には、ログイン情報と認証用の値が付くためです。
Webサーバー側でREST API全体を遮断すると、ログイン中の通信も拒否されます。この場合、投稿の取得や保存など、ブロックエディターの主要機能が動かなくなります。
テーマの functions.php でREST APIを止める方法もありますが、テーマの変更や読み込み状態に左右されます。緊急対策では、WAFやWebサーバーなど、WordPressより前の段階で遮断する方が管理しやすくなります。
使用していないWordPressはサイト全体を止める
公開する必要がないWordPressなら、REST APIだけを止めるより、サイト全体をアクセス遮断する方が確実です。
WordPressを残したままREST APIだけを遮断しても、ログイン画面、XML-RPC、テーマやプラグインのPHPファイルなどは公開されたままです。将来見つかる別の脆弱性も対象になります。
使用予定がない場合は、次の手順で整理します。
- WordPressファイルとデータベースをバックアップする
- バックアップを公開ディレクトリの外へ保存する
- Webサーバー側でサイト全体をアクセス遮断する
- 恒久的に不要なら、公開領域からWordPressを撤去する
- 不要なデータベースとデータベースユーザーも整理する
バックアップファイルを公開ディレクトリへ置いたままにすると、別の情報漏洩につながります。公開URLから取得できない場所へ保存してください。
更新しても侵害確認は別に必要
WordPressを修正版へ更新すれば、新たなwp2shell攻撃は防げます。しかし、更新前に侵害されていなかったことまでは証明できません。
影響を受けるバージョンを公開していた場合や、不審な挙動がある場合は、次の項目を確認します。
- 覚えのない管理者ユーザーが作成されていないか
- WordPress本体、テーマ、プラグインが改ざんされていないか
uploadsやキャッシュディレクトリなどに不審なPHPファイルがないか.htaccessや.user.iniに覚えのない設定がないか- アクセスログに対象のバッチAPIへの不審なリクエストがないか
- サーバー上の定期実行処理に不審な登録がないか
WP-CLIでコアとプラグインの改ざんを確認する
WordPressコアの改ざん確認には、WP-CLIのチェックサム検証も利用できます。
# WordPressコアを公式チェックサムと照合する
wp core verify-checksums --include-root
# WordPress.org配布プラグインを公式チェックサムと照合する
wp plugin verify-checksums --all --strictコアファイルやWordPress.orgで配布されているプラグインを公式チェックサムと照合し、変更・欠落したファイルを検出します。--include-rootを付けると、WordPress本体に含まれないルート直下のファイルについても警告を確認できます。
チェックサムが一致しても、侵害されていなかったことの証明にはなりません。次の対象は別途確認が必要です。
wp-config.php- 独自・有料テーマ
- 独自・有料プラグイン
uploadsなどに追加された不審なファイル.htaccessや.user.ini- データベース内の管理者ユーザーや改ざん
- サーバー上の定期実行処理
- アクセスログ
また、WordPress.orgで配布されていないプラグインは、公式チェックサムを取得できない場合があります。その場合は、配布元の正常なファイルや、侵害前のバックアップとの照合が必要です。
改ざんが確認された場合、見つかったファイルだけを削除して終わらせるのは危険です。公開を止め、証拠となるログとファイルを保全したうえで、正常なバックアップや公式配布ファイルとの照合を行います。管理者、サーバー、データベースなどの認証情報も変更します。
まとめ
- WordPress 6.9.0〜6.9.4、7.0.0〜7.0.1はwp2shellの対象
- 7.0系は7.0.2、6.9系は6.9.5へ更新する
- 6.8.0〜6.8.5は別のSQLインジェクション脆弱性があるため、6.8.6へ更新する
- 更新までの間は、WAFによるバッチAPIの遮断や未認証REST APIの遮断を検討する
- 一般公開が不要なサイトは、Basic認証またはサイト全体のアクセス遮断を行う
- 更新と侵害確認は別の作業として実施する
まず、管理しているすべてのWordPressについて、バージョンと公開状態を確認してください。使っていないWordPressがインターネット上に残っていないかも、同時に確認する機会です。
