VPSのWordPressサイトに来た攻撃を公開してみる

Cyber Attack against WordPress Website SECURITY
Image by Hnnng from Pixabay

グローバルIPアドレスを持つWebサーバーでサイトを運営していますが(このサイトのこと)、脆弱性を狙った不審なアクセスが毎日来ます。一度内容まとめたいと考えていたので、してみました。

実際に来た不正アクセス試行は種類を挙げればきりがありませんが、件数が多いものを紹介したいと思います。有効な対策だと思われることについても言及しています。

ちなみに解析の方法は、ログを一旦DBに入れてSQLで集約しています。

インターネットにWebサーバーを公開すると、こんな攻撃が毎日来て対策するのが大変だよ…という参考にして頂ければと思います。と考えると、はてなブログやレンタルサーバーは楽ですね。

環境

  • VPS (Virtual Private Server: 仮想のCentOS)
  • WordPress

一応、WAF (Web Application Firewall)がありますので、そこからもログを取得しています(POSTのパラメータなど)。分析ですが、今回は11月の直近の分のみを対象に解析してみました。

WordPressに対する(と思われる)攻撃

日頃からログ・通知を見ていても、WordPressを標的にしたと思われるアクセス試行が最も多く感じます。

公開されているWordPressの脆弱性については、プラグインが多いせいもありますが、JVN iPediaでも結構な数が登録されています。

WPは導入が容易かつ機能拡張も楽にできるので便利ですが、プラグインに脆弱性があると不正アクセスの入り口を増やしてしまいますし、世界的にも導入数が多いこともあってターゲットになりやすいようです。

以下、実際に自サイトに来た不正アクセス試行のログです。

ログインページの存在確認

言わずと知られたWordPressのログインページ(wp-login.php)ですが、それがアクセス可能かを調査しに来ているようです。

GET [url]/wp-login.php
POST [url]/wp-login.php

404(存在しないページへのアクセス)を記録しているアクセスの中では一番多いのが上の二つです。wp-login.phpを探しにくるアクセスは、実は月に250件ほどあります。

対策としては、ログインページのURL変更が可能で、これは基本と思います。また、アクセス元を特定のIPアドレスのみに制限する方法も有効です(いわゆる踏み台の利用)。

プラグインの脆弱性を狙った攻撃

WordPressのプラグインであるFile Managerを狙ったもの。readme.txtを取得しているのは、インストールしているかを確認するためでしょう。

GET /wp-content/plugins/wp-file-manager/readme.txt

FileManagerについては、最近、深刻な脆弱性として報告されていました。

上でも書きましたが、WordPress本体に脆弱性がなくても、プラグインの脆弱性を突くことで攻撃ができてしまいます。WPは便利な反面、リスクも少なくありません。

xmlrpc.phpにたいする攻撃

この、xmlrpc.phpに対するPOSTは月に400件ほど来るリクエストで、正直、うんざりするほど見ます。

POST /xmlrpc.php
POST /blog/xmlrpc.php
POST /xmlrpc.php

xmlrpc.phpへのアクセス抑止はググれば結構な数のサイトで解説されています。

ちなみに、上のようなPOSTリクエストでは様々なパラメータ付きでアクセスがあります。例を挙げると下の通りです。このdie(@md5(文字列))は結構目にします。

Magento=die(@md5(Apri1))

MagentoはPHPで実装されたECプラットフォームのようです。WP以外にも同一名称のファイル名を使用したパッケージがあるようです。

特定製品を狙った攻撃

NETGEAR製品の脆弱性を狙ったものです。

GET /currentsetting.htm

↓はDasan製(韓国企業)ルーターの脆弱性を狙ったもの。かなり以前から頻繁に見ます。

POST /GponForm/diag_Form?images/

この辺りの情報は、JVN iPediaにもありますし、IPAのセキュリティに関するニュースを確認していれば自動的に目に飛び込んでくると思います。

PHP絡み

PHPUnitの脆弱性を狙った攻撃

これも月に40件程のアクセスがありました。
vendorはcomposerで使用するものですが、Laravelを使用しているサイトでも注意が必要そうです。

POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php

このアクセスからは、下のようなパラメータが送られてきていました。

<?php  echo 'RCE_VULN|'; echo php_uname();?>

PHPUnitには、任意のコードが実行される脆弱性があるようですので、そこを突いた攻撃でしょう。サーバーの情報を確認するコマンドを送っているようです。

Xdebugへのアクセス

XdebugはPHPのデバッグ用のツールで、PHPStormはPHP用のIDE。
まぁ、インストールはしていないので404を返しているわけですが、不正な試行であることに変わりありません。

GET /?XDEBUG_SESSION_START=phpstorm

権限の設定漏れを突いてくる攻撃

.env

これもHTTPステータス404を返したログとして残ってました。

GET /.env

node.jsで使用される環境設定用のファイルらしいですが、アクセスが多かったです。

