mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 05:33:10 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/README.md', 'src/p
This commit is contained in:
@@ -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 \
|
||||
|
||||
Reference in New Issue
Block a user