ECS-cape – Hijacking IAM Privileges in Amazon ECSを解説する

Black Hat USA 2025にてNaor Haziz氏によって発表された、Amazon ECSの攻撃手法であるECS-capeの概要を解説した資料です。
こちらの勉強会で解説を行いました。

Transcript

1. ECS-cape – Hijacking IAM Privileges in Amazon ECS を解説する kuzushiki
2. 背景 8/2～8/7にて、Black Hat USA 2025という世界最大級のセキュリティカンファレンスが開催 された。 ラスベガスには行けなかったが、発表資料は公開されているので読んでみた。 https://www.blackhat.com/us-25/briefings/schedule/index.html ECS-capeというAmazon ECSにおける攻撃手法の発表が面白かったので解説する。 part1: https://naorhaziz.com/posts/under-the-hood-of-amazon-ecs/ part2: https://www.sweet.security/blog/ecscape-understanding-iam-privilege-boundaries-in-amazon-ecs
3. ECS-cape – Hijacking IAM Privileges in Amazon ECS Amazon ECSの異なるタスクが同一のEC2インスタンス上で動いている場合に、タスク 間の侵害ができるというもの。 例えば低権限のタスクと高権限のタスクを同時に動かしていると、低権限のタスクが侵 害された際に高権限のタスクのクレデンシャルにもアクセスされてしまう。
4. Amazon ECSとは？ Amazon Elastic Container Service フルマネージドのコンテナオーケストレーションサービス 3つの起動モードが存在 - EC2 - EC2インスタンス上で動作 ←ECS-capeが刺さる可能性あり - Fargate - マネージドの隔離された環境で動作 - ECS Anyware - AWS以外の環境やオンプレで動作
5. ECS Agent EC2上のコンテナとクラウド上のControl Planeの仲介役 引用元：https://naorhaziz.com/posts/under-the-hood-of-amazon-ecs/
6. ECS-capeのアプローチ EC2上のコンテナを侵害した攻撃者はECS AgentになりすましControl Planeと接続し、 Control Planeから他のタスクのクレデンシャルを窃取する。
7. ECS Agentの処理の流れ Step 1：IMDSからインスタンスロールのクレデンシャルを取得 Step 2：API経由で管理用URLを取得 Step 3：管理用URLへ接続するためのWebSocket URLを生成 Step 4：Control PlaneとのACSプロトコルによる通信を開始 Step 5：取得したクレデンシャルをコンテナに渡す
8. Step 1：IMDSからインスタンスロールのクレデンシャルを取得 ECS用のEC2が起動する際、ECS Agentは自身がエージェントであることをControl Planeに伝える。 ECS AgentはIMDS (169.254.169.254) を通してEC2のクレデンシャルにアクセスし、イ ンスタンスロールで認証することでエージェントであることを証明する。 引用元：https://naorhaziz.com/posts/under-the-hood-of-amazon-ecs/
9. Step 2：API経由で管理用URLを取得 インスタンスロールに付与されている権限（ecs:DiscoverPollEndpoint）を用いてAPIを 呼び出し、管理用URLを取得する。 APIのレスポンス例： { "endpoint": "https://ecs-a-1.us-east-1.amazonaws.com", "telemetryEndpoint": "https://ecs-t-1.us-east-1.amazonaws.com", "serviceConnectEndpoint": "https://ecs-sc-1.us-east-1.amazonaws.com", }
10. Step 3：管理用URLへ接続するためのWebSocket URLを生成 wss://ecs-a-1.<region>.amazonaws.com/ws? agentHash=<agent-hash>& agentVersion=<agent-version>& clusterArn=arn:aws:ecs:<region>:<account-id>:cluster/<cluster-name>& containerInstanceArn=arn:aws:ecs:<region>:<account-id>:container-instance/<instance-uuid>& dockerVersion=<docker-version>& protocolVersion=<protocol-version>& seqNum=1& sendCredentials=true
11. Step 4：Control PlaneとのACSプロトコルによる通信を開始 前のステップで作成したURLでControl Planeと接続し、ACSと呼ばれる AWSの独自プ ロトコルによる通信を開始する。 プロトコルの詳細は公開されていないが、パケットキャプチャなどの解析によりタスクの クレデンシャルがやりとりされている ことが判明している！
12. Step 5：取得したクレデンシャルをコンテナに渡す ECS AgentはControl Planeから受け取ったクレデンシャルをメモリ上に保存 その後、ローカルIPアドレス (169.254.170.2) で動くメタデータサービス経由でコンテナ に提供する。 http://169.254.170.2/v2/credentials/<UUID> <UUID>はタスク固有のもので、タスクの一部であるコンテナを起動する際に環境変数 経由で注入する。 よって他のタスクからはアクセスできないはずだが ...
13. おさらい：ECS-capeのアプローチ EC2上のコンテナを侵害した攻撃者はECS AgentになりすましControl Planeと接続し、 Control Planeから他のタスクのクレデンシャルを窃取する。
14. ECS-capeの流れ Step 1：タスクの一部であるコンテナを侵害後、IMDSに問い合わせ Step 2：盗んだインスタンスロールを用いて管理URL取得 Step 3：WebSocket URLを推測 Step 4：ECS Agentになりすまして接続 Step 5：ACS経由で他のタスクのクレデンシャルを得る
15. Step 1：タスクの一部であるコンテナを侵害後、IMDSに問い合わせ ECS on EC2環境で、タスクの一部であるコンテナが侵害されたとする。 デフォルトではEC2上のコンテナからIMDS (169.254.169.254) にアクセス可能なため、 攻撃者はIMDS経由でインスタンスロールのクレデンシャルを取得できてしまう。
16. Step 2：盗んだインスタンスロールを用いて管理URL取得 インスタンスロールのクレデンシャルを取得した攻撃者は、API呼び出しにより管理URL を取得できる。 { "endpoint": "https://ecs-a-1.us-east-1.amazonaws.com", "telemetryEndpoint": "https://ecs-t-1.us-east-1.amazonaws.com", "serviceConnectEndpoint": "https://ecs-sc-1.us-east-1.amazonaws.com", }
17. Step 3：WebSocket URLを推測 攻撃者はECS Agentが利用するWebSocket URLを推測する。 他コンテナの情報が必要になるが、侵害したコンテナからECS Agent用のIntrospection API (http://localhost:51578/v1/metadata) を呼び出せるため取得できてしまう！ コンテナから Introspection APIにアクセスできること がこの攻撃の肝。ECS Agentか らのみアクセスできるように制限すべきだった。
18. Step 4：ECS Agentになりすまして接続 推測したURLを用いて、Control Planeと偽の接続を試みる。 ECS Agentとまったく同じリクエストを送るため、Control Planeは見分けがつかず、接続 を許可してしまう。 同時接続数が 1インスタンスにつき 1エージェントに制限されてない ことも問題。 接続数が1に制限されていれば正規のECS Agentが先に接続するため偽の接続は失 敗する。
19. Step 5：ACS経由で他のタスクのクレデンシャルを得る 攻撃者はACS経由でControl Planeから他のタスクのクレデンシャルを窃取する。 引用元：https://naorhaziz.com/posts/under-the-hood-of-amazon-ecs/
20. Proof of Concept 攻撃コードおよび環境構築用ファイルが公開されているので試せます！ https://github.com/naorhaziz/ecscape
21. ECS-capeの特長 - タスク間の権限昇格 - 情報収集に悪用可能 - ACSではクレデンシャル以外にもネットワーク情報などが流れる - ステルス性 - ACSとのやりとりはCloudTrailのログには残らない - API呼び出しは正規のECS Agentも行うため見分けがつきにくい - デフォルトの設定で悪用可能 - ECS on EC2の環境はデフォルトで脆弱 - とはいえ、攻撃者は少なくとも 1つのコンテナを侵害する必要があるので悪用ハードルは高い
22. ECS-capeの対策 - IMDSアクセスの無効化または制限 - コンテナ内からIMDSへのアクセスをブロックする - IMDS IP (169.254.169.254) へのegressを拒否するセキュリティグループを適用 - ECS_AWSVPC_BLOCK_IMDSの設定　 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-iam-roles.ht ml#task-iam-role-considerations - 高権限タスクは隔離された環境で動かす - EC2インスタンスを分ける、もしくは Fargateを利用する - 監視 - CloudTrailなどを設定してIAMロールの異常な利用に気づけるように - GuardDutyでインスタンスのクレデンシャルが外部に持ち出された場合に検知
23. おわりに ECS-capeという攻撃手法について解説した。 とても詳細にECSの挙動が分析されており興味深かった。 - ECSがタスクのクレデンシャルをコンテナに渡す流れ - ACSという独自プロトコルの調査 前提として攻撃者はコンテナを侵害する必要があり、AWSも脆弱性とは認めていない が、ECSをEC2上で利用している方は影響がないか確認しておこう。