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 15:22:11 +00:00
parent c139e18e38
commit c017bc8756
3 changed files with 144 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -4,15 +4,64 @@
## dynamodb
dynamodbに関する詳細情報は次を確認してください:
dynamodbに関する詳細情報は、以下を確認してください：
{{#ref}}
../aws-services/aws-dynamodb-enum.md
{{#endref}}
### Post Exploitation
### `dynamodb:PutResourcePolicy` およびオプションで `dynamodb:GetResourcePolicy`
私の知る限り、AWSの`dynamodb`権限を持っているだけで特権を昇格させる**直接的な方法はありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの資格情報を含む可能性があります）、テーブルに**情報を書き込む**ことができます（これにより、lambdaコードインジェクションなどの他の脆弱性が引き起こされる可能性があります）が、これらのオプションはすでに**DynamoDB Post Exploitationページ**で考慮されています:
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:Put*` を付与することでプリンシパルがデータベースにアイテムを追加できるだけだと考える場合や、2024年3月以前にその権限セットを付与した場合に、しばしば偶然に発生します...
理想的には、他の潜在的に重要な権限を上書きせず、必要な追加権限のみを注入するために、`dynamodb:GetResourcePolicy` も持っているべきです：
```bash
# get the current resource based policy (if it exists) and save it to a file
aws dynamodb get-resource-policy \
--resource-arn <table_arn> \
--query 'Policy' \
--output text > policy.json
```
現在のポリシーを取得できない場合は、テーブルに対してあなたのプリンシパルに完全なアクセスを付与するこのポリシーを使用してください：
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullAccessToDynamoDBTable",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
},
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
]
}
]
}
```
もしカスタマイズが必要な場合、すべての可能な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` が準備できたので、リソースポリシーを設定します:
```bash
# put the new policy using the prepared policy file
# dynamodb does weirdly not allow a direct file upload
aws dynamodb put-resource-policy \
--resource-arn <table_arn> \
--policy "$(cat policy.json)"
```
今、必要な権限を持っているはずです。
### ポストエクスプロイト
私の知る限り、AWSの`dynamodb`権限を持っているだけで権限を昇格させる直接的な方法は**他にありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの資格情報を含む可能性があります）、テーブルに**情報を書き込む**ことができ（他の脆弱性を引き起こす可能性があります、例えばlambdaコードインジェクションなど...）ますが、これらのオプションはすでに**DynamoDBポストエクスプロイトページ**で考慮されています：
{{#ref}}
../aws-post-exploitation/aws-dynamodb-post-exploitation.md

29
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"**というcloudformationバケットに対してこれらの権限を持つ攻撃者は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます:
```json
{
"Version": "2012-10-17",
@@ -34,25 +34,38 @@
]
}
```
そして、ハイジャックが可能なのは、**テンプレートがバケットにアップロードされる瞬間から**、**テンプレートがデプロイされる瞬間までの小さな時間ウィンドウ**があるためです。攻撃者は、自分のアカウントに**lambda function**を作成し、**バケット通知が送信されたときにトリガーされる**ようにし、その**バケット**の**コンテンツ**を**ハイジャック**することができます。
そして、ハイジャックが可能なのは、**テンプレートがバケットにアップロードされる瞬間から**、**テンプレートがデプロイされる瞬間までの小さな時間ウィンドウ**があるためです。攻撃者は、自分のアカウントに**lambda function**を作成し、**バケット通知が送信されるとトリガーされる**ように設定し、その**バケット**の**コンテンツ**を**ハイジャック**することができます。
![](<../../../images/image (174).png>)
Pacuモジュール[`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection)を使用して、この攻撃を自動化できます。\
Pacuモジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) を使用して、この攻撃を自動化できます。\
詳細については、元の研究を確認してください: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `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ステートファイル上
[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 Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください：
{{#ref}}
terraform-security.md#abusing-terraform-state-files
{{#endref}}
### `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>
@@ -110,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>