隔離の突破が内部認証へつながった
Railwayの説明では、攻撃者は10月20日6時50分（UTC）にビルド基盤の調査を始め、7時28分に未知の欠陥を悪用した。複数顧客のビルドを同じ仮想マシンで動かしながら分離する仕組みから一部抜け出し、ホスト側のファイルを読める状態になった。
そこで得た内部認証情報は、完成したビルドのイメージを保存先へ送るためのものだった。最初から顧客の秘密情報を復号できる万能鍵ではない。しかし攻撃者は内部のビルド履歴353件とRailwayのソースコードを読み、次に使える経路を探した。異常なAPI呼び出しが警報を出したのは13時58分で、最初の突破から約6時間半後である。[1]
次の入口はOIDCと呼ばれる短時間の認証を発行する仕組みの信頼設定だった。攻撃者は本来許可されない条件でも認証を受け取り、クラウド内部の認証情報を取得した。さらに、顧客の処理を各サーバーへ割り振る機械に入り、環境変数の復号に使える長期の認証情報へ到達した。
最大10万件は流出確定数ではない
攻撃者は10月21日4時7分から5時21分にかけて、暗号化された環境変数をデータベースから取得した。4時42分から7時15分には入手した認証情報で一部を復号した。検索条件はAI事業者の鍵を優先し、変数を多く持つ顧客も狙っていたという。クラウド、データベース、決済サービスの認証情報に合う検索もあった。[1]
Railwayは復号された可能性がある範囲を最大1.85％、約10万ワークスペースとした。ログで特定できるのは対象になった環境であり、個々の変数が実際に盗まれたかまでは示さない。約10万件は影響の上限であり、10万件すべての鍵が流出した確定値ではない。
同社はフォレンジック調査から、認証情報を盗まれた危険性が高い顧客へメールを送った。ただし、取得された別のデータがあっても、攻撃時に使われた復号用の認証情報は無効化済みで、後から復号できないと説明する。対象通知の有無と、実際に発生した不正利用の有無は同じ判定ではない。
一方で、GitHubのOAuthトークンや持ち込みのAIエージェント鍵など、連携アカウントのトークンは1852人分が復号対象に含まれた。Railwayは全件をリセットして本人へ通知した。顧客のGitリポジトリやデータベースへ攻撃者が入った証拠は確認していないとしているが、環境変数から別サービスへ移動できる可能性は残る。
AIの鍵は短時間で現金化される
環境変数の侵害が大きな請求へ直結したのは、AIのAPIキーが利用量に応じて課金されるからである。攻撃者は盗んだ鍵を自ら使うだけでなく、非正規の中継サービスで再販売できる。Railwayは不正利用額を約74万ドルと推計し、事業者へ返金を求め、応じない分は自社残高から補う方針を示した。[1]
セキュリティ企業Wizは、10月に少なくとも9つのAI開発基盤が侵害を公表したとまとめた。各事件を結ぶ一つの欠陥が確認されたわけではないが、保存された環境変数、とくにAIアクセス用の鍵を探す傾向は共通する。Wizが追跡した別の2事例では、不正なAI呼び出しが約80万回と約170万回に達し、定価換算の利用額は合計10万ドル超だった。これらの数値はRailway固有の被害ではない。[2]
BleepingComputerもRailwayの報告を照合した。同媒体は、74万ドルが不正利用の推計であり、最大10万ワークスペースは確定流出数ではないと報じた。[3]
利用者が今確認する三つの範囲
Railwayは事件当時、全環境変数と認証情報の交換を利用者へ求めた。今回の最終報告を受けた確認は、通知メールの有無だけで区切らない。秘密情報は利用先ごとに止める必要がある。
- 鍵を交換する：AI、クラウド、データベース、決済、コンテナレジストリの鍵を失効させ、新しい値に替える。古い鍵を残したまま新しい鍵を追加するだけでは止まらない。
- 履歴と請求を見る：10月20日以降のAPI呼び出し元、利用モデル、地域、時間帯、請求額を確認する。通常利用と区別できる保存期間も確かめる。
- 権限を狭める：開発、検証、本番で鍵を分け、読み取りだけで済む処理に管理権限を渡さない。上限額や異常利用の通知も設定する。
連携トークンをRailway側がリセットしていても、自社が環境変数として保存した第三者サービスの鍵まで自動で替わるとは限らない。秘密情報の一覧を作り、発行元で失効を確認する作業が必要だ。
基盤側の改善だけでは請求を止めきれない
Railwayはビルド基盤を別世代へ切り替え、旧世代と計算機、保存領域、キャッシュを共有しない設計にした。内部認証の権限縮小、利用者セッションの無効化、監視強化も実施した。攻撃者が顧客データへ触れられたのは10月21日9時25分までで、その後の成功した侵入は確認していないという。[1]
ただし、基盤が修復されても、外部へ持ち出された鍵は発行元で失効するまで使える。PaaSを選ぶ企業は稼働率だけでなく、秘密情報を環境ごとに分離できるか、復号権限がどの機械に届くか、侵害後に対象を特定できるログが残るかを見るべきである。
開発速度を優先して一つの鍵を複数サービスで共有すると、交換範囲と停止時間が広がる。今回の事件は環境変数を安全な保管庫そのものとみなさず、漏れる前提で権限、期限、利用上限、交換手順を設計する必要を示した。
まとめ
- Railwayではビルド隔離の欠陥と認証の信頼設定が連鎖し、最大約10万ワークスペースの環境変数が復号された可能性がある。
- 不正なAI利用料は約74万ドルに達した。復旧済みという表示だけでは、持ち出された鍵の失効や請求確認は終わらない。
- 利用者は鍵の交換、利用履歴と請求の確認、環境別の権限分割を行い、次回の交換を短時間で実施できる状態にする必要がある。
読者のコメント (0)
コメントを残す