ここ数日、PHPの脆弱性に関する話題で持ち切りですが、自分のWordPressサイトは大丈夫なのか気になりました。
普段はWordPressの管理画面からプラグインを更新する程度で、サーバー内のファイルを直接確認する機会はほとんどありません。
今回は取り急ぎ、PHPとWordPressのバージョン確認、レンタルサーバー会社の対応状況の確認、バックドアと思われるファイルが設置されていないかの簡易調査を行いました。
結論として、レンタルサーバー会社側で今回の脆弱性への対応が行われたことを確認でき、SSHで調べた範囲でも明らかに不審なファイルやコードは見つかりませんでした。
ただし、簡易的な調査なので、サイトの安全性を完全に保証できるものではありません。
まずはプラグインの更新状況を確認
最初にWordPressの管理画面から、インストール済みプラグインの更新状況を確認しました。
プラグインはWordPressの機能を増やしてくれる一方、脆弱性が発見されることもあります。
ただ、プラグインを最新にしているだけでは、WordPress本体やPHPの実行環境、すでに設置されているかもしれない不正ファイルまでは確認できません。
そこで、サーバーにSSHで接続して調べることにしました。
PHPのバージョンを確認する
SSHでサーバーに接続し、まずPHPのバージョンを確認しました。
php -v実行結果は以下のとおりです。
PHP 8.3.35 (cli)PHP 8.3系が利用されていることを確認できました。
ただし、このコマンドで確認できるのはCLI（コマンドライン）で使用されるPHPです。Webサイトの表示に使われるPHPと同じバージョンとは限りません。
また、バージョン番号だけで特定の脆弱性への対応状況を判断することもできません。
レンタルサーバー側の対応状況も確認
PHPのバージョンを確認しただけでは、今回話題になった脆弱性への対策が済んでいるかどうかまでは分かりません。
そこで、利用しているレンタルサーバー会社の対応状況も確認しました。
その結果、レンタルサーバー会社側で今回の脆弱性への対応が行われたことを確認できました。
自分でPHPの設定を変更する必要があるのか気になっていましたが、今回はサーバー会社側で対応されていたようです。
ただし、サーバー側の対応が完了していても、WordPress本体やプラグインの脆弱性、不正ファイルの有無は別の問題です。
そのため、念のためSSHでの簡易調査も実施しました。
WordPress本体のバージョンを確認する
次に、WordPress本体のバージョンを確認しました。
WordPressのインストールディレクトリで、次のコマンドを実行します。
grep '^\$wp_version =' wp-includes/version.php私の環境では、次の結果になりました。
$wp_version = '7.1.3';WordPressのバージョン情報は、wp-includes/version.php に定義されています。
管理画面からも確認できますが、SSHで直接ファイルを調べる方法もあると分かりました。
なお、バージョンを確認できたことと、WordPress本体のファイルが改ざんされていないことは別の話です。
バックドアが設置されていないか調べる
ここからは、サーバー内に不審なPHPファイルが存在しないかを確認しました。
バックドアとは、正規の認証手順を経ずにシステムへアクセスするための不正な仕組みのことです。
例えば、攻撃者がサーバーにPHPファイルを設置すると、そのファイルを経由して不正な処理を実行される可能性があります。
今回は新しいツールをサーバーにインストールせず、Linuxの標準的なコマンドで調査しました。
uploadsディレクトリにPHPファイルがないか確認
WordPressの wp-content/uploads は、通常、画像などのアップロードファイルを保存する場所です。
そのため、まずはこのディレクトリ内にPHPファイルが存在しないか確認しました。
find wp-content/uploads -type f \
\( -iname '*.php' -o -iname '*.phtml' \
-o -iname '*.phar' -o -iname '*.php[0-9]' \) \
-printこのコマンドでは、指定した拡張子のファイルを再帰的に検索します。
私のサイトでは、該当するファイルは見つかりませんでした。
ただし、PHPファイルが存在するだけで不正とは限りませんし、今回の検索に一致しない形式の不正ファイルが存在する可能性もあります。
不審な処理に使われる関数を検索
次に、PHPのコード内で、バックドアに悪用されることのある関数が使われていないかを確認しました。
grep -RInE --include='*.php' \
'eval[[:space:]]*\(|base64_decode[[:space:]]*\(|shell_exec[[:space:]]*\(|passthru[[:space:]]*\(' \
wp-content 2>/dev/null | head -50検索対象にしたのは、次の関数です。
| 関数 | 主な用途 |
|---|---|
eval() | 文字列をPHPコードとして実行する |
base64_decode() | Base64形式の文字列を復号する |
shell_exec() | OSコマンドを実行する |
passthru() | OSコマンドを実行し、出力する |
これらは正規のプログラムでも使用される関数です。
特に base64_decode() は、データの変換などにも普通に利用されます。
そのため、検索にヒットしただけでマルウェアと判断することはできません。
今回の調査では、該当するコードは検出されませんでした。
なお、エラー出力を非表示にしているため、読み取り権限などの問題で検索できなかったファイルがある可能性には注意が必要です。
最近更新されたPHPファイルも確認
不審なファイルが最近追加・変更されていないかを調べるため、過去30日以内に更新されたPHPファイルの数も確認しました。
find . -type f -iname '*.php' -mtime -30 -print | wc -l結果は4,391件でした。
想像以上に多くて、少し驚きました。
ただ、WordPressでは本体やプラグインの更新によって、多数のファイルの更新日時が変わります。
そこで、どのディレクトリに更新が集中しているのかを確認しました。
調査したところ、大部分は wp-content/plugins 以下のファイルでした。
プラグインの更新によるものと考えられる分布だったため、件数が多いことだけを理由に不正とは判断しませんでした。
また、WordPress本体のディレクトリにも最近更新されたファイルがありましたが、確認した範囲では標準的なファイル名でした。
ただし、更新日時やファイル名だけでは改ざんの有無を判定できません。
今回の調査結果
今回確認した内容を整理すると、次のようになります。
| 調査内容 | 結果 |
|---|---|
| プラグインの更新状況 | 管理画面から確認 |
| PHPのバージョン | CLIで8.3.35を確認 |
| レンタルサーバー会社の脆弱性対応 | 対応済みであることを確認 |
| WordPressのバージョン | 7.1.3を確認 |
| uploads内のPHPファイル | 指定した拡張子では検出なし |
| 特定のPHP関数の検索 | 検出なし |
| 最近更新されたPHPファイル | 多くがプラグイン配下 |
| 明確なバックドアの兆候 | 今回の調査範囲では見つからず |
ひとまず、明らかに不審なファイルが大量に設置されているような状況ではなさそうで、少し安心しました。
一方で、今回実施したのはファイル名・更新日時・特定のコードパターンを使った簡易的な調査です。
WordPress公式ファイルとのチェックサム照合、データベース内の不正コードの調査、アクセスログの詳細分析などは実施していません。
そのため、バックドアが存在しないと断定できるわけではありません。
調べてみて感じたこと
普段はJavaで開発しているため、WordPressやPHPの内部構造を意識する機会はあまりありませんでした。
今回調べてみて、WordPressは管理画面だけで完結するものではなく、サーバー上にPHPファイルが配置され、それらが実行されて動いているWebアプリケーションなのだと改めて実感しました。
また、プラグインを更新することと、不正なファイルが存在しないかを調べることは、別の確認作業なのだと分かりました。
今回は取り急ぎの調査でしたが、自分のサイトの構成を知る良い機会にもなりました。
今後はWordPress本体の整合性確認やアクセスログの調査など、もう少し踏み込んだ確認方法も勉強していきたいと思います。
🔎 はじめての方へ
このサイトの全体像はまとめページにあります。
学習ログまとめはこちら →