damian89/extended-ssrf-searchScanner ssrf intelligent utilisant différentes méthodes comme parameter brute forcing en post et get...
Cet outil recherche les SSRF en utilisant des paramètres prédéfinis dans différentes parties d'une requête (chemin, hôte, en-têtes, paramètres POST et GET).
Renommez example.app-settings.conf en app-settings.conf et ajustez les paramètres. Le paramètre le plus important est l'URL de rappel. Je recommande d'utiliser Burp Collaborator. Ensuite, vous pouvez ajouter vos URLs dans config/url-to-test.txt. Ici, le script accepte les domaines ainsi que les URLs avec chemin et paramètres de requête. Si vous le souhaitez, vous pouvez ajouter vos propres cookies dans config/cookie-jar.txt et ajouter des en-têtes supplémentaires pour vos requêtes. La liste de force brute utilisée pour les requêtes POST et GET est actuellement petite ; je ne pense pas qu'ajouter 2000 paramètres soit judicieux. Nous devrions nous concentrer sur ceux qui ont la plus grande probabilité d'être vulnérables. Si vous n'êtes pas d'accord, ajoutez les vôtres !
Cet outil n'attend aucun argument via la ligne de commande, tapez simplement :
python3 extended-ssrf-search.py
Il est possible de définir de nombreuses options et paramètres, voici donc quelques explications.
Le fichier de configuration principal est "app-settings.conf", tout doit être fait dans ce fichier ! En plus de cela, il existe d'autres fichiers qui permettent de définir des données plus complexes comme les en-têtes, les URLs et les cookies.
config/cookie-jar.txt
Utilisez ce fichier pour ajouter une chaîne de cookie. Je copie généralement celle que l'on voit dans chaque requête Burp. Veuillez simplement copier la valeur de l'en-tête "Cookie:". Un exemple d'entrée se trouve dans le fichier par défaut.
config/http-headers.txt
Ce fichier définit les en-têtes HTTP qui sont ajoutés à la requête et manipulés (une charge utile est ajoutée à chacun). Les plus importants sont déjà dans le fichier. Mais n'hésitez pas à en ajouter d'autres.
config/parameters.txt
L'outil offre la possibilité de forcer brutalement les paramètres GET et POST. Dans ce cas, ces paramètres (+ ceux de la chaîne de requête) seront utilisés. Chaque paramètre reçoit la charge utile comme valeur. Les plus importants sont déjà dans ce fichier.
config/static-request-headers.txt
Ces en-têtes sont ajoutés à chaque requête, mais ils ne seront pas manipulés. Ils sont statiques. C'est le meilleur endroit pour ajouter des cookies d'autorisation ou de bearer. Un (Clé : Valeur) par ligne !
config/urls-to-test.txt
C'est le fichier dont vous avez besoin ! Veuillez ajouter ici vos liens à analyser. Les formats suivants sont autorisés :
Lorsque le dernier cas est détecté, un "http://" est ajouté au début. Cet outil est conçu pour fonctionner avec une bonne liste d'URLs. Un bon moyen d'en obtenir une est de l'exporter avec Burp. Vous aurez alors une liste valide d'URLs. Tout ce que vous avez à faire est d'ajouter vos cookies.
Le fichier app-settings.conf définit le flux de travail du programme. C'est le fichier le plus important ; vous pouvez y activer/désactiver différents modules.
CallbackHost
L'URL/hôte vers lequel toutes les requêtes DNS et HTTP sont renvoyées - j'utilise principalement Burp Collaborator ici, mais DNSBin ou votre propre serveur est également parfait.
HTTPMethod
Définit la méthode de requête. Les options valides sont : GET, POST, PUT, DELETE, PATCH, GET, OPTIONS. Des valeurs invalides produiront des erreurs massives car http.client interdit d'autres méthodes ! Je ne vérifie pas si vous avez fait une erreur ici ;)
HTTPTimeout
Certaines requêtes peuvent prendre du temps. Ici, vous pouvez définir le temps d'exécution maximum d'une requête. Je recommande des valeurs entre 2 et 6 secondes.
MaxThreads
Plus il y a de threads, plus le script est rapide - mais comme nous traitons beaucoup de connexions, je maintiens généralement cela en dessous de 10 sur mon ordinateur personnel et autour de 30 sur mon VPS.
ShuffleTests
Surtout lorsqu'on travaille avec une GROSSE liste d'URLs, définir ceci sur "true" mélangera tous les tests créés. Ainsi, le même hôte ne sera pas trop sollicité. Si vous ne scannez qu'un seul hôte, cela n'a pas d'importance.
GetChunkSize
Lorsqu'on travaille avec de plus grandes listes de paramètres, cela peut être pratique et éviter les erreurs 400 entité trop volumineuse.
Chaque point d'insertion peut être activé (défini sur true/1) ou désactivé (défini sur false/0)
InPath
L'exemple montre une requête GET, mais selon vos paramètres, cela pourrait aussi être POST, PUT, DELETE, ...
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
L'exemple montre une requête GET, mais selon vos paramètres, cela pourrait aussi être POST, PUT, DELETE, ...
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
L'exemple montre une requête GET, mais selon vos paramètres, cela pourrait aussi être POST, PUT, DELETE, ...
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
Ici, la méthode est fixée à GET.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
Ici, la méthode est fixée à POST.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
Ici, la méthode est fixée à POST.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
Dans les paramètres par défaut, cet outil essaie simplement de déclencher des requêtes HTTP via SSRF. Mais il est également possible d'exfiltrer des données via DNS, lorsqu'une commande OS est injectée. La charge utile la plus courante est "$(hostname)". Il existe quelques options qui permettent d'utiliser ce type d'attaque en complément.
UseExecPayload
En utilisant ce paramètre, vous pouvez activer/désactiver ce comportement.
ExecPayload
Ici, vous pouvez définir votre propre charge utile, par exemple $(uname -a)
Pour faciliter un peu l'identification, une combinaison de l'hôte actuel et de la méthode (sous forme abrégée, voir Tests.py) est ajoutée (append) ou préfixée (prepend) à la charge utile.
Position
Les options valides sont "append" et "prepend" !
Si "append" est choisi, les charges utiles ressemblent à ceci :
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
Si "prepend" est choisi, les charges utiles ressemblent à ceci :
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
Il est également possible d'utiliser un tunnel, par exemple "127.0.0.1:8080" (proxy Burp), pour surveiller tout le trafic dans Burp.
Active
Définir ceci sur "true" forcera le script à utiliser une connexion tunnelisée.
Tunnel
Définissez ici votre serveur proxy "ip:port".
Le résultat est le suivant : lorsque vous ouvrez Burp, vous pouvez voir votre historique HTTP :
Veuillez simplement créer un ticket (issue) et le marquer comme demande de fonctionnalité.
Vous aimez cet outil ? Vous a-t-il aidé à obtenir une prime ? Vous voulez rendre la pareille/me soutenir ? Pourquoi pas !