要約

  • 不正な162.55.80.0/24は、経路末尾にHetznerのAS24940を残し、/24まで許すROAの下でRPKI Validとなったうえ、攻撃者による有効なTLS証明書の取得につながった。
  • VirtualizorはRIPE RISの368ピアから経路伝播を復元したが、攻撃者が返した更新応答は自社ログを通らず、影響を受けた導入先の確定リストを作れないと説明する。
  • 必要なのは、要求した版、署名済みマニフェスト、パッケージのダイジェスト、受理した鍵、検証結果、導入またはロールバック結果を結ぶ、プライバシーに配慮した端末側レシートだ。

インシデント報告では、最も大きな数字が被害規模のように読まれがちだ。今回は368である。Virtualizorによれば、調査対象となったRIPE Routing Information Serviceの368ピアすべてが、期間中のどこかでハイジャック経路を保持した。これは経路の広がりを示す強い観測だが、顧客数でも、更新要求数でも、ダウンロード完了数でも、侵害台数でもない。

この区別は言葉の細部ではない。BGPコレクターはAS経路を観測する。認証局はドメイン検証と証明書発行を記録する。攻撃者のサーバーは迂回してきた要求を見る。Virtualizorを動かす各サーバーは、受け取った更新を検証し、拒否し、導入する。その四つの記録が同じ母集団を持たないことこそ、今回の証拠上の問題である。

LACNICは2026年9月10日、Kentikの分析をスペイン語で掲載した。これは地域コミュニティにとって現在性のある題材だが、LACNICが被害システムを運用していたという意味ではない。掲載ページも、意見は執筆者のものでLACNICの見解とは限らないと明記する。したがって、LACNICは事例を掲載し、Kentikは経路を分析し、Virtualizorは製品側の影響を説明した、と分けて読む必要がある。

RPKI Validが保証した範囲

8月28日20時57分（UTC）ごろ、162.55.80.0/24が世界の経路表に現れた。AS pathの末尾は6204 62390 24940だった。/24はHetznerが通常広報する162.55.0.0/16より具体的であり、双方を受け取ったルーターは最長一致によって新しい/24を選びやすい。

攻撃の要点は、見かけ上の起点をAS24940のままにしたことだ。対象アドレスを覆うROAはAS24940を認め、最大/24まで許可していた。起点検証はその組み合わせをValidと判定できる。だが、AS62390が正当な上流か、直前の接続関係が真実かまでは署名しない。検証は仕様通りに働き、攻撃者は仕様の外側を使った。

RFC 9319は、この「起点を偽装したサブプレフィックス・ハイジャック」を説明している。実際には広告していない細分化プレフィックスまでROAが覆うと、攻撃者は許可済みASを経路末尾に置いて空いた範囲を利用できる。同RFCが可能な限り最小ROAを勧めるのは、この余白を減らすためだ。ただし最小ROAもAS path全体の暗号学的な真正性を与えるものではない。

よって「RPKI Valid」は安全マークではなく、質問を限定した回答である。プレフィックス長と起点ASが公開済み承認に合う、と述べるだけだ。上流の許可、到達サーバーの所有者、TLSの相手、配布ファイルの正当性までは証明しない。この限界を示すことはRPKIへの批判ではなく、起点検証を過大販売しないための条件である。

Virtualizorは、発生期間を8月28日20時57分ごろから30日6時10分ごろまでとし、約11時間の静かな時間を挟んだ二つの活動波を報告している。経路取り下げは約1万600件に達した。10分ごとの復元値は連続映像ではなく標本である。8時間ごとのRIBダンプに合う時刻の値が比較的確かで、激しいフラップの間は途中の標本が可視ピアを少なく数えることもある、と注意している。

「368のうち368」には時間軸がある。全ピアが少なくとも一度見たのであって、全ピアが同時に見たわけではない。活動波のピークでは、完全な368ピア集合のおよそ72％に経路が見えたとされる。これも通信量ではなく、各観測ピアの最良経路を数えたトポロジー上の代理値だ。大規模トランジットも小規模参加者も一票なので、顧客影響への変換には使えない。

正しい証明書が誤った終点を自然に見せた

迂回された通信には、認証局のドメイン管理確認も含まれた。Virtualizorによれば、攻撃者はSoftaculous系の複数ドメインについて技術的に有効なTLS証明書を取得し、更新配布先もその範囲に入った。迂回されたクライアントは証明書警告なしに暗号化接続を完了できた。TLSはBGPが届けた終点との通信を保護したが、本来の終点を選び直してはくれなかった。

複数視点による発行確認、MPICはこの攻撃を難しくするための制度である。単一地点だけでドメイン管理を確認せず、離れたネットワーク視点の一致を求める。CA/Browser Forumの現行要件では、該当する確認について2026年6月15日から少なくとも四つの遠隔視点が必要で、同意する視点は少なくとも二つのRIRサービス地域にまたがる。Let’s Encryptも、検証経路をハイジャックまたは転送できれば単一点は欺かれると説明してきた。

