Zeaburの顧客には、漏えいした認証情報の交換と、プラットフォームの停止前のアプリケーション移行という、2つの緊急対応が求められる。
開発者向けホスティングプラットフォームのZeaburは、10月14～15日に発生した侵入により、321,810アカウントと、320万件を超える環境変数レコードの情報が流出したと公表した。このインシデントは8月に起きた別の侵害に続くもので、Zeaburは12月末までに運営を停止する計画を発表している。
セキュリティチームにとって、懸念はアカウント情報だけにとどまらない。デプロイメントプロバイダーに保存された認証情報によって、攻撃者が他の場所にあるデータベースやクラウドリソース、有料AIサービスにアクセスできる可能性がある。
攻撃者がアクセスした情報
Zeaburの 暫定インシデント報告書は、メールアドレス、ユーザー名、電話番号などのアカウント情報とともに、名前と値を含む環境変数レコード3,218,965件を攻撃者が読み取ったことを確認している。
環境変数にはアプリケーションの設定が保存され、パスワードやAPIキーが含まれる場合がある。レコード数は、320万件の顧客や、利用可能な認証情報が320万件流出したことを意味しない。Zeaburによると、8月以降に顧客自身のサーバーだけに移行された変数はこのデータベースの露出対象外だったが、侵害されたホストから流出する可能性はなお残っていた。
Zeaburはまた、92人のユーザーにサービスを提供するGoogle Cloudの専用サーバー101台へのrootアクセスも確認した。攻撃者が管理するSSHキーが50台のサーバーに追加され、初回の侵入後も再アクセスできる状態になっていた。
アカウント保有者は標的型フィッシングに警戒し、 個人情報が漏えいしていないか確認する必要がある。アプリケーションの所有者は、保存された認証情報でどの外部サービスにアクセスできる可能性があるかも特定する必要がある。
このリスクは、最近の OpenCodeのAPIキー流出と似ている。ある開発者向けプラットフォームから盗まれた認証情報によって、別のプロバイダー上で直接操作が承認される可能性がある。
ローテーションされていない認証情報がアクセスを放置
Zeaburによると、長期間有効な管理者認証情報が平文で保存され、共有クラスターの管理インターフェースがパブリックインターネットからアクセス可能な状態だった。一部の管理者トークンは2024年1月以降ローテーションされておらず、8月の対応でも見落とされていた。
同社は、攻撃者が当初どのようにそれらの認証情報を入手したのかを確認していない。8月の侵害との関連は、依然として仮説の段階だ。
このインシデントは、 ネットワークのセグメンテーションとアクセス制限の重要性を改めて示している。1つのサービスの認証情報を持っているだけで、他のシステムへの無制限の経路が得られてはならない。
12月の停止で移行期限が迫る
Zeaburは 停止の告知で、2つの期限を示した。
- 12月1日：専用サーバーの更新を停止し、各サーバーは個別の契約満了日に停止する。稼働中の共有クラスターサービスは一時停止されるが、顧客は手動で再起動してデータをバックアップできる。
- 12月31日：すべての専用サーバーと共有クラスターの運用を停止する。
顧客は、自身のサーバーの契約満了日を基準に計画を立てる必要がある。同社は、データ削除日、最終エクスポート期限、サポート終了日をまだ確定していない。
セキュリティチームが今すべきこと
直ちに優先すべきなのは、認証情報の無効化、調査、復旧だ。Zeaburは顧客に対し、流出した認証情報を交換し、侵害されたGoogle Cloudサーバーを再構築するよう求めている。
実際の対応には、次の作業を含めるべきだ。
- 発行元プロバイダーで認証情報を無効化する。 露出したAPIキー、クラウドキー、データベースパスワード、署名鍵または暗号化鍵を無効化して交換し、依存するアプリケーションを更新する。環境変数内のデータベースパスワードを変更しても、データベース内部のパスワードは変わらない。
- アクティビティとコストを確認する。 プロバイダーの監査ログ、データベースのアクティビティ、AIサービスの請求を確認し、不審なアクセスや料金がないか調べる。
- 永続化したアクセスを調査する。 SSHキー、アカウント、スケジュールタスク、サービス設定を調べる。パスワードを変更するだけでは、攻撃者が追加したSSHキーは削除されない。
- クリーンな移行を準備する。 置き換えるサービスを再構築・テストする前に、関連するログを保存し、必要なデータをバックアップする。
接続されたサービス全体で復旧を確認する
セキュリティチームは、認証情報の整理と移行を一体の作業として扱うべきだ。アプリケーションを移行すれば可用性は回復できるが、盗まれたキーが元のプロバイダーで有効なまま残る可能性がある。インシデントを終了する前に、古い認証情報が機能しないことと、交換した認証情報が意図した場所でのみ機能することを確認する。
影響を受けた各インテグレーションに担当者を割り当てる。その担当者は、認証情報でアクセスできた範囲、無効化した日時、確認したログ、不審な変更について追加調査が必要かどうかを記録する必要がある。管理者権限、機密データへのアクセス権、大きな支出権限を持つ認証情報を優先する。
復旧作業を、古い環境全体の丸ごとのコピーと混同してはならない。アプリケーションコードと設定を検証し、必要なデータを復元するとともに、不正なアカウントやアクセス手段がワークロードとともに新しい環境へ移行していないことを確認する。
他のホスティングベンダーを評価する組織にとって、この事例は具体的な問いを示している。プロバイダーは、インシデントに関係したすべての認証情報を特定し、無効化が完了したことを証明し、顧客への影響を調査するのに十分なログを提供できるか。こうした回答によって、セキュリティ保証だけでそのサービスへの信頼を再開できるかどうかを判断できる。
詳しくは、 ConnectWise Cloud Backupの侵害を参照。この事例は、侵害されたベンダー認証情報を無効化しても、不正な変更や永続化したアクセスを見つけるために管理者がなお作業を行う必要がある理由を示している。