Metadati e SSRF

Ogni VM cloud può interrogare un endpoint interno speciale per ottenere informazioni su se stessa: il servizio di metadati dell'istanza (IMDS). Cosa fondamentale, può anche fornire le credenziali temporanee del ruolo associato all'istanza.

• AWS / GCP / Azure espongono tutti i metadati all'indirizzo 169.254.169.254
• È raggiungibile solo dall'interno dell'istanza
• Non richiede autenticazione ai processi locali

Questa comodità diventa un'arma se combinata con una SSRF.

Nell'ormai obsoleto IMDSv1, una singola richiesta GET restituisce i metadati, incluse le credenziali del ruolo. Non è richiesto alcun token.

È proprio questo che rende pericoloso IMDSv1 quando un'applicazione presenta una SSRF.

La Server-Side Request Forgery (SSRF) è una vulnerabilità in cui un attaccante induce un server a effettuare richieste HTTP per suo conto. Il server diventa un proxy verso luoghi che l'attaccante non può raggiungere direttamente.

• Un parametro URL che il server recupera
• Un webhook, un generatore di PDF o una funzionalità di ridimensionamento delle immagini
• Qualsiasi elemento che accetti un URL fornito dall'utente

Nel cloud, l'obiettivo classico di una SSRF è l'endpoint dei metadati.

La combinazione letale è questa: un'applicazione con una SSRF consente all'attaccante di indirizzare il server verso 169.254.169.254. Il server recupera le credenziali IAM dell'istanza e le restituisce.

A questo punto l'attaccante possiede credenziali cloud, spesso il primo passo verso la compromissione completa dell'account.

La risposta dei metadati contiene una chiave di accesso, una chiave segreta e un token di sessione. L'attaccante le esporta e agisce immediatamente assumendo il ruolo dell'istanza.

Da qui può enumerare i permessi e cercare percorsi per l'escalation dei privilegi.

AWS ha introdotto IMDSv2 per attenuare il rischio delle SSRF. Richiede prima un token di sessione ottenuto tramite una richiesta HTTP PUT, che la maggior parte dei meccanismi SSRF non è in grado di eseguire, poiché supporta solo GET.

Imporre IMDSv2 e impostare un limite di hop basso riduce drasticamente il furto dei metadati tramite SSRF.

Anche gli altri provider espongono metadati, con alcune specificità. Entrambi richiedono un'intestazione speciale, che costituisce di per sé una piccola mitigazione contro le SSRF.

• Azure richiede Metadata: true
• GCP richiede Metadata-Flavor: Google

I difensori spesso bloccano 169.254.169.254. Gli attaccanti aggirano i filtri ingenui usando rappresentazioni alternative degli indirizzi IP e reindirizzamenti.

• IP decimale: 2852039166
• Rappresentazioni ottali/esadecimali dello stesso indirizzo
• DNS rebinding verso un nome che risolve nell'IP dei metadati
• Open redirect che inoltrano la richiesta all'URL dei metadati

Le difese solide devono convalidare l'IP risolto, non la stringa originale.

I metadati sono l'obiettivo principale, ma una SSRF può raggiungere altre risorse interne:

• Pannelli e dashboard di amministrazione interni associati a localhost
• Database e cache interni (Redis, Elasticsearch)
• Server API Kubernetes ed endpoint kubelet
• Altri microservizi non esposti esternamente

Una SSRF perfora di fatto il perimetro di rete da un punto di osservazione attendibile.

Per interrompere la catena SSRF-metadati è necessaria una difesa a più livelli:

• Imporre IMDSv2 e impostare a 1 il limite di hop dei metadati
• Convalidare gli URL in uscita e inserirli in una allowlist nelle funzionalità di recupero
• Bloccare le richieste verso gli intervalli IP link-local e privati dopo la risoluzione DNS
• Applicare il principio del privilegio minimo ai ruoli delle istanze, così da limitare le credenziali rubate

I ruoli con privilegi minimi garantiscono che anche un furto riuscito produca danni limitati.

I test per le SSRF possono raggiungere, per loro natura, sistemi interni sensibili. Proceda con disciplina:

• Confermi che l'host di destinazione e l'account cloud rientrino nell'ambito autorizzato
• Non utilizzi i sistemi al di fuori dell'incarico come punto di passaggio
• Si fermi e segnali il problema non appena avrà dimostrato l'accesso alle credenziali

Raggiungere i metadati ha un impatto elevato: lo dimostri con cautela e non utilizzi indiscriminatamente le chiavi rubate.

Ha appreso la catena d'attacco specifica del cloud con il maggiore impatto.

• Il servizio di metadati all'indirizzo 169.254.169.254 fornisce le credenziali del ruolo dell'istanza
• La SSRF consente all'attaccante di fare in modo che il server recuperi quell'endpoint
• Le credenziali temporanee rubate consentono di compromettere l'account
• IMDSv2 blocca la maggior parte delle SSRF richiedendo un token basato su PUT
• Si difenda con allowlist degli URL, convalida degli IP e ruoli con privilegi minimi

Con questo si conclude il pentesting cloud. Prossimo corso: Bug Bounty Hunting.