実際にWordPressのサイトがハッキングされていたので調査と対処

ブログ, 技術系

「ブログの投稿が全て英語になっているんです」という問い合わせがありまして、作成の際にお手伝いさせてもらったサイトさんだったのですが、見たところクラッキング（ハッキング、不正アクセス）のようでしたので現況の確認と対処のお勧めについてまとめました。

（ここではクラッキングという呼び方で統一します）

https://ja.wikipedia.org/wiki/クラッカー_(コンピュータセキュリティ)

目次

はじめに

「WordPressサイトのサイトの投稿が英語になっている」という連絡が入りました。
当初はその方のブラウザでGoogle翻訳が有効になってしまったのでは、ですとか、翻訳系のプラグインを入れたのではないか、ということを推測したのですが、確認したところクラッキングだったようでした。

https://wpdocs.osdn.jp/FAQ/ハッキング・クラッキング被害

現況の被害確認

サイトを確認したところ確かに英語の記事が沢山出ていました。
先方に確認したところ投稿に覚えは無い、ということでしたのでクラッキングが強く疑われました。

こんな感じで記事が投稿されています。投稿日については一日一件ずつ、キレイに投稿されていました。
投稿者は全て同じです。

よくあるクラッキングと目的

WordPressでよくあるクラッキングは次の通りです。

  1. 不正な記事の投稿
  2. コアファイルへのバックドアの設置
  3. スパムメールの踏み台サーバ化

それぞれの事例と目的を見ていきます。

不正な記事の投稿

クラッカーが不正な記事を投稿します。不正な記事はスパムコメントの用に自分に利益のあるリンク（広告ページや被リンク稼ぎ）を埋め込んだり、スクリプトタグなどを埋め込んでXSSを誘発させアクセスに来たユーザに対して二次被害を増やす、ログイン情報やカード情報を盗み取るフィッシングページの設置などが目的です。
この不正な記事の手口も巧妙になってきており、新規記事の投稿だけではなく、過去の記事改ざんといったことも行っています。多くの記事を投稿している場合には過去の記事を改ざんされるとなかなか気づきにくいです。
今回はこの不正な記事の投稿が行われていました。

コアファイル、テーマファイルへのバックドアの設置


上記の画像は実際にあったテーマファイルの汚染です。

コアファイル（WordPress本体）やテーマファイルに悪さをするプログラムを仕掛けられます。
こういったプログラムを仕掛けられてしまうと、パスワードの変更などでこの時のクラッキング自体の対処を行ったとしても、後々に埋め込まれたプログラムを使って後からクラッキングを引き起こされる場合があります。
後からのクラッキングはユーザのパスワード変更やボットネットでのスパムメールの送信など、対処を行った、と思っても被害が止まらくなってしまいます。
このようなプログラムは後から侵入するために設置することからバックドア（裏口）と呼ばれています。

上記のファイルの例では author.php のヘッダ部分に特殊なコードが埋め込まれていました。
難読化が施されていますが、これらの多くは「悪いことがなんでもできちゃうプログラム」が埋め込まれることが多いです。
特徴としては「あれっ、こんなコード誰が入れたんだろう…。わかんないから置いておくか。」となりがちなことで、難読化のために読んでもわからず放置されることも多いです。

Drupalでも同じようなコードが報告されていました。

dogmapさんの記事がすごく参考になります。

スパムメールの踏み台サーバ化

スパムメールの送信ですね。こちらもバックドアと組み合わせて使われることがあります。
国内大手のレンタルサーバやVPSなどを使っているとある日突然「お客様のアカウントから大量のメールが。（略）。対処をしてください、さもなくば利用停止します。」という連絡が入ったりします。
ちょっとびっくりしますよね。
2000年代ごろの一昔前ではスパムメールが全盛を迎え、手がつけられなくなっていました。
そういったスパムメールの多くはブロックなどを防ぐため、送信元を偽った踏み台サーバを経由されています。
スパムメールの対処は難しかったのですが、現在は国内のレンタルサーバの多くでスパムメールをブロック、警告するようになっていて、踏み台化された場合にはそれらの連絡が入ります。
スパムメールはクラッカーが送信することでお金をもらえていたのですが、メール自体が廃れてきたりスパム対処が進んだため、最近ではスパムメール被害は減ってきた印象があります。

Botとクラッキング

