WordPressでリモートコード実行（RCE）攻撃を防ぐ方法：9つのヒント

サイト所有者が直面する多くの脅威の中で、WordPress におけるリモート コード実行 (RCE) 攻撃は最も危険なものとして際立っています。.

RCE 攻撃が成功すると、攻撃者はサーバー上で任意の悪意のあるコードを直接実行できるようになり、何かがおかしいことに気付いたときには、すでに被害が発生していることになります。.

このガイドでは、RCEとは何か、攻撃者がどのようにRCEを実行するのか、そして注意すべき兆候について説明します。また、 WordPressサイトを保護する。

TL;DR: WordPress でのリモートコード実行 (RCE) 攻撃を防ぐ

• 、攻撃者がサーバー上で直接悪意のあるコードを実行できるため、最も危険なWordPress の脆弱性

• ほとんどの RCE 攻撃は、古いプラグイン、脆弱なテーマ、またはセキュリティが不十分なファイルのアップロードを通じて発生します。.

• 攻撃者は RCE アクセスを使用して、マルウェアをインストールしたり、データを盗んだり、非表示の管理者アカウントを作成したり、サーバーを完全に制御したりすることができます。.

• 一般的な警告サインには、予期しない管理者ユーザー、疑わしい PHP ファイル、異常なサーバーアクティビティ、プラグインからのセキュリティ警告などがあります。.

• RCE を防ぐには、定期的な更新、安全なファイルアップロードの検証、サーバーの強化、不要なプラグインの制限などの階層化されたセキュリティが必要です。.

• Web アプリケーション ファイアウォール、二要素認証、継続的なマルウェア スキャンなどのツールにより、悪用されるリスクが大幅に軽減されます。.

• RCE攻撃の疑いがある場合は、直ちに行動を起こしてください。マルウェアのスキャン、認証情報のローテーション、ログの確認、そして必要に応じてクリーンなバックアップからの復元を実施してください。.

WordPress におけるリモートコード実行攻撃とは何ですか?

リモート コード実行は、攻撃者が物理的または直接的なアクセスを必要とせずに、Web サーバー上で任意のコードを実行できる脆弱性の一種です。.

これは、WordPress のインストール、プラグイン、またはテーマの脆弱性を悪用してリモートで実行されます。.

こう考えてみてください。サーバーはあなたの家です。通常、鍵を持っているのはあなただけです。RCE脆弱性は、攻撃者があなたより先に発見した隠された裏口のようなものです。攻撃者は侵入し、中を覗き込み、欲しいものを持ち去り、あなたに通知することなく立ち去ることができます。.

改ざん攻撃やブルートフォース攻撃とは異なり、RCE攻撃は多くの場合、完全に静かに行われます。攻撃者はサイトをクラッシュさせようとしているのではなく、あなたの環境への持続的で静かなアクセスを狙っています。

RCE 攻撃が成功すると、通常、攻撃者は次の操作を実行できます。

• 顧客記録、支払い情報、ログイン資格情報などの機密データを盗む

• マルウェアやランサムウェアをサーバーに直接インストールする

• 長期アクセスを維持するために不正な管理者アカウントを作成する

• サーバーを利用してスパムを送信したり、ボットネット活動に参加したりする

• サイトとデータベースを完全に消去または破損する

RCEは、状況に応じてコードインジェクション、リモートコマンド実行、または任意のコード実行と呼ばれることもあります。しかし、これらはすべて同じ根本的な脅威を表しています。.

ハッカーは実際にどうやって WordPress サイトに対して RCE 攻撃を実行するのでしょうか?

攻撃ベクトルを理解することは重要です。理解していないものを防御することはできないからです。.

攻撃者は、WordPressサイトでリモートコード実行を実現するために、よく知られた複数のエントリポイントを悪用します。最も一般的なエントリポイントを詳しく見ていきましょう。.

時代遅れのプラグインやテーマの悪用

これは、RCE攻撃の最も一般的な経路です。セキュリティ研究者が広く使用されているプラ​​グインに脆弱性を発見した場合、通常はまず開発者に非公開で報告します。.

しかし、パッチがリリースされ、脆弱性が公になると、攻撃者は直ちに何百万ものサイトをスキャンし、パッチ未適用バージョンをまだ実行しているインストールを探し始めます。.

