
Intelligenter SSRF-Scanner, der verschiedene Methoden wie Parameter-Brute-Force in POST und GET verwendet...
Dieses Tool sucht nach SSRF unter Verwendung vordefinierter Einstellungen in verschiedenen Teilen einer Anfrage (Pfad, Host, Header, POST- und GET-Parameter).
Benennen Sie example.app-settings.conf in app-settings.conf um und passen Sie die Einstellungen an. Die wichtigste Einstellung ist die Callback-URL. Ich empfehle die Verwendung von Burp Collaborator. Dann können Sie Ihre URLs zur Datei config/url-to-test.txt hinzufügen. Das Skript akzeptiert sowohl Domains als auch URLs mit Pfad und Query-Parametern. Wenn Sie möchten, können Sie Ihre eigenen Cookies zur Datei config/cookie-jar.txt hinzufügen und zusätzliche Header für Ihre Anfragen hinzufügen. Die Brute-Force-Liste, die in POST- und GET-Anfragen verwendet wird, ist derzeit klein. Ich glaube nicht, dass das Hinzufügen von 2000 Parametern sinnvoll ist. Wir sollten uns auf diejenigen konzentrieren, die die höchste Wahrscheinlichkeit haben, anfällig zu sein. Wenn Sie das nicht glauben: Fügen Sie einfach Ihre eigenen hinzu!
Dieses Tool erwartet keine Argumente über die CLI, geben Sie daher einfach Folgendes ein:
python3 extended-ssrf-search.py
Es ist möglich, viele Optionen und Einstellungen zu setzen, daher hier einige Erklärungen.
Die Hauptkonfigurationsdatei ist die „app-settings.conf“, alles muss in dieser Datei erledigt werden! Daneben gibt es einige andere Dateien, die das Setzen komplexerer Daten wie Header, URLs und Cookies ermöglichen.
config/cookie-jar.txt
Verwenden Sie diese Datei, um einen Cookie-String hinzuzufügen. Normalerweise kopiere ich den, den Sie in jeder Burp-Anfrage sehen können. Bitte kopieren Sie einfach den Wert des „Cookie:“-Headers. Eine Beispiel-Eingabe befindet sich in der Standarddatei.
config/http-headers.txt
Diese Datei definiert die HTTP-Header, die zur Anfrage hinzugefügt und manipuliert werden (jedem wird eine Payload hinzugefügt). Die wichtigsten sind bereits in der Datei enthalten. Aber fügen Sie ruhig weitere hinzu.
config/parameters.txt
Das Tool hat die Möglichkeit, GET- und POST-Parameter zu brute-forcen. In diesem Fall werden diese Parameter (+ die im Query-String) verwendet. Jeder Parameter erhält die Payload als Wert. Die wichtigsten sind bereits in dieser Datei enthalten.
config/static-request-headers.txt
Diese Header werden jeder Anfrage hinzugefügt, aber sie werden nicht manipuliert. Sie sind statisch. Das ist der beste Ort, um Autorisierungs- oder Bearer-Cookies hinzuzufügen. Einer (Key: Value) pro Zeile!
config/urls-to-test.txt
Das ist die Datei, die Sie brauchen! Bitte fügen Sie hier Ihre zu scannenden Links hinzu. Die folgenden Formate sind erlaubt:
Wenn der letzte Fall erkannt wird, wird ein „http://“ vorangestellt. Dieses Tool ist dafür gedacht, mit einer guten Liste von URLs zu arbeiten. Eine gute Möglichkeit, eine solche zu erhalten, ist, sie einfach mit Burp zu exportieren. Dann haben Sie eine gültige Liste von URLs. Alles, was Sie tun müssen, ist, Ihre Cookies hinzuzufügen.
Die Datei app-settings.conf definiert den Programmablauf. Sie ist die wichtigste Datei, dort können Sie verschiedene Module aktivieren/deaktivieren.
CallbackHost
Die URL/der Host, an den alle DNS- und HTTP-Anfragen zurückgesendet werden - ich verwende hier meistens Burp Collaborator, aber DNSBin oder ein eigener Server sind auch perfekt.
HTTPMethod
Definiert die Anfragemethode. Gültige Optionen sind: GET, POST, PUT, DELETE, PATCH, GET, OPTIONS Ungültige Werte führen zu massiven Fehlern, da http.client andere Methoden nicht erlaubt! Ich überprüfe nicht, ob Sie hier etwas falsch gemacht haben ;)
HTTPTimeout
Manche Anfragen können lange dauern. Hier können Sie die maximale Ausführungszeit einer Anfrage festlegen. Ich empfehle Werte zwischen 2 und 6 Sekunden.
MaxThreads
Je mehr Threads, desto schneller ist das Skript - aber da wir mit vielen Verbindungen umgehen, halte ich diesen Wert auf meinem persönlichen Rechner normalerweise unter 10 und auf meinem VPS bei etwa 30.
ShuffleTests
Besonders bei einer GROßEN Liste von URLs führt das Setzen auf „true“ dazu, dass alle erstellten Tests gemischt werden. Auf diese Weise wird derselbe Host nicht so stark getroffen. Wenn Sie nur einen Host scannen, spielt es keine Rolle.
GetChunkSize
Bei der Arbeit mit größeren Parameterlisten kann dies praktisch sein und 400 Too Large Entity-Fehler verhindern.
Jeder Einfügepunkt kann aktiviert (auf true/1 gesetzt) oder deaktiviert (auf false/0 gesetzt) werden.
InPath
Das Beispiel zeigt eine GET-Anfrage, aber abhängig von Ihren Einstellungen könnte dies auch POST, PUT, DELETE, ... sein.
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
Das Beispiel zeigt eine GET-Anfrage, aber abhängig von Ihren Einstellungen könnte dies auch POST, PUT, DELETE, ... sein.
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
Das Beispiel zeigt eine GET-Anfrage, aber abhängig von Ihren Einstellungen könnte dies auch POST, PUT, DELETE, ... sein.
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
Hier ist die Methode auf GET festgelegt.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
Hier ist die Methode auf POST festgelegt.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
Hier ist die Methode auf POST festgelegt.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
In den Standardeinstellungen versucht dieses Tool lediglich, HTTP-Anfragen über SSRF auszulösen. Es ist aber auch möglich, Daten per DNS zu exfiltrieren, wenn ein OS-Befehl eingeschleust wird. Die häufigste Payload ist „$(hostname)“. Es gibt einige Optionen, die die zusätzliche Verwendung dieser Art von Angriff ermöglichen.
UseExecPayload
Mit dieser Einstellung können Sie dieses Verhalten aktivieren/deaktivieren.
ExecPayload
Hier können Sie Ihre eigene Payload definieren, z.B. $(uname -a)
Um die Identifikation etwas einfacher zu machen, wird eine Kombination aus aktuellem Host und Methode (in Kurzform, siehe Tests.py) an die Payload angehängt oder vorangestellt.
Position
Gültige Optionen sind „append“ und „prepend“!
Wenn „append“ gewählt wird, sehen die Payloads wie folgt aus:
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
Wenn „prepend“ gewählt wird, sehen die Payloads wie folgt aus:
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
Es ist auch möglich, einen Tunnel zu verwenden, z.B. „127.0.0.1:8080“ (Burp Proxy), um den gesamten Verkehr in Burp zu überwachen.
Active
Das Setzen auf „true“ zwingt das Skript, eine getunnelte Verbindung zu verwenden.
Tunnel
Geben Sie hier Ihren Proxyserver als „ip:port“ an.
Das Ergebnis ist das folgende: Wenn Sie Burp öffnen, können Sie Ihren HTTP-Verlauf beobachten:


Bitte erstellen Sie einfach ein Issue und markieren Sie es als Funktionsanfrage (Feature Request).
Gefällt Ihnen dieses Tool? Hat es Ihnen geholfen, eine Prämie zu erhalten? Möchten Sie etwas zurückgeben/mich unterstützen? Warum nicht!