公表までの流れ

この脆弱性は、Wordfenceのバグバウンティ（脆弱性報奨金）制度を通じて研究者Jack Taylor氏が報告し、5,761ドルの報奨金が支払われています。「見つけた人が黙って売る」のではなく、報告して直させる正規のルートを通った案件です。

SQLインジェクションを一言でいうと

サイトのデータベースは「注文書のとおりに動く倉庫」のようなものです。SQLインジェクションは、その注文書の空欄に、注文書そのものを書き換える一文を紛れ込ませる攻撃です。「商品名：みかん」と書くべき欄に「みかん。ついでに倉庫の中身を全部教えて」と書き、システムがそれを命令として読んでしまう。仕組みの基本はSQLインジェクションの解説記事で詳しく扱っています。

「危ないプラグインは、とりあえず止めておけばいい」——これは多くの場合に正しい対処です。プラグインが動いていなければ、そのプラグインの穴は突かれません。ところが今回は、その常識が半分しか通用しません。

理由は、この攻撃が二段構え（セカンドオーダー）だからです。ふつうのSQLインジェクションは、攻撃者がデータを送り込んだ瞬間にその場で発火します。今回は違います。攻撃者が送り込むのは、ただの文字列です。その時点では何も起きません。データベースの中で、じっと待っています。

たとえるなら、郵便受けに時限式の手紙を入れられた状態です。手紙はポストの中でおとなしくしています。あなたがそれを取り出して読み上げたとき、はじめて仕掛けが動く。プラグインを無効化するのは「しばらく郵便物を読まない」ことに相当します。読まないあいだは安全ですが、手紙自体はポストに残ったままです。

公開されている解析にもとづく、攻撃の全体像です。専門用語は都度かみ砕きます。

ステップ1：攻撃者が、公開記事にトラックバックを送る

トラックバックとは、「あなたの記事を、私の記事から紹介しました」と自動で知らせるWordPressの古い機能です。ブログ同士がリンクし合っていた時代の名残で、多くのサイトでは今も受け付けたままになっています。送るのにログインは要りません。だからこそ、攻撃者にとっては誰でも使える「投入口」になります。

ステップ2：送られた文字列は、そのまま眠る

この時点では何も起きません。データベースの中に、ちょっと変わった記号（引用符やバックスラッシュ）を含む文字列があるだけです。サイトは普通に動き続けます。気づく手がかりが、ほとんどありません。これがこの攻撃の嫌なところです。

ステップ3：管理者がバックアップを復元（インポート）する

サーバーを移す、テスト環境を本番に反映する、障害から戻す——理由は何でも構いません。このプラグインが復元処理を始めると、バックアップの中身に対してURLやデータベースの接頭辞の一括置換をかけます。引っ越し先で正しく動くようにするための、必要な処理です。

ステップ4：置換処理で「文字列の囲い」が壊れる

ここが脆弱性の本体です。データベースへの命令文では、文字列を引用符で囲って「これはただの文字ですよ」と示します。ところがこの置換処理は、末尾がバックスラッシュで終わる値などを正しく扱えませんでした。その結果、囲いが途中で外れ、続く文字が「ただの文字」ではなく「命令」として読まれてしまう。攻撃者が数か月前に置いた文字列が、ここで初めて命令に変わります。

ステップ5：合言葉が公開コメントに書き出され、乗っ取りへ

実行される命令が狙うのは、ai1wm_secret_keyという値です。これはこのプラグインが「正規の依頼かどうか」を確かめるために使う合言葉で、本来は外に出てはいけません。攻撃者はこれを誰でも読める公開コメントの中に書き出させ、あとからコメント一覧のAPIを開いて回収します。

合言葉さえ手に入れば、あとはログインは要りません。攻撃者は自分で用意した細工済みのバックアップファイルを、正規の依頼のふりをして流し込めます。その中に、WordPressが起動時に必ず読み込む場所（mu-plugins）へ置かれるPHPファイルを仕込んでおけば、次にページが開かれた瞬間に攻撃者のコードが動きます。ここまで来ると、管理者権限を持った第三者がサイトの中にいるのと同じ状態です。

手順1：いま入っているバージョンを確認する

WordPressの管理画面で「プラグイン」→「インストール済みプラグイン」を開き、All-in-One WP Migration and Backupを探します。プラグイン名の下に「バージョン 7.1xx」と表示されています。ここが7.110以上なら対応済み、7.109以下なら要更新です。無効化してあるプラグインも、この一覧には表示されます。

手順2：更新する

「更新可能」と出ていれば「今すぐ更新」を押すだけです。表示が出ない場合は、画面上部の「更新」メニューから最新情報を再取得してください。無効化したままでも更新はできます。「有効化しないと更新できない」という制限はないので、不安な人は無効のまま更新して、あとから有効化して構いません。

手順3：更新後にバージョンを見直す

表示が7.110以上になっていれば、今回の脆弱性については対応完了です。ここまでで、タイプCの人（前掲の振り分け表）はすべて終わりです。

すぐに更新できない事情がある場合

「本番サイトで、テストしてからでないと更新できない」という現場もあります。その場合の暫定策は次のとおりですが、いずれも時間稼ぎであって解決ではないことを前提にしてください。

なお、ここまで確認して何も見つからなかったとしても、それは「侵害されていないことの証明」ではありません。あくまで「分かりやすい痕跡は見当たらなかった」という意味です。企業サイトや個人情報を扱うサイトで不安が残る場合は、専門業者の調査を検討してください。

一般則1：使っていないプラグインは「無効化」ではなく「削除」する

無効化したプラグインは、動いていないだけでファイルはサーバーに残っています。今回のように「無効化しても仕掛けは残る」ケースもあれば、無効なプラグインのファイルが直接呼び出されて悪用された事例も過去にあります。何より、いつか誰かが有効化します。1年使っていないプラグインは、思い切って削除するほうが安全です。必要になったら、また入れればいい。

一般則2：「復元」は作業ではなく、リスクのある操作だと考える

バックアップからの復元は、心理的には「安全な側に戻す」行為です。ところが技術的には、過去のある時点のデータを、いまのサイトに丸ごと注ぎ込む操作です。その中に何が入っているかは、取った時点では誰も検査していません。だからこそ、

一般則3：使っていない「受け口」は閉じる

今回の入口になったトラックバックは、ほとんどのサイトが使っていないのに開いたままの機能の典型です。「使っていない＝無害」ではありません。攻撃者から見れば、それはログインせずにデータを置ける場所です。今回は復元処理がその置き場所を読みましたが、別のプラグインが別の形で読む可能性は常にあります。