mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 13:43:24 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
@@ -1,77 +1,77 @@
|
||||
# AWS - Persistenza di Lambda
|
||||
# AWS - Lambda Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda
|
||||
|
||||
Per maggiori informazioni consulta:
|
||||
Per maggiori informazioni controlla:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistenza con Lambda Layer
|
||||
### Lambda Layer Persistence
|
||||
|
||||
È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando la Lambda viene eseguita in modo stealthy:
|
||||
È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando la Lambda viene eseguita in modo stealth:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistenza con Lambda Extension
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Abusando dei Lambda Layers è anche possibile abusare delle extension e persistere nella Lambda oltre a rubare e modificare le richieste.
|
||||
Abusando dei Lambda Layers è anche possibile sfruttare le extension per persistere nella Lambda ma anche per rubare e modificare le richieste.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### Tramite resource policies
|
||||
### Via resource policies
|
||||
|
||||
È possibile concedere accesso a diverse azioni di Lambda (ad esempio invoke o update code) ad account esterni:
|
||||
È possibile concedere accesso a diverse azioni su Lambda (come invoke o update code) ad account esterni:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versioni, Alias e Pesi
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
Una Lambda può avere **diverse versioni** (con codice diverso per ciascuna versione).\
|
||||
Poi, puoi creare **diversi alias con versioni diverse** della Lambda e assegnare differenti pesi a ciascuno.\
|
||||
In questo modo un attacker potrebbe creare una **backdoored version 1** e una **version 2 con solo il codice legit** ed **eseguire solo la version 1 nel 1%** delle richieste per rimanere stealth.
|
||||
Una Lambda può avere **diverse versioni** (con codice differente per ogni versione).\
|
||||
Poi, puoi creare **diversi alias con versioni differenti** della Lambda e impostare pesi diversi per ciascuno.\
|
||||
In questo modo un attacker potrebbe creare una **versione backdoored 1** e una **versione 2 con solo il codice legittimo** ed **eseguire la versione 1 solo nell'1%** delle richieste per rimanere stealth.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Copia il codice originale della Lambda
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
|
||||
1. Chiama l'API Gateway relativa alla Lambda per eseguire il codice
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
2. **Crea una nuova versione backdooring** il codice originale (o semplicemente con codice maligno). Pubblica e **deploia quella versione** su $LATEST
|
||||
1. Chiama l'API Gateway correlata alla Lambda per eseguire il codice
|
||||
3. **Crea una nuova versione con il codice originale**, Pubblica e deploia quella **versione** su $LATEST.
|
||||
1. Questo nasconderà il codice backdoored in una versione precedente
|
||||
4. Vai all'API Gateway e **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. Nota il final :1 dell'arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
|
||||
5. Seleziona il metodo POST creato e in Actions seleziona **`Deploy API`**
|
||||
6. Ora, quando **call the function via POST your Backdoor** verrà invocata
|
||||
4. Vai su API Gateway e **crea un nuovo metodo POST** (o scegli qualsiasi altro metodo) che eseguirà la versione backdoored della Lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Nota il finale :1 dell'arn **che indica la versione della function** (la versione 1 sarà quella backdoored in questo scenario).
|
||||
5. Seleziona il metodo POST creato e nelle Actions seleziona **`Deploy API`**
|
||||
6. Ora, quando **chiami la function via POST your Backdoor** verrà invocato
|
||||
|
||||
### Attivatore Cron/Event
|
||||
### Cron/Event actuator
|
||||
|
||||
Il fatto che puoi fare in modo che le funzioni Lambda vengano eseguite quando qualcosa succede o dopo che passa del tempo rende Lambda un modo comune e comodo per ottenere persistenza ed evitare il rilevamento.\
|
||||
Ecco alcune idee per rendere la tua **presenza in AWS più stealth creando Lambda**.
|
||||
Il fatto che tu possa far **eseguire funzioni Lambda quando succede qualcosa o quando passa del tempo** rende Lambda un modo comune e utile per ottenere persistenza ed evitare il rilevamento.\
|
||||
Qui ci sono alcune idee per rendere la tua **presenza in AWS più stealth creando Lambda**.
|
||||
|
||||
- Every time a new user is created lambda generates a new user key and send it to the attacker.
|
||||
- Every time a new role is created lambda gives assume role permissions to compromised users.
|
||||
- Every time new cloudtrail logs are generated, delete/alter them
|
||||
- Ogni volta che viene creato un nuovo user, una lambda genera una nuova user key e la invia all'attacker.
|
||||
- Ogni volta che viene creato un nuovo role, una lambda assegna permessi di assume role agli utenti compromessi.
|
||||
- Ogni volta che vengono generati nuovi cloudtrail logs, cancellali/modificali
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Abusa della variabile d'ambiente `AWS_LAMBDA_EXEC_WRAPPER` per eseguire uno script wrapper controllato dall'attacker prima che il runtime/handler inizi. Distribuisci il wrapper via un Lambda Layer in `/opt/bin/htwrap`, imposta `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, e poi invoca la funzione. Il wrapper gira all'interno del processo runtime della funzione, eredita il ruolo di esecuzione della funzione, e infine `exec` il runtime reale così l'handler originale viene ancora eseguito normalmente.
|
||||
Abusa della variabile d'ambiente `AWS_LAMBDA_EXEC_WRAPPER` per eseguire uno wrapper script controllato dall'attacker prima che il runtime/handler inizi. Distribuisci lo wrapper tramite un Lambda Layer in `/opt/bin/htwrap`, imposta `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, e poi invoca la function. Lo wrapper gira all'interno del processo runtime della function, eredita il ruolo di esecuzione della function, e infine esegue con `exec` il runtime reale così che l'handler originale continui a essere eseguito normalmente.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Esposizione pubblica di Lambda Function URL
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Abusa di Lambda asynchronous destinations insieme alla Recursion configuration per fare in modo che una funzione si richiami continuamente senza uno scheduler esterno (no EventBridge, cron, ecc.). Per default, Lambda termina i loop ricorsivi, ma impostando la recursion config su Allow li si riabilita. Le destinations consegnano lato servizio per async invokes, quindi una singola seed invoke crea un stealthy, code-free heartbeat/backdoor channel. Facoltativamente limita con reserved concurrency per mantenere il rumore basso.
|
||||
Abusa delle asynchronous destinations di Lambda insieme alla configurazione di Recursion per far sì che una function si reinvii continuamente senza uno scheduler esterno (nessun EventBridge, cron, ecc.). Di default, Lambda termina i loop ricorsivi, ma impostando la recursion config su Allow li si riabilita. Le destinations eseguono la consegna lato servizio per gli invoke asincroni, quindi un singolo invoke seed crea un canale stealthy, senza codice, per heartbeat/backdoor. Opzionalmente limita il traffico con reserved concurrency per mantenere il rumore basso.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Crea una versione nascosta della Lambda con logica dell'attacker e scope una resource-based policy a quella specifica versione (o alias) usando il parametro `--qualifier` in `lambda add-permission`. Concedi solo `lambda:InvokeFunction` su `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a un attacker principal. Le invocazioni normali tramite il nome della funzione o l'alias primario rimangono inalterate, mentre l'attacker può invocare direttamente l'ARN della versione backdoored.
|
||||
Crea una versione nascosta della Lambda con la logica dell'attacker e scope una resource-based policy a quella specifica versione (o alias) usando il parametro `--qualifier` in `lambda add-permission`. Concedi solo `lambda:InvokeFunction` su `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a un principal attacker. Le invocazioni normali via nome della function o alias primario rimangono invariate, mentre l'attacker può invocare direttamente l'ARN della versione backdoored.
|
||||
|
||||
Questo è più stealth rispetto all'esporre una Function URL e non cambia l'alias principale del traffico.
|
||||
Questo è più stealth rispetto all'esporre una Function URL e non cambia l'alias di traffico primario.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
Un attacker che abbia i permessi lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, e lambda:GetRuntimeManagementConfig può modificare la runtime management configuration di una function. Questo attacco è particolarmente efficace quando l'obiettivo è mantenere una Lambda su una versione di runtime vulnerabile o preservare la compatibilità con layer maligni che potrebbero essere incompatibili con runtime più recenti.
|
||||
|
||||
L'attacker modifica la runtime management configuration per fissare la versione del runtime:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
Verifica la configurazione applicata:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Opzionale: bloccare su una versione specifica del runtime
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
Blocca su una versione specifica del runtime:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user