Future Tech Blog
フューチャー技術ブログ
Securityカテゴリ

WordPressの脆弱性への攻撃とセキュリティ対策の実施

はじめに

2021年7月入社の八田です。現在はCSIG（Cyber Security Innovation Group）に所属しています。CSIGは、リスクアセスメントやセキュリティ対策支援を行うコンサルティングチームと、FutureVulsの開発を行っているチームがあり、私は前者のコンサルティングチームに所属しています。今回はIT未経験で入社した私が技術面のキャッチアップとして取り組んだ、脆弱性への攻撃および対策方法を共有したいと思います。

本記事で、読者の皆さんのセキュリティ分野への関心・理解を深められたり、「文系・IT未経験でも入社半年でこのレベルのことができるようになるのだ！」ということを伝えられたら嬉しいです。

WordPressプラグインの脆弱性CVE-2020-25213

今回扱ったのは、WordPressのプラグインFile Managerの脆弱性で、CVE-2020-25213が割り当てられているものです。

ご存知の方も多いかもしれませんが、WordPressというのは簡単にホームページが作成できるCMS（Contents Management System）であり、File ManagerはWordPress上のフォルダやファイルの管理ができるプラグインのことです。その利便性が故に、File Managerは非常に人気のプラグインでダウンロードは70万を超えているようです。

そんな大人気のプラグインFile Managerですが、2020年に重大な脆弱性が発覚しました。
この脆弱性を利用することで、認証不要でファイルのアップロードができます。WebShellをアップロードすることで、任意のコードを実行することができます。

この脆弱性を利用すれば、Webサーバからの情報漏洩やサイトの改ざんが可能です。また、具体的な方法は後述しますが攻撃が非常に容易であるのもこの脆弱性の特徴で、誰でも利用できてしまいます。（今回のキャッチアップでこの脆弱性を選んだのも攻撃が容易だったというのが理由です。）

また、米国のサイバーセキュリティやインフラの安全に関わるアドバイザリーを行う政府機関のCISA（Cybersecurity and Infrastructure Security Agency）が発表している脆弱性リスト「Known Exploited Vulnerabilities Catalog（KEV Catalog）」にも登録されていることから、悪用される危険性が非常に高い脆弱性ということがわかります。

攻撃方法

今回確認したPoCは、攻撃対象のWordPressサーバとは別のホストから攻撃を仕掛け、攻撃対象のWordPressサーバに格納されたテストファイルの削除や新たにファイル配置を行うというものです。

攻撃対象サーバ構築では、以下のものを使用しました。

環境情報（攻撃対象サーバ）

  • CentOS 7.9
  • Apache 2.4.6
  • MariaDB 10.6
  • PHP 8.0
  • WordPress 5.9.1
  • File Manager 6.0

一般的な構築手順のためインストール作業の詳細は省略しますが、以下の流れで進めました。

  1. Apache、MariaDB、PHPインストール
  2. WordPressインストール
  3. File Managerインストール
  4. テストファイル（testfile）作成

環境情報（攻撃クライアント）

  • CentOS 7.9（攻撃対象サーバとは別に用意）
  • Python 2.7
  • pip 20.3.4
  • requests 2.6.0

検証に使うPoCはこちらで公開されているコードを使用しました。

このPoCは、攻撃対象サーバのconnector.minimal.phpというファイルに対してPOSTし、connector.minimal.phpを介してelFinder（サーバ内のファイルを扱うもの）インスタンスを呼び出すことで、x.phpというWebShellを配置します。そして配置したx.phpに対して任意のコマンドを送ります。
攻撃仕組み4_2022-04-08_085527.png

したがって、今回のFile Managerの脆弱性はconnector.minimal.phpが外部から実行できてしまうことに原因があると言えるでしょう。

攻撃実行

攻撃対象サーバに対して攻撃をしていきます。
./vul.py http //192.168.10.6/wordpress
まず、攻撃クライアント構築で作成したファイルを実行します。これにより、攻撃側が用意したPHPファイルが攻撃対象サーバへ格納され、任意のコマンド実行が可能な状態となります。

その後、任意のコマンドを入力できるようになるので、攻撃対象サーバ内で実行させたい任意のコマンドを入力します。

今回実行したコマンドは順に、

  1. 既存ファイルの削除

rm -f /var/www/html/testfile

  1. ファイルの配置

