damian89/extended-ssrf-searchScanner ssrf intelligente che utilizza diversi metodi come brute forcing dei parametri in POST e GET...
Questo strumento cerca SSRF utilizzando impostazioni predefinite in diverse parti di una richiesta (percorso, host, header, parametri POST e GET).
Rinomina example.app-settings.conf in app-settings.conf e regola le impostazioni. L'impostazione più importante è l'URL di callback. Raccomando di usare Burp Collaborator. Poi puoi aggiungere i tuoi URL a config/url-to-test.txt. Qui lo script accetta sia domini che URL con percorso e parametri query. Se vuoi, puoi aggiungere i tuoi cookie a config/cookie-jar.txt e aggiungere header aggiuntivi per le tue richieste. La lista di brute force utilizzata nelle richieste POST e GET è attualmente piccola; non penso che aggiungere 2000 parametri sia saggio. Dovremmo concentrarci su quelli con la più alta probabilità di essere vulnerabili. Se non sei d'accordo: aggiungi i tuoi!
Questo strumento non accetta argomenti da CLI, quindi basta digitare:
python3 extended-ssrf-search.py
È possibile impostare molte opzioni e impostazioni, quindi ecco alcune spiegazioni.
Il file di configurazione principale è "app-settings.conf", tutto deve essere fatto in quel file! Oltre a quello, ci sono altri file che permettono di impostare dati più complessi come header, URL e cookie.
config/cookie-jar.txt
Usa questo file per aggiungere una stringa di cookie. Di solito copio quella che si vede in ogni richiesta Burp. Per favore, copia solo il valore dell'header "Cookie:". Un esempio di input è nel file predefinito.
config/http-headers.txt
Questo file definisce gli header HTTP che vengono aggiunti alla richiesta e manipolati (il payload viene aggiunto a ciascuno). I più importanti sono già nel file. Ma sentiti libero di aggiungerne altri.
config/parameters.txt
Lo strumento ha l'opzione di fare brute force sui parametri GET e POST. In quel caso, quei parametri (più quelli nella query string) verranno utilizzati. Ogni parametro riceve il payload come valore. I più importanti sono già in quel file.
config/static-request-headers.txt
Questi header vengono aggiunti a ogni richiesta, ma non vengono manipolati. Sono statici. Questo è il posto migliore per aggiungere cookie di autorizzazione o bearer. Una coppia (Chiave: Valore) per riga!
config/urls-to-test.txt
Questo è il file che ti serve! Per favore aggiungi qui i tuoi link da scansionare. Sono ammessi i seguenti formati:
Quando viene rilevato l'ultimo caso, viene anteposto "http://". Questo strumento è pensato per funzionare con una buona lista di URL. Un buon modo per ottenerne una è esportarla usando Burp. Poi hai una lista valida di URL. Tutto ciò che devi fare è aggiungere i tuoi cookie.
app-settings.conf definisce il flusso di lavoro del programma. È il file più importante, puoi attivare/disattivare diversi moduli lì.
CallbackHost
L'URL/host a cui vengono inviate tutte le richieste DNS e HTTP - di solito uso Burp Collaborator qui, ma anche DNSBin o il tuo server sono perfetti.
HTTPMethod
Definisce il metodo di richiesta. Opzioni valide: GET, POST, PUT, DELETE, PATCH, GET, OPTIONS. Valori non validi produrranno errori massicci poiché http.client non consente altri metodi! Non controllo se hai sbagliato qui ;)
HTTPTimeout
Alcune richieste possono richiedere molto tempo. Qui puoi definire il tempo massimo di esecuzione di una richiesta. Raccomando valori tra 2 e 6 secondi.
MaxThreads
Più thread, più veloce è lo script - ma poiché abbiamo a che fare con molte connessioni, di solito lo tengo sotto 10 sul mio computer personale e intorno a 30 sul mio VPS.
ShuffleTests
Soprattutto quando si ha a che fare con una GRANDE lista di URL, impostare questo su "true" mescolerà tutti i test creati. In questo modo lo stesso host non verrà colpito così tanto. Se scansionate un solo host, non ha importanza.
GetChunkSize
Quando si lavora con liste di parametri più grandi, questo può essere utile e prevenire errori di entità troppo grande 400.
Ogni punto di inserimento può essere attivato (impostato su true/1) o disattivato (impostato su false/0).
InPath
L'esempio mostra una richiesta GET, ma a seconda delle impostazioni, potrebbe essere anche POST, PUT, DELETE, ...
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
L'esempio mostra una richiesta GET, ma a seconda delle impostazioni, potrebbe essere anche POST, PUT, DELETE, ...
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
L'esempio mostra una richiesta GET, ma a seconda delle impostazioni, potrebbe essere anche POST, PUT, DELETE, ...
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
Qui il metodo è fissato a GET.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
Qui il metodo è fissato a POST.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
Qui il metodo è fissato a POST.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
Nelle impostazioni predefinite, questo strumento cerca solo di attivare richieste HTTP tramite SSRF. Ma è anche possibile esfiltrare dati usando DNS, quando viene iniettato un comando del sistema operativo. Il payload più comune è "$(hostname)". Ci sono alcune opzioni che permettono di utilizzare ulteriormente questo tipo di attacco.
UseExecPayload
Usando questa impostazione puoi attivare/disattivare questo comportamento.
ExecPayload
Qui puoi definire il tuo payload, ad esempio $(uname -a)
Per rendere l'identificazione un po' più facile, una combinazione di host corrente e metodo (in forma breve, vedi Tests.py) viene aggiunta alla fine o all'inizio del payload.
Position
Le opzioni valide sono "append" e "prepend"!
Se viene scelto "append", i payload appaiono così:
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
Se viene scelto "prepend", i payload appaiono così:
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
È anche possibile usare un tunnel, ad esempio "127.0.0.1:8080" (Burp Proxy), per monitorare tutto il traffico all'interno di Burp.
Active
Impostando questo su "true" si forza lo script a usare una connessione tunnelizzata.
Tunnel
Imposta qui il tuo server proxy "ip:port".
Il risultato è il seguente: quando apri Burp puoi vedere la tua cronologia HTTP:
Per favore crea una issue e contrassegnala come richiesta di funzionalità.
Ti piace questo strumento? Ti ha aiutato a ottenere una bounty? Vuoi dare qualcosa in cambio/supportarmi? Perché no!