mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-01 10:35:06 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -12,7 +12,7 @@
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
|
||||
これらの権限のいずれかがあれば、新しい buildspec でビルドをトリガーし、プロジェクトに割り当てられた IAM ロールのトークンを盗むのに十分です:
|
||||
これらの権限のいずれかがあれば、新しいbuildspecでビルドをトリガーし、プロジェクトに割り当てられたiamロールのトークンを盗むのに十分です:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -218,7 +218,7 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file
|
||||
|
||||
aws codebuild start-build --project-name codebuild-demo-project
|
||||
```
|
||||
**潜在的影響:** どのAWS Codebuildロールにも直接的な権限昇格。
|
||||
**潜在的影響:** どのAWS Codebuildロールへの直接的な権限昇格。
|
||||
|
||||
### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
@@ -325,7 +325,7 @@ For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/
|
||||
|
||||
特定のCodeBuildプロジェクトのビルドを開始/再起動できる攻撃者は、その`buildspec.yml`ファイルを攻撃者が書き込みアクセスを持つS3バケットに保存している場合、CodeBuildプロセスでコマンド実行を取得できます。
|
||||
|
||||
注意: エスカレーションは、CodeBuildワーカーが攻撃者とは異なる役割を持っている場合にのみ関連します。おそらく、より特権のある役割です。
|
||||
注意: エスカレーションは、CodeBuildワーカーが攻撃者とは異なる役割を持っている場合にのみ関連します。希望的には、より特権のある役割です。
|
||||
```bash
|
||||
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
|
||||
|
||||
@@ -354,7 +354,7 @@ commands:
|
||||
**影響:** 通常高い権限を持つAWS CodeBuildワーカーによって使用されるロールへの直接的な権限昇格。
|
||||
|
||||
> [!WARNING]
|
||||
> buildspecはzip形式で期待される可能性があるため、攻撃者はダウンロードして解凍し、ルートディレクトリから`buildspec.yml`を修正し、再度zipしてアップロードする必要があります。
|
||||
> buildspecはzip形式で期待される可能性があるため、攻撃者はダウンロードして解凍し、ルートディレクトリから`buildspec.yml`を修正し、再度zip化してアップロードする必要があります。
|
||||
|
||||
詳細は[こちら](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/)で確認できます。
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
ECSに関する**詳細情報**は以下にあります:
|
||||
ECSに関する**詳細情報**は以下を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,7 +12,7 @@ ECSに関する**詳細情報**は以下にあります:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
`iam:PassRole`、`ecs:RegisterTaskDefinition`、および`ecs:RunTask`の権限を悪用する攻撃者は、**メタデータ認証情報を盗む**悪意のあるコンテナを持つ**新しいタスク定義を生成**し、**それを実行**することができます。
|
||||
`iam:PassRole`、`ecs:RegisterTaskDefinition`、および`ecs:RunTask`の権限を悪用する攻撃者は、**メタデータ認証情報を盗む** **悪意のあるコンテナ**を持つ**新しいタスク定義を生成**し、**実行する**ことができます。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -135,16 +135,16 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**潜在的な影響:** どのECSロールへの直接的な権限昇格。
|
||||
**潜在的な影響:** すべてのECSロールへの直接的な権限昇格。
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限が**ない**場合です。\
|
||||
これは依然として興味深いです。なぜなら、たとえロールなしであっても任意のコンテナを実行できる場合、**特権コンテナを実行して**ノードに脱出し、**EC2 IAMロール**やノードで実行されている**他のECSコンテナのロール**を**盗む**ことができるからです。\
|
||||
このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限が**ない**点が異なります。\
|
||||
これは依然として興味深いです。なぜなら、たとえロールなしであっても任意のコンテナを実行できる場合、**特権コンテナを実行して**ノードに逃げ込み、**EC2 IAMロール**やノードで実行されている**他のECSコンテナのロール**を**盗む**ことができるからです。\
|
||||
さらに、あなたが侵害したEC2インスタンス内で**他のタスクを実行させる**こともでき、その資格情報を盗むことができます（[**ノードへの権限昇格セクション**](aws-ecs-privesc.md#privesc-to-node)で説明されています）。
|
||||
|
||||
> [!WARNING]
|
||||
> この攻撃は、**ECSクラスターがEC2**インスタンスを使用している場合にのみ可能です。
|
||||
> この攻撃は、**ECSクラスターがEC2**インスタンスを使用している場合にのみ可能であり、Fargateではありません。
|
||||
```bash
|
||||
printf '[
|
||||
{
|
||||
@@ -187,7 +187,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
**`ecs:ExecuteCommand`, `ecs:DescribeTasks`** を持つ攻撃者は、実行中のコンテナ内で **コマンドを実行** し、それに付随するIAMロールを抽出することができます（`aws ecs execute-command` を実行するためには describe 権限が必要です）。\
|
||||
**`ecs:ExecuteCommand`** と **`ecs:DescribeTasks`** を持つ攻撃者は、実行中のコンテナ内で **コマンドを実行** し、それに付随するIAMロールを抽出することができます（`aws ecs execute-command` を実行するためには describe 権限が必要です）。\
|
||||
しかし、そのためには、コンテナインスタンスが **ExecuteCommandエージェント** を実行している必要があります（デフォルトでは実行されていません）。
|
||||
|
||||
したがって、攻撃者は以下を試みることができます：
|
||||
|
||||
@@ -32,6 +32,6 @@ aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
**潜在的な影響**: 不正なユーザーやサービスによるトピックへの不正アクセス、メッセージの露出、またはトピックの操作、トピックに依存するアプリケーションの正常な機能の中断。
|
||||
**潜在的な影響**: 不正なユーザーやサービスによるトピックへの不正アクセス、メッセージの露出、またはトピックの操作、トピックに依存するアプリケーションの正常な機能の妨害。
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+10
-10
@@ -25,7 +25,7 @@
|
||||
|
||||
### `states:TestState` & `iam:PassRole`
|
||||
|
||||
**`states:TestState`** および **`iam:PassRole`** 権限を持つ攻撃者は、既存のステートマシンを作成または更新することなく、任意のステートをテストし、任意のIAMロールをそれに渡すことができ、ロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。これらの権限が組み合わさることで、ワークフローの操作からデータの変更、データ漏洩、リソースの操作、特権昇格に至るまで、広範な不正行為が引き起こされる可能性があります。
|
||||
**`states:TestState`** および **`iam:PassRole`** 権限を持つ攻撃者は、既存のステートマシンを作成または更新することなく、任意のステートをテストし、任意のIAMロールをそれに渡すことができ、ロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。これらの権限を組み合わせることで、ワークフローの操作からデータの変更、データ漏洩、リソースの操作、特権昇格に至るまで、広範な不正行為が引き起こされる可能性があります。
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
@@ -59,11 +59,11 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
"status": "SUCCEEDED"
|
||||
}
|
||||
```
|
||||
**潜在的影響**: ワークフローの不正な実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
|
||||
**潜在的影響**: ワークフローの不正実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
**`states:CreateStateMachine`** と **`iam:PassRole`** を持つ攻撃者は、ステートマシンを作成し、任意のIAMロールを提供することができ、そのロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。前の特権昇格技術 (**`states:TestState`** & **`iam:PassRole`**) と対照的に、これは自動的には実行されず、**`states:StartExecution`** または **`states:StartSyncExecution`** の権限が必要です (**`states:StartSyncExecution`** は **標準ワークフローには利用できず、** 表現ステートマシンのみに適用されます) ので、ステートマシンの実行を開始する必要があります。
|
||||
**`states:CreateStateMachine`** と **`iam:PassRole`** を持つ攻撃者は、ステートマシンを作成し、任意のIAMロールを提供することができ、ロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。前の特権昇格技術 (**`states:TestState`** & **`iam:PassRole`**) と対照的に、これは自動的には実行されず、ステートマシン上での実行を開始するために **`states:StartExecution`** または **`states:StartSyncExecution`** の権限が必要です (**`states:StartSyncExecution`** は **標準ワークフローには利用できず、** 表現ステートマシンのみに適用されます)。
|
||||
```bash
|
||||
# Create a state machine
|
||||
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
@@ -123,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition
|
||||
"creationDate": "2024-07-09T20:29:35.381000+02:00"
|
||||
}
|
||||
```
|
||||
- **コマンド** 実行して **以前に作成されたステートマシンの実行を開始**:
|
||||
- **コマンド**は、以前に作成したステートマシンの**実行を開始**するために実行されました：
|
||||
```json
|
||||
aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
|
||||
{
|
||||
@@ -142,16 +142,16 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
|
||||
|
||||
ステートマシンに関連付けられたIAMロールがどれだけ許可的であるかによって、攻撃者は2つの状況に直面します。
|
||||
|
||||
1. **許可的なIAMロール**: ステートマシンに関連付けられたIAMロールがすでに許可的である場合（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーが添付されている場合）、特権を昇格させるために**`iam:PassRole`** 権限は必要ありません。ステートマシンの定義を更新する必要がないためです。
|
||||
2. **許可的でないIAMロール**: 前のケースとは対照的に、ここでは攻撃者は**`iam:PassRole`** 権限も必要です。ステートマシンの定義を変更するだけでなく、許可的なIAMロールをステートマシンに関連付ける必要があるためです。
|
||||
1. **許可的なIAMロール**: ステートマシンに関連付けられたIAMロールがすでに許可的である場合（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーが添付されている場合）、特権を昇格させるために**`iam:PassRole`** 権限は必要ありません。ステートマシンの定義を更新する必要がないため、ステートマシンの定義だけで十分です。
|
||||
2. **許可的でないIAMロール**: 前のケースとは対照的に、ここでは攻撃者は**`iam:PassRole`** 権限も必要です。ステートマシンの定義を変更するだけでなく、ステートマシンに許可的なIAMロールを関連付ける必要があるためです。
|
||||
```bash
|
||||
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
|
||||
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
|
||||
```
|
||||
以下の例は、HelloWorld Lambda関数を呼び出す正当なステートマシンを更新し、ユーザー**`unprivilegedUser`**を**`administrator`** IAMグループに追加する追加のステートを加える方法を示しています。このようにして、正当なユーザーが更新されたステートマシンの実行を開始すると、この新しい悪意のあるステルスステートが実行され、特権昇格が成功します。
|
||||
以下の例は、HelloWorld Lambda関数を呼び出す正当なステートマシンを更新し、ユーザー **`unprivilegedUser`** を **`administrator`** IAMグループに追加する追加のステートを加える方法を示しています。このようにして、正当なユーザーが更新されたステートマシンの実行を開始すると、この新しい悪意のあるステルスステートが実行され、特権昇格が成功します。
|
||||
|
||||
> [!WARNING]
|
||||
> ステートマシンに許可されたIAMロールが関連付けられていない場合、許可されたIAMロールを関連付けるためにIAMロールを更新するには、**`iam:PassRole`**権限も必要です（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`**ポリシーが添付されたものなど）。
|
||||
> ステートマシンに許可されたIAMロールが関連付けられていない場合、許可されたIAMロールを関連付けるためにIAMロールを更新するには **`iam:PassRole`** 権限も必要です（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーが添付されたものなど）。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
@@ -218,7 +218,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <value
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
- **Command** executed to **update** **the legit state machine**:
|
||||
- **コマンド** 実行して **正当なステートマシン** を **更新**:
|
||||
```bash
|
||||
aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
|
||||
{
|
||||
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
|
||||
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
|
||||
}
|
||||
```
|
||||
**潜在的な影響**: ワークフローの不正な実行と操作、機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
|
||||
**潜在的な影響**: ワークフローの不正な実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+14
-14
@@ -4,11 +4,11 @@
|
||||
|
||||
## S3 パブリックバケット
|
||||
|
||||
バケットは、**「パブリック」**と見なされる場合、**任意のユーザーがバケットの内容をリストできる**場合であり、**「プライベート」**は、バケットの内容が**特定のユーザーによってのみリストまたは書き込まれる**場合です。
|
||||
バケットは、**任意のユーザーがバケットの内容をリストできる**場合に**「パブリック」**と見なされ、**特定のユーザーのみがリストまたは書き込みできる**場合に**「プライベート」**と見なされます。
|
||||
|
||||
企業は、**バケットの権限が誤って設定されている**可能性があり、すべての人またはAWSの任意のアカウントに認証されたすべての人にアクセスを許可することがあります（つまり、誰にでも）。このような誤設定があっても、バケットには独自のアクセス制御リスト（ACL）があるため、いくつかのアクションを実行できない場合があります。
|
||||
企業は、**バケットの権限が誤って設定されている**可能性があり、すべてのユーザーまたはAWSの任意のアカウントに認証されたすべてのユーザーにアクセスを許可することがあります（つまり、誰でも）。このような誤設定があっても、バケットには独自のアクセス制御リスト（ACL）があるため、いくつかのアクションは実行できない場合があります。
|
||||
|
||||
**AWS-S3の誤設定について学ぶにはこちらを参照してください:** [**http://flaws.cloud**](http://flaws.cloud/) **および** [**http://flaws2.cloud/**](http://flaws2.cloud)
|
||||
**AWS-S3の誤設定についてはこちらで学ぶ:** [**http://flaws.cloud**](http://flaws.cloud/) **および** [**http://flaws2.cloud/**](http://flaws2.cloud)
|
||||
|
||||
### AWS バケットの発見
|
||||
|
||||
@@ -26,8 +26,8 @@ http://[bucket_name].s3.amazonaws.com/
|
||||
```
|
||||
|
||||
- **CNAMES**を確認します。`resources.domain.com`は`bucket.s3.amazonaws.com`のCNAMEを持っている可能性があります。
|
||||
- **[s3dns](https://github.com/olizimmermann/s3dns)** – DNSトラフィックを分析することでクラウドストレージバケット（S3、GCP、Azure）を受動的に特定する軽量DNSサーバーです。CNAMEを検出し、解決チェーンを追跡し、バケットパターンを一致させ、ブルートフォースやAPIベースの発見に対する静かな代替手段を提供します。偵察やOSINTワークフローに最適です。
|
||||
- [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/)を確認してください。すでに**発見されたオープンバケット**があります。
|
||||
- **[s3dns](https://github.com/olizimmermann/s3dns)** – DNSトラフィックを分析することでクラウドストレージバケット（S3、GCP、Azure）を受動的に特定する軽量DNSサーバー。CNAMEを検出し、解決チェーンを追跡し、バケットパターンを一致させ、ブルートフォースやAPIベースの発見に対する静かな代替手段を提供します。偵察やOSINTワークフローに最適です。
|
||||
- [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/)、すでに**発見されたオープンバケット**のウェブサイト。
|
||||
- **バケット名**と**バケットドメイン名**は**同じである必要があります。**
|
||||
- **flaws.cloud**は**IP** 52.92.181.107にあり、そこに行くと[https://aws.amazon.com/s3/](https://aws.amazon.com/s3/)にリダイレクトされます。また、`dig -x 52.92.181.107`は`s3-website-us-west-2.amazonaws.com`を返します。
|
||||
- バケットであることを確認するには、[https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/)を**訪問**することもできます。
|
||||
@@ -97,14 +97,14 @@ Non-authoritative answer:
|
||||
11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
|
||||
```
|
||||
解決されたドメインに「website」という単語が含まれていることを確認してください。\
|
||||
静的ウェブサイトには次のようにアクセスできます: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
|
||||
または、バケットには次のようにアクセスできます: `flaws.cloud.s3-us-west-2.amazonaws.com`
|
||||
静的ウェブサイトには次のURLでアクセスできます: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
|
||||
または、バケットには次のURLでアクセスできます: `flaws.cloud.s3-us-west-2.amazonaws.com`
|
||||
|
||||
|
||||
|
||||
#### 試してみる
|
||||
|
||||
バケットにアクセスしようとしたが、**指定したドメイン名に別のリージョンが含まれている場合**（たとえば、バケットが `bucket.s3.amazonaws.com` にあるが、`bucket.s3-website-us-west-2.amazonaws.com` にアクセスしようとした場合、正しい場所に**誘導されます**:
|
||||
バケットにアクセスしようとした場合、**指定したドメイン名に別のリージョンが含まれている**（たとえば、バケットが `bucket.s3.amazonaws.com` にあるが、`bucket.s3-website-us-west-2.amazonaws.com` にアクセスしようとした場合）、**正しい場所に誘導されます**:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -120,7 +120,7 @@ Non-authoritative answer:
|
||||
|
||||
.png>)
|
||||
|
||||
これをcliで確認することもできます:
|
||||
これをCLIでも確認できます:
|
||||
```bash
|
||||
#Use --no-sign-request for check Everyones permissions
|
||||
#Use --profile <PROFILE_NAME> to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions
|
||||
@@ -128,7 +128,7 @@ Non-authoritative answer:
|
||||
#Opcionally you can select the region if you now it
|
||||
aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile <PROFILE_NAME>] [ --recursive] [--region us-west-2]
|
||||
```
|
||||
バケットにドメイン名がない場合、列挙しようとするときは、**バケット名のみを入力**し、全体のAWSs3ドメインは入力しないでください。例: `s3://<BUCKETNAME>`
|
||||
バケットにドメイン名がない場合、列挙しようとするときは、**バケット名のみを入力**し、AWSs3ドメイン全体は入力しないでください。例: `s3://<BUCKETNAME>`
|
||||
|
||||
### 公開URLテンプレート
|
||||
```
|
||||
@@ -137,7 +137,7 @@ https://{user_provided}.s3.amazonaws.com
|
||||
### 公開バケットからアカウントIDを取得する
|
||||
|
||||
新しい **`S3:ResourceAccount`** **ポリシー条件キー**を利用することで、AWSアカウントを特定することが可能です。この条件は、アカウントが存在するS3バケットに基づいてアクセスを**制限**します（他のアカウントベースのポリシーは、リクエスト元のプリンシパルが存在するアカウントに基づいて制限します）。\
|
||||
ポリシーには**ワイルドカード**を含めることができるため、アカウント番号を**1つの数字ずつ**見つけることが可能です。
|
||||
ポリシーには**ワイルドカード**を含めることができるため、アカウント番号を**1つずつ**見つけることが可能です。
|
||||
|
||||
このツールはそのプロセスを自動化します：
|
||||
```bash
|
||||
@@ -153,7 +153,7 @@ s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/
|
||||
|
||||
### バケットが AWS アカウントに属していることを確認する
|
||||
|
||||
[**このブログ投稿**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、**バケットをリストする権限がある場合**、リクエストを送信することでバケットが属する accountID を確認することが可能です。
|
||||
[**このブログ投稿**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、**バケットをリストする権限がある場合**、次のようなリクエストを送信することで、バケットが属する accountID を確認することが可能です。
|
||||
```bash
|
||||
curl -X GET "[bucketname].amazonaws.com/" \
|
||||
-H "x-amz-expected-bucket-owner: [correct-account-id]"
|
||||
@@ -163,9 +163,9 @@ curl -X GET "[bucketname].amazonaws.com/" \
|
||||
```
|
||||
エラーが「Access Denied」の場合、アカウントIDが間違っていることを意味します。
|
||||
|
||||
### ルートアカウント列挙としての使用されたメール
|
||||
### ルートアカウント列挙としての使用メール
|
||||
|
||||
[**このブログ記事**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、ACLを介してS3バケットに対してメールアドレスに権限を付与しようとすることで、そのメールアドレスがAWSアカウントに関連しているかどうかを確認することが可能です。これがエラーを引き起こさない場合、そのメールは何らかのAWSアカウントのルートユーザーであることを意味します。
|
||||
[**このブログ記事**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、S3バケットに対してACLを介してメールに権限を付与しようとすることで、メールアドレスがAWSアカウントに関連しているかどうかを確認することが可能です。これがエラーを引き起こさない場合、そのメールは何らかのAWSアカウントのルートユーザーであることを意味します。
|
||||
```python
|
||||
s3_client.put_bucket_acl(
|
||||
Bucket=bucket_name,
|
||||
|
||||
Reference in New Issue
Block a user