え、私のFlagまるみえ!? クラウド問題やインフラにおける題設計ミスにみるクラウドセキュリティ(入門) - 魔女のお茶会 #7 おふらいん! (2025冬)
6K Views
March 20, 25
スライド概要
関連スライド
各ページのテキスト
え、私のFlagまるみえ!? クラウド問題やインフラにおける題設計ミスにみるクラウドセキュリティ(入門) Azara / @a_zara_n / Norihide Saito 魔女のお茶会 #7 おふらいん! (2025冬) #witchskeyparty
目次 1 CTFとクラウド クラウドカテゴリの問題ってどのくらい出題されているのだろうか？ インフラと問題を混ぜた環境は危険 ２ DEFCON Cloud Village 2023で起きたCloud Storage...の話 3 境界を知る - 権限やSandbox、コンピュータリソース 4 XS3やSecurity-JAWS Daysなどにみる クラウドを題材にしたCTF問題の作り方と脅威の実践 5 クラウド問題を解く際の思考 < オムニバス形式だよ
目次 1 CTFとクラウド クラウドカテゴリの問題ってどのくらい出題されているのだろうか？ インフラと問題を混ぜた環境は危険 ２ DEFCON Cloud Village 2023で起きたCloud Storage...の話 3 境界を知る - 権限やSandbox、コンピュータリソース 4 5 クラウド問題を解く際の思考 < 時間的に4番はとばすよ
各章の大体の関係 ２ インフラと問題を混ぜた環境は危険 (Bad practiceの理解) 1 3 4 CTFとクラウド (全体像の把握) 境界を知る (背景の理解) クラウドを題材にした (CTF問題の作り方と脅威の実践) 5 クラウド問題を解く際の思考 (課題解決に向けたの大まかな理解) < オムニバス形式だよ
自己紹介 名前 所属 Azara / @a_zara_n / Norihide Saito CTFとクラウド関係の活動(登壇以外) CTF XS3 主催 CTF Security JAWS Days CTF 作問 CTF SECCON 2022 国内決勝出場 CTF 所属企業主催 CTF作問 国際 AWS Community Builder - Security プロダクトセキュリティ事業部 プロフェッショナルサービス部
自己紹介 名前 所属 Azara / @a_zara_n / Norihide Saito プロダクトセキュリティ事業部 プロフェッショナルサービス部 見ての通り筋金入りのCTFerではないので CTFとクラウド関係の活動(登壇以外) お手柔らかに...! XS3 主催 (クラウド問題っぽいものが出たら駆けつけるやつです) Security JAWS Days CTF 作問 (VikeSECCON CTFとか事前に開催を把握してる 2022 国内決勝出場 Cloud問題が必ず出るやつには参加してます) 所属企業主催 CTF作問 CTF CTF CTF CTF 国際 AWS Community Builder - Security
自己紹介 - 普段はクラウド大好き人間 https://github.com/flatt-security/xs3 クラウドを起点にしたXSSの研究 https://cloudsecjp.connpass.com/event/347542/ クラウドセキュリティについて話すコミュニティ主催
1 CTFとクラウド クラウドカテゴリの問題ってどのくらい出題されているのだろうか？
TL;DR だいたいの問題がWeb Categoryの派生的立ち位置の問 大体流れとし 設定ミスや実装ミスを発 IAMの取得と権限列 内部への侵入と情報の収 これの繰り返 実質的にCloud Pentestチックなものにな クラウドのAPIから取得できる情報が全て
CTFとクラウド CTFtimeのarchiveを参照すると2018~19年ごろからEC2 を対象にしたSSRFやS3の設定ミスに起因する情報の暴露 について取り上げる問題が存在し また、これ以外にもIAMや各種AWS・GCPのサービス の機能の使い方といった点にフォーカスを置いた問題も 見られ 近年だとCloud PTを模した問題やCognito、Firebase、 Lambdaなど問題で利用されるサービスの数も増えてきて いる
CTFとクラウド http://flaws.cloud/ http://flaws2.cloud/
こんな問題があるよ- Just CTF 2023 Easy Auth コメント Easy AuthはAmazon Cognito (User Pool / Identity Pool)を用いた問題で、Full サーバーレス環境か らAWSのアカウントに侵入することを想定し、Lambda内のソースコードを抜き取る問題
こんな問題があるよ- DownUnderCTF 2021 Whale Blog 補足情報・追加情報 Kubernetesを対象にしたCTFで、アプリケーションの脆弱性を用いてファイルとしてマウントされ た、serviceaccountの認証情報を用いてコントロールプレーンにアクセスをする問題
大まかな流れとCloud PT 1 [スタート] 表面的な 技術スタックの把握 2 5 リソースへの攻撃/探索 認証情報を用いて 設定値の収集 3 開発者などを標的に フィッシング/マルウェア配布/ サプライチェーン攻撃 4 認証情報の 取得と把握 7 6 必要な 情報の収集 [ゴール] 標的/機微情報へのアクセス
大まかな流れとCloud PT 1 [スタート] 表面的な 技術スタックの把握 2 5 リソースへの攻撃/探索 認証情報を用いて 設定値の収集 3 開発者などを標的に フィッシング/マルウェア配布/ サプライチェーン攻撃 4 認証情報の 取得と把握 7 6 必要な 情報の収集 [ゴール] 標的/機微情報へのアクセス おおよそクラウドのControl Planで操作
Cloud PTでCTFらしさだけ取り出してみる 6 1 [スタート] 表面的な 技術スタックの把握 2 5 リソースへの攻撃/探索 認証情報を用いて 設定値の収集 4 認証情報の 取得と把握 必要な 情報の収集 7 [ゴール] 標的/機微情報への アクセス
Cloud PTでCTFらしさだけ取り出してみる Web問題的な領域 1 [スタート] 表面的な 技術スタックの把握 6 2 5 リソースへの攻撃/探索 認証情報を用いて 設定値の収集 4 認証情報の 取得と把握 必要な 情報の収集 7 [ゴール] 標的/機微情報への アクセス
Cloud PTでCTFらしさだけ取り出してみる Cloud問題的な領域 1 [スタート] 表面的な 技術スタックの把握 2 5 リソースへの攻撃/探索 認証情報を用いて 設定値の収集 4 認証情報の 取得と把握 6 必要な 情報の収集 7 [ゴール] 標的/機微情報への アクセス
4 認証情報の権限を把握すべき 取得した認証情報は多くの場合、ただの文字列以上の情報を 有していません この場合、プレイヤーはどのように権限を確認するべきか 付与された権限を確認する方法は大きく2 推測による操作と周辺情 総あたりによる操作とそのレスポンス 補足情報・追加情報 クラウド系CTFでは稀に総あたりでの権限列挙を許可していないことがあるからルールは見ようね！ あと、CloudTrailなどでコントロールプレーンのログをとってる人がいるからワンチャンEDoSに！
4 認証情報の権限を把握すべき 推測による操作と周辺情報 アプリケーションのユースケースや関連する操作を元に推測を す ObjectStorage → s3:<推測される動作 Secret manager → secretmanager:<推測される動作 Container Registry → ecr:<推測される動作>
4 認証情報の権限を把握すべき 推測による操作と周辺情報 それだけでは操作の幅が広いので、もう少し小さくしてみ SSRFで認証情報を取得したなら→UserDataやIMDSから Role LFIで取得したなら→アプリケーションのソースコー それ以外→関係しそうなものを探 .gitやzipとしてあるならファイル内を探索するなど
4 認証情報の権限を把握すべき 総あたりによる操作とそのレスポンス 特定のサービスに リクエストをする 権限がある場合 操作に関連するレスポンス 権限がない場合 permission denial
4 認証情報の権限を把握すべき 総あたりによる操作とそのレスポンス 特定のサービスに リクエストをする 権限がある場合 操作に関連するレスポンス 権限がない場合 permission denial
4 認証情報の権限を把握すべき 総あたりによる操作とそのレスポンス 正直権限把握のために生のHTTPリクエストを書くのは辛いの で、誰かが作った便利なものは使いましょう。 https://github.com/nccgroup/PMapper https://github.com/andresriancho/ enumerate-iam
5 認証情報を用いて設定値の収集 認証情報を把握したら、次はリソースに設定された設定値やド メインなどを収集しましょう 外部からアクセスできるか？→ドメインが付与されてない どのようなイメージやコンテナを使っているか？→ECRからImage Pul データはどのようなものか？→S3の中に何か落ちてない ネットワーク構成は？→VPCの設定値やSecurityGroupなど など 補足情報・追加情報 一回の認証情報ではいけない場合もあるけど、 強めの権限が付与されてたりするから色々調べてみよう
6 情報の収集 認証情報やアクセス状況などを把握できたら各種データストア にアクセスしてクラウド以外のアプリケーションなどの情報を 取得しましょ Terraform StateやCloudFormationなどの構成データにア クセスできないか LambdaのGetFunctionを用いてソースコードを取 S3に認証情報や.gitなどを取得 補足情報・追加情報 結構機微情報や重要な情報が落ちているよ
章まとめ だいたいの問題がWeb Categoryの派生的立ち位置の問 → initialがWeb起点が多いか 大体流れとし 設定ミスや実装ミスを発 IAMの取得と権限列 内部への侵入と情報の収 これの繰り返 実質的にCloud Pentestチックなものにな クラウドのAPIから取得できる情報が全て
2 インフラと問題を混ぜた環境は危険 DEFCON Cloud Village 2023で起きたCloud Storage事件の説明
TL;DR クラウドサービスの特性や マネージドポリシーの権限を把握しよ 権限をミスるとデプロイされた問題の断片や Flagが見えてしまうこと 影響が波及する可能性が少しでもあるなら 環境を分離しよう ※事象の説明なだけで問題そのものの解説はしません
DEFCON Cloud Village 2023で 何が起きたのか - 前説 現地で遊んでました Cloud Village (DEFCON 31) https://kanzya.github.io/posts/DEFCON/
DEFCON Cloud Village 2023で 何が起きたのか - 大まかな事件解説 Cloud Village CTF(DEFCON 31)では 問題の保管をGoogle Cloud Storage(GCS)で行ってい CTFの問題としてCloudRunのIMDSにSSRFでアクセスする過程があっ SSRFを用いて認証情報を取得するが、その認証情報にGCS全体にアクセス 可能な権限が付与されていた、すべてのGCSへアクセスが可能だっ GCS内にはFlagを含む複数の問題のアプリケーションが存在した
前提 GCPの権限の境界と特性 1 GCPの権限はプロジェクトという 単位でサンドボックス化されている × 2 明示された場合、 このプロジェクトの越境ができる × 明示されていない 3 プロジェクト内のリソースは 越境はできない 明示すればアクセスの制限がかけられる Project A コメント AWSなどの詳しい内容は次の3章ではなすよ Project B
起点となったCTF問題 - Digital Forest 1 SSRFを用いた IMDSへの通信 2 付与された認証情報を用いた GCS Bucketへのアクセス コメント 権限さえ付与されていれば直接アクセスできてしまう
Digital Forestで発生した問題 1 なんか怪しい Bucketが 取得した認証情報を用いて あるな “DFのホストされる”プロジェクト全体の GCS BucketのListができた(問題ない) コメント ListBucketsはリスト可能なバケットを制御できないので仕方ない 1 本来の想定 バケット 問題保管用 バケット
Digital Forestで発生した問題 1 2 取得した認証情報を用いて “DFのホストされる”プロジェクト全体の GCS BucketのListができた(問題ない) 取得した認証情報を用いて “DFのホストされる”プロジェクトの 想定されたバケットにアクセスをした コメント 権限さえ付与されていれば直接アクセスできてしまう まぁいいか 1 2 本来の想定 バケット 問題保管用 バケット
Digital Forestで発生した問題 1 2 3 取得した認証情報を用いて “DFのホストされる”プロジェクト全体の GCS BucketのListができた(問題ない) 取得した認証情報を用いて “DFのホストされる”プロジェクトの 想定されたバケットにアクセスをした 取得した認証情報を用いて “DFのホストされる”プロジェクトの 問題保管用バケットにもアクセスができた コメント 権限さえ付与されていれば直接アクセスできてしまう !? 1 2 3 本来の想定 バケット 問題保管用 バケット
Digital Forestで発生した問題 コメント このようにファイルがいっぱい並んでいてなんだろうと思ったら
Digital Forestで発生した問題 コメント Flagが一つ目〜
Digital Forestで発生した問題 コメント Flagが二つ目〜
Digital Forestで発生した問題 コメント いっぱいですね〜、他の人も見つけてブログとしても取り上げられてるよ https://blog.ctis.me/2023/10/defcon-31-cloud-ctf-writeup/
章まとめ DEFCON Cloud Village 2023のようなことを起こさないための教訓 IAMを使う問題の場合、問題ごとに権限の境界であるプロジェクトで分離 す 問題に関係ないものを環境(プロジェクト)に入れな 過剰な権限が付与されていないかリソースレベルで確認する コメント 一つの問題としてみれば、これはこれで面白かった(not 皮肉)
3 境界を知る - 権限やSandbox、コンピュータリソース クラウドの立ち位置
TL;DR Q.なぜ2のようなことが起こったのか A. 権限の境界線を意識せずに問題を構築したか Q. クラウドにおける境界線・区域分けの線はどのように考 える 明示しなくても権限が適用される範 AWSであればAWSアカウン GCPであればプロジェク Q. 問題をホストするコンピュータリソースについて、境界 線を知りた VM(EC2)とコンテナ(ECS/EKS on EC2)と 結構厳密に管理されたコンテナ (ECS/EKS on Fargate, Lambda)
AWSの場合 AWSはAWSアカウントが権限の境界 アカウントを跨いだ操作の場合は 2 すべて明示的に宣言する ユーザーの操作に必要なもろもろは 3 IAM で管理される イメージ: アカウント > IAMに内包される 1 補足情報・追加情報 権限関連のことを考えるとAWSが一番境界線が明確だよ
AWSの場合 補足情報・追加情報 権限関連のことを考えるとAWSが一番境界線が明確だよ
GCPの場合 GCPはプロジェクトが権限の境界 プロジェクトを跨いだ操作の場合は 2 すべて明示的に宣言する ユーザーの操作に必要なもろもろは 3 GoogleのIdentityで管理されている イメージ: 1 Google アカウントにプロジェクトが権限を付与する 補足情報・追加情報 アカウントとプロジェクトは別のサービスだよ
GCPの場合
Azureの場合 Azureは 1 課金単位(Subscription)が権限の境界 課金単位を跨いだ操作の場合は 2 すべて明示的に宣言する(全てそう) ユーザーの操作に必要なもろもろは 3 Entra IdのIdentityで管理されている イメージ: EntraId アカウント(オブジェクト)にAzureから 権限を付与する 補足情報・追加情報 境界をまとめる管理グループというのもあるよ...面倒だね
Azureの場合
Azureの場合
コンピュータリソースレベル IaaS(EC2やCloud Compute engine), FaaS(Lambdaや Cloud Function)などが最小単 ECSやEKS、GKEなどの場合は、部分マネージドと完全マ ネージドがあるのでややこし 完全マネージドの場合、Container Escapeなどは難し い(Fargateなどを用いている場合 部分マネージドの場合、設定値次第でContainer Escapeが可能(ちょっと情報が古いものの ただし、マネージドであってもベンダーの用意する コンピュータリソースの上で動いているので完全に分離は されていない(仮想化基盤やコンテナなどで分離)
章まとめ クラウドベンダーにおける権限の境界は多くの場合、明示的に設定しない と越境できな 権限設計やサンドボックス化が必要な場合は、この境界を意識す コンピュータリソースはクラウドベンダーというよりサービス特性に依存 す クラウドは結果として、完全(物理的)に分離されているわけではないので、 脆弱性を見つければ突破できるかも... https://msrc.microsoft.com/update-guide/vulnerability/ CVE-2023-21777 (イエラエさんのやつ) コメント 境界線はベンダーごとに違うけど、AWSが権限周りではシンプルだと思った 組織体系と合わせたり、予算主体で分離をしたい場合は、AzureやGCPも良いかもとは思う。
4 XS3やSecurity-JAWS Days、 所属会社主催CTF開催にみる クラウドを題材にしたCTFの構築の仕方と脅威(Skip)
TL;DR クラウドサービスの特性や マネージドポリシーの権限を把握しよ 権限をミスるとデプロイされた問題の断片や Flagが見えてしまうこと 影響が波及する可能性が少しでもあるなら 環境を分離しよう 時間がないので次回以降にクラウドでCTFインフラを作ったら 見たいなの話したいですね〜
5 問題を解く際の思考
TL;DR どこにFlagがあるのか確認をする(ゴールから逆算 取得できる情報を集め、構成を把握す 認証情報→IMDS, Lambdaの/var/self/env, Cognito Identity Poo 構成情報→Terraform state, Cloud formation, ソースコード→LFI, Lambda Function Code, Container Repositor 権限の推測や列挙による権限把握(注意点あり 権限の昇格も考慮に入れ ドキュメントを読む
6 情報の収集(再掲) 認証情報やアクセス状況などを把握できたら各種データストア にアクセスしてクラウド以外のアプリケーションなどの情報を 取得しましょ Terraform StateやCloudFormationなどの構成データにア クセスできないか LambdaのGetFunctionを用いてソースコードを取 S3に認証情報や.gitなどを取 コントロールプレーンAPIの情報は正義 補足情報・追加情報 結構機微情報や重要な情報が落ちているよ
問題を解く際の思考の流れ 6 1 [スタート] 表面的な 技術スタックの把握 2 5 リソースへの攻撃/探索 認証情報を用いて 設定値の収集 4 認証情報の 取得と把握 必要な 情報の収集 7 [ゴール] 標的/機微情報への アクセス
サービス特性や機能がわからなかったら クラウドサービスのソースコードがみれない以上、 ドキュメントが大正 AWSやGCPは日本語は独特だがある程度は書いてあ Azureは急に書いてあることが変わるが、最近は精度が 上がってい アンドキュメントだが、サービスの組み合わせによって 特性が相反している場合があ 自前環境を用意してできる限り触ってみる
章まとめ ゴール(Flag)は何どこにあるかを、 1 周辺情報から集める → Cloudに限らずゴールからの逆算 ソースコードや見えない構成などもあるので、できる限り 2 コントロールプレーンや周辺の情報を集める 考えられることは全て試してみる 3 ユースケースをある程度の推測でも書き出し、整理する APIから取れるものが正義 4 落ちているデータも利用する(boot2root的な形で)
Thank you for reading. クラウド問題やインフラにおける題設計ミスにみるクラウドセキュリティ(入門) Azara / @a_zara_n / Norihide Saito 魔女のお茶会 #7 おふらいん! (2025冬) #witchskeyparty https://x.com/a_zara_n