開発

Softaculousが33時間BGPハイジャック被害 認証情報の再設定要請

Softaculousが33時間にわたるBGPハイジャック被害を公表。Hetzner経由の経路乗っ取りで更新サーバーが偽装され、Let's Encrypt証明書も不正取得された。

13分で読める SINGULISM 編集チームが確認・編集

Softaculousが33時間BGPハイジャック被害 認証情報の再設定要請
Photo from Unsplash

ホスティング業界向けソフトウェアを手がけるSoftaculousと、同社が提供する仮想化管理パネルVirtualizorが、33時間に及ぶBGPハイジャックの被害を受けたことが明らかになった。同社は顧客に対し、認証情報の再設定とサーバー上の不審なパッケージの確認を呼びかけている。The Register の Connor Jones の報道では、攻撃者が経路情報を偽装し、一部のトラフィックを自らのサーバーへ誘導したと伝えられている。

今回の事案は、インターネットの経路制御そのものを悪用した点で、単一の脆弱性を突く攻撃とは性質が異なる。インフラ層への介入により、正規の証明書取得まで可能になったことは、運用者が前提としてきた信頼の連鎖が崩れ得ることを示した。

33時間に及ぶ経路乗っ取りの経緯

Softaculousの説明によれば、最初の異常は2026年8月28日20時57分(UTC)ごろに発生した。無関係なネットワークが、Softaculousが利用するHetznerのIPアドレスブロックに対する経路を不正に広報し始めた。Hetznerはドイツに拠点を置くホスティング事業者で、Softaculousの上流インフラを担っている。

影響を受けたアドレスは、Virtualizorのソフトウェア更新用エンドポイントや、Softaculousの顧客・課金サイトを含む複数のシステムで使われていた。攻撃者はHetznerが通常広報する範囲よりも詳細な(より長いプレフィックスの)IP範囲を広報した。BGPの経路選択では、より詳細な経路が優先されるため、広報を受け入れたネットワークではトラフィックが攻撃者側へ流れることになった。

同社の時系列によれば、不正な経路は当初「それを受信するほぼすべてのインターネット上の観測点で受け入れられた」状態にあった。ただし継続的に維持されたのではなく、繰り返し不安定な挙動を示したという。

a number of Softaculous systems

Softaculousは8月29日8時50分(UTC)ごろにHetznerへ問題を報告した。Hetznerは同じ詳細なアドレス範囲を自ら広報することで対抗し、約11時間にわたり迂回はほぼゼロまで抑えられた。しかし同日20時00分(UTC)ごろに不正な広報が再び広く受け入れられ、約10時間続く第二波が始まった。不正な経路は8月30日5時50分から6時10分(UTC)の間に撤回され、その後世界的に正常な経路が復旧した。

より詳細な経路を用いた乗っ取りの手口

今回の手法は、BGPの仕様に根ざした古典的な経路乗っ取りである。攻撃者は正規の事業者が広報する集約された経路よりも、細かく分割した経路を広報した。インターネット上のルーターは最長一致で転送先を決めるため、細かい経路が優先される。このため、攻撃者の広報がフィルタリングされずに伝播した範囲では、正規のSoftaculous宛てトラフィックが攻撃者のサーバーへ向かった。

Softaculousによれば、いずれかの波が継続している間、特定のサーバーが攻撃者の経路に引き込まれる確率は約72パーセントに達したと推定されている。この数値は、観測点ごとの経路の受け入れ状況に基づく推計であり、すべての利用者が一様に影響を受けたわけではない。経路が不安定に変動したことも、影響のばらつきを生む要因になったと見られる。

この種の攻撃は、高度な脆弱性を必要としない。BGP自体が経路情報の正当性を厳密に検証する仕組みを当初から備えていないため、広報の内容が誤っていても、受け手側で拒否されなければ伝播する。近年はRPKI(Resource Public Key Infrastructure)による経路起点検証などの対策が進むが、普及と運用は依然として途上にある。

TLS証明書の不正取得による影響

特筆すべき点は、攻撃者がLet’s Encryptから正規のTLS証明書を取得することに成功したことだ。The Register の報道によれば、認証局によるドメイン所有確認のための自動検証通信もハイジャック経由で攻撃者のサーバーへ流れたため、所有確認がを通じてしたという。

これにより、影響を受けた接続では、攻撃者のサーバーが正規の証明書を提示できた。ブラウザや更新クライアントは証明書の警告を表示せず、利用者側で異常に気づく機会が失われた。経路の乗っ取りと証明書の不正取得が組み合わさることで、検知の難易度は大幅に高まった。

この問題は、ドメイン検証がネットワーク経路の健全性に依存していることを浮き彫りにする。DNSやHTTPを用いた検証は、経路が乗っ取られた場合に検証者自身が攻撃者と通信してしまう危険を抱える。複数の視点から検証を行うマルチパースペクティブ検証などの緩和策が導入されつつあるが、今回のように広範な観測点で不正経路が受け入れられた場合、その効果にも限界が生じ得る。

被害範囲とベンダーが求める対応

Softaculousは、少数のインストール環境でマルウェアが配信されたことを確認している。具体的なマルウェアの種類や感染後の挙動について詳細は公表されていないが、同社はすべての顧客に対し、認証情報の再設定とサーバー上の不審なパッケージの精査を求めている。

Virtualizorは仮想プライベートサーバーの展開と管理に使われる制御パネルであり、ホスティング事業者や管理者が広く利用している。更新エンドポイントが乗っ取られた場合、正規の更新に見せかけた不正なコードが配布される恐れがある。Softaculousの顧客・課金サイトが影響を受けたことも、認証情報や支払い情報の露出リスクを高める。

