セキュリティ事故のBlack October、UpdraftPlusは更新だけでは直らない

出典: Black October: what got hacked and how to stay safe

事故の話が続くと、全部すぐ直さなきゃ、と焦りますよね。でも、Danielさんが最初に置いたのは、事故の一覧ではありませんでした。直す前の約束。そこから話が始まります。

動画は、10月に相次いだ事故を Black October と名づけ、パッチを当ててしっかり安全になるところまで手伝う、と切り出します。

Danielさん（動画 0:18〜）

We call it Black October. And I’m here to help you of course to patch everything up and so we can be full on safe.

私たちはこれを Black October と呼んでいる。そして私は、全部パッチを当てて、しっかり安全になれるよう手伝う。

シリーズの名前は The Patch Forecast。月の事故をかみ砕いて説明し、項目ごとに、自分のAIエージェントに貼るプロンプトが付く作りです。

使い方は3手。予報を見て、次のスライドのプロンプトをコピーし、Claude Code などの自分のAIエージェントに貼る、という順番です。

予報の札は3種類。STORM は攻撃が起きている、SHOWERS は修正済みで更新はそのうちでよい、LOCAL は使っている人だけ、という分け方になっています。

続いて、全部のプロンプトに共通する約束が、画面にもはっきり出てきます。

Danielさん（動画 3:33〜）

So rules, report first and change nothing until you say yes.

ルールは、まず報告し、あなたがyesと言うまで何も変えない。

ここで出てくるのは、貼る前に全文を読んで確かめる、というひと手間。セキュリティの話だから、という理由です。

私がまず目を留めたのは、約束が事故の一覧より先に置かれている点です。事故が続く月ほど、直す前の手順が効いてきます。焦る時こそ、順番。

AIに頼むと、仕事はとにかく速いですよね？ ただ、その速さは、ずれた直しにも同じように働きます。気づけば知らない所まで書き換わっている、そんな場面も起こりえます。

だから、AIの役目は、まず見たことを話すところまで。直すかどうかの yes は、人の手に残します。

報告が先で、直すのは後。この順番は、AIに任せる時の段取りとして筋が通っている、と私は見ています。

貼る前に全文を読む、というひと手間も同じ向きです。何を頼んでいるのかを、頼む側が先に知っておくための読み込み。ここが抜けると、yes を握っていても、何に yes と言っているのか分からなくなりますよね。

約束の一行。それだけで、AIの速さが人の判断を追い越さない形に変わります。地味ですが、効く一行です！

読まずに貼ったプロンプトが、知らない所を書き換えていたら、どうしますか？

最新版に更新したから大丈夫、と思いたくなりますよね。でも、Danielさんの話は、更新しても残るものがある、というところから始まります。残るのは何か。

話の始まりは、WordPress の人気のバックアップのプラグイン UpdraftPlus が、10月18日にハッキングされた件です。

Danielさん（動画 1:47〜）

UpdraftPlus, a popular backup plugin, was hacked on October 18. Attackers stole the keys that control customer sites and use them to add fake plugins. Updating alone won’t fix this.

人気のバックアップのプラグイン UpdraftPlus が、10月18日にハッキングされた。攻撃者は、顧客のサイトを操作する鍵を盗み、それを使って偽のプラグインを加えている。更新だけでは、これは直らない。

盗まれたのは、UpdraftCentral という管理用の鍵。プラグインを更新しても、盗まれた鍵は消えずに残るという説明です。

WordPress 用のプロンプトが確かめる項目は5点。最新の版か、接続鍵の一覧、Must-Use を含む全プラグイン、10月18日以降に作られた管理者、データベースの _sync_token です。

画面には、偽のプラグインの例として、Site Health Cache という名前が出てきます。

疑わしいプラグインは、直さずに消す方針。順番は、先に鍵、次にプラグイン。パスワードと鍵の全文は表示させない、という念の入れ方です。

提供元の発表では、不正アクセスの確認は10月17日から18日の週末。報道では、盗まれた鍵で、管理者の追加と偽プラグインの設置が起きました。

修正版は、通常版が 1.26.13 以上、Premium 版が 2.26.13 以上。一方、動画の画面が目安にしているのは 1.26.12 以上です。

