Quboleのサプライチェーン攻撃、信頼されたIAMロールを悪用しAWSシークレットが流出
攻撃者はQuboleのAWSアカウント認証情報を悪用して顧客のIAMロールを引き受け、2026年10月14日から26日の間にデータを窃取しました。
英語の原文から自動翻訳されました。
2026年10月14日から10月26日にかけて、Idera傘下のデータレイクプラットフォームであるQuboleの顧客に属する複数のAWSアカウントが侵害されました。クラウドセキュリティ企業Wizによると、侵入者はQubole自身のAWSアカウントから盗み出した認証情報を使用し、セキュリティ制御を回避して顧客環境にアクセスしたとのことです。
この侵害は、サードパーティベンダーにクラウドインフラへのアクセス権限を付与する方法における重大な脆弱性を浮き彫りにしています。信頼されたIdentity and Access Management (IAM) ロールを活用することで、攻撃者は個々のユーザーパスワードを解読したり、アプリケーションレベルのバグを悪用したりすることなく、機密性の高いシークレットを抽出し、大量のデータをコピーすることができました。
何が起きたのか
Quboleは、顧客がプラットフォーム向けに作成した特定のIAMロールを引き受けることで、顧客のAWSアカウント内で動作します。これらのロールには、QuboleのAWSアカウントがロールの権限を引き受けることを許可するトラストポリシーが含まれています。AWSはこれらのリクエストを検証するために、Quboleが提供するコードであるExternal IDを要求します。攻撃者はQuboleの中央AWSアカウントの認証情報を入手し、それを使用して顧客アカウントに対してAssumeRoleリクエストを送信しました。
Wizの研究者は、侵害されたロールの多くが顧客によって使用されていなかったものの、設定上は有効なまま残っていたと指摘しています。トラスト関係がまだ維持されていたため、正しいExternal IDが含まれていれば、攻撃者のリクエストは受理されました。これにより、侵入者は2週間の期間中に複数の顧客環境間で横方向に移動することが可能になりました。
ロールベースの侵入に加え、10月8日から10月11日にかけて、別個だが関連性のない活動が発生しました。この期間中、攻撃者はQubole用に設定されたと考えられるAWSアクセスキーを使用して、いくつかのクラウド環境を侵害しました。Wizはこの初期イベントを、AssumeRoleの悪用を伴う主要なキャンペーンとは関連付けていません。
仕組み
この攻撃の中核的なメカニズムは、標準的なAWSクロスアカウントアクセスパターンに依存していました。Quboleのようなベンダーが顧客のアカウント内のリソースを管理する必要がある場合、顧客はベンダーのアカウントIDを指すトラストポリシーを持つIAMロールを作成します。その後、ベンダーはAssumeRole API呼び出しを使用して、一時的にその権限を取得します。External IDは「confused deputy」問題を防止することを目的としていますが、秘密ではありません。CloudTrailログに表示され、Infrastructure as Codeファイルに保存されていることがよくあります。
内部に入った後、攻撃者はパスワードを推測する必要はありませんでした。彼らは直ちに既存の認証情報の収集を開始しました。侵入者はLambda関数の環境変数を読み取り、AWS Secrets Managerからシークレットを取得し、SSM Parameter Storeの値にアクセスしました。どの認証情報が有効かを検証するために、攻撃者はオープンソースのシークレット検出ツールであるTruffleHogを使用し、AWSアクセスキー、Entra IDクライアントシークレット、Oktaクライアント認証情報をテストしました。
データの外部漏洩は、標的型ではなく広範なものでした。攻撃者は引き受けたロールがアクセスできるすべてのS3バケットからデータをコピーしました。場合によっては、単一のセッションでバケット全体がダウンロードされました。利便性のためにロールに広範な読み取り権限が付与されていることが多いため、攻撃者はさらに権限をエスカレーションすることなく、保存されている大量の情報にアクセスできました。
主要な詳細
- 攻撃者アカウント: 悪意のあるAssumeRoleリクエストは、Quboleに属するAWSアカウントID 805246085872から発信されました。
- 期間: 主要なロールベースの攻撃は2026年10月14日から10月26日の間に発生しました。
- 侵害指標 (IoC): AWS以外のソースIPアドレス、特にOVHまたはMullvad VPN範囲からのアカウント805246085872によるAssumeRoleリクエストを探してください。
- 特定のIAMユーザー: IAMプリンシパルID AIDA3W7DIFLYOLTK63SFS および AIDAJYRRH5Y3A7AAJM2HW からのアクティビティで、非AWS IPからのものである場合は調査してください。
- ツール: 攻撃者は盗まれた認証情報を検証するためにTruffleHogを使用しており、GetCallerIdentity呼び出しのユーザーエージェントで識別できます。
- ログギャップ: 多くの被害者はS3データイベントやサーバーアクセスログを欠いており、正確にどのオブジェクトが読み取られたかを特定することが不可能でした。
なぜ重要なのか
エンジニアリングチームにとって、この事件は休眠状態のベンダーアクセスのリスクを強調しています。サービスがもはや積極的に使用されていない場合でも、IAMロールとトラストポリシーはしばしばそのまま残っています。これらの忘れられた接続は、ベンダーの中央認証情報が侵害された場合に攻撃者が悪用できる広い攻撃面を生み出します。これは、自社の境界線を守るだけでなく、すべてのサードパーティ統合の衛生状態を検証するというセキュリティ負担へと移行させるものです。
また、この攻撃はExternal IDをセキュリティ制御として利用することの限界を示しています。External IDは秘密ではないため、信頼するアカウントの認証情報が盗まれた場合、不正アクセスを防ぐことはできません。エンジニアはベンダーロールに対し、内部管理者ロールと同じ厳格さで扱い、厳格なネットワーク条件と最小権限の原則を適用する必要があります。広範なS3読み取りアクセスを許可することが多いデフォルトの設定ガイドに頼ると、これらのロールが悪用された際に壊滅的なデータ損失につながる可能性があります。
対応策
- 2026年10月1日以降のCloudTrailログを監査し、非AWS IPアドレスから発信されたアカウント805246085872によるAssumeRoleリクエストを確認してください。
- 侵害の兆候が見られるQuboleロールからアクセス可能なすべてのシークレット、パラメータ、Lambda環境変数をローテーションし、アクティブなセッションを取り消してください。
- もはや必要ないQubole IAMロールを削除するか、サービスが廃止された場合はトラストポリシーからQuboleのアカウントIDを削除してください。
- ベンダーロールのトラストポリシーに aws:SourceIp または aws:SourceVpce 条件を追加し、ベンダーの文書化されたネットワーク範囲へのアクセスを制限してください。
- 機密データを含むすべてのバケットでS3データイベントまたはサーバーアクセスログを有効にし、将来のオブジェクトレベルアクセスの可視性を確保してください。
- トラストポリシー内のアカウント全体の :root プリンシパルを、サポートされている場合は特定のIAMプリンシパルに置き換え、各ロールごとに一意のExternal IDを使用してください。
