Una vulnerabilità di tipo SSRF si verifica quando una Web Application consente ad un utente malitenzionato di indurre il server a compiere azioni che potrebbero essere considerate dannose e/o non autorizzate, come per esempio: richieste a file locali del server, richieste ad altre porte e/o servizi del server o richieste ad altri dispositivi all’interno della rete per ottenere informazioni utili o accessi indebiti ai dati.
Gli impatti di questa vulnerabilità potrebbero essere diversi:
- Accesso non autorizzato a risorse interne alla rete: l’utente, potrebbe visualizzare o accedere ad alcune risorse attraverso questo tipo di vulnerabilità. Se il server ha accesso a dispositivi interni come NAS o altri server, l’attaccante potrebbe ottenere informazioni importanti riguardo a questi.
- Accesso a file locali del server stesso: se non è stato implementato nessun tipo di filtraggio, l’utente potrebbe essere in grado di ottenere il contenuto dei file locali come logs, file di configurazione, codici sorgenti, ed altro, attraverso l’URL “file:///”.
- L’utente potrebbe manipolare le richieste in modo da creare disservizi al server causando così possibili perdite di dati e/o DoS al server stesso.
- Un attaccante potrebbe sfruttare l’applicativo vulnerabile a SSRF per inviare continue richieste per conto del server per eseguire attacchi DDoS in altri target.
- In alcuni casi, anche se rari, questa vulnerabilità potrebbe portare ad una RCE, questo dipende da molti fattori e dalle configurazioni del web server messe in atto; anche se questa potrebbe essere una possibilità remota, potrebbe comunque esistere e causare una compromissione del server e un accesso indebito alla rete
L’impatto più comune e causato maggiormente da questa vulnerabilità riguarda l’accesso non autorizzato a risorse interne alla rete, cioè la possiblità di manipolare le richieste effettuate dall’applicativo web per ottenere accesso ad informazioni su dispositivi interni alla rete a cui il server ha accesso.
Esistono 3 tipologie d’attacco che possono essere categorizzate in base al modo in cui avviene la risposta della richiesta del server:
- Non-Blind SSRF: questa tipologia permette di visualizzare la risposta alla richiesta effettuata al server, ciò permette all’attaccante di ottenere le informazioni richieste riguardo al server stesso e/o alla rete interna.
- Semi-Blind SSRF: questa tipologia di vulnerabilità permettere una parziale visione dell’output che potrebbe aiutare l’attaccante a ricavare informazioni con le richieste effettuate.
- Blind SSRF: questa tipologia di attacco è la più difficile da sfruttare, in quanto l’attaccante non ha un output “visivo” di come il server sta rispondendo alla richiesta. Solitamente, se l’attaccante trova questa tipologia, può sfruttare la vulnerabilità per creare disservizi, in quanto potrebbe essere difficile ottenere informazioni con questa tipologia di attacco.
Nel primo esempio d’attacco si vuole prendere come esempio la tipologia di attacco Non-Blind SSRF, in cui dopo aver effettuato la richiesta al server, esso risponde con la risposta completa della pagina; qui sotto andremo ad analizzare due esempi di questo tipo:
Scenari D’Attacco:
Il server in questione possiede la porta 80 accessibile in tutta la rete e la porta 8000, accessibile solamente da localhost. Eseguiamo, all’interno dell’input vulnerabile, una richiesta HTTP all’indirizzo http://127.0.0.1:8000/admin.html. Questo URL punta all’altra Web Application, che è accessibile solo in locale del server: infatti, come si può vedere, la web app vulnerabile ha fatto una semplice richiesta per conto suo al suo stesso localhost, poi attraverso la visualizzazione della risposta abbiamo effettivamente notato che esiste un’altra web app in locale in cui, in questo caso, è possibile anche eseguire azioni e interagire con essa:
Sempre usando la tipologia Non-Blind SSRF, facciamo un altro esempio usando l’URL locale “file:///” per visualizzare i file locali, in questo caso ho fatto l’esempio con il file “/etc/hosts” in questo modo:
In caso di vulnerabilità di tipo Blind-SSRF, l’attaccante non ha la possibilità di visualizzare l’output della risposta alla richiesta. Per verificare se il server è effettivamente vulnerabile a SSRF, è possibile creare un piccolo web server nella macchina dell’attaccante in modo tale da poter fare la richiesta a lui. In questo modo, è possibile visualizzare se il server esegue effettivamente le richieste:
Per difendersi da questa vulnerabilità ci sono diverse possibili tecniche da poter applicare:
- Come nelle iniezioni SQL e XSS, tutti i dati inseriti negli input e nei parametri dovrebbero essere sanificati e validati, questa regola vale anche per questa tipologia di vulnerabilità poichè l’utente potrebbe inserire del codice malevolo ovunque. Esempio: se la funzione della web app è quella di effettuare solo la richiesta http o https, sarebbe consigliato fare un filtro di validazione in modo tale che l’utente possa eseguire solo questo tipo di richieste e non anche altre come potrebbe essere: “file:///”
- Utilizzare librerie e framework che offrono protezione basata su codice.
- Controllare le risposte del server alle richieste dell’utente in modo da non esporre troppi dati ma solamente quelli strettamente neccessari per il funzionamento corretto dell’applicativo.
- Segregare in modo corretto il web server in modo da ridurre l’impatto della vulnerabilità.
- Implementare WAF e/o IPS potrebbe essere un buon metodo per filtrare le richieste interne che il server può fare, per esempio monitorare le richieste ai file interni come /etc/passwd, ed altri.
- Configurare in modo opportuno il Web Server, il Reverse Proxy e l’ambiente di produzione in modo da evitare di esporre file locali e informazioni di altri dispositivi all’interno della rete.
- Implementare una Whitelist o una Blacklist (in base alla funzione dell’applicativo) di URL in modo da limitare gli accessi del server alle risorse interne.