mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-02 07:50:00 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-persistence/aws-lambd
This commit is contained in:
@@ -1,64 +1,91 @@
|
||||
# AWS - Lambda Persistence
|
||||
# AWS - Persistenza di Lambda
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda
|
||||
|
||||
Per ulteriori informazioni controlla:
|
||||
Per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistenza del Lambda Layer
|
||||
### Persistenza con Lambda Layer
|
||||
|
||||
È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando il lambda viene eseguito in modo furtivo:
|
||||
È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando la Lambda viene eseguita in modo stealthy:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistenza dell'Estensione Lambda
|
||||
### Persistenza con Lambda Extension
|
||||
|
||||
Abusando dei Lambda Layers è anche possibile abusare delle estensioni e persistere nel lambda ma anche rubare e modificare le richieste.
|
||||
Abusando dei Lambda Layers è anche possibile abusare delle extension e persistere nella Lambda oltre a rubare e modificare le richieste.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### Tramite politiche delle risorse
|
||||
### Tramite resource policies
|
||||
|
||||
È possibile concedere accesso a diverse azioni lambda (come invocare o aggiornare il codice) a account esterni:
|
||||
È possibile concedere accesso a diverse azioni di Lambda (ad esempio invoke o update code) ad account esterni:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versioni, Alias e Pesi
|
||||
|
||||
Un Lambda può avere **diverse versioni** (con codice diverso per ogni versione).\
|
||||
Poi, puoi creare **diversi alias con diverse versioni** del lambda e impostare pesi diversi per ciascuno.\
|
||||
In questo modo un attaccante potrebbe creare una **versione 1 backdoored** e una **versione 2 con solo il codice legittimo** e **eseguire solo la versione 1 nel 1%** delle richieste per rimanere furtivo.
|
||||
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.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Backdoor della Versione + API Gateway
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Copia il codice originale del Lambda
|
||||
2. **Crea una nuova versione backdooring** il codice originale (o solo con codice malevolo). Pubblica e **deplora quella versione** su $LATEST
|
||||
1. Chiama l'API gateway relativo al lambda per eseguire il codice
|
||||
3. **Crea una nuova versione con il codice originale**, Pubblica e deplo quella **versione** su $LATEST.
|
||||
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.
|
||||
1. Questo nasconderà il codice backdoored in una versione precedente
|
||||
4. Vai all'API Gateway e **crea un nuovo metodo POST** (o scegli un altro metodo) che eseguirà la versione backdoored del 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 funzione** (la versione 1 sarà quella backdoored in questo scenario).
|
||||
5. Seleziona il metodo POST creato e in Azioni seleziona **`Deploy API`**
|
||||
6. Ora, quando **chiami la funzione via POST la tua Backdoor** sarà invocata
|
||||
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
|
||||
|
||||
### Attuatore Cron/Event
|
||||
### Attivatore Cron/Event
|
||||
|
||||
Il fatto che puoi far **eseguire funzioni lambda quando accade qualcosa o quando passa del tempo** rende lambda un modo piacevole e comune per ottenere persistenza ed evitare il rilevamento.\
|
||||
Ecco alcune idee per rendere la tua **presenza in AWS più furtiva creando lambdas**.
|
||||
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**.
|
||||
|
||||
- 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
|
||||
|
||||
### 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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Esposizione pubblica di Lambda Function URL
|
||||
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### 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.
|
||||
|
||||
Questo è più stealth rispetto all'esporre una Function URL e non cambia l'alias principale del traffico.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
- Ogni volta che viene creato un nuovo utente, lambda genera una nuova chiave utente e la invia all'attaccante.
|
||||
- Ogni volta che viene creata una nuova funzione, lambda concede permessi di assunzione del ruolo agli utenti compromessi.
|
||||
- Ogni volta che vengono generati nuovi log di cloudtrail, cancellali/modificali
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user