1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

wp2shell で WordPress サイトを乗っ取られて、あせりまくった話をする。

1
Posted at

はじめに

WordPress では、CVE-2026-60137(GHSA-fpp7-x2x2-2mjf)及びCVE-2026-63030(GHSA-ff9f-jf42-662q)の脆弱性が修正されました。(……)影響を受けるウェブサイトでは、直ちに更新することが推奨されています。

(……)

これらの 2 つの脆弱性を組み合わせは「wp2shell」と呼ばれ、標準構成において、管理者権限などを要さないで、攻撃者が遠隔でのコード実行に至る可能性が指摘されています。


これにやられましたよ

情報、見てたんですけどね。

「あんまり関係ないかー」と思って、スルーしてましたよ。

どこの誰が、1 日 10 PV もない超弱小な個人ブログを狙うのかと。

X でかるーくほかのひとの様子をうかがってみたのですが、じっさいに乗っ取られたってひとはあまりいなかった印象。(そりゃそうか)

自分に悪意が向けられるとは思わなかったですね。当事者意識がなかったというか。まぁ、今回の場合は無差別なアタックなんでしょうけど。(無差別的な悪意も怖いか)


この記事の内容
・WordPress の個人ブログサイトにログインできなくなりました。勝手に管理者パスワードを変更されたようです。

・あせりまくりました。AI の悠長な回答にもイライラしました。状態の保存?犯人の特定?そんなのどうでもいい早く復旧したい。

・現在は復旧済み。メールアドレスが生きていたので、パスワードリセット → バックアップデータの復元をしました。

・足りなかったのは当事者意識。「自分のサイトがやられたら?」なんて考えたことなかった。有事のシミュレーションって大事なんだなぁと思いました。


あとは時系列順にざっくばらんと。


身に覚えのないパスワード変更通知

サイトが乗っ取られたのは 8/3 の月曜日の11時頃(らしい)。

こんなメールが届いていることに、日付がかわったあとのベッドで気がつきました。



「……。パスワードの変更なんてした覚えないけどな…」というのと、嫌な予感がしたので眠たい目をこすってデスクに移動。

お気に入りからブログの管理者ページをひらいてお祈りログイン。



んあー……マジかー

この時点で眠気は完全にふきとぶ。


そして大パニック。

どどど、どうすればいいんだこれ。


生成AI に聞いてみる

困ったときは AI に相談です。

あせった私が「サイトの管理センターに入れなくなった。不正ログインで管理者のパスワードが変更された」と相談します。

チャッピーは「それは災難でしたね」からの、「近年 Wordpress は不正ログインが増加傾向にあり…」などと、心底どうでもいいことばかりを言ってきます。


「どうしたらいい?」と聞いても、

「では、詳細な状況を教えてください」と言われてしまいました。

(こっちの指示もザツいのは分かってるけど)「そうじゃなくてこういうときにどうすればいいのか端的に欲しいんだよ!」とイライラしてきます。

こっちは早くなんとかしたいんだよ!

いま(午前)1時も回ってて、明日も仕事なんだぞ!


─── で、いろいろ対話してパスワードリセットに辿り着いたのは 20 分後。

「すぐに思いつきそう」なアクションなんですけどね。あせってるとホントに思いつかないものでして、「火災のときはエレベーターを使用しないでください」と同じですよ。

そんな非常時に、気も動転した私が、「エレベータをつかうな」とだけいわれて、すぐに階段をつかうことを思いつけるわけないんですよね。

「火災のときは階段を使って避難してください」と書いてほしい。


幸いなことに、メールアドレスは生きていました。

パスワードのリセットも成功しました。


管理者アカウントが増産されていた

パスワードが分かったので、いざ管理センターにログイン。


まずはアカウントの確認……

って、なんじゃこりゃーーーーーーーーーー!



知らないユーザーが4人も作成されていました。

wp2shell.local ?「wp2shell」ってどこかで…

あ、脆弱性の……


で、バージョン確認。WordPress 6.9.2 か……

だからか。ダメじゃん。


ととと、とりあえず管理者アカウントを消さないと、またいつログインされるか分からない。─── ということで管理者を削除。


--


侵入されてたのは確定だけど、次は何をすればいいのだろう。


チャッピーに聞いてみます。引きつづきよろしくお願いいたします。

Chat GPT「バックドアが仕掛けられている可能性があります。不審な php ファイルがないか確認してください。」


(。´・ω・) ????????


バックドア…?php ファイルってなに、どうやって見るの?

と、思ったことをそのまま私が聞くわけです。

Chat GPT「不正アクセスでは、いきなりリストアするより、可能なら先に証拠保全 → 調査 → 復旧の順にするのが基本です。サーバーの管理センターから確認してみましょう。」


まっっっったお前は…!!!

アクセスログなんて見てどうするんだ。

ログの見かた分からんし、どうせ見ても分からんし。

