ECScape という侵害手法:EC2 上の ECS プロトコルの悪用によるタスク間 IAM 認証情報漏洩を実証

ECScape: Exploiting ECS Protocol on EC2 to Exfiltrate Cross-Task IAM and Execution Role Credentials

2025/08/08 CyberSecurityNews — Amazon Elastic Container Service (ECS) 上で実行される、悪意のコンテナが用いる “ECScape” という高度な手法により、同一の EC2 インスタンスを共有する他コンテナから、AWS 認証情報の窃取が可能なことが判明した。この問題が浮き彫りにするのは、マルチテナントの ECS デプロイメント分離における深刻な弱点である。その一方で、AWS Fargate のマイクロ VM アーキテクチャが持つ、セキュリティ上の優位性が示されている。

この手法は、ECS エージェントと AWS コントロール・プレーンの間で使用される、非公開の内部プロトコルを悪用し、コンテナ境界を越えて IAM 認証情報を窃取するものであり、セキュリティ研究者である Naor Haziz により実証された。

従来からのホスト・レベルへのアクセスを前提とするコンテナ・エスケープ手法とは異なり、ECScape はネットワーク操作により ECS エージェントを偽装し、コンテナの名前空間内で動作を完結する。

侵害されたコンテナが、169.254.169.254 の Instance Metadata Service (IMDS) にアクセスし、EC2 インスタンスの IAM ロール認証情報を取得するところから、この攻撃は開始される。これらの認証情報は、ECS エージェントの正規処理に利用されるものであるため、攻撃者による成りすまし攻撃に悪用されてしまう。

インスタンス認証情報を接種した攻撃者は、ecs:DiscoverPollEndpoint API を介して ECS コントロール・プレーンのポーリング・エンドポイントを特定し、クラスター ARN やコンテナ・インスタンス ARN (Amazon Resource Name) などの識別情報を収集する。続いて、ECS がタスク認証情報をエージェントに配信する内部チャネルを悪用することで、偽造 WebSocket による AWS Agent Communication Service (ACS) への接続を確立する。

ECScape 攻撃は ECS プロトコルを悪用する

WebSocket ハンドシェイク時に、”sendCredentials=true” パラメータを付与する攻撃者は、同一の EC2 インスタンス上の、すべてのタスクの IAM 認証情報を取得できる。そこに取り込まれるものには、アプリケーション・ロールやタスク実行ロールの認証情報があり、AWS Secrets Manager/ECR/CloudWatch Logs などへアクセスするための、機密性の高い権限が含まれていることも多い。

ECScape が窃取した認証情報は、正規の情報と同様に機能するため、ステルス性が高い。AWS CloudTrail がログとして残すのは、被害タスク・ロールへの API 呼び出しの記録であるが、攻撃元コンテナの特定は困難である。この特性により、低権限タスクであっても高権限タスクの権限奪取が可能となり、ECS 環境におけるコンテナ分離の前提が覆ってしまう。

Naor Haziz の実証環境では、すべてのアクセスを拒否するという IAM ポリシーを持つコンテナが、S3 フルアクセス権限を持つ隣接タスクから窃取した認証情報を使用し、S3 バケットを削除することに成功している。それにより、他コンテナ向けの機密情報が漏洩し、マルチテナントのセキュリティ・モデルが侵害されることになった。

この件に関する AWS の説明は、脆弱性ではなく設計上の考慮事項として分類するというものであり、同一 EC2 インスタンス上のタスクは、暗黙的に同一信頼ドメインに属するとしている。また、AWS の公開情報が強く推奨するのは、より強固な分離が必要な場合における、AWS Fargate の利用である。

セキュリティ専門家たちは、緩和策として以下を推奨している:

  • ネットワーク制御または ECS_AWSVPC_BLOCK_IMDS 設定による、IMDS アクセスの制限または無効化。
  • 共有インスタンス上で、高権限タスクと低権限タスクを共存させない設計。
  • 各タスク・ロールに対する最小権限ポリシーの適用。
  • CloudTrail の包括的な監視による、異常な認証情報使用の検出。

EC2 上で ECS を運用する組織は、各インスタンスを潜在的な障害ドメインとみなして、セキュリティ境界を強化すべきである。さらに言えば、機密度の高いワークロードに関しては、Fargate の隔離マイクロ VM アーキテクチャへ移行することが望ましい。