Attacchi SSRF: come viene sfruttato il DNS

Il server-side request forgery (SSRF) si verifica quando un attaccante induce un server a fare per suo conto una richiesta HTTP (o di altro tipo di rete) verso una destinazione scelta da lui e non dallo sviluppatore dell'applicazione. Un vettore classico è una funzione che recupera un URL fornito dall'utente (l'importazione di un'immagine, la destinazione di un webhook, l'anteprima di un link) e l'attaccante fornisce un URL che punta all'infrastruttura interna invece che a una risorsa pubblica.

Dove entra in gioco il DNS nell'attacco

La difesa ingenua è controllare se l'hostname dell'URL fornito somiglia a un indirizzo interno. Si aggira in modo banale: l'attaccante registra un dominio pubblico, fa puntare il suo record DNS a un IP interno e passa al tuo server un hostname perfettamente normale. La tua convalida vede un dominio, non un IP: la parte pericolosa emerge solo dopo la risoluzione DNS, che spesso avviene nel profondo della libreria client HTTP che effettua la richiesta, ben oltre qualsiasi passaggio di convalida iniziale.

Come si presenta una protezione vera

• Risolvi tu stesso l'hostname, in modo esplicito, prima di fare qualsiasi richiesta: non lasciare che un client HTTP lo risolva in modo invisibile al posto tuo.
• Controlla ogni indirizzo risolto (tutti: un dominio può restituirne diversi) confrontandolo con una blocklist di indirizzi privati, loopback, link-local e di metadati cloud.
• Rifiuta la richiesta se anche solo uno degli indirizzi risolti non è consentito, invece di controllare soltanto il primo restituito.
• Riconvalida al momento della richiesta, non solo al momento dell'input, per chiudere la falla del DNS rebinding descritta a parte: nella pratica SSRF e rebinding vengono spesso combinati.

Gli endpoint dei metadati cloud meritano qui una menzione speciale: sulla maggior parte dei provider cloud, una richiesta dall'interno di una VM verso uno specifico indirizzo link-local può restituire credenziali, metadati dell'istanza o configurazioni che non erano mai pensati per essere raggiungibili dall'esterno della macchina. L'SSRF combinato con un endpoint di metadati come bersaglio è una delle catene di sfruttamento più comuni e di maggior impatto nel mondo reale, e parte, ogni volta, da un nome di dominio dall'aspetto ordinario.

I filtri che controllano la stringa e non l'indirizzo non funzionano

Un indirizzo IP ha più rappresentazioni testuali valide di quante ne considerino la maggior parte dei codici di convalida. Un filtro scritto come confronto di stringa con «127.0.0.1» o «localhost» lascia passare indisturbata ciascuna delle forme alternative qui sotto, perché nessuna somiglia alla stringa cercata.

L'unica difesa affidabile interpreta prima l'indirizzo nel suo vero valore numerico e valuta la blocklist su quello: esattamente l'approccio adottato dal resolver di questo strumento, invece di cercare corrispondenze di pattern su come l'indirizzo sia stato scritto. Un resolver restituisce un indirizzo normalizzato a prescindere da come il record dell'hostname originale lo abbia codificato, ed è proprio per questo che risolvere prima e convalidare il risultato risolto è più robusto che cercare di convalidare una stringa grezza in ogni forma che un attaccante possa scegliere di scrivere.

I redirect sono l'altro aggiramento comune

Anche un sistema che risolve e convalida correttamente l'URL iniziale può essere comunque colto di sorpresa da un redirect HTTP. Una richiesta a un URL pubblico approvato può rispondere con un 302 che punta a un indirizzo interno, e un client HTTP che segue automaticamente i redirect (il comportamento predefinito nella maggior parte delle librerie) farà senza problemi quella seconda richiesta senza mai rieseguire la convalida superata la prima volta. Qualsiasi difesa SSRF che convalida una sola volta, in anticipo, e poi lascia gestire i redirect al client HTTP sottostante ha una falla della stessa forma di quella creata dalla risoluzione DNS, e anche la soluzione è la stessa: convalida di nuovo, esplicitamente, prima di seguire qualsiasi redirect, invece di fidarti che un URL che ha superato il controllo una volta continui a puntare a qualcosa di sicuro.