ああもうそんなのはどーでもいいからとにかくサイトを安全な状態に戻したいんだ!

「誰が攻撃してきた」とか、まったく興味ないんだ!


─── で、いろいろ対話して各種ログイン情報の変更が必要であることに辿り着いたのは 30 分後。そして、サイトに関わるすべてのログイン情報のパスワードを変更。

・WordPress管理者アカウント
・レンタルサーバーのログイン情報
・FTP/SFTP情報
・データベース接続情報
・メールアカウント


最終的にはバックアップデータの復元

これで全部解決したー!と思いたかったのですが……そういうわけにもいかず。チャッピーに散々「バックドアがー!」とか脅されてるもんで、不安になってるんですよね。


管理センターに接続して不審な php ファイルがないか確認したり、データベースに接続して直近変更があったファイルがないか確認しましたよ。

でもさ、ぜーんぜん大丈夫か分かんねーんだよ。


「不審な php ファイルがないか」って言われても、どれが不審で、どれが不審じゃないか分からないし。

直近変更ファイルをフィルターする管理シェルのコマンドとか用意されても、シェルの使い方わからないし、そんな機能あったんだって感じ。

そもそもさ、サイトのファイル構成なんて、レンタルサーバーごとに違うんじゃないの?うちは ConoHa だけど、それってキミに教えてないよね。(文句ばっか)

とはいっても、やっぱりバックドア(?)とか、はあんまり分からないけど、何か仕掛けられてたらイヤだなーと思うわけですよ。


結局かんがえて、「侵入される前にリストアするのがよくね?」ってなりましたよ。なんだかんだ、バックアップからの復元がカンタンな正解な気がして、こんなことをしましたよ。

①侵入される前のバックアップデータに復元
②管理者ページから不要な管理者ユーザーを削除。
③バージョンも戻るので、すぐにバージョンアップ。
④各種管理センターのパスワードを変更。
⑤1週間ほど、勝手に管理者が追加されないか監視。


準備してないとあせるしかない

こんな感じで、あせりまくって AI にザツい指示を出しては「そうじゃないー(泣)」って言ってました。意味ないプロンプト投げるくらい精神やられてました。

AI に「落ち着けよ」となだめられる始末。

→ パスワードのタイポで入れなかっただけ。


で、今となっては、私があせり散らかさないといけなかった理由は、当事者意識がなかったから、だと思ったわけです。こんな意識が足りなかったなと。

①攻撃されないように注意しているか。
②攻撃されたらどうするか。


①攻撃されないように注意しているか

通常のセキュリティ対策をするのは当たり前で、追加で「情報をキャッチできるか?」と、「それを自分事だと捉えてアクションできるか?」になると思います。

(生成AI のおかげで脆弱性祭り)


今回、IPA の情報は見ていたんですよ。

「WordPress に脆弱性がある」は知っていて……、でも「ふーん」で終わっていました。


これは全然ダメ。


「情報を知っている」だけではダメなんですよね。(当たり前か)

自分の環境に当てはめないと、行動にはつながらないっちゅーことです。


あと、wp2shell は、アクセス数の多い有名サイトだけを狙うものでもないんだとか。機械的に探されて攻撃されるものらしいです。

つまり、そもそも「こんな弱小ブログを、誰が狙うんだよ」という考えも間違い。

(当事者意識があれば、そんな楽観的ではいられないはず。)


②攻撃されたらどうするか

もうひとつ。

「攻撃されたらどうするか」をまったく考えていませんでした。


これが一番にキツかった。

そんな状態で AI に相談しても、そりゃあ AI も困るってもんです。


サイトが乗っ取られたときに、

「まずパスワードを変更する」とか、「バックアップデータから復元する」とか、そういうことをひとつでも決めていたら、こんなにテンパることはなかったでしょう。

一番いいのは、「まず何をする?」手順を、事前に作っておくことでしょうか。

それが正解かはとにかく、「何をするか」を有事になって考えるよりは絶対にいい。


有事のシミュレーションは大事

今回の件で、「攻撃されないようにする」ことと「攻撃されたときにどうするか」をセットで考えておいたほうがいい、と思うようになりました。

セキュリティ対策というと、「攻撃されない」ための話になりがちです。

・最新版にアップデートしましょう

・強いパスワードを設定しましょう

・多要素認証を設定しましょう


それでも攻撃されることはあります。


そのときに、「どどど、どうすればいいんだこれ」となるのではなく、「まずこれをやる」と言えるようにしておくことも、セキュリティ対策のひとつなんじゃないかなー。

会社のPCがランサムウェアに感染してたとき

会社のPCで標的型攻撃メールを踏んでしまったとき。

取引先に、間違えて社外秘のファイルを送ってしまったとき。

─── いろいろ並べてみると、「こういうときは、どうするのがいいんだっけ?」というものも出てきます。


有事に動けるようにしておこうねってことと、

システムのアップデートはしたほうがいいよっていうお話でした。


以上。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?