touch /var/www/html/wordpress/testfile2

  1. ファイルへの書き込み

echo Hello >> /var/www/html/wordpress/testfile2

の3つです。

※上の黒いウィンドウが攻撃対象（192.168.10.6）、下の青いウィンドウが攻撃クライアントです。
攻撃実行タイトルフレーム付_0408

このように、非常に簡単にWordPressサーバ内のファイル配置や削除、変更が可能であることがわかります。
これを利用すれば、WordPress関連の設定ファイルの改ざんや悪意のあるスクリプトが記載されたファイルをアップロードするといった不正が行われてしまいます。

対策方法

攻撃に対してどのように検知・防御できるかを検討しました。

脆弱性に対する対策として、ソフトウェアのアップデートを行うことが最も効果的です。

しかし、他のソフトウェアとの互換性がなくなってしまう、などの事情でアップデートできない場合も考えられます。そこで今回は、他に行うことができる対策として複数のセキュリティツールで対策を行う、多層防御を実施しました。

対策図_2022-04-08_104452

複数の層で対策をすることで、一か所の防御が破られても他のレイヤでカバーできセキュリティレベルが高まります。

実際に行った対策は以下の通りです。

  1. 改ざん検知
  2. 脆弱性検知・管理
  3. 侵入防御
  4. アクセス制御
  5. ログ監視・通知

実施した各対策について説明していきたいと思います。

1. 改ざん検知

今回の攻撃では、攻撃用のPHPファイルが追加されたり既存のファイルが削除されたりと、攻撃対象サーバ内でのファイルの不審な動きが多かったため、ファイルの変更監視を行うTripwireというツールを使用して改ざん検知および間接的な不正侵入検知を行いました。

Tripwireとはホスト型IDSで、あらかじめ作成したベースラインデータベースと現行システム上のファイル・ディレクトリの状態を照合（整合性チェック）することで、差分検知を行います。また、不正に改ざんされたり意図せず破損してしまったりした場合には元の状態に戻すこともできます。

こちらを使って、実施した攻撃の一つのテストファイルの削除を検知しました。

検知の実施

差分検知には、監査対象および監査ルールを定義するポリシーファイルとベースラインデータベースの作成が必要です。まず、ポリシーファイルを作成します。
デフォルトのポリシーファイルの内容を今回の環境に最適化するため、ファイルを書き換えました。
新しいポリシーファイルを基にベースラインとなるデータベースを作成します。
tripwire -m i -s -c /etc/tripwire/tw.cfg

データベースが作成できたら、攻撃クライアントから攻撃対象サーバ内のテストファイルを削除し、攻撃対象サーバで差分検知をします。
tripwire -m c -s -c /etc/tripwire/tw.cfg
レポートを見てみるとテストファイルがなくなっていることがわかります。➀
また、Modifiedの欄にあるPHPファイルが攻撃クライアントから送られてきたものです。➁（何度も攻撃しているのでModified欄に入っていますが、攻撃初回はAddedの欄に表示されると思います。）

TWレポート_再

今回は手動で差分検知を実施しましたが、cronで設定することで定期的な自動検知が可能となります。
また、ポリシーファイル内でEmailアドレスを設定すれば、ルール違反が発生した際に通知が送信されるので、更に管理が容易になり被害を抑える迅速な対応が可能となるでしょう。

2. 脆弱性検知・管理

日頃から自分が扱う環境に脆弱性が存在するか確認し、パッチを適用しておけば未然に被害を防ぐことができます。今回はFile Managerに潜む脆弱性の検知を行うためFutureVulsというサービスを使いました。

FutureVulsとは、2016年にフューチャーの神戸氏が開発・公開し世界的に話題になった脆弱性検知ツールOSS Vulsの商用版です。
OSS Vulsは管理下のシステムに入っているOSパッケージやライブラリなどのソフトウェア情報を収集し、公開されている脆弱性データベースの情報と関連付け、自システムに内在する脆弱性情報のみをメールやSlack等で関係者に通知できます。OSS Vulsの導入により脆弱性管理を効率化できます。
また、商用版のFutureVulsは、スキャン結果をグラフィカルに表示するダッシュボード機能、検知した脆弱性を漏れなく管理できるチケット管理機能、複数の事業部での脆弱性管理が可能なグループ横断管理機能など、OSS Vulsと比較するとより運用・管理を意識した機能が充実しています。