実際の例: 2024 年 2 月、25,000 を超えるアクティブなインストールを持つ Bricks Builder テーマに、 CVE-2024-25600。

公開から24時間以内に、攻撃者はすでに脆弱なバージョンを実行しているサイトを積極的に悪用していました。.

2024 年に広く報道されたもう 1 つの例は、 Bit File Manager プラグイン、まれな脆弱性により、攻撃者が影響を受けるサイトに任意の PHP ファイルをアップロードして実行できる可能性があります。

パッチがリリースされてから実際に悪用が開始されるまでの期間は、数日ではなく数時間で測られることがよくあります。これは、脆弱性が公開されると攻撃者が迅速に行動することを意味します。.

重要なポイント:使用しているプラ​​グインまたはテーマのアクティブなインストール数が 10,000 を超えており、パッチが適用されていない重大な脆弱性が発表された場合は、サイトがすでにスキャンされ、標的にされていると想定してください。

制限のない、または検証が不十分なファイルのアップロード

WordPressは、添付ファイル付きのお問い合わせフォームから、メディアを多用したポートフォリオや会員制プラットフォームまで、ファイルアップロード機能を備えた無数のウェブサイトを支えています。ファイルアップロード処理のコーディングが適切でないと、RCEの直接的な侵入ポイントとなります。.

攻撃の仕組みは次のとおりです。攻撃者は、一見無害に見えるものの、実際にはPHPのWebシェルであるファイルをアップロードします。Webシェルとは、攻撃者がブラウザ経由でサーバーにコマンドを送信できるようにする小さなスクリプトで、実質的にはリモートターミナルから攻撃者の環境にアクセスできるようになります。.

攻撃者が弱いアップロード検証を回避するために使用する一般的な手法は次のとおりです。

• 基本的な拡張子チェックを欺くために、malware.png.php などの二重拡張子を使用する

• Content-Type ヘッダーを変更して PHP ファイルを正当な画像として表示する

• サーバー側での処理中に実際の拡張子を切り捨てるためにヌルバイトを挿入したファイルをアップロードする

根本的な問題は、多くの開発者がクライアント側でファイル拡張子のみをチェックしていることです。あるいは、MIMEタイプの検証のみを行い、サーバー側では強制的に適用していないという点です。どちらのチェックも必要であり、どちらか一方だけでは不十分です。.

オブジェクトインジェクションとデシリアライゼーションの脆弱性

PHP には、文字列を PHP オブジェクトに変換する unserialize() という組み込み関数があります。.

攻撃者が unserialize() に渡される内容を制御できる場合、アプリケーション内でメソッド呼び出しのチェーン (POP チェーンと呼ばれる) をトリガーする悪意のあるペイロードを作成し、最終的にサーバー上で任意のコードを実行できます。.

WordPress 自体はバージョン 6.4.2 で重大な POP チェーンの脆弱性を修正しました。.

コアとなる脆弱性は単独では直接悪用できませんでした。しかし、独自のオブジェクトインジェクション脆弱性を持つ特定のプラグインと組み合わせることで、完全なRCE攻撃パスが構築されました。.

これは、一見無関係に見える 2 つの脆弱性が組み合わさって重大な脅威を形成する可能性があることを示す完璧な例です。.

サーバーサイドテンプレートインジェクション

一部のWordPress テーマおよびページ ビルダーでは、テンプレート エンジンを使用して動的なコンテンツ。

ユーザー入力が適切なサニタイズなしでこれらのテンプレートに流入すると、攻撃者はサーバーによって評価および実行されるテンプレート構文を挿入できます。.

前述の Bricks Builder CVE-2024-25600 は、実際にはサーバー側のテンプレート インジェクションの脆弱性でした。.

ユーザーが制御するデータが、テンプレートレンダリングエンジンを介してPHP評価関数に直接渡されていました。これが非常に危険で、リモートからの攻撃が容易だった原因です。.

リモートファイルインクルード攻撃

リモート ファイルのインクルードでは、誤って構成された PHP 設定が利用されます。.

allow_url_include ディレクティブが有効になっていて、アプリケーションがユーザー入力を組み込んだ動的ファイル パスを使用している場合、攻撃者は自分のサーバーでホストされている PHP スクリプトを完全に取得して実行するようにサーバーに強制できます。.

