Zeabur情報流出、32万1,810アカウントに影響：利用者が取るべき対応

Zeaburの利用者は、漏えいした認証情報の入れ替えと、プラットフォーム終了前のアプリケーション移行という、2つの急務に直面しています。

開発者向けホスティングプラットフォームのZeaburは、10月14〜15日に不正アクセスを受け、32万1,810アカウントの情報と320万件を超える環境変数レコードが流出したと公表しました。同社は8月にも別の情報流出を起こしており、12月末までにサービスの運営を終了する方針も明らかにしています。

セキュリティ担当者にとって、懸念はアカウント情報だけにとどまりません。デプロイ事業者に預けた認証情報があれば、攻撃者は外部のデータベースやクラウドリソース、有料のAIサービスにアクセスできる可能性があります。

攻撃者がアクセスした情報

Zeaburの インシデント速報によると、攻撃者は3,218,965件の環境変数レコード（名前と値を含む）を読み取りました。あわせて、メールアドレス、ユーザー名、電話番号といったアカウント情報も閲覧しています。

環境変数にはアプリケーションの設定が保存されており、パスワードやAPIキーが含まれることもあります。ただし、レコード数が、320万の顧客や使用可能な認証情報が漏えいしたことを意味するわけではありません。Zeaburによると、8月以降に顧客自身のサーバーへ完全に移行した変数は、今回のデータベースからの流出の対象外です。ただし、サーバー自体が侵害された場合は、それらも漏えいするおそれがあります。

Zeaburはさらに、92人のユーザーにサービスを提供していた101台のGoogle Cloud専用サーバーで、root権限が奪われたことも確認しました。このうち50台には攻撃者管理のSSH鍵が追加されており、最初の侵入後も再び入り込める状態になっていました。

アカウント保有者は、標的型フィッシングに警戒するとともに、 個人情報が流出していないかを確認する対策を取る必要があります。アプリケーションの所有者も、保存していた認証情報でどの外部サービスにアクセスできるかを洗い出すべきです。

このリスクは、最近の 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の情報流出は、侵害されたベンダーの認証情報を無効化しても、管理者には不正な変更や永続的なアクセスを突き止める作業が残ることを示しています。