Linuxでは、”.”で開始するファイルは隠しファイル(もしくはディレクトリ)なわけですが、そこを読み取ろうとしてくるアクセス試行は他にもありました。具体的には、以下。

GET /.wp-config.php.swp 
GET /.local 
GET /.gitignore 
GET /.production 
GET /.meta 
GET /.remote 
GET /.DS_Store 
GET /.well-known/security.txt 
GET /.vscode/sftp.json 
GET /.addressbook 
GET /.proclog 
GET /.dockerignore 

インストールや更新の後はディレクトリの中身が丸見えになっていないかや、アクセス権限の確認をきちんとしておく必要があります。

その他

ログインページの探索試行

下もログインページを探す試行でしょう。

HEAD /admindede/login.php
HEAD /manage/login.php
HEAD /admin/login.php
HEAD /manager/login.php
HEAD /dede/login.php
HEAD /htadmin/login.php

ちなみに、HEADメソッドはGETと違って本文を返しませんので、ファイルの存在の確認をしていると考えられます。

同一IPからの大量リクエスト

下の感じで短時間に大量アクセスを仕掛けられることも頻繁にあります(日時はアクセス日時)。

2020-11-02 07:54:57 GET /myadmin/scripts/db___.init.php 
2020-11-02 07:54:58 GET /MyAdmin/scripts/db___.init.php 
2020-11-02 07:54:58 GET /plugins/weathermap/editor.php 
2020-11-02 07:54:59 GET /cacti/plugins/weathermap/editor.php 
2020-11-02 07:54:59 GET /weathermap/editor.php 
2020-11-02 07:55:01 GET /App/?content=die(md5(HelloThinkPHP)) 
2020-11-02 07:55:01 GET /index.php/module/action/param1/${@die(md5(HelloThinkPHP))} 
2020-11-02 07:55:01 GET /index.php?s=/module/action/param1/${@die(md5(HelloThinkPHP))} 
2020-11-02 07:55:01 GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> 
2020-11-02 07:55:03 GET /joomla/ 
(中略)
2020-11-02 07:55:42 POST /my.php 
2020-11-02 07:55:42 POST /qq.php 
2020-11-02 07:55:46 POST /kpl.php 
2020-11-02 07:55:46 POST /hgx.php 
2020-11-02 07:55:46 POST /ppl.php 
2020-11-02 07:55:46 POST /tty.php 
(以下略)

実は以前、自サイト(WordPress)がダウンする事件がありました。それが上の一連の大量アクセスで、該当のアクセス元(中国だった)は大量のリクエストを送付してxmlrpc.phpまで来たところで、xmlrpc.phpに対し膨大なPOSTリクエストを送り付け、DBが死んだ…ことがありました。

対策については、「wordpress xmlrpc.php」でググると出てきます。プラグイン(Site Guard WP Pluginとか)でも対処できますし、fail2banとか、WAFの導入も有効です(fail2banもWAFも結構リソースを消費しますが)。

有効だと思う対策

脆弱性情報の確認

IPA(情報処理推進機構)は脆弱性に関する情報を集約・発信しています。RSSも公開されているので、そこで重要な情報は拾えます。まぁ、この辺りは基本でしょう。

また、JVN iPediaは脆弱性に関する情報をデータベース化し、公開しています。

また、twitterアカウントをお持ちであれば、JVNやIPAのセキュリティ関連の最新ニュースは、以下のアカウントをフォローすれば自動的に流れてきます(これが結構時短になるので、おすすめです)。

このあたりの情報を見ておけば、情報収集と対策の手がかりは掴めるかもしれません。

OS・ソフトウェアのアップデート

これも基本ですよね。

プラグインや本体の更新通知についてはWordPressのダッシュボードに通知されるはずですし、Site Guard WP Pluginを使えば更新の通知をメールにも入れてくれます(他にも色々な対策が使用可能です)。ただ、NGINXには対応していないはずなので、Apache HTTP Server限定になります。

加えて、OS、Webサーバー、PHPの更新も可能な限り、きちんと実施したほうが良さそうです。

とは言いつつ、いきなり本番環境に適用は普通しませんし、検証後に適用するのが普通だと思います。ですので、そう早急にはできないかもしれません。この辺りは、WAFを導入することで多層的な防御を施すことも有効な施策になります。

ちなみに、yumでインストールしたWebサーバー(Apache HTTP Serverとか)のバージョンは、httpd -vで確認すると古いバージョンが見えますが、バックポート(古いバージョンのソフトウェアを更新すること)が施されているようなので、むやみにOSS版(ソースからコンパイルするやつ)にする必要はないかもしれません。

でも、RHEL版とCentOS版は同様のバックポートが施されているんですかね?(そこがよく分からなかった) 試しにApacheのバグフィックスに関してRHELのサイトとCentOSのRPMのChangelogを見たりしてみましたが、CentOS版にも施されているようには…見えましたが。

また、上でも挙げましたが、ファイルに対するアクセス権限の設定にも注意を払う必要があります。

以上です。