クラウドホスティングプロバイダーのRailwayに侵入した攻撃者が、盗んだ顧客のAPIキーを使って約74万ドル相当の不正なAI利用料を発生させたことを、同社が11月10日のインシデント報告書で明らかにした。Railwayは、AIプロバイダーが不正利用分を返金しない場合、影響を受けた顧客に返金するとしている。
攻撃は10月20日から21日にかけて発生し、侵入者が暗号化された顧客のシークレットにアクセスし、その一部を復号するために必要な認証情報を取得できる、複数のインフラ上の弱点が悪用された。Railwayは、最大10万のワークスペースで環境変数が流出した可能性があると見積もっている。
同社の調査によると、攻撃者は特にAIプロバイダーの認証情報を狙っていた。Railwayは、それらがAIモデルの蒸留に利用または転売されることを意図したものとみている。疑われる流通ネットワークと、関与した人物の身元は、依然として確認されていない。
攻撃者は複数の弱点を悪用して顧客のシークレットに到達
Railwayのインシデント報告書によると、侵入は10月20日午前7時28分（UTC）に始まった。攻撃者は同社のビルド用インフラに存在する未知の脆弱性を悪用した。
この欠陥によりファイルシステムの隔離を部分的に突破でき、Railwayのビルドサービスが使用する内部認証情報が露出した。
攻撃者はその後、この認証情報を使って保存されたビルド履歴とRailwayの内部ソースコードのコピーを取得した。コードを調べてさらなる侵入経路を探した結果、OpenID Connect（OIDC）の信頼関係が誤って設定されていることを発見した。
10月21日までに、攻撃者は一時的なクラウド認証情報を取得し、内部インフラに侵入するとともに、顧客の環境変数を復号できる認証情報にアクセスしていた。
Railwayのデータベースログによると、攻撃者はAIプロバイダーのキーを特に狙って検索していた。追加のクエリでは、クラウド、データベース、決済サービスの認証情報も対象になっていた。
同社は10月20日午後1時58分（UTC）に不審な活動を検知し、翌日午前9時24分（UTC）までに攻撃者を完全に排除した。
Railwayは、悪用された弱点を修正し、より厳格なアクセス制御を備えた専用の一時仮想マシンへビルドを移行したとしている。
影響を受けた顧客は何人か
Railwayは、流出について複数の明確なカテゴリーを確認している。
- 最大10万のワークスペース：最大で全体の1.85%にあたるワークスペースの環境変数が復号された可能性がある。これは潜在的な最大流出規模であり、被害を確認した顧客数ではない。
- 1,852人のユーザー：GitHubのOAuthトークンや、顧客が独自のキーを持ち込むタイプのAIエージェント認証情報など、連携アカウントのトークンが復号されたことが確認された。Railwayはトークンをリセットし、影響を受けたユーザーに通知した。
- 353件のビルド履歴：攻撃者は、ビルド関連の情報やシークレットを含む保存済みのビルド履歴にアクセスした。
- $740,000:侵害された認証情報に関連する不正なAI利用について、Railwayが算出した推定値。
Railwayは、顧客のGitリポジトリがダウンロードされた証拠や、顧客のデータベースにアクセスされた証拠は見つからなかったとしている。また、今回のインシデントで盗まれた認証情報を使ってRailwayのアカウントにログインした形跡も確認されていない。
今回の侵害は、開発者向けプラットフォームを狙った他の攻撃と類似している。10月には、Zeaburへの侵害によって数百万件の環境変数レコードが流出し、ホスティングされた開発インフラに保存されたシークレットをめぐって同様の懸念が浮上した。
盗まれたAI認証情報が不正利用を発生させる
Railwayは、攻撃者が商用モデルへのアクセスを中継または転売するサービスを通じて流通させるため、AIキーを狙ったとみている。
この活動はしばしば「LLMjacking」と呼ばれる。盗んだAPI認証情報を使い、アカウント所有者の許可なく有料AIサービスを利用する行為だ。
Railwayの調査では、コーディングエージェントやAIトレーニング関連のワークロードに関わる不正なリクエストが確認された。同社は、一部の認証情報がモデルの蒸留に使われたと推測している。これは、あるモデルの出力を別のモデルの学習に役立てる手法だ。
ただしRailwayは、疑われる流通サービスの運営者を特定しておらず、元の攻撃者がそれらを管理していたかどうかも確認できていない。
同様の認証情報窃取のリスクは、LiteLLMのサプライチェーン攻撃にも見られた。この攻撃では、トークンや機密性の高いインフラデータを盗むよう設計された悪意あるパッケージが使われた。
Railway、返金方針を転換
Railwayは当初、10月26日に影響を受けた顧客へ、侵害されたAPIキーを通じて発生した料金は返金できないと伝えていた。
しかし11月10日の報告書では、異なる方針を示した。同社はAIプロバイダーと連携して返金を進め、プロバイダーが返金を拒否した場合はトークン関連の損失を補填する。
同社が報告した対応は以下のとおり。
- AWS BedrockとGoogle Gemini：既存の不正利用ポリシーに基づく返金手続きが開始されている。
- OpenAI：顧客はサポートケースを開き、連携した調査のためにケースIDをRailwayへ提供する必要がある。
- Anthropic：プロバイダーとの協議が続く間、Railwayが影響を受けた料金を負担する。
- OpenRouter：プロバイダーが返金しない方針を維持しているため、Railwayが損失を負担する。
- SpaceXSI：申し立ては、連携したサポートを通じて個別に審査されている。
Railwayは顧客に対し、不正な料金を報告するよう求めている。ただし同社の発表は、影響を受けたすべての顧客が返金を受けたことを示すものではない。
Railwayへの侵害後にセキュリティチームが取るべき対応
Railwayは、疑わしい活動が確認されていない場合でも、10月21日より前に同プラットフォームへ保存した機密性の高い認証情報を失効させ、置き換えるよう顧客に勧告している。
推奨される対応は以下のとおり。
- 露出した認証情報をローテーションする。発行元のプロバイダーを通じて、侵害された可能性のあるAPIキーを失効させ、依存するアプリケーション内で置き換える。
- 利用状況と請求を確認する。AIプロバイダーのログを調べ、予期しないリクエスト、見慣れないワークロード、不正な料金がないか確認する。
- 連携アカウントを監査する。GitHub、クラウドサービス、コンテナレジストリ、データベースのアクセスログを確認し、不審な活動がないか調べる。
- 権限を制限する。対応している場合は、範囲を絞った認証情報を使用し、ワークロードごとに異なるキーを分けて使う。
- 利用制御を設定する。プロバイダーが提供している場合は、APIクォータ、利用額の上限、異常検知アラートを適用する。
- 不正な料金を報告する。請求に関する証拠を保存し、Railwayと影響を受けたAIプロバイダーを通じて申し立てを行う。
セキュリティチームは、古いキーがアプリケーション設定から削除されただけでなく、実際に失効していることも確認すべきだ。
AIを利用した認証情報窃取に関する研究では、攻撃者が自動化ツールを使い、クラウドサービスやAIサービス全体に露出した認証情報を発見して有効性を検証していることが記録されている。
Railwayは、シークレットの保管を強化し、復号権限を制限するとともに、暗号化・復号処理の集中ログを導入したとしている。
同社はまた、インシデントをFBIのInternet Crime Complaint Center（IC3）に報告し、外部のフォレンジック調査員との協力を続けている。
調査では、攻撃者の身元や盗まれた認証情報の最終的な行き先は特定されていない。Railwayは、法執行機関の承認を得た後、追加の侵害指標を一般公開する予定だ。
影響を受けた組織では、Railwayがインフラを修正した後も、認証情報のローテーションとプロバイダー側での請求確認が必要だ。盗まれたAPIキーは、無効化されるまで外部サービスへのアクセスを承認し続ける可能性がある。
関連記事：2度目のFireworks AI侵害でNotion AIのチャット記録が流出――クラウドインフラ侵害の影響が下流の顧客にも及ぶ