AWS - S3 Post Exploitation

Reading time: 4 minutes

S3

Per maggiori informazioni consulta:

AWS - S3, Athena & Glacier Enum

Informazioni sensibili

Talvolta potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, i segreti dello terraform state.

Pivoting

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'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'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 è 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'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'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'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 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.

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

s3:Delete*

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.

# 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 check the original research.