実は私も、UpdraftPlus と UpdraftCentral の侵害を伝える X の投稿を見かけて、AIに見せて確認を頼みました。

AIの答えは、投稿と提供元の発表を照らしたうえでの一言。更新や接続鍵の削除だけでは、すでに置かれた裏口は消えない、というものでした。

そのうえで、私のサイトに被害があったかどうかは、まだ確認していない、と分けて答えています。

で、私は続けて、点検に回してほしいと頼みました。ところが、ここで落とし穴。AIが私のサイトを調べ始める入口が、再開してよいかの確認待ちで止まっていたんです。

点検の依頼は、まだ送られていませんでした。頼んだつもりの私と、届いていない依頼。10月21日以降に点検を行った記録は、探しても見つかっていません。

更新することと、確かめ終えること。動画の、更新しても鍵は残る、という話は、更新と確認が別物だという所を突いています。

通知を読んで、AIに確かめてもらっただけでは、確かめ終えたことにはなりません。被害があったかどうかは、別の作業で見て初めて分かる話。

頼んだ、と、済んだ、を一つの行にまとめてしまうと、あとで読み返した時に、終わったように見えてしまいますよね？

私なら、頼んだことと終わったことを分けて、点検の記録が残るまで、済みと言いません。

WordPress を最新にしたら、それで安心でしょうか？ 実は、その下で動いている言語は別の話。サイトの土台にあたる PHP にも、10月は大きな欠陥が出ていました。

PHP は、WordPress が動いている言語です。そこにバグが2つあり、見知らぬ人がログインなしで Web サーバーを乗っ取れる、とDanielさんは切り出します。

Danielさん（動画 3:57〜）

So two bugs in PHP, the language WordPress runs on. They let strangers take over a web server without logging in.

PHP、つまり WordPress が動いている言語に、バグが2つある。見知らぬ人が、ログインなしで Web サーバーを乗っ取れる。

修正が出たのは10月21日。攻撃者はすでに試していた、と続けます。多くのホスティング会社は対応済み、という見立ても添えていました。

プロンプトの画面に並ぶのは、系列ごとの安全な版。たとえば 8.5 系なら 8.5.12 以上です。8.1 以下は公式の修正が無い、と画面と説明にあります。

続いて確かめるのは、ホスティングの種類と php -v の答え。実際にサイトを動かしている PHP-FPM の版と、更新の手順も見ます。Cloudflare を使っているなら、オレンジの雲がオンかどうかも。

php.net の発表では、10月21日に、ログイン不要で遠隔から処理を実行できる重大な欠陥2件が公表されました。完全な緩和策は無く、更新だけが安全、という案内です。

8.1 以下は、PHP プロジェクトとしては更新の対象外。ただ、保守ベンダーが修正を移植して出す場合があり、ソースから最小限の修正を移した物も出ています。

ここで押さえたいのは、WordPress の更新と、サーバーの PHP の更新は別、という点です。php -v の答えと、実際に動いている版を分けて見るのは、そのずれを埋めるため。

私は23日の21時に、PHP の重大な欠陥の注意喚起を、AIに読み取りだけで確かめてもらいました。注意喚起は本物でした。

私は4つのサイトを持っていて、そのうち公開ページが応答したのは3サイト。ただ、PHP の版は、公開ページからは分からないんです。

サーバー会社は、レンタルサーバーの PHP 5.6 から 8.5 のすべてに、今回の修正を適用済みと案内していました。

でも、各サイトの実際の PHP の版と契約の種類を、管理画面で照合する作業は、23日の夜の時点で途中のまま。サーバーの設定は、変えていません。

正直、ここが一番ずれやすい所なんです。サーバー会社の案内を読んだだけで、自分のサイトまで済んだ気になりがちですよね？

提供元全体の発表と、自分のサイトの版の照合は、別の行に書く話。WordPress を更新しただけでは、サーバーの PHP が直ったとは言えません。

レンタルサーバーで php -v を打てない時は、管理画面の PHP の設定の欄で版を見られます。そこだけは、見ておいてくださいね。

案内は提供元の話。版の照合は、自分の行。

