朝、メールボックスを開いたら、自分のドメインから自分宛てに届いているメールがあった。
件名は、データベースのバックアップが完了したという内容。添付には、圧縮されたSQLファイルが付いている。
送信元は、長く運営してきた自分のサイトだった。ただ、そのサイトは更新をほぼ止めている。リニューアルするつもりで、何度も先送りにしている状態だ。
心当たりがない。
自動バックアップの設定は、たしかに昔いじった記憶がある。でも、その後で解除したはずだった。実際、ここしばらくこの種のメールは届いていなかった。
それが、何の前触れもなく届いた。
最初に浮かんだのは、乗っ取りだった
更新を止めているサイトは、狙われやすい。本体もプラグインも古いまま放置されるので、すでに公開されている脆弱性がそのまま残っている。
しかも、管理画面を乗っ取った攻撃者がバックアップ系のプラグインを仕込み、データベースを丸ごと外部へ送信させる、という手口は実際にある。
届いたメールは、まさにその形をしていた。データベースの中身が、添付ファイルとして飛んでいる。
正直、ひやりとした。
ただ、慌てて管理画面へログインする前に、まずメールそのものを調べることにした。中身が本物かどうかも分からない段階で、リンクを踏んだりパスワードを入れたりするのは順番が違う気がした。
メールヘッダーを見たら、偽装ではなさそうだった
調べたのは、こういうところだ。
送信元の認証（SPFなど）が通っているか。実際にどのサーバーから出ているか。メールを組み立てたプログラムは何か。添付ファイルの名前は規則的か。
結果は、どれも自分のサーバーと矛盾しなかった。契約しているレンタルサーバーのホスト名がそのまま出ていたし、送信に使われていたのはWordPressが標準で使うメール送信ライブラリだった。
決め手になったのは、添付ファイル名だった。
ファイル名の先頭に、数字の羅列が入っている。これはUNIX時間と呼ばれる形式の日時で、変換するとメール本文に書かれた日時と秒単位で一致した。
外から送られた偽物が、ここまで整合するとは考えにくい。
それに、送信先は外部のアドレスではなく、自分のドメイン内のアドレスだった。データを盗む目的なら、攻撃者は自分の受け取れる場所へ送るはずだ。
この時点で、「メール自体が偽装されている」という最初の仮説はほぼ消えた。
では、なぜ今になって動いたのか
ここからが、まだ分かっていない部分だ。
いちばんありそうなのは、設定を解除したつもりで解除できていなかった、という話だ。バックアップの間隔がもともと長く設定されていて、その周期がたまたま巡ってきただけ、という可能性もある。
ただ、これだと「しばらく届いていなかった」という感覚とうまく噛み合わない。自分の記憶違いなのか、どこかで一度止まって、また動き出したのか。
正規の通知である可能性は高い。それでも、「解除したはずの設定が理由不明で動いた」ことと「更新を止めた古いサイトである」ことが重なっているのは、無視できない気がしている。
だから、判断はここで一度止めた。安全だと結論を出すには、まだ見ていないものが多すぎる。
調べる順番を先に決めた
確認したいことを並べてみた。
管理画面のユーザー一覧に、覚えのない管理者アカウントがないか。バックアップの設定内容が、自分が過去に触った状態と変わっていないか。入れた覚えのないプラグインが増えていないか。サーバー側の定期実行の設定や、アクセスの記録に不自然なものがないか。受信用アドレスの転送設定が書き換えられていないか。
パスワードの変更や本体の更新は、この確認と並行してやる。もし不審な点が一つでも出てきたら、リニューアル作業より先にサイトを一時停止して掃除する。
順番を決めておくのは、慌てないためでもある。
不安なときほど、片っ端から触りたくなる。でも、先にログを見ずに設定を上書きしてしまうと、何が起きていたのか分からなくなる。
AIに大量の作業を任せるようになってからも、同じことを何度か考えた。実行そのものは任せられても、どこで止めて何を人間が判断するかは、先に決めておかないと危ない。
今回のメールヘッダーの解析も、実際にはAIに手伝ってもらった。ただ、管理画面にログインして確認する部分は自分でやるしかない。
そのAIをどう使い分けているかは、別の記事に書いている。
調べているうちに、もっと危ない設定に気づいた
面白かったのは、乗っ取りかどうかを調べているうちに、別の問題が見えてきたことだ。
仮にこのメールが完全に正規のものだったとしても、データベースの中身をメールで送るという設定自体が、そもそも危ない。
メールの経路は、必ずしも暗号化されているとは限らない。受信箱が一度破られれば、データベースが丸ごと持っていかれる。バックアップを取ること自体は正しいのに、その届け方でリスクを作っている。
つまり、攻撃を受けていなかったとしても、この設定は止めた方がいい。
侵入されたかどうかを心配していたら、侵入されていなくても危ない場所が出てきた。これは予想していなかった。
放置していたこと自体が原因なのだと思う
このサイトは、作り直すつもりで止めていた。修理して延命するより、一度作り直した方が早いと判断した経緯もある。
判断としては、今も間違っていないと思っている。ただ、「作り直す予定だから」と言いながら、古いまま公開し続けていたことは別の問題だった。
アクセスは今も少しある。動いている以上、それは放置ではなく運用だ。
今回のメールは、結果的に「そこにまだ生きているサイトがある」ことを思い出させた。攻撃の通知ではなかったかもしれないが、通知としては十分だった。
まだ結論は出ていない
管理画面はこれから見る。何も出てこない可能性も高いと思っている。
それでも、今回はっきりしたことが一つある。
「多分大丈夫」と「確認した」は違う。メールの形式が正しくても、それは送信元が正しいという話であって、管理画面が無事だという保証ではない。
急いで安心してしまわないように、順番を決めて一つずつ見ていく。
そして、たとえ何も出てこなかったとしても、データベースをメールで送る設定だけは先に止めるつもりだ。
