ソーシャル エンジニアリング コンテンツが https://xxx で検出されました サイト復旧の手順
2020年9月3日18時頃、Google Search Consoleから「ソーシャル エンジニアリング コンテンツがhpps://xxx(サイトURL)で検出されました。」という題名のメールが届きました。その内容と対応の記録です。結論から言うと、プラグインのFile Managerが攻撃されてWordPressのファイルがすべて捨てられ、不審なphpファイルが置かれているという状況が起きました。
概要
Google Search Consoleでのメッセージ
お客様のサイトのページの一部で有害なコンテンツが検出されました。早急にコンテンツを削除することをおすすめします。… 検出された問題として、URLの一部の例が記載されていた。
また、修正完了後の「審査をリクエスト」のボタン。
どのようなサイトか
レンタルサーバーのさくらサーバーを借りています。WordPressで構築されているコーポレートサイトです。更新作業はお客様がある程度する形式をとっています。WordPressとPaypalを使って、物品やプログラムの販売をしています。
プラグインは使用中が17種類。WordPressのダッシュボードで設定が済むように基本的にフォームのプラグイン(MW WP Form)や販売用のプラグイン(Simple Cart、Easy Digital Downloads)、WordPressを簡単にカスタマイズできる一般的なプラグイン、自動アップデートのプラグイン、自動バックアップ用のプラグイン、ファイルをサーバーにアップロードするためのプラグイン(File Manager)など多数設定済み。
どのような現象が起きたか
まず検出された問題のあるURLを見ました。
上記のように「偽のサイトにアクセスしようとしています」と表示されました。URLを見ると/Office366/の文字。MicrosoftのOffice365に似せたサイトがサーバー内に生成されているようです。実際にどのようなページだったのかを見ることなくブラウザを閉じました。
通常のページを見るとphpのエラーメッセージ。「wp–blog–header.php on line 17」この時点で事態の深刻さに気付きました。
FTPでサーバーを見るとWordPressがフォルダごとありませんでした。バックアップ用にとっておいたフォルダも。
見たことのないmoded.phpというファイルとinfoというフォルダが生成されてます。
サイトの復旧手順
サーバーのログとデータベースの確認
まずサーバーのアクセスログを見てみたが特に怪しいログがない。
エラーログを見てみると例の怪しいURLに対するエラーログが1時間程度で130件ほど生成されていた。
この時点で原因が全く分からず、利用者の中で
- FTPまたはサーバーのID、パスワードが漏れた
- WordPressのID、パスワードが漏れた
この2択かなと考えた。サイトの会社の方は既に就業時刻を過ぎていたので、つながらずこちらで一方的に対応することを決めた。
データベースを見ると、データベースは生きていた。WordPressをインストールして再度繋げば記事やプラグインと紐づいてある程度復旧できる目星がついた。しかしメディアはすべて捨てられているので完全な復旧は難しい。
さくらサーバーのFAQを読み、共有サーバーでのサーバー会社による復旧は難しいということも分かった。
moded.php、infoフォルダを含む全ファイルを削除
他のファイルも書き換えられているかもしれないと考えたので、ローカルに原状サーバーのバックアップを取り、すべてのファイルを削除し、index.htmlで「ただいまメンテナンス中です」のメッセージを出した。
WordPressのインストール
簡単インストールで新しいデータベースができたり、追加で書き込みがされるを避けたかったので、WordPressのサイトからファイルをダウンロードした。
WordPressのインストール手順に従い、データベース名、ユーザー名、パスワード、データベースのホスト名、テーブルの接頭辞を入力していく。この時、phpAdminでデータベースを確認しながらインストール。
これにより記事や固定ページのテキストは復活。
※この手順時に、直近のバックアップをサーバー以外で持っていればそのバックアップを利用すればよいと思う。All-in-One WP Migrationなどで定期的にバックアップを取っておけば、バックアップ時点に簡単に戻れる。
- 1年半前に環境構築のためにローカルに保存したものが最後
- 記事や固定ページは更新され、プラグインも新規で入れているのでデータベースはそのまま利用したい。
という状況でした。
テーマファイルのアップロード
WordPressのテーマはバックアップがローカルにあり、contentsフォルダにアップロードしてある程度見た目が復活。
サイト構成に必要なプラグインをインストール
ローカル環境上で新規でプラグインを入れたりするときに使っていた環境があったので、それを参考に最低限必要なプラグインをインストール。
ほとんど見た目が元通りに。
ただし、メディアファイルがなくなっていたので、記事等の写真が抜けている。
ローカル環境にバックアップファイルの環境を再構築
メディアのURLを再現するため、残っていた1年半前のバックアップファイルの環境をローカルに再構築。/wp-content/uploadsのファイルを本番環境に移す。
後は地道な復旧作業
お客様にも協力いただき、ファイルを再アップロードして復旧完了。
Google Search Consoleで審査のリクエスト
復旧に時間が掛からないのであれば、復旧完了後、修正の審査リクエストを送りましょう。
今回は修正に時間かかりそうだったので、テーマファイルをアップロードした時点で審査リクエストを送ることにしました。
ソーシャル エンジニアリング コンテンツが検出された原因は何だったのか?
発生当初は全く理由がわからなくて、自分のPCのウィルス感染、取引先のユーザーの感染などを疑いました。WordPress、プラグインは月に一度は最新のものに更新されているかチェックしていましたし、バックアップも定期的にサーバー内で取っており問題ないと考えていました。
数日して「File Managerの脆弱性」に関するツイートを目にしました。サーバー各社からもニュースとして流れています。この件もどうやらFile Managerの脆弱性をつかれ、ファイルが全部捨てられ、書き換えられた事案であったと思われます。
- 利便性向上のためにプラグインを複数入れているリスク
- ファイルの書き換えができるようなプラグインを入れる怖さ
- バックアップの取り方の検討
など、改めて検討すべき課題だと思いました。
File Managerの脆弱性
2020年9月1日時点でパッチが出ていたようですが、2日パッチに対応していなかっただけで攻撃にあってしまう怖さを感じました。サーバー各社が情報を出しているので、多数のサイトが被害にあったのでしょう。
このプラグインは、メディアにアップロードできるファイルが限られており、メディアにアップロードすることができない。WordPressの管理画面上で処理を完結したい。FTPソフトを使ってWordPressのシステムファイルを誤って消されてしまうことを防ぎたいという要望・実務的なことから入れたものでした。
ただ、All-in-One WP Migrationでバックアップファイルをエクスポートしようとすると、File Managerからアップロードしたファイルもバックアップしてしまい、今回のサイトでは50GB程度のバックアップファイルが生成され、ダウンロードしようとすると共有サーバーの容量をこえ、503サーバーエラーが起きてあきらめたという経緯があります。
WordPressとの付き合い方
WordPressは世界で最もシェアの高いCMSです。そのため攻撃も頻繁にあいます。
- セキュリティの見直し
- 不要なプラグインの削除
- プラグインに頼らない構築
- サーバーサイドでの有料のバックアップ
というものを私も進めていきたいと思いますし、皆さんも検討されてはいかがでしょうか。また、同じような被害に遭われた方の参考になれば幸いです。もっといい方法がある!というご意見も頂けると嬉しいです。
カテゴリー : ホームページのメンテナンス