それでも証明書が出たからといって、MPICが無意味になったわけではない。Kentikの指摘は限定的だ。競合する正規/24がない状態で、より具体的な不正経路が広く伝播し、複数地点が同じ攻撃者サーバーを見た。多視点は局所的な嘘を不一致として検出するが、嘘が広域の共通像になれば定足数も誤る。厳密なROA、異常経路監視、pathを意識した制御、ネットワーク的に分散した証明書確認は、代替品ではなく重ねる防御である。

正規サーバーのログに不正サーバーの応答は残らない

Virtualizorは、悪意ある更新パッケージが少数、あるいは「一握り」の導入先に配布されたと確認した。その一方で、影響サーバーの確定リストは作れないという。攻撃者のシステムが応答し、その通信がVirtualizor自身のログへ届かなかったからだ。

Webログは、そのWebサーバーを訪れた要求の記録にすぎない。正常サーバーに行がない場合、要求がなかった可能性と、別サーバーが回答した可能性を区別できない。経路ハイジャックが成功するほど、正規側の中央ログは取引から外れる。空白は無事故の証明ではなく、観測不能の印にもなる。

通常の更新運用は、この盲点を大きくした。Virtualizorの文書では、自動更新を止めない限り24時間ごとに更新を確認し、管理画面やコマンドラインからも更新を開始できる。活動時間中にどの導入先が確認したか、その要求が迂回中だったか、ダウンロードが完了したか、パッケージが受理・実行されたかは別の質問である。経路ピアの表には答えがなく、正規サーバーログにも攻撃者の応答はない。

さらに同社は、当時の更新クライアントがパッケージを暗号学的に検証していなかったと説明し、すべてのパッケージにコード署名を用意するとした。これは必須の予防策だ。特権的なアップデーターは、署名済みメタデータ、ダイジェスト、版、配布チャネル、承認鍵を確認し、失敗したら導入を止めなければならない。TLSだけをコードの真正性証明にしてはならない。

ただし署名と事故範囲の特定は違う。署名は未承認パッケージを将来拒否する。端末が過去に何をしたかを自動的に報告するわけではない。署名導入後でも、要求版、受信ダイジェスト、受理鍵、検証失敗、導入完了、隔離、ロールバックを端末ごとに追える証拠が要る。

更新判断の現場でレシートを書く

各更新試行は、端末に小さな耐改ざん記録を残すべきだ。配布チャネル、要求版、要求時刻、署名済みマニフェストのダイジェスト、パッケージのダイジェスト、受理した鍵または鍵の閾値、検証結果、拒否・隔離・導入・失敗・ロールバックの結果を記す。後日の鍵失効、事故通知、修正版も元の記録を参照できるようにする。

顧客一覧を公開する必要はない。レシートは運用者の管理下に置き、機器やフリートを仮名で表し、事故時に必要最小限だけ開示できる。ベンダーは任意の受領確認を返してもよい。ブラインド化または仮名化した証明を受け、時刻付き確認を返す。大手事業者は自社内で集計し、小規模運用者はサポート依頼時に一台分を輸出する。プライバシーは設計条件であり、無記録の理由ではない。

このレシートは二つの台帳を結ぶ。ベンダーのリリース台帳は、どのマニフェスト、パッケージ、鍵が承認済みかを示す。端末台帳は、その機械がどれを要求し、何を検証し、どう判断したかを示す。経路とWeb終点を攻撃者が握っても署名鍵が無ければ、拒否が残る。後から鍵が失効すれば、それを受理した端末を探せる。検証器に欠陥が見つかれば、ダイジェストから対象パッケージを絞れる。

そして用語を五段階に分けられる。RISピアが経路を見たのはネットワーク露出。迂回時間中の要求は配布機会。完了ダウンロードは取得。成功した導入は実行。悪意あるサービスなどの侵害指標は影響証拠である。各段階に別の分母と確度がある。「影響あり」で一括すれば、分からない部分を隠すだけだ。

現在の対応を評価したうえで残る不足

Virtualizorは、悪意あるパッケージの配布を公表し、侵害指標を示し、API資格情報の更新と制限、アクセス監査、証拠保全を求めた。証明書の失効を依頼し、公開経路データから事象を復元し、パッケージ署名も約束した。KentikとLACNICは厳密なROAと監視を説明し、起点検証が経路全体を保証するとは書かなかった。いずれも実質的な対応である。

批判すべきは、攻撃者のログから得られない確実性をベンダーに要求することではない。更新を決める場所に、後から運べる記録を残す制度がなかった点だ。攻撃者が応答した瞬間、中央ログは取引に参加していない。独立した証拠を持てるのは導入先だけだった。対象が分からない以上、全運用者に確認を促すのは正しい。同時に、それはレシート不在の作業コストでもある。

次の成熟した事後報告では、三つの台帳を横に置けるはずだ。経路台帳は誰がいつどのpathを見たか、リリース台帳はどの版・パッケージ・鍵が正規だったか、導入台帳は各クライアントがどう判断したかを示す。互いに代替できないが、結合すれば全顧客への警報を、根拠ある修復対象へ狭められる。

参照資料