最新の PHP 構成では、allow_url_include がデフォルトで無効になっていますが、多くの共有ホスティング環境や古い WordPress セットアップでは、初期展開後に再検討されなかった安全でない構成が依然として残っています。.

WordPress サイトが侵害された可能性があることを示す警告サインは何ですか?

多くのRCE攻撃は、数週間、あるいは数ヶ月もの間、潜伏したままになります。攻撃者は、目に見える形での妨害よりも、静かに継続的なアクセスを好みます。しかし、サイトのフロントエンドに被害がすぐには現れない場合でも、攻撃者に気付かせる兆候は存在します。.

注意すべき最も重要な危険信号は次のとおりです。

• アップロードまたはプラグインディレクトリ内に疑わしい、または見慣れない PHP スクリプトが現れた場合に警告するセキュリティプラグイン

• 自分で作成していない新しい管理者アカウントがWordPressダッシュボードに表示される

• サーバーのCPU使用率または送信帯域幅の異常な急増。これは、サーバーが知らないうちにスパムやボットネット活動に利用されている可能性を示している可能性があります。

• 検証済みの元のバージョンと比較した場合の、WordPress コアファイル、テーマファイル、またはプラグインファイルへの予期しない変更

• サーバーのアクセスログに、wp-content/uploads ディレクトリ内のファイルに対する疑わしい POST リクエストが記録されている

• PHPプロセスから発信され、不明な外部IPアドレスと通信する送信ネットワーク接続

• 検索エンジンがマルウェア警告でサイトをフラグ付けしたり、ホスティングプロバイダーが明確な説明なしにアカウントを停止したりする

これらの兆候を早期に発見する最も確実な方法は、自動監視とファイル整合性スキャンです。すでに複数の危険信号が確認されている場合は、この記事の最後にあるインシデント対応セクションをご覧ください。.

WordPress でリモートコード実行攻撃を防ぐにはどうすればよいでしょうか?

RCE攻撃の防止は、単一のプラグインや単一の設定変更だけでは不十分です。WordPress環境全体にわたる多層的な防御が必要です。.

各レイヤーごとに攻撃対象領域が縮小され、攻撃者が有効なエントリ ポイントを見つけるのが著しく困難になります。.

WordPressのコア、プラグイン、テーマを常に最新の状態に保つ

これは、あなたができる最も効果的な対策です。成功するRCE攻撃の大部分は、古いソフトウェアの既知の脆弱性を標的にしています。.

これらの脆弱性は既にパッチが公開されており、適用を待っている状態です。アップデートの遅延は、大規模なエクスプロイト攻撃キャンペーンにおいてサイトが侵害される主な原因です。.

堅実な更新戦略の実際の例は次のとおりです。

• wp-config.php ファイルにdefine('WP_AUTO_UPDATE_CORE', 'minor');を追加して、WordPress コアのマイナーリリースの自動バックグラウンド更新を有効にします

• Patchstack の脆弱性アラートを購読すると、実行中のプラグインが新しいセキュリティ問題を報告した瞬間に知ることができます。

• プラグインリストを毎月監査し、12か月以上開発者によるアップデートを受け取っていないプラグインは削除してください。放置されたプラグインは常にハイリスクなターゲットとなるためです。

• 互換性の問題が発生する可能性が高いメジャーバージョンアップグレードを本番環境にプッシュする前に、ステージング環境で更新をテストします。

複数のクライアント サイトを管理している場合、集中管理されたダッシュボード ツールを使用すると、各サイトに手動でログインしなくても、すべてのインストールを最新の状態に保つことが非常に簡単になります。.

サイト上のすべてのファイルアップロードパスをロックダウンする

サイトに、問い合わせフォーム、メンバーシップ プラグイン、WooCommerce ストアフロント、ポートフォリオ ビルダーなどを通じてユーザーがファイルをアップロードできる機能がある場合は、そのアップロード パスをデフォルトで高リスクの攻撃対象領域として扱います。

適切なファイルアップロードの強化は次のようになります。

• アップロードのたびにファイル拡張子とMIMEタイプの両方をサーバー側で検証し、クライアント側のJavaScript検証だけに頼らないでください。