手間が減る部品ほど、中身を見ずに入れてしまうこと、ありますよね？ 次の話は、入れる前に疑う、という順番から始まります。開発の部品と、Python の証明書の2本立て。

開発用の追加部品が、パスワードを盗む版にすり替えられました。別の攻撃では、偽の security という名前の補助ファイルが、GitHub の多数のプロジェクトに仕込まれた、とDanielさんは話します。

Danielさん（動画 6:05〜）

So that’s you. If your agent keep code on GitHub or install add-ons from npm, be extremely careful.

それはあなたのことだ。あなたのエージェントが GitHub にコードを置いたり、npm から追加の部品を入れたりしているなら、十分に気をつけて。

ここで出てくるプロンプトは、ロックファイルの中から、名指しされた2つの版を探すもの。部品の名前と版は、画面に出ています。

続いて、.github/workflows に覚えのないファイルが無いかを見ます。とくに security-audit.yml。npm のインストールスクリプトが、既定でオフになっているかも確かめます。

替える対象のトークンは、名前だけを表示させて、値は出させません。

報道とセキュリティ会社の報告では、その2つの版は毒入り。偽のセキュリティ用ワークフローで秘密情報を盗む手口も、報告されています。

Python の話は、また別の筋です。証明書を出す会社 eMudhra の鍵が弱く、うち1つは4という数字だった、という説明。ブラウザは、すでに遮断しています。

ただ、Python 系の道具は、その証明書を信頼してしまうんですよね。攻撃の確認は無し。pip と certifi の更新で直り、パスワードの変更は要りません。

名前と中身は、別物。security という名前を見ると、つい安心してしまいますよね？

9月17日、X に、入れると自律型になる、という GitHub のプロジェクトの投稿がありました。私はそれを、丸ごとは入れませんでした。

まず、AIが作者と実際の数字を一次情報で確認。私が選んだのは、走査だけ試す、でした。

走査の道具も、作者が一致することと、インストールスクリプトが無いことを確かめてから入れました。

入れた先は、作業用の隔離したフォルダ。スクリプトを動かさない設定で、読み取りだけを走らせました。

設定を変える前に、私が求めたのは影響の説明。それを読んでから、適用を選びました。

で、ここで言い切れるのは、話題の道具ほど丸ごとは入れない、ということです。作者とインストールスクリプトを確かめて、隔離した場所で、読み取りだけで試す順番。

Python の証明書のほうは、攻撃が確認されていない話。慌てずに、更新で済ませれば十分です。

疑うのは、入れる前。

鍵が漏れた、と聞くと、手元の鍵を全部替えたくなりますよね。でも、ここでDanielさんが先に置くのは、替える人と替えない人をどう分けるか、という問いです。

LiteLLM は、AIのモデルとアプリをつなぐ道具です。悪意のある版が、10月21日に2時間、公開されていました。

Danielさん（動画 9:42〜）

A bad version was online for two hours on October 21st. It stole passwords and keys as soon as it ran.

悪意のある版が、10月21日に2時間、公開されていた。動いた途端に、パスワードと鍵を盗んだ。

当てはまるのは、その頃に pip か Docker で入れた人だけ。報道では、公開から隔離までは約1時間40分でした。

続いて Railway。アプリを動かす場所です。侵入者が、顧客の保存済みのパスワードや鍵を読んだ可能性があり、Railway は全ユーザーに変更を求めました。

Danielさん本人はどうしたか？自分の鍵を全部、中身ごと入れ替えた、と話します。

Danielさん（動画 10:20〜）

I have rotated all my keys and everything inside in full.

私は自分の鍵を全部、中身ごと入れ替えた。

Railway の10月21日の公式発表では、暗号化して保存した環境変数に触れられ、一部は復号された内容も取られた可能性があります。

最後は Plex Media Server。古い版がいま攻撃されていて、更新して、公開インターネットから外す、という説明です。

同じ、鍵を替えて、の話でも、出どころが違うんですよね。LiteLLM は当てはまる人だけ。Railway は会社が全員に求めた話。

LiteLLM や Railway とは別の種類の出来事として、鍵が漏れた時のことを1つ。

実は7月22日に、自分の Gemini の汎用の API キーで、私の作業と一致しない利用が見つかりました。名前なし。IP と参照元の制限もなし。