同社は影響を受けた可能性のある顧客への通知を進めると同時に、サーバー側での整合性検証を促している。具体的には、インストール済みパッケージのハッシュ検証、最近変更されたファイルの監査、特権アカウントのパスワードとAPIキーの再発行、外部への不審な通信の有無の確認が求められる。バックアップからの復元を検討する場合も、汚染された状態のバックアップを再導入しないよう注意が必要だ。

インフラの信頼性に関する長期的な課題としては、Microsoft Secure Boot、13年間脆弱なままで指摘されたように、正当な仕組みが長期間にわたり検証不十分なまま運用される危険がある。今回のBGPハイジャックも、経路検証の不在が長く放置されてきた結果として捉えることができる。

BGPが抱える構造的な脆弱性

BGPは1980年代に設計された経路制御プロトコルであり、相互に信頼するネットワーク間で経路情報を交換することを前提としている。当初は悪意ある広報を想定しておらず、経路の正当性を暗号学的に保証する機能を持たない。このため、誤った広報や意図的な乗っ取りが世界規模で伝播する余地が残る。

対策としてRPKIによるROA(Route Origin Authorization)検証や、BGPsecによる経路の署名検証、IRRデータベースに基づくフィルタリングなどが提案・実装されている。Hetznerのような大手事業者がROAを登録し、上流で検証を徹底すれば、今回のような詳細な経路の不正広報は拒否される可能性が高まる。ただし、検証を有効化していないネットワークが一つでも経路を中継すれば、影響は広がり得る。

また、証明書の透明性やCTログの監視も、今回のような不正取得の早期発見に役立つ可能性がある。Let’s Encryptの証明書はCTログに記録されるため、所有者が監視していれば想定外の発行を検知できる。経路監視サービスと組み合わせることで、異常な広報と証明書発行の相関を捉える運用も考えられる。

再発防止に向けた運用と検証の課題

今回の事案では、Hetznerが同じ詳細な経路を広報し返すことで一時的に被害を抑えた。この手法は対症療法として有効だが、根本的な解決ではない。攻撃者がさらに詳細な経路を広報する競争に発展すれば、経路表の肥大化や不安定化を招く恐れがある。恒久的な対策は、検証に基づく拒否を広く普及させることにある。

ホスティング事業者やソフトウェアベンダーにとっても、更新基盤の保護は喫緊の課題だ。更新サーバーへの通信を単一の経路や単一の検証方法に依存させない設計が求められる。例えば、更新パッケージへの署名とクライアント側での署名検証を必須化すれば、経路が乗っ取られても不正なコードの実行を防げる。証明書のピンニングや、複数経路での到達性確認も有効な層になり得る。

利用者側では、今回のような広域的な乗っ取りを個別に検知することは難しい。ベンダーが提供する整合性検証ツールや、外部からの監視情報を活用することが現実的な対応になる。業界全体としては、経路監視データの共有と、異常検知時の迅速な連携体制の整備が重要性を増している。アプリケーション統合の動きが進む中でも、Copilot統合へ、Microsoftがアプリ統合発表で見られるような利便性向上と、基盤層の安全性確保は両立させなければならない。

知的財産や契約を巡る紛争が技術基盤の信頼に影響を与える事例も増えている。Round Hill、SunoとAnthropicに10億ドル超訴訟が示すように、サービスの継続性は技術だけでなく法的・制度的な要因にも左右される。経路の安全性も、技術的対策と運用ポリシーの双方で支える必要がある。

編集部の見解

短期的には、ホスティング業界で更新サーバーの真正性検証を強化する動きが広がると見る。SoftaculousとVirtualizorの利用者は今後数か月、認証情報の再設定やパッケージ検証を迫られる。ベンダー側も署名付き更新の徹底や、CTログ監視の導入を急ぐと評価する。Hetznerを含む上流事業者では、RPKI検証の厳格化や詳細経路のフィルタリングが再点検されると見られる。 長期的には、BGPの信頼モデルそのものへの圧力が強まると考える。RPKIやマルチパースペクティブ検証は普及途上にあり、今回のように広範な観測点で不正経路が受け入れられた事実は、部分的な導入では不十分であることを示した。1〜3年のスパンでは、経路検証を前提とした運用が業界標準になると見る。利用者にとっては、更新基盤が署名検証を前提とするか否かが、サービス選定の基準になると言えそうだ。 編集部からの問いとして、経路と証明書という二つの信頼の連鎖が同時に破られたとき、誰が被害を検知し通知する責任を負うのかという論点がある。認証局は経路の健全性をどこまで考慮すべきなのか。

参考

よくある質問

BGPハイジャックとは何か
BGPはインターネットで経路情報を交換する仕組みだ。BGPハイジャックは、攻撃者が本来の持ち主ではないIPアドレス範囲の経路を不正に広報し、トラフィックを自らのサーバーへ誘導する攻撃を指す。より詳細な経路が優先される特性を悪用する手口が典型的である。
SoftaculousとVirtualizorの利用者は何をすべきか
ベンダーは認証情報の再設定とサーバー上の不審なパッケージの確認を求めている。管理者パスワードやAPIキーの再発行、インストール済みパッケージのハッシュ検証、最近更新されたファイルや外部通信の監査を実施することが推奨される。不明な変更があれば、汚染されていないバックアップからの復元を検討する必要がある。
なぜLet's Encryptの証明書が不正に取得されたのか
Let's Encryptのドメイン所有確認は、検証用通信が正規のサーバーに到達することを前提とする。今回はBGPハイジャックにより検証通信自体が攻撃者のサーバーへ流れたため、攻撃者が所有者として誤認され、正規の証明書が発行された。これにより警告なしに偽サーバーへ接続される状態が生じた。
出典: The Register

コメント

← トップへ戻る