• 許可されたファイルタイプの明示的なホワイトリストを維持し、そのリストにないファイルはすべてハードエラー応答で拒否します。

• サーバーレベルで二重拡張子をブロックし、image.php.jpg のようなファイルがアプリケーションロジックに到達する前に拒否されるようにします。

• アップロードされたファイルは、アプリケーションアーキテクチャが許す限り、Webルートディレクトリの外に保存し、URL経由で直接アクセスしたり実行したりできないようにします。

• 次のルールを含む .htaccess ファイルを wp-content/uploads に配置することで、アップロード フォルダー内での PHP 実行を完全にブロックします。

すべてのオプションを拒否 -ExecCGI AddType text/plain .php .php5 .phtml

ヒント：たとえ攻撃者がPHPウェブシェルをアップロードフォルダにアップロードすることに成功したとしても、そのディレクトリ内でのPHP実行をブロックすれば、ファイルは実際には実行されません。この.htaccessルール一つで、そうでなければ成功していたであろう無数のRCE攻撃を阻止してきました。

仮想パッチを備えたWebアプリケーションファイアウォールを導入する

Web アプリケーション ファイアウォールは、サイトと受信トラフィックの間に配置され、リクエストが WordPress に到達する前に検査します。.

高品質の WAF は、RCE 試行に関連する攻撃シグネチャを含む既知の悪意のあるペイロードを、サーバー上の脆弱なコードとやり取りする前にブロックします。.

RCE防止において特に有効なWAF機能は、仮想パッチです。重大な脆弱性が公開されると、信頼できるWAFプロバイダーは数時間以内に仮想パッチを配信し、プラグインやテーマの開発者が公式の修正プログラムをリリースする前であっても、既知の攻撃をブロックします。.

これにより、攻撃者が積極的に悪用する、情報公開とパッチの可用性の間の危険な期間が閉じられます。.

WordPress の場合、 WordPress 固有のルールセットを備えたCloudflare WAF は、

Sucuri Firewall は WordPress 専用に構築されており、マルウェア スキャン、CDN パフォーマンス、仮想パッチを単一の管理ソリューションにバンドルしています。

知っておく価値のある重要な違いは、一部のセキュリティ プラグインにはファイアウォールが組み込まれていますが、これは PHP エンドポイント レベルで動作するため、WordPress 自体内で読み込まれるということです。

クラウドベースの WAF は、トラフィックがサーバーに到達する前にフィルタリングするため、RCE 攻撃を防ぐための強力な第一防衛線となります。.

ダッシュボードでWordPressファイルエディターを無効にする

WordPress には、管理者がダッシュボードから直接テーマやプラグインのファイルを変更できる組み込みのコード エディターが付属しています。.

このエディタは開発中は便利ですが、攻撃者が管理者アカウントにアクセスした場合、大きなリスクとなります。有効にすると、FTPやSSHの認証情報なしで、サイト上の任意のファイルに悪意のあるPHPコードを瞬時に挿入できるようになります。.

wp-config.php で永続的に無効にします。

'DISALLOW_FILE_EDIT' を true で定義します。'DISALLOW_FILE_MODS' を true で定義します。

2 番目の定数はさらに進んで、ダッシュボードからのプラグインとテーマのインストールを完全に防止します。.

これはオプションですが、本番環境では強く推奨される設定です。これにより、侵害された管理者アカウントがWordPressインターフェース経由で悪意のあるプラグインをインストールするのを防ぐことができます。.

これは、WordPress バージョン 6.4.3 がリリースされる前に CVE-2024-31210 に対して推奨された緩和策でもありました。.

PHPとサーバー構成を強化する

WordPressのセキュリティの大部分は、実際にはサーバーのセキュリティです。サイト上のすべてのプラグインを完全に更新していても、サーバーの設定が適切でないと、インフラストラクチャレベルでRCE攻撃の脅威にさらされる可能性があります。

ホストまたはシステム管理者と協力して、次の強化策を実施してください。

• 最も危険なPHP実行関数が実行されないようにするには、php.iniのdisable_functionsディレクティブにeval() 、 system() 、 shell_exec() 、 passthru() 、 proc_open() 、 popen()を追加します

• 正しいファイル権限を設定します。wp-config.php は 400 または 440、ディレクトリは 755、個々のファイルは 644 にする必要があります。