同じ日に、そのキーを隔離しました。旧キーの隔離と削除、そして Google への報告。ここまでは進めました。

新しい鍵への入れ替えは、済んだ記録が見つからない状態です。

AIに任せたのは、証拠の整理と文面づくりまで。秘密値も、外部への送信も、設定の変更も、決める権限は私が持ちました。

私はこう見ます。替える前に、まず自分が当てはまるか。当てはまらないのに全部の鍵を替えると、替え漏れや、止まる仕組みが増えるだけです。

替えた、と言えるのは、新しい鍵に替え終えて、古い鍵が使えなくなったと見届けた時だけ。隔離した、削除した、とは別の行なんですよね。

手元の鍵のうち、通知を受けたものはどれですか？そこから順番が決まります。

私なら、当てはまるかを先に見て、通知を受けた鍵から順に替え、替え終えるまでは、替えた、と言いません。

大げさな見出しが続く月は、全部がつながって起きているように見えますよね。Danielさんの大げさな噂を確かめるコーナーは、それを一つずつ原因に戻すところから入ります。

大げさな噂を確かめるコーナーの画面は、ネットで見た噂と、実際を、左右に並べた表です。

PHP、Node、GitLab、Python の話は、別々の原因の、別々の出来事が、同じ週に重なっただけ、という説明です。

Danielさん（動画 11:34〜）

So separate events with separate causes that happened in the same week.

つまり、別々の原因の、別々の出来事が、同じ週に重なっただけだ。

たとえば、Python が大緊急事態、という噂。正体は証明書会社のミスで、更新すれば直ります。Linux の重大な脆弱性2件は実在しますが、影響を受ける部分は、ほとんどのパソコンでオフです。

画面には、全部入りの1本のプロンプトも出てきます。使っているものをエージェントが判断して、赤・黄・緑で報告を返す形。

締めくくりは4つの習慣。自動更新をオンにする、頼んだものだけ入れる、鍵は漏れた時だけ変える、まず報告して次に直す、の順です。

Danielさん（動画 12:23〜）

So keep the auto updates on for now. Install only what you asked for.

だから、今は自動更新をオンにしておく。頼んだものだけを入れる。

Danielさん（動画 12:33〜）

And report first and fix second with your agent.

そして、エージェントとは、報告が先、直すのは後。

次の予告は、10月27日に Chrome が emSign の証明書の1つを信頼しなくなる件。Cloudflare や Let’s Encrypt を使っているサイトは問題ない、と話します。

Danielさんの締めは、怖がらなくていい、きちんとパッチを当てれば大丈夫、というメッセージでした。

警報の見出しも、原因と直し方に戻すと、落ち着いて見られるんですよね。見出しの大きさと、直す手間の大きさは別物。

自動更新をオンにする、の習慣の所で、私の環境で起きたことを1つ。

9月19日から4日間、Claude Code の自動更新が毎時失敗していました。

原因は、npm が作った退避フォルダの残骸が1つ。そのせいで更新が止まり、失敗のたびに古い版へ戻っていました。

失敗の知らせは、送り先が未設定で飛ばされて、私には届きませんでした。

9月23日に残骸を退避して更新。6つのコマンドの更新は、毎日1本のスクリプトで回す形にまとめました。

自動更新は、オンにして終わりではありません。動いているかを見るところまでで、ひと組。

失敗の知らせが自分に届かなければ、オンにしていても、オフと同じです。

スマホのアプリで考えると、分かりやすいかな。更新が止まっていても知らせが来なければ、古い版のまま使い続けることになりますよね？

手元の自動更新は、失敗した時に、その知らせが届く形になっているでしょうか？

Black October の動画は、報告が先の約束から入り、UpdraftPlus は更新だけでは直らないこと、PHP はサーバー側の版で見ることを順に示します。

続いて、開発の部品と証明書。入れる前に疑い、pip と certifi の更新で直る物を見分ける流れでした。

鍵を替えるのは、当てはまる人と通知を受けた人。最後は見せかけの警報を原因に戻し、4つの習慣で締めくくります。

私は、通知を読んだだけで済みにせず、頼んだことと終わったことを分けて残したいんです。報告を見てから直す、この順番を先に決めておくことですよね。