OSS Vuls および FutureVulsの歴史についてはこちらの記事で詳しく説明されています。

https://future-architect.github.io/articles/20201027/

今回は機能がより充実したFutureVulsを使用しました。

検知の実施

対象のサーバにスキャナをインストールし、スキャンを実施します。
WordPressプラグインの脆弱性ということで、WordPress関連の脆弱性情報を2万件以上持つwpscan.comの脆弱性データベースを利用したWordPressスキャンを行います。

スキャンはスキャナのインストール後5分毎に行われますが、手動でも可能です。今回は手動でスキャンしてみました。
/opt/vuls-saas/vuls-saas.sh
スキャン後しばらくするとポータルサイトにスキャン結果が表示されました。
CVE-2020-25213が検知されていることが確認できます。
FV_ポータルサイト1
管理画面では検知された脆弱性情報がまとめられています。
FV_脆弱性詳細タブ

冒頭で触れましたが、CVE-2020-25213が重大なリスクのある脆弱性としてCISAのKEVに登録されていることが詳細タブからも確認できます。➀
また、どこから攻撃可能なのかを表す攻撃元区分や攻撃の複雑さといったCVSSの評価も表示されます。➁　今回の脆弱性では攻撃の複雑さが「低」となっており、攻撃が容易であるということが推測できます。

脆弱性検知後は管理画面「タスク」タブからチケットによるタスク管理が可能です。対応に応じて各タスクのステータスを変更したりコメントを投稿して他ユーザと情報共有が行えたりします。パッチが適用されたら次回スキャンでステータスが自動で「PATCH_APPLIED」となります。

その他の機能についてはこちらから確認できます。

https://help.vuls.biz/

3. 侵入防御

攻撃方法の箇所で触れましたが、今回の脆弱性の原因はconnector.minimal.phpが外部から実行できてしまう点にありました。なので、攻撃用PHPファイルをconnector.minimal.phpファイルに対してPOSTするアクセスをブロックできれば攻撃を防ぐことができます。攻撃クライアントから送られるパケットの中身を確認し不正なアクセス防御を行うためCloud One Workload Securityを使いました。

Cloud One Workload Securityとは、以前Deep Securityという名称で販売されていたもので、サーバ周りの様々なセキュリティ対策が可能な商用サービスです。今回はWAFと同等の機能である侵入防御機能を利用しましたが、他にも以下の機能が利用可能です。

  • 不正プログラム対策
  • Webレピュテーション
  • アクティビティ監視
  • 変更監視
  • アプリケーションコントロール
  • ファイアウォール
  • セキュリティログ監視

本サービスは、エージェントを対象サーバに導入することで利用でき、ポータルサイトで結果を一括で管理できます。
また、脆弱性検知と管理を行うFutureVulsと連携が可能となっており、FutureVulsで検知した脆弱性情報をもとに関連する侵入防御ポリシーを適用することができます。

防御の実施

まず、攻撃対象サーバ上でCloud Oneのエージェント（ds_agent）のステータスがactiveになっていることを確認します。その後、攻撃クライアントから攻撃を仕掛けると、エラーが出て攻撃対象サーバに接続することができません。

WS_攻撃失敗

Workload Securityのポータルサイトの侵入防御イベントを見てみると、不正なアクセスが検知されブロックしたことが確認できました。➀　イベントを選択し関連する情報を見てみると、CVE-2020-25213の脆弱性を理由に侵入防御されていることがわかります。➁

WS_侵入防御イベント

4. アクセス制御

次に、アクセス制御です。

今回の検証では、攻撃クライアントで入力したコマンドが対象サーバ/var/www/html下のファイルやディレクトリに対して実行されてしまう、というものでした。幸いなことに、Linuxにはリソースへのアクセスが指定された条件通りかどうかを監視・制御するSELinuxという仕組みが存在するため、こちらを使用してアクセス制御を行ってみました。

SELinuxにはaudit logへのログ記録のみが行えるPermissiveモードと、ログの記録に加えて不正アクセスをブロックするEnforcingモードがあります。ログに関しては次章で触れるので、ここではEnforcingモードでブロックをしてみたいと思います。

検知・防御の実施

まず、現在設定されているモードをgetenforceコマンドで確認し、Permissiveであればsetenforce 1でEnforcingモードに切り替えます。

