gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-29 14:13:20 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/terraform-security.md', 'src/pentestin

Browse Source
This commit is contained in:
Translator
2025-01-05 20:58:45 +00:00
parent c017bc8756
commit 6b153d797f
3 changed files with 45 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
View File

@@ -10,15 +10,15 @@ dynamodbに関する詳細情報は、以下を確認してください：
../aws-services/aws-dynamodb-enum.md
{{#endref}}
### `dynamodb:PutResourcePolicy` およびオプションで `dynamodb:GetResourcePolicy`
### `dynamodb:PutResourcePolicy` とオプションで `dynamodb:GetResourcePolicy`
2024年3月以降、AWSはDynamoDBに対して*リソースベースのポリシー*を提供しています（[AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)）。
したがって、テーブルに対して `dynamodb:PutResourcePolicy` を持っている場合、自分自身または他の任意のプリンシパルにテーブルへの完全なアクセスを付与できます。
したがって、テーブルに対して`dynamodb:PutResourcePolicy`を持っている場合、テーブルへの完全なアクセス権を自分自身または他の任意のプリンシパルに付与できます。
`dynamodb:PutResourcePolicy` をランダムなプリンシパルに付与することは、管理者が `dynamodb:Put*` を付与することでプリンシパルがデータベースにアイテムを追加できるだけだと考える場合や、2024年3月以前にその権限セットを付与した場合に、しばしば偶然に発生します...
`dynamodb:PutResourcePolicy`をランダムなプリンシパルに付与することは、管理者が`dynamodb:Put*`を付与することでそのプリンシパルがデータベースにアイテムを追加できるだけだと考える場合や、2024年3月以前にその権限セットを付与した場合に、しばしば偶然に発生します...
理想的には、他の潜在的に重要な権限を上書きせず、必要な追加権限のみを注入するために、`dynamodb:GetResourcePolicy` も持っているべきです：
理想的には、他の潜在的に重要な権限を上書きせず、必要な追加の権限のみを注入するために、`dynamodb:GetResourcePolicy`も持っているべきです：
```bash
# get the current resource based policy (if it exists) and save it to a file
aws dynamodb get-resource-policy \
@@ -47,9 +47,9 @@ aws dynamodb get-resource-policy \
]
}
```
もしカスタマイズが必要な場合、すべての可能なDynamoDBアクションのリストは次のとおりです: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html)。また、リソースベースのポリシーを介して許可できるすべてのアクションのリスト *およびこれらのうちどれがクロスアカウントで使用できるか（データの流出を考えてください！）*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
もしカスタマイズが必要な場合、すべての可能なDynamoDBアクションのリストは次のとおりです: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html)。また、リソースベースのポリシーを介して許可されるすべてのアクションのリスト *およびこれらのうちどれがクロスアカウントで使用できるか（データの流出を考えてください！）*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
さて、ポリシードキュメント `policy.json` が準備できたので、リソースポリシーを設定します:
さて、ポリシードキュメント `policy.json` が準備できたら、リソースポリシーを設定します:
```bash
# put the new policy using the prepared policy file
# dynamodb does weirdly not allow a direct file upload
@@ -59,9 +59,9 @@ aws dynamodb put-resource-policy \
```
今、必要な権限を持っているはずです。
### ポストエクスプロイト
### ポストエクスプロイテーション
私の知る限り、AWSの`dynamodb`権限を持っているだけで権限を昇格させる直接的な方法は**他にありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの資格情報を含む可能性があります）、テーブルに**情報を書き込む**ことができ（他の脆弱性を引き起こす可能性があります、例えばlambdaコードインジェクションなど...）ますが、これらのオプションはすでに**DynamoDBポストエクスプロイトページ**で考慮されています：
私の知る限り、AWSの`dynamodb`権限を持っているだけで権限を昇格させる直接的な方法は**他にありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの認証情報を含む可能性があります）、テーブルに**情報を書き込む**ことができます（これにより、lambdaコードインジェクションなどの他の脆弱性が引き起こされる可能性があります）が、これらのオプションはすでに**DynamoDBポストエクスプロイテーションページ**で考慮されています：
{{#ref}}
../aws-post-exploitation/aws-dynamodb-post-exploitation.md

18
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
View File

@@ -8,7 +8,7 @@
興味深いバケットに対してこれらの権限を持つ攻撃者は、リソースをハイジャックし、権限を昇格させることができるかもしれません。
例えば、**"cf-templates-nohnwfax6a6i-us-east-1"**というcloudformationバケットに対してこれらの権限を持つ攻撃者は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます:
例えば、"cf-templates-nohnwfax6a6i-us-east-1"というクラウドフォーメーションバケットに対してこれらの**権限を持つ攻撃者**は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます:
```json
{
"Version": "2012-10-17",
@@ -43,19 +43,19 @@ Pacuモジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityL
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
これらは、**S3にオブジェクトを取得およびアップロードするための権限**です。AWS内（および外部）でいくつかのサービスが、**設定ファイル**を保存するためにS3ストレージを使用しています。\
これらは、**S3にオブジェクトを取得およびアップロードするための権限**です。AWS内（および外部）のいくつかのサービスは、**設定ファイル**を保存するためにS3ストレージを使用します。\
それらに**読み取りアクセス**を持つ攻撃者は、**機密情報**を見つける可能性があります。\
それらに**書き込みアクセス**を持つ攻撃者は、**データを変更してサービスを悪用し、特権を昇格させようとする**ことができます。\
以下はそのいくつかの例です：
- EC2インスタンスが**ユーザーデータをS3バケットに保存している**場合、攻撃者はそれを変更して**EC2インスタンス内で任意のコードを実行する**ことができます。
### `s3:PutObject`, `s3:GetObject` (オプション) terraformステートファイル上
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) ステートファイルがクラウドプロバイダーのブロブストレージに保存されることは非常に一般的です。例えば、AWS S3です。ステートファイルのファイルサフィックスは`.tfstate`であり、バケット名も通常、terraformステートファイルを含んでいることを示します。通常、すべてのAWSアカウントには、アカウントの状態を示すステートファイルを保存するためのそのようなバケットが1つあります。\
また、実際のアカウントでは、ほぼすべての開発者が`s3:*`を持ち、時にはビジネスユーザーでさえ`s3:Put*`を持っています。
[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html)の状態ファイルがクラウドプロバイダーのブロブストレージに保存されることは非常に一般的です。例えば、AWS S3です。状態ファイルのファイルサフィックスは`.tfstate`であり、バケット名も通常、terraform状態ファイルを含んでいることを示します。通常、すべてのAWSアカウントには、アカウントの状態を示す状態ファイルを保存するためのそのようなバケットが1つあります。\
また、実際のアカウントでは、ほとんどすべての開発者が`s3:*`を持ち、時にはビジネスユーザーでさえ`s3:Put*`を持っています。
したがって、これらのファイルに対してリストされた権限を持っている場合、`terraform`の特権でパイプライン内でRCEを取得することを可能にする攻撃ベクターがあります - ほとんどの場合、`AdministratorAccess`であり、あなたをクラウドアカウントの管理者にします。また、そのベクターを使用して、`terraform`に正当なリソースを削除させることによってサービス拒否攻撃を行うこともできます。
したがって、これらのファイルに対してリストされた権限を持っている場合、`terraform`の特権でパイプライン内でRCEを取得することを可能にする攻撃ベクターがあります。ほとんどの場合、`AdministratorAccess`であり、クラウドアカウントの管理者になります。また、そのベクターを使用して、`terraform`に正当なリソースを削除させることによるサービス拒否攻撃を行うこともできます。
直接使用可能なエクスプロイトコードについては、*Terraform Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください：
@@ -65,7 +65,7 @@ terraform-security.md#abusing-terraform-state-files
### `s3:PutBucketPolicy`
攻撃者は、**同じアカウントからである必要があります**。そうでない場合、エラー`The specified method is not allowed will trigger`が発生します。この権限を持つ攻撃者は、バケットに対して自分自身により多くの権限を付与し、読み取り、書き込み、変更、削除、バケットを公開することができるようになります。
攻撃者は、**同じアカウントからである必要があり**、そうでない場合はエラー`The specified method is not allowed will trigger`が発生します。この権限を持つ攻撃者は、バケットに対して自分自身により多くの権限を付与し、読み取り、書き込み、変更、削除、バケットを公開することができるようになります。
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -123,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
```
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
攻撃者はこれらの権限を悪用して、特定のバケットに対して**より多くのアクセスを付与する**ことができます。\
攻撃者は同じアカウントからである必要はありません。さらに、書き込みアクセス
攻撃者はこれらの権限を悪用して、特定のバケットに対する**より多くのアクセスを付与する**ことができます。\
攻撃者は同じアカウントからである必要はないことに注意してください。さらに、書き込みアクセス
```bash
# Update bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name>