Endpoint metadati cloud: la superficie d'attacco nascosta

Ogni grande provider cloud espone un servizio di metadati dell'istanza alle macchine virtuali che girano sulla sua piattaforma, in genere raggiungibile all'indirizzo link-local 169.254.169.254. Dall'interno dell'istanza, una semplice richiesta HTTP a quell'indirizzo può restituire la configurazione dell'istanza, i dettagli di rete e, in molte configurazioni predefinite, credenziali di sicurezza temporanee per il ruolo o l'identità assegnati all'istanza.

Perché è pericoloso soprattutto in combinazione con SSRF

L'endpoint dei metadati dovrebbe essere raggiungibile solo dall'istanza stessa e non è esposto a Internet. Ma se un processo lato server può essere indotto a inviare una richiesta HTTP a un indirizzo scelto dall'attaccante (il classico SSRF) e quell'indirizzo è proprio l'endpoint dei metadati, l'attaccante fa recuperare al server le sue stesse credenziali cloud e se le fa restituire nella risposta. Non serve alcun accesso di rete diretto all'endpoint dei metadati dall'esterno: il recupero lo fa il server vulnerabile per conto dell'attaccante.

• 169.254.169.254 rientra nell'intervallo link-local più ampio 169.254.0.0/16, che non dovrebbe mai essere considerato una destinazione legittima per una risoluzione DNS pubblica.
• Alcuni provider sono passati a una versione del servizio di metadati protetta da token, proprio per alzare l'asticella contro gli SSRF più ingenui, ma bloccare del tutto l'indirizzo a livello applicativo resta la difesa più robusta.
• È esattamente per questo che gli indirizzi link-local vanno inseriti nella stessa blocklist degli intervalli privati e di loopback in qualsiasi strumento che risolva domini forniti dall'utente: non sono una categoria di rischio separata e minore.

La lezione pratica

Qualsiasi sistema che risolve e richiede un URL per conto di un utente deve trattare 169.254.169.254, e l'intero intervallo link-local a cui appartiene, come rigorosamente off-limits, con un controllo eseguito al momento della richiesta effettiva, ogni volta, a prescindere da come si sia arrivati a quell'indirizzo (digitato direttamente o raggiunto tramite un record DNS che punta proprio lì).

Non riguarda un solo provider cloud

169.254.169.254 è la convenzione di AWS, Google Cloud e Azure, ma lo schema di fondo, un indirizzo link-local che espone identità e credenziali dell'istanza solo all'istanza stessa, si ritrova in qualche forma in praticamente tutte le principali piattaforme cloud e di container, a volte allo stesso indirizzo, a volte a uno specifico del provider. I cluster Kubernetes hanno spesso i propri endpoint interni simili ai metadati, raggiungibili dall'interno di un pod. Vale la pena memorizzare l'indirizzo dei provider cloud più comuni, ma la parte che si generalizza davvero è il principio: considera ogni endpoint in stile metadati off-limits per qualsiasi componente che risolva e recuperi un URL fornito dall'utente, indipendentemente dalla piattaforma su cui gira.

IMDSv2: una vera mitigazione, non solo un filtro

La risposta di AWS ad anni di sfruttamento proprio di questo schema è stata una seconda versione del suo servizio di metadati, IMDSv2, che richiede un token di sessione ottenuto con una speciale richiesta PUT prima di poter leggere qualsiasi metadato. Aspetto cruciale: quella richiesta PUT non può essere replicata da una semplice richiesta GET innescata da un SSRF, che è proprio quella che la maggior parte dei percorsi di codice vulnerabili effettua.

È un miglioramento significativo, ma su molti account è facoltativo per ragioni di retrocompatibilità e protegge solo l'endpoint dei metadati: non fa nulla per tutti gli altri indirizzi privati e interni che un SSRF potrebbe comunque raggiungere. Il filtraggio a livello applicativo degli indirizzi risolti resta necessario, a prescindere dalla versione del servizio di metadati in uso.