クラッキングの多くはBot（自動化プログラム）にて行われます。
Botプログラムがウェブサイトを自動的に巡回し、既知の脆弱性などを自動的にクラッキングして回ります。
今回の件ではアカウントへの不正アクセスが疑われたので、おそらくはパスワードのブルートフォース攻撃（パスワード総当り攻撃）を受けてパスワードが漏れてしまったことが原因だと推測されました。
特に先方にパスワードについて確認したところ「簡単なものです」とのことでしたのでブルートフォースが濃厚でした。

ちなみにWordPressでは過去に「デフォルト管理者ユーザ名はadmin」ということがありました。
ブルートフォースによるログイン試行では「ユーザ名＋パスワード」をセットでアタックしますが、このユーザ名が固定値であったため多くの被害が出ました。
現在では初期の管理者ユーザ名を入力させるようになっていますのでadminが破られることは少なくなりました。
ただし投稿者名やスラッグなどでユーザ名はすぐに分かってしまいますので、Botなどでも攻撃可能です。

今回の対処

今回は直接対処を行ったわけではありませんが、下記の対処方法をおすすめしました。

  1. パスワードの変更
  2. 投稿されたと思われる記事の削除
  3. 本体とプラグインの更新

ただ「本体とプラグインの更新」については「更新したら崩れるかもしれない」とのことでしたので見送りとなりました。
見送り自体は良くないことなのですが「更新で動作不良となって復旧させるコストのリスク」を踏まえての結果となりました。
プラグインの脆弱性も多く発見されていますが、大型の脆弱性出ない限りは実際にクラッキングされている例は多くないと感じています。
本体バージョンは自動更新がオンになっており最新版でした。少し前にあった大型ハッキング（4.7.0, 4.7.1のREST API）は超えていましたので大丈夫そうでした。

でもプラグインの更新がたくさん来ていますね…。

また今回は該当ユーザのパスワードが脆弱だったことが強く疑われたため、そこからの被害だろうと推測されました。

対処としての模範解答は絶対に「WordPress本体とプラグイン、ミドルウェア類は必ず最新に！」なのですが実際問題としてアップデートのコストを誰が負担するか、という点は難しいですね。

本来は行わなければいけない対処

今回はユーザのパスワード変更と記事の削除だけでしたが、クラッキングが疑われた場合にはもう少し色々と対処を行う必要があります。

コアファイル、テーマファイルの改ざんの調査、復元

コアファイルやテーマファイルにバックドアを仕掛けられている可能性がありますのでこれらの復元が必要です。
コアファイルについてはプラグインで改ざん検出ができたりします。（たぶん）
若しくは改ざんが起こったという前提で全てを差し替えた方が安全でしょう。

テーマファイルについても同様です。テーマファイルも汚染されていないと確認できるバージョンへの差し戻し、差分の確認などが必要です。

過去記事の調査

過去の記事の改竄の調査も必要です。不正なコードや不正なリンクが埋め込まれていないか調査を行っておいたほうが良いでしょう。
優しいクラッキングの場合には投稿日ごとセットで書き換えられることも多いのです。その場合には投稿日や更新日を中心に確認すると改ざんが分かります。
若しくはwp-cliで投稿の検索を行うと良いです。

scriptやhrefといったキワードを中心に確認すると良いです。

プラグインの導入

最近ではセキュリティ系のプラグインが充実してきました。

クラッキングを防ぐために

クラッキングはその痕跡をほとんど残さずに行われることもあります。
ですので事前の防衛が非常に重要です。

WordPressであれば本体のアップデート、プラグインのアップデート、パスワード管理を中心に行うことが肝要ですね。
またロールバックのためのバックアップも重要ですね。

その他

WordPressに限らないですがIT系にいると実際にクラッキングを目にすることはありますね。
クラッキングの目的によってはウイルスと同じく被害を拡大することになりかねません。
ですので出来る限り防ぐことが重要ではあると思うのですが、実際の現場ではコスト問題があるので完璧な対処は難しいですね。
このあたりは病気のリスクと診療コスト、予防コストなどで医療現場とも似ているのかな、と感じています。難しい問題ですね。

そういえば最近話題のランサムウェアですが、ウェブサイトも同じような被害に遭いそうですね。ただロールバックしやすいのであまり標的にはならないのかな、というところですね。