• wp-config.php をファイルシステムレベルで読み取り専用にすることで、部分的なコード実行によってデータベースの資格情報やセキュリティキーが変更されるのを防ぐことができます。

• PHP 設定で allow_url_include を無効にして、リモートファイルインクルード攻撃ベクトルを排除します。

• PHP がサーバーのルートとして実行されないようにしてください。ルートレベルで実行されれば、RCE 攻撃が成功するとホスティング環境全体に無制限にアクセスできるようになります。

マネージドWordPressホスティングご利用の場合、これらの設定の多くはプロバイダーによってインフラストラクチャレベルで処理されます。それでも、何がカバーされていて何がカバーされていないかを確認する価値はあります。

プラグインのフットプリントを減らし、インストールするものを精査する

サイト上のすべてのプラグインは、サーバー上で実行されるコードです。すべてのコードは潜在的な攻撃対象です。プラグインの数が増えるほど、特に非アクティブまたは放置されているプラ​​グインは、悪用される可能性のある侵入口が増えます。.

以下のプラグイン衛生習慣に一貫して従ってください。

• 使用しなくなったプラグインは無効化し、完全に削除してください。無効化だけではコードがサーバー上に残り、残ったファイルパスを通じて攻撃される可能性があります。

• プラグインをインストールする前に、WordPressの公式プラグインリポジトリで最終更新日、アクティブなインストール数、既知の脆弱性履歴を確認してください。

• 非公式のソースやnull化されたリポジトリからプラグインをインストールしないでください。これらのプラグインには、プリインストールされたバックドアや難読化された悪意のあるコードが組み込まれていることが多いためです。

• Patchstack または同様の脆弱性監視サービスを使用して、サイトで現在実行されているプラ​​グインに新たに発見されたセキュリティ問題がある場合、自動アラートを受信します。

2025 年に広く報道された事件では、攻撃者は、無効化されているものの削除されていない廃止されたプラグインを標的にして、数千の WordPress サイトを侵害しました。.

プラグインのコードはまだサーバー上に存在し、URL 経由でアクセス可能であったため、悪用が成功するのに十分でした。.

すべての管理者アカウントで2要素認証を有効にする

盗まれた管理者の認証情報による RCE 攻撃は、エクスプロイトベースの攻撃ほど一般的ではありませんが、実際に存在し、文書化された経路です。.

管理者アクセス権を取得した攻撃者は、悪意のあるプラグインをインストールしたり、テーマファイルを編集したり、ダッシュボードのファイルエディターを使用して数秒で任意のコードを実行したりすることができます。.

2 要素認証では検証レイヤーが追加され、他の場所でのデータ侵害によりパスワードが漏洩した場合でも、資格情報ベースの攻撃の実行が大幅に困難になります。

少なくともすべての管理者および編集者レベルのアカウントで2FAを有効にしてください。WP 2FAなどのプラグインやWordfenceに組み込まれている2FA機能を使えば、サイト所有者は簡単に2FAを実装できます。.

管理者ログインの強化について詳しくは、 WordPress のログイン セキュリティではパスワード以外のことにも注意を払う必要があることをご確認ください。

継続的なセキュリティ監視とファイル整合性スキャンを設定する

発生しているかどうかわからない攻撃には対応できません。.

継続的な監視とファイル整合性スキャンにより、攻撃者が深く永続的なアクセスを確立してクリーンアップが困難になる前に、侵害を早期に検出できるようになります。.

堅牢な監視設定には以下が含まれます。

• ファイル整合性監視は、WordPressのコアファイル、テーマ、アクティブなプラグインへのすべての変更をリアルタイムで追跡し、予期しない変更が検出されるとすぐに警告します。

• eval(base64_decode(...))、およびインストール内の不正なバックドア ファイルを検索する、スケジュールされたマルウェア スキャン。

• ログインアクティビティログは、すべてのログイン試行の失敗と成功を記録し、異常な地理的アクセスパターンや同じIPからの連続ログイン失敗をフラグ付けします。

• 外部のコマンドアンドコントロールサーバーとの通信を試みるPHPプロセスを検出するためのサーバーレベルでの送信接続監視

Wordfence 、Sucuri、MalCare は、WordPress 固有のセキュリティ監視に最も広く使用されているツールです。

