gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-s3-a

Browse Source
This commit is contained in:
Translator
2026-02-27 14:16:18 +00:00
parent ac65c892d5
commit c7987f1345
1 changed files with 69 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

138
src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md
View File

@@ -4,36 +4,36 @@
## S3
Amazon S3 は **大量のデータを格納** できるサービスです。
Amazon S3 は大量のデータを保存できるサービスです。
Amazon S3 は REST 状態のデータの **保護** を実現するための複数のオプションを提供します。オプションには **Permission (Policy)**、**Encryption (Client and Server Side)**、**Bucket Versioning**、および **MFA based delete** が含まれます。ユーザーはこれらの任意のオプションを有効にしてデータ保護を行えます。**Data replication** は AWS の内部機能で、**S3 が各オブジェクトをすべての Availability Zones に自動的に複製**するもので、この場合組織側で有効にする必要はありません。
Amazon S3 は、REST 状態のデータ保護を実現するための複数のオプションを提供します。これらのオプションには、**権限**（Policy）、**暗号化**（クライアント側およびサーバー側）、**Bucket Versioning**、および **MFA** による **削除制御** が含まれます。**ユーザーは** これらのオプションのいずれかを有効にしてデータ保護を実現できます。**Data replication** は AWS の内部機能で、**S3 が各オブジェクトをすべての Availability Zones に自動的に複製**するため、組織が有効化する必要がない場合があります。
リソースベースの権限を使用すると、bucket のサブディレクトリごとに権限を個別に定義できます。
リソースベースの権限を使用すると、バケットのサブディレクトリごとに権限を個別に定義できます。
### Bucket Versioning and MFA based delete
Bucket Versioning が有効になっている場合、ファイルの内容を変更しようとする操作は新しいバージョンを生成し、以前の内容も保持するため、上書きされません。
Bucket Versioning が有効な場合、ファイルを変更しようとするあらゆる操作はファイルの新しいバージョンを生成し、以前の内容も保持するため、内容が上書きされることはありません。
さらに、MFA based delete により S3 バケット内のファイルのバージョンが削除されるのを防ぎ、Bucket Versioning の無効化も防止されるため、攻撃者がこれらのファイルを改変することはできません。
さらに、MFA ベースの削除は S3 バケット内のファイルのバージョンが削除されるのを防ぎ、Bucket Versioning を無効化することも防止するため、攻撃者がこれらのファイルを改ざんすることを難しくします。
### S3 Access logs
特定のバケットで **S3 access login**（デフォルトでは無効）を有効にして、ログを別のバケットに保存することで、どのユーザーがバケットにアクセスしているかを把握できます（両方のバケットは同じリージョンである必要があります）。
特定のバケットで **S3 access login** を有効（デフォルトでは無効）にして、ログを別のバケットに保存することで、誰がバケットにアクセスしているかを把握できます（両方のバケットは同じリージョンである必要があります）。
### S3 Presigned URLs
presigned URL を生成すると、通常その presigned URL を使ってバケット内の指定ファイルにアクセスできます。presigned URL の例は次のようになります：
バケット内の指定ファイルに **アクセスするための presigned URL** を生成することが可能です。通常、この presigned URL を使って **指定されたファイルにアクセスする** ことができます。**presigned URL は次のようになります**：
```
https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa
```
presigned URLは、**created from the cli using credentials of a principal with access to the object** ことで作成できます（使用するaccountにアクセス権がない場合、より短いpresigned URLが作成されますが、役に立ちません）
presigned URLは、**cliからオブジェクトにアクセス権を持つprincipalのcredentialsを使用して作成できます**（使用するaccountにアクセス権がない場合、より短いpresigned URLが作成されますが、役に立ちません）
```bash
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
```
> [!NOTE]
> presigned URL を生成するのに必要な権限は、付与されるその権限だけです。したがって、前のコマンドではプリンシパルが必要とする権限は `s3:GetObject` のみです。
> presigned URL を生成するために必要な唯一の権限は、付与される権限そのものです。したがって、前のコマンドではプリンシパルが必要とする唯一の権限は `s3:GetObject` です
It's also possible to create presigned URLs with **他の権限**:
presigned URL を **他の権限** で作成することも可能です：
```python
import boto3
url = boto3.client('s3').generate_presigned_url(
@@ -42,24 +42,24 @@ Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'},
ExpiresIn=3600
)
```
### S3 暗号化の仕組み
### S3 Encryption Mechanisms
**DEK means Data Encryption Key** は常に生成され、データの暗号化に使用される鍵です。
**DEK means Data Encryption Key** and is the key that is always generated and used to encrypt data.
<details>
<summary><strong>S3管理キーによるサーバーサイド暗号化, SSE-S3</strong></summary>
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
このオプションは最小限の設定で済み、使用される暗号化鍵の管理はすべてAWSが行います。やるべきことは**データをアップロードするだけで、S3がその他すべてを処理します**。S3アカウント内の各バケットにはバケットキーが割り当てられます。
このオプションは最小限の設定で済み、使用される暗号化キーの管理はすべてAWSが行います。やるべきことはデータをアップロードするだけで、S3がその他の処理をすべて処理します。各バケットにはバケットキーが割り当てられます。
- 暗号化:
- オブジェクトデータ + 生成された平文DEK --> 暗号化データ（S3内に保存）
- 生成された平文DEK + S3 Master Key --> 暗号化DEK（S3内に保存）および平文はメモリから削除
- 復号:
- 暗号化DEK + S3 Master Key --> 平文DEK
- 平文DEK + 暗号化データ --> オブジェクトデータ
- Encryption:
- Object Data + created plaintext DEK --> Encrypted data (stored inside S3)
- Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) and plain text is deleted from memory
- Decryption:
- Encrypted DEK + S3 Master Key --> Plaintext DEK
- Plaintext DEK + Encrypted data --> Object Data
ご注意：この場合、**鍵はAWSによって管理されます**（ローテーションは3年ごと）。独自の鍵を使用すると、ローテーション、無効化、アクセス制御の適用が可能です。
Please, note that in this case **the key is managed by AWS** (rotation only every 3 years). If you use your own key you willbe able to rotate, disable and apply access control.
</details>
@@ -67,16 +67,16 @@ ExpiresIn=3600
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
この方法では、S3がKey Management Serviceを利用してデータ暗号化キーを生成できます。KMSは鍵管理に関してより高い柔軟性を提供します。たとえば、CMKの無効化、ローテーション、アクセス制御の適用が可能で、AWS Cloud Trailを使って使用状況を監査できます。
この方法では、S3がKMSを使ってあなたのデータ暗号化キーを生成できます。KMSによりキー管理の柔軟性が大幅に向上します。例えば、CMKを無効化、ローテーション、アクセス制御を適用したり、その利用をAWS Cloud Trailで監査することが可能です。
- 暗号化:
- S3がKMSにデータキーを要求
- KMSはCMKを用いて平文DEKと暗号化DEKのペアを生成し、それをS3に返す
- S3は平文DEKを用いてデータを暗号化し、暗号化データと暗号化DEKを保存し、平文鍵をメモリから削除
- 復号:
- S3はオブジェクトの暗号化データキーの復号をKMSに依頼
- KMSはCMKでデータキーを復号してS3に返送
- S3がオブジェクトデータを復号
- Encryption:
- S3 request data keys from KMS CMK
- KMS uses a CMK to generate the pair DEK plaintext and DEK encrypted and send them to S£
- S3 uses the paintext key to encrypt the data, store the encrypted data and the encrypted key and deletes from memory the plain text key
- Decryption:
- S3 ask to KMS to decrypt the encrypted data key of the object
- KMS decrypt the data key with the CMK and send it back to S3
- S3 decrypts the object data
</details>
@@ -84,17 +84,17 @@ ExpiresIn=3600
<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
このオプションでは、AWS外で既に使用しているかもしれない独自のマスターキーを提供できます。カスタマー提供の鍵はデータと共にS3に送られ、S3がその鍵で暗号化を行います。
このオプションは、AWS外で既に使用している可能性のある自身のマスターキーを提供する機会を与えます。カスタマー提供キーはデータとともにS3に送信され、S3が暗号化を実行します。
- 暗号化:
- ユーザーがオブジェクトデータ + カスタマー鍵をS3に送信
- カスタマー鍵でデータを暗号化し、暗号化データを保存
- カスタマー鍵の検証用にソルト付きHMAC値も保存
- カスタマー鍵はメモリから削除
- 復号:
- ユーザーがカスタマー鍵を送信
- 鍵は保存されているHMAC値と照合される
- 照合が取れたカスタマー提供鍵でデータを復号
- Encryption:
- The user sends the object data + Customer key to S3
- The customer key is used to encrypt the data and the encrypted data is stored
- a salted HMAC value of the customer key is stored also for future key validation
- the customer key is deleted from memory
- Decryption:
- The user send the customer key
- The key is validated against the HMAC value stored
- The customer provided key is then used to decrypt the data
</details>
@@ -102,17 +102,17 @@ ExpiresIn=3600
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
SSE-KMSと同様に、KMSを利用してデータ暗号化キーを生成しますが、今回KMSはクライアント側から呼び出され、暗号化はクライアント側で行われた後に暗号化データがS3へ送られます。
SSE-KMSと同様に、こちらもKMSを使ってデータ暗号化キーを生成します。ただし今回はS3ではなくクライアント側からKMSを呼び出します。暗号化はクライアント側で行われ、暗号化済みデータがS3に送られて保存されます。
- 暗号化:
- クライアントがKMSへデータキーを要求
- KMSは平文DEKとCMKで暗号化されたDEKを返す
- 両方の鍵が返される
- クライアントは平文DEKでデータを暗号化し、暗号化データと暗号化DEKをS3へ送信（暗号化DEKはS3内の暗号化データのメタデータとして保存）
- 復号:
- 暗号化DEK付きの暗号化データがクライアントに送られる
- クライアントはCMKを使ってKMSに暗号化鍵の復号を依頼し、KMSは平文DEKを返す
- クライアントはその平文DEKで暗号化データを復号
- Encryption:
- Client request for a data key to KMS
- KMS returns the plaintext DEK and the encrypted DEK with the CMK
- Both keys are sent back
- The client then encrypts the data with the plaintext DEK and send to S3 the encrypted data + the encrypted DEK (which is saved as metadata of the encrypted data inside S3)
- Decryption:
- The encrypted data with the encrypted DEK is sent to the client
- The client asks KMS to decrypt the encrypted key using the CMK and KMS sends back the plaintext DEK
- The client can now decrypt the encrypted data
</details>
@@ -120,21 +120,21 @@ SSE-KMSと同様に、KMSを利用してデータ暗号化キーを生成しま
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
この方式では、独自の鍵を使用し、AWS-SDKクライアントでデータをS3に送信する前に暗号化できます。
この仕組みを使うと、自分で提供したキーを利用し、AWS-SDKクライアントで送信前にデータを暗号化してS3に保存できます。
- 暗号化:
- クライアントがDEKを生成して平文データを暗号化
- そのDEKを自前のCMKで暗号化
- 暗号化データ + 暗号化DEKをS3に送信して保存
- 復号:
- S3が暗号化データと暗号化DEKを返送
- クライアントはDEKを暗号化したCMKを既に持っているためDEKを復号し、平文DEKでデータを復号
- Encryption:
- The client generates a DEK and encrypts the plaintext data
- Then, using it's own custom CMK it encrypts the DEK
- submit the encrypted data + encrypted DEK to S3 where it's stored
- Decryption:
- S3 sends the encrypted data and DEK
- As the client already has the CMK used to encrypt the DEK, it decrypts the DEK and then uses the plaintext DEK to decrypt the data
</details>
### **列挙**
### **Enumeration**
AWS組織を侵害する伝統的な主要な手法の一つは、公開アクセス可能なバケットを侵害することから始まります。**該当するツールは** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**にあります。**
One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
```bash
# Get buckets ACLs
aws s3api get-bucket-acl --bucket <bucket-name>
@@ -229,16 +229,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
```
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
virtual hosted-style または path-style のエンドポイント名を使用して、dual-stack エンドポイント経由で S3 バケットにアクセスできます。これらは IPv6 を介して S3 にアクセスするのに便利です。
バーチャルホスト方式またはパススタイルのエンドポイント名を使って、dual-stack エンドポイント経由で S3 バケットにアクセスできます。これらは IPv6 経由で S3 にアクセスする際に有用です。
Dual-stack エンドポイントは次の構文を使用します:
Dual-stack endpoints use the following syntax:
- `bucketname.s3.dualstack.aws-region.amazonaws.com`
- `s3.dualstack.aws-region.amazonaws.com/bucketname`
### Privesc
In the following page you can check how to **abuse S3 permissions to escalate privileges**:
次のページで、**S3 の権限を悪用して権限を昇格させる方法**を確認できます：
{{#ref}}
../aws-privilege-escalation/aws-s3-privesc/README.md
@@ -266,19 +266,19 @@ In the following page you can check how to **abuse S3 permissions to escalate pr
### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) it was possible to cache the response of an arbitrary bucket as if it belonged to a different one. This could have been abused to change for example javascript file responses and compromise arbitrary pages using S3 to store static code.
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) 任意のバケットのレスポンスを別のバケットのもののようにキャッシュすることが可能でした。これを悪用すると、例えば javascript ファイルのレスポンスを書き換え、S3 を利用して静的コードをホストしている任意のページを改ざんすることができました。
## Amazon Athena
Amazon Athena は、Amazon Simple Storage Service (Amazon **S3**) 内のデータを標準の **SQL** を使って直接 **分析** することを容易にするインタラクティブなクエリサービスです。
Amazon Athena は、Amazon Simple Storage Service (Amazon **S3**) 内のデータを標準の **SQL** を **使用して** 直接 **データを分析する**ことを容易にするインタラクティブなクエリサービスです。
監視対象の S3 バケットに現れるコンテンツの形式に合わせた **リレーショナル DB テーブルを準備する** 必要があります。すると、Amazon Athena はログからそのテーブルを作成・更新してクエリできるようになります。
監視対象の S3 バケットに出現するコンテンツの形式に合わせて、**リレーショナル DB テーブルを準備**する必要があります。すると、Amazon Athena はログからそのテーブルにデータを取り込み、クエリを実行できるようになります。
Amazon Athena は、すでに暗号化されている S3 データをクエリする機能をサポートしており、設定によっては **Athena がクエリ結果を暗号化して S3 に保存することもできます**。
Amazon Athena は既に暗号化されている S3 データをクエリする機能をサポートしており、設定によっては **Athena がクエリ結果を暗号化し、それを S3 に保存する**こともできます。
**このクエリ結果の暗号化は、問い合わせ対象の S3 データ自体の暗号化とは独立しています**。つまり、S3 データが暗号化されていなくても、クエリ結果は暗号化できます。注意すべき点として、Amazon Athena は **次の S3 暗号化方式で** **暗号化された** データのみをサポートします: **SSE-S3, SSE-KMS, and CSE-KMS**。
**このクエリ結果の暗号化は、クエリ対象となる基盤の S3 データとは独立しています**。つまり S3 データ自体が暗号化されていなくても、クエリ結果は暗号化できます。注意点として、Amazon Athena は **以下の S3 暗号化方式**、**SSE-S3、SSE-KMS、および CSE-KMS** で暗号化されたデータのみをサポートします。
SSE-C と CSE-C はサポートされていません。さらに、Amazon Athena は **クエリが実行されるリージョンと同じリージョン内にある暗号化オブジェクトのみ** に対してクエリを実行する、という点も重要です。KMS を使って暗号化された S3 データをクエリする必要がある場合、Athena ユーザーにはクエリ実行のための特定の権限が必要になります。
SSE-C と CSE-C はサポートされません。加えて、Amazon Athena は **クエリ自体と同じリージョンにある暗号化されたオブジェクト**に対してのみクエリを実行する点に注意してください。KMS を使って暗号化された S3 データをクエリする場合、クエリを実行するために Athena ユーザーに特定の権限が必要になります。
### Enumeration
```bash