フォームの送信内容やネットショップの注文を管理画面で確かめるのは、サイトを運営していればごく日常の作業です。WordPressのセキュリティ企業Patchstackが10月6日に公開した報告では、その日常の作業そのものを入口にして、管理画面からは見えない管理者アカウントを作り込む攻撃が観測されています。入口は特定のプラグインの不具合ですが、手口はプラグインを問わず使い回せる作りで、保守に関わる立場として押さえておきたい内容でした。
送られてきたデータが管理者の画面で動き出す
報告によると、今回使われたのは保存型のクロスサイトスクリプティング(stored XSS)と呼ばれる種類の脆弱性です。ログインしていない誰でも送れるデータの中にスクリプトを紛れ込ませておき、それがデータベースに保存され、あとで管理者が画面に表示したときに実行される、という流れです。
確認されたのは二つのプラグインです。ひとつはWooCommerce向けのセット販売プラグイン「WPC Product Bundles for WooCommerce」の8.6.6以前で、数量の欄に数字で始まる値を入れると検証を通ってしまい、続けて書いたタグが注文の情報として残る不具合でした。もうひとつは有効インストール数が50万を超える「Ninja Forms」の3.15.3以前で、複数行のテキスト欄に送られた内容が、旧来の送信内容の編集画面で適切にエスケープされずに表示されていました。前者は10月4日、後者は10月5日に悪用が観測され、どちらも同じ外部サーバーから同じJavaScriptを読み込ませていたことから、ひとつの攻撃活動とみられています。
厄介なのは、管理者にあやしいリンクを踏ませる必要がない点です。仕事として必ず開く画面を開いた瞬間に、その管理者の権限でスクリプトが動きます。
ログイン中の権限を借りて裏口を何重にも置く
読み込まれたスクリプトは、管理者のCookieを盗むわけではありません。同じサイトの中で動いているため、管理画面へのリクエストには自動的にログイン中の情報が付きます。スクリプトは管理画面のページを読み込んで操作に必要なワンタイムの値(nonce)を拾い、プラグインの追加や新しい管理者の作成を、正規の機能を使って管理者本人の代わりに実行していきます。CookieにHttpOnlyを付けていても、この流れは防げないと報告は指摘しています。
そうして置かれるのは、サムネイルを扱う普通のプラグインに見せかけた偽物です。WordPressから読み込まれたときには何もせず、そのファイルへ直接アクセスしたときだけ、認証のないファイル管理の画面として動きます。さらに別のファイルが、次のような仕掛けを加えます。
- support や maintenance のような、ありがちな名前の管理者アカウントを作る
- must-useプラグイン(mu-plugins)を置いて、そのアカウントをユーザー一覧からも人数の表示からも消す
- 特定の文字列を付けてログイン画面を開くと、いちばん古い管理者としてログインできる裏口のURLを用意する
見えている管理者、見えない管理者、裏口のURL、ファイル管理の画面と、戻り道が四つ残ります。管理画面から確認できるのは最初のひとつだけで、もとの脆弱なプラグインや偽のプラグインを消しても、残りの三つは閉じないとされています。置かれたファイルは更新日時をWordPressの中でいちばん古いファイルに合わせてあり、最近変わったファイルを探すいつもの手順にも引っかかりません。
ダッシュボードの外から確かめる
対応としては、まずWPC Product Bundles for WooCommerceを8.6.7以降、Ninja Formsを3.15.4以降に更新することが挙げられています。そのうえで、すでにスクリプトが動いた可能性があるサイトでは、管理画面の表示を信じずに確かめる必要があります。
報告で勧められているのは、データベースから管理者権限を持つユーザーを直接一覧にして、ユーザー一覧の画面に出ているアカウントと見比べる方法です。画面に出ていないのにデータベースにいるアカウントがあれば、隠されていると考えられます。あわせて、プラグインの画面には出てこない wp-content/mu-plugins の中身、wp-content/plugins に wp-smart-thumbnails というフォルダがないか、オプションの表に fz_emer で始まる項目がないかを見ていきます。日付ではなく中身で見ることが要点です。
痕跡が見つかった場合は、不正なアカウントやファイルを消すだけでなく、管理者のパスワードと認証用のソルト(salt)を入れ替えることも求められています。裏口のURLはいちばん古い管理者として入る仕組みなので、そのアカウントは直接盗まれていなくても漏れたものとして扱う、というのが報告の考え方です。
入口より奥の片付けを想定しておく
今回の報告が示しているのは、攻撃する側が特定のプラグインに縛られていないということです。管理者の画面でスクリプトを動かせる保存型XSSであれば、どのプラグインの不具合からでも同じ仕掛けを流し込めます。二つの脆弱性は9月22日に公表されており、攻撃に使われたドメインはその約十日後に登録されていました。公表から悪用までの間隔は、思っているよりも短いと見ておいたほうがよさそうです。
中小企業のサイトでは、問い合わせフォームや簡単なネットショップの機能をプラグインでまかなうことが多く、送信内容を管理画面で開くのは担当者の毎日の仕事です。プラグインの更新を早めに回すことに加えて、管理者アカウントの一覧をデータベースの側から定期的に照らし合わせる、mu-pluginsの中身を把握しておく、といった点検を保守の手順に入れておくと、こうした見えない仕掛けにも気づきやすくなります。管理画面に出ている情報だけで安心しない姿勢が、これからの保守ではいっそう大事になりそうです。