この層を専門家に処理してもらいたい場合は、WordPress メンテナンス サービスが、ビジネスに不可欠なサイトには検討する価値があります。

安全でテスト済みのバックアップを保管し、復元方法を知る

バックアップは、他のすべてが機能しなくなった場合の最後の安全網です。RCE攻撃が成功し、サイトが侵害されたり破壊されたりした場合でも、クリーンなバックアップがあればオンライン状態に戻ることができます。.

しかし、バックアップ戦略が機能するのは、危機が発生する前に復元プロセスが実際にテストされている場合のみです。.

次のバックアップ手順に従ってください。

• サーバーレベルの攻撃により、サイトファイルとともにローカルバックアップが破壊または暗号化される可能性があるため、バックアップはオフサイトでホスティング環境から完全に分離して保存してください。

• 少なくとも毎日自動バックアップを実行し、メジャーアップデートやコード展開の前には必ず実行してください。

• 少なくとも四半期ごとに復元プロセスをテストして、実際に負荷がかかる前に、どれくらいの時間がかかり、どのような手順が必要なのかを正確に把握してください。

• 複数の復元ポイントを維持して、最新のスナップショットだけでなく、侵害前のバージョンにロールバックできるようにします。

RCE 攻撃が疑われる場合は、すぐに何をすべきでしょうか?

危険信号が表示されたり、セキュリティ警告が表示されたりした場合は、スピードが重要です。以下の手順に従ってください。

• 調査中に攻撃者が既存のアクセスポイントを使い続けたり、追加のデータを盗み出したりすることを防ぐために、サイトをオフラインにするか、すぐにメンテナンスモードに切り替えます。

• 完全なマルウェアスキャンを実行して、インストール全体にわたって悪意のあるファイル、バックドア、挿入されたコードを特定します。

• すべてのWordPress管理者アカウントを監査し、自分で作成していないアカウントを削除します。特に、管理者レベルのロールを持つ最近追加されたアカウントに注意してください。

• WordPress 管理者パスワード、データベースパスワード、FTP および SFTP 認証情報、SSH キー、ホスティング コントロール パネルのパスワード、および wp-config.php 内の WordPress セキュリティ キーとソルトを含むすべての認証情報をローテーションします。

• サーバーのアクセス ログとエラー ログを確認し、アップロード ディレクトリ内のファイルへの POST リクエスト、予期しない場所からの PHP 実行、外部 IP アドレスへの送信接続など、侵害の兆候がないか確認

• のクリーンなバックアップが利用可能な場合は、そこから復元し、サイトをオンラインに戻す前に、すべての未処理の更新を直ちに適用します。

• 元の脆弱性を特定して修正することで、サイトを復元しても、攻撃が最初に成功した状況が再現されるだけにならないようにします。

インシデント対応を自分で処理することに自信がない場合は、専門的な WordPress サイト復旧を利用できます。適切なツールと経験がないまま手動でクリーンアップを試みるよりも、多くの場合、より迅速かつ徹底的な復旧が可能です。

最後に

リモート コード実行攻撃は、WordPress セキュリティにおける最も深刻な脅威の 1 つですが、決して避けられないものではありません。.

侵害を受けるサイトは、ほとんどの場合、セキュリティを後回しにしていたサイトです。攻撃者はあなたのサイトを特に狙っているわけではありません。.

彼らは数百万のサイトを同時にスキャンし、パッチが適用されていないプラグイン、アップロードディレクトリが開かれているサイト、監視が無効になっているサイト、アクティブな防御策が実施されていないサイトを探しています。.

このガイドで紹介する保護対策は、それぞれ複雑なものではありません。これらの対策を階層的な戦略として組み合わせることで、より強力になります。常に最新の状態を維持し、ファイルのアップロードをロックダウンし、WAFを導入し、PHP環境を強化し、継続的に監視しましょう。そして、必要になる前に、クリーンでテスト済みのバックアップを用意しておきましょう。.

これらの保護機能の実装について専門家のサポートが必要な場合、または現在のWordPressセキュリティ設定の専門的な監査が必要な場合は、Seahawk Mediaチームが喜んでお手伝いいたします。お気軽にお問い合わせください。お客様のサイトに必要なものをお伺いいたします。

WordPress RCE攻撃に関するよくある質問