[root@localhost ~]# setenforce 1
[root@localhost ~]# getenforce
Enforcing

これで準備ができたので、攻撃をしていきます。
Enforcing_攻撃失敗確認
ファイルが削除されていないことが確認できました。
SELinuxのEnforcingモードを使うことによって、リモートからのコマンドを防御することができました。

5. ログの監視

前章ではSELinuxのEnforcingモードでルール違反のアクセスブロックを行いました。しかし、実際にはEnforcingモードを有効にすると正常なアクセスも拒否されることを懸念しPermissiveモードに留め、ログ記録のみ行っている環境も多いかと思います。ということで今回は、Permissiveモードで取得したログを攻撃防御に役立てるために、Elasticsearchというサービスを使用してログの集約・検索をしてみました。

出力されたログの監視を行うことで攻撃の早期発見・対応に繋げられ、結果的に被害の拡大を防ぐことができるでしょう。

Elasticsearchとは拡張性に優れた全文検索エンジンのことです。他Elastic製品と組み合わせることで、取得したログを集約、検索、分析、検知、アラート、通知、レポートなどに活用することができます。
Elasticsearchに関する用語の説明やインストール方法はこちらの記事で詳しく解説されています。

https://future-architect.github.io/articles/20200623/

今回は検索を行うElasticsearch、データをグラフィカルに可視化するKibana、特定のログを収集するFilebeat Moduleを使用しaudit logおよびApacheのエラーログの確認を行いました。

検知・防御の実施

setenforce 0 でSELinuxをPermissiveモードにしアクセス可否のログが記録されるようにしておきます。

[root@localhost ~]# setenforce 0
[root@localhost ~]# getenforce
Permissive

攻撃クライアントから攻撃をし、テストファイルが削除されていることを確認後、ブラウザからKibanaへアクセスします。
Analytics → Dashboardと進み、検索から[Filebeat Auditd]Audit Events ECSのタイトルを選択します。

SELinuxによるアクセス制御の動作はAVC(Access-Vector-Cache)というフィールドを見れば確認できます。
avcがdeniedとなっており、アクセス拒否のログが出力されたことがわかります。Permissiveなので実際にアクセスはブロックされずテストファイルは削除されています。
ES_KibanaAVCdenied

ちなみにEnforcingモードの場合は実際にアクセスをブロックするため、audit logに加えApacheのエラーログも出力されます。
Analytics → Dashboardより確認してみると、Apacheのエラーが出ていることがわかります。

ES_Apacheerrorlogcheck

このように、Elasticsearch、Kibana、Filebeat Moduleを導入することによって、確認したいログをダッシュボードで視覚的に表示することができます。

今回はKibanaでのログ確認のみを実施しましたが、章の冒頭で述べたようにPermissiveの設定の場合、不正な挙動の早期発見・対応を行うにはログを監視する必要があります。そこでおすすめなのが、X-Packという拡張機能です。

X-Packはアラート、モニタリング、レポートなどの機能を含むパッケージで、不正行為をリアルタイムに検知しアラート・通知させることができます。
例えば、今回収集した「audit logのavcの値がdeniedだった場合」「Apacheのエラーログが検出された場合」に「アラート・通知する」と設定しておけばすぐに攻撃に気づくことができるでしょう。

さいごに

本記事では、WordPressプラグインの脆弱性への攻撃～対策を実施・解説しました。

上記で示したように、アップデートができない場合でも、複数のツール・サービスを組み合わせて多層防御を行うことでより堅牢なセキュリティ対策が行えるため攻撃被害を軽減する可能性が高まります。例えば、ゼロデイ攻撃を受けた場合、Workload Securityでは未対応のため侵入防御できないことがありますが、ファイルの変更監視を行うTripwireを併せて使っていればゼロデイ攻撃への対応有無に関係なく検知ができ、不正ファイルの削除するなどの対応に繋げられます。

このように、一か所の対策が破られても他のものでカバーでき、甚大な被害を避けられる可能性が高まるため、異なる特徴をもつ対策を併用することをおすすめします。

また、有識者の方々に半年間根気強くサポートしていただけたおかげで、「Linuxって何？」なレベルから、仮想サーバ構築～セキュリティ対策までできるレベルに成長することができました。この記事で、「フューチャーにはチャレンジする者を応援する環境が整っている」ということが伝わっていれば幸いです。

最後までお付き合い頂きありがとうございました！