当方の集客手法の特徴でもあるのですが、スポット新規のWordPressのセキュリティ・インシデントのレスキュー依頼が、毎年、年に数回あります。セキュリティ対策を意識していない企業は、零細中小企業に多く、同一サーバー内の他のアプリケーションに対するラテラルムーブメントなども発生し、被害が拡大しやすいです。
インシデントの渦中、WordPressダッシュボードにブラウザでログイン出来ない状態の場合、ダッシュボードにログインして使える状態まで仮復旧させ、仮復旧状態でマルウェアスキャンプラグインを利用し、マルウェア除去を実施します。
仮復旧までには、目視、grep、find、ファイルシステム改ざん履歴に対する各種の時系列検索コマンド、原本ファイルとの比較、DB検索などでマルウェアを取り除く必要があります。慣れると、ソースコードを斜め読み程度で素早くマルウェアを判別して除去出来ます。また、psコマンドでプロセスも不自然なものがないか確認します。TeraTerm等のLinuxコマンドのログも、必ず、残しておくようにします。
仮復旧までに、DBはwp_optionsテーブルのsiteurlやhomeの改ざん被害なども確認し、改ざんされていれば修正します。なるべくwp-cliのwp search-replaceコマンドを使います。
マルウェア探索/除去の作業の際には、ファイルシステムの改ざんされた年月日時分を並べて表をつくり、何のソースコードなのか？わかる範囲で分析と対策に活かします。依頼者の方がインシデントに気づく前の日時から、既にバックドアが設置されているなどサイバーキルチェーンの段階推測に役立ちます。
レンタル共有サーバーでWordPress稼働中で、ITセキュリティ予算は経営計画に入っていない様な零細中小企業における方法となります。毎年、外部監査法人によるセキュリティ監査を実施している様な規模の企業では、そもそもレンタル共有サーバーを選択する事が無い(はず)です。企業規模や経営層の姿勢によって、セキュリティ・インシデント対応と堅牢化の精緻性には大きな格差があります。
公式テーマ、公式プラグイン、コアについては、github公開リポジトリで該当バージョンを入手してdiffによる差分比較でマルウェア探索と除去が可能です。github公開リポジトリから入手可能なファイルは、汚染領域のバックアップを事前に取得しておいて、サーバ内からコアやプラグインなどの個別パーツ単位で全削除してgithubから持ってきて新規アップロードする。
(開発検証環境無しのレンタル共有サーバーで)「本番環境なので稼働を止めないで・・・」という顧客要望がある場合もありますが、マルウェア除去の精度確保のためには「肉を切らせて骨を断つ」として可能な限りのファイル削除を実施するため、数分の稼働停止を経営陣と交渉するケースもあります。公式プラグインや公式テーマではない場合、DBも含む完璧なマルウェア除去の立証は、さらに難しくなります。ベストを尽くすべきです。
オリジナルテーマやオリジナルプラグインの場合、事情を伝えて開発者から購入時のソースコードを受け取れたらベターです。インシデント対応開始直後、オリジナルが脅威被害の直接原因であるかどうかわからないです。エビデンスが無い身勝手な判断で責任を押し付けず、慎重に打診を行ってください。
マルウェアスキャンプラグインは、それぞれ利用している脆弱性データベースのウィルスパターンファイルが異なるので検出結果も異なります。異なる脆弱性DBのマルウェアスキャンプラグイン複数で最新のパターンファイルでDBとファイルの両方のスキャンを行い、検出結果の誤検知仕分けを行い、マルウェアのみ除去を行ってください。マルウェアスキャンプラグイン1つだけ実施して満足しないでください。また、プラグインによるマルウェアスキャンと目視手作業で除去を行ったから、マルウェア全部を除去出来たと断定は出来ません。リクエスト/レスポンスの分析を行うと、不審な通信をある程度絞り込むことはできますが、未知のゼロデイのマルウェア混入は脆弱性DBを使うスキャンで発見できない可能性があります。
マルウェア除去を行う場合、WPScanのようなバージョンスキャンによる既存の脆弱性スキャンではなく、マルウェア(Virus)スキャンでファイルとDBの改ざん被害をあぶり出す、いわゆるウイルススキャンを実施してください。
9 Best WordPress Malware Removal Plugins (2022)を上から順番に使っていきますが、アカウント作成が必要だったり、初回スキャンのみ無料だったり、有償でないとスキャン出来なかったり、有償でないとパターンファイルを最新に出来なかったり、コスト的な課題があります。
相手はボットなので、堅牢化しないと数時間以内に必ず同じインシデントが発生します。セキュリティ・インシデントに1人で対応する場合、対応速度と対応精度の限界戦です。完了するまで一喜一憂せず、冷静沈着を貫いてください。この記事はサンドボックス検証やインターネット遮断などは行わず、対応手法の費用を極限まで削減したWordPress専用の対応手法となります。
テーマ原本のファイルなどのソースコード脆弱性の静的診断は、Snykなどを使います。レンタル共有サーバーを利用しているクライアント企業の場合、予算の問題もありますがフォレンジック実施まで至ったことはありません。レンタル共有サーバー会社に、フォレンジック実施交渉を行うこと自体が不毛だと考えています。
WordPressの堅牢化は、更新永続、低品質プラグインの選別と利用禁止、外部ユーザーによるphpの実行を許可しないことなどが大事です。脅威を含むリクエストを受けても実行させない環境を作ります。
レンタル共有サーバー会社で可能な脅威対策は、主に「仮想化基盤セキュリテイ」と「ネットワークトラフィックに対するWAF」と「OS更新の永続」です。セキュリティインシデントのレスキュー依頼をいただくWordPressは、レンタル共有サーバーで運営されているケースが多いです。
攻撃者が最も悪質であることは不変の事実ですが、レンタル共有サーバーが脆弱なのではなく、phpバージョン、WordPressバージョン、プラグインバージョンなどの更新放置やプラグイン(バージョン)脆弱性診断などを怠る運用者のリテラシー不足がインシデント被害原因の大多数を占めます。小中学校の義務教育でソフトウェアアップデートの重要性を定着させる必要があります。レンタル共有サーバー会社の中には、OSアップグレードまで頑張っている会社もあります。ビジネス的に負けていて大胆な刷新メンテナンスの費用を捻出できていない弱小なレンタル共有サーバーを選ばない/使わない事も非常に大事です。
phpバージョンなども含めたアップデートの実施、堅牢化、DB内の不要テーブル削除、不要なバックアップデータの削除とバックアップデータやログのローテーション設定、CVSSのスコアで脆弱なプラグインやテーマの除去、（オリジナル）テーマのソースコードエラー修正、などを行い、再被害から脱出できます。堅牢化では、マルウェアの実行阻害やC&Cサーバとの通信阻害も設定することで、未発見な残りの潜在マルウェアをなるべく無効化します。
以降、採用するプラグインとテーマの厳選、アップデートの永続を行うことでセキュリティ・インシデント発生を無くせます。法人組織の情シス業務ほどカバー範囲が広いものではないため、WordPressのWEBサイト1つか2つ程度であれば、1人情シスでも面倒を見られます。大量WordPressの場合、一元管理が必要です。