AWS - S3 Post Exploitation

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

S3

Per maggiori informazioni consulta:

AWS - S3, Athena & Glacier Enum

Informazioni sensibili

A volte potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, terraform state secrets.

Pivoting

Diverse piattaforme possono usare S3 per memorizzare asset sensibili.
Per esempio, airflow potrebbe memorizzare lĂŹ il DAGs code, oppure web pages potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe modify the code dal bucket per pivot verso altre piattaforme, o takeover accounts modificando file JS.

S3 Ransomware

In questo scenario, l’attaccante crea una KMS (Key Management Service) key nel proprio account AWS o in un altro account compromesso. Rende quindi questa key accessibile a chiunque nel mondo, permettendo a qualsiasi utente, ruolo o account AWS di cifrare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decifrati.

L’attaccante individua un target S3 bucket e ottiene accesso in scrittura su di esso usando vari metodi. Questo può essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente o all’attaccante che guadagna accesso all’ambiente AWS stesso. Tipicamente l’attaccante prende di mira bucket che contengono informazioni sensibili come PII, PHI, log, backup e altro.

Per determinare se il bucket può essere preso di mira per 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 ransomware quel specifico bucket.

Usando l’AWS API, 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’attaccante programma la cancellazione della KMS key usata nell’attacco. Questo dà al target una finestra di 7 giorni per recuperare i dati prima che la key venga cancellata e i dati vadano perduti in modo permanente.

Infine, l’attaccante potrebbe caricare un file finale, solitamente chiamato “ransom-note.txt”, che contiene istruzioni per il target su come recuperare i propri file. Questo file viene caricato senza cifratura, probabilmente per attirare l’attenzione del target e renderlo consapevole dell’attacco ransomware.

SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)

Un’altra variante è l’abuso di SSE-C (S3 server-side encryption with customer-provided keys). Con SSE-C, il client fornisce la chiave di cifratura ad ogni richiesta e AWS non memorizza la chiave. Questo significa che se un attaccante riscrive oggetti usando la propria SSE-C key, i dati della vittima diventano illeggibili a meno che la vittima non possa fornire quella chiave controllata dall’attaccante.

  • Precondizioni: Credenziali AWS compromesse (o qualsiasi principal con i permessi corretti) e la capacitĂ  di rewrite objects (es., s3:PutObject sulle chiavi/prefissi target). Questo è spesso abbinato alla capacitĂ  di impostare lifecycle policies distruttive (vedi sotto), es. s3:PutLifecycleConfiguration.
  • Catena di attacco:
  1. L’attaccante genera una chiave casuale a 256-bit (AES-256) e la conserva.
  2. L’attaccante riscrive gli oggetti esistenti (stesse object keys) usando header SSE-C in modo che l’oggetto memorizzato sia ora cifrato con la key dell’attaccante.
  3. La vittima non può scaricare/decifrare senza fornire la SSE-C key (anche se i permessi IAM sono a posto).
  4. L’attaccante può cancellare la key (o semplicemente non fornirla mai) per rendere i dati irrimediabili.

Esempio (concettuale) di utilizzo CLI:

# Upload/overwrite an object encrypted with attacker-provided SSE-C key
aws s3 cp ./file s3://<BUCKET>/<KEY> \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>

# Download requires providing the same key again
aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
Aumentare la pressione: abuso del “timer” del ciclo di vita

Per rimuovere opzioni di ripristino (come versioni precedenti), gli attaccanti possono abbinare riscritture SSE-C con regole del ciclo di vita che fanno scadere gli oggetti e/o cancellano le versioni non correnti dopo un breve periodo:

  • s3:PutLifecycleConfiguration sul bucket permette a un attaccante di pianificare cancellazioni senza eseguire operazioni di delete esplicite per ogni oggetto/versione.
  • Questo è particolarmente impattante quando versioning è abilitato, perchĂŠ può rimuovere la “versione precedente valida” che altrimenti permetterebbe il ripristino.
Rilevamento & Mitigazioni
  • Preferire SSE-KMS (o SSE-S3) rispetto a SSE-C a meno che non ci sia una forte esigenza operativa per consentire SSE-C.
  • Monitorare/allertare le richieste PutObject che usano header SSE-C (CloudTrail data events per S3).
  • Monitorare/allertare su PutBucketLifecycleConfiguration inaspettati (modifiche al lifecycle).
  • Monitorare/allertare su picchi improvvisi nell’attivitĂ  di overwrite (stesse chiavi aggiornate rapidamente) e su delete-marker/cancellazioni di versioni.
  • Restringere i permessi ad alto rischio: limitare s3:PutObject ai prefissi necessari; restringere fortemente s3:PutLifecycleConfiguration e s3:PutBucketVersioning; considerare di richiedere MFA per azioni amministrative sensibili (quando applicabile) e usare ruoli amministrativi separati con approvazioni.
  • Approccio al recupero: usare versioning, backup e copie immutabili/offline (S3 replication verso account protetto, vault di backup, ecc.); proteggere le versioni non correnti dalle cancellazioni aggressive e tutelare le modifiche al lifecycle con SCPs / guardrails.

s3:RestoreObject

Un attaccante con il permesso s3:RestoreObject può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo abilita il ripristino e l’exfiltration di dati storicamente archiviati (backup, snapshot, log, 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.

aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'

s3:Delete*

Un attacker con il permesso s3:Delete* può eliminare oggetti, versioni e interi bucket, interrompere i backup e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione di backup o recovery artifacts.

# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>

Per maggiori informazioni consulta la ricerca originale.

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks