damian89/extended-ssrf-searchEscáner ssrf inteligente que utiliza diferentes métodos como fuerza bruta de parámetros en POST y GET...
Esta herramienta busca SSRF utilizando configuraciones predefinidas en diferentes partes de una solicitud (ruta, host, encabezados, parámetros POST y GET).
Renombra example.app-settings.conf a app-settings.conf y ajusta la configuración. El ajuste más importante es la URL de callback. Recomiendo usar Burp Collaborator. Luego puedes añadir tus URLs a config/url-to-test.txt. Aquí el script acepta dominios así como URLs con ruta y parámetros de consulta. Si lo deseas, puedes añadir tus propias cookies a config/cookie-jar.txt y añadir encabezados adicionales para tus solicitudes. La lista de fuerza bruta que se usa en las solicitudes POST y GET es actualmente pequeña, no creo que añadir 2000 parámetros sea inteligente. Deberíamos centrarnos en aquellos que tengan la mayor probabilidad de ser vulnerables. Si no lo crees así: ¡solo añade los tuyos!
Esta herramienta no espera ningún argumento a través de la CLI, así que simplemente escribe:
python3 extended-ssrf-search.py
Es posible configurar muchas opciones y ajustes, así que aquí hay algunas explicaciones.
El archivo de configuración principal es "app-settings.conf", ¡todo debe hacerse en ese archivo! Además de eso, hay algunos otros archivos que permiten establecer datos más complejos como encabezados, URLs y cookies.
config/cookie-jar.txt
Usa este archivo para añadir una cadena de cookies. Normalmente copio la que se ve en cada solicitud de Burp. Por favor, solo copia el valor del encabezado "Cookie:". Hay un ejemplo en el archivo por defecto.
config/http-headers.txt
Este archivo define los encabezados HTTP que se añaden a la solicitud y se manipulan (se añade el payload a cada uno). Los más importantes ya están en el archivo. Pero siéntete libre de añadir más.
config/parameters.txt
La herramienta tiene la opción de realizar fuerza bruta en parámetros GET y POST. En ese caso, esos parámetros (más los de la cadena de consulta) se utilizarán. Cada parámetro recibe el payload como valor. Los más importantes ya están en ese archivo.
config/static-request-headers.txt
Esos encabezados se añaden a cada solicitud, pero no serán manipulados. Son estáticos. Ese es el mejor lugar para añadir cookies de autorización o bearer. ¡Uno (Clave: Valor) por línea!
config/urls-to-test.txt
¡Ese es el archivo que necesitas! Por favor, añade aquí tus enlaces a escanear. Se permiten los siguientes formatos:
Cuando se detecta el último caso, se antepone "http://". Esta herramienta está diseñada para funcionar con una buena lista de URLs. Una buena manera de obtener una es exportarla usando Burp. Entonces tendrás una lista válida de URLs. Todo lo que necesitas hacer es añadir tus cookies.
El archivo app-settings.conf define el flujo de trabajo del programa. Es el archivo más importante, puedes activar/desactivar diferentes módulos allí.
CallbackHost
La URL/host a la que se envían todas las solicitudes DNS y HTTP de vuelta; suelo usar Burp Collaborator aquí, pero DNSBin o tu propio servidor también son perfectos.
HTTPMethod
Define el método de solicitud. Las opciones válidas son: GET, POST, PUT, DELETE, PATCH, GET, OPTIONS. ¡Los valores no válidos producirán errores masivos ya que http.client no permite otros métodos! No compruebo si hiciste algo mal aquí ;)
HTTPTimeout
Algunas solicitudes pueden tardar mucho. Aquí puedes definir el tiempo máximo de ejecución de una solicitud. Recomiendo valores entre 2 y 6 segundos.
MaxThreads
Cuantos más hilos, más rápido es el script, pero como estamos lidiando con muchas conexiones, normalmente mantengo esto por debajo de 10 en mi computadora personal y alrededor de 30 en mi VPS.
ShuffleTests
Especialmente cuando se trabaja con una lista GRANDE de URLs, tener esto configurado como "true" mezclará todas las pruebas creadas. De esa manera, el mismo host no recibirá tantos golpes. Si escaneas solo un host, entonces no importa.
GetChunkSize
Cuando trabajas con listas de parámetros más grandes, esto puede ser útil y evitar errores de entidad demasiado grande 400.
Cada punto de inserción se puede activar (true/1) o desactivar (false/0).
InPath
El ejemplo muestra una solicitud GET, pero dependiendo de tu configuración, también podría ser POST, PUT, DELETE, ...
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
El ejemplo muestra una solicitud GET, pero dependiendo de tu configuración, también podría ser POST, PUT, DELETE, ...
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
El ejemplo muestra una solicitud GET, pero dependiendo de tu configuración, también podría ser POST, PUT, DELETE, ...
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
Aquí el método está fijado a GET.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
Aquí el método está fijado a POST.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
Aquí el método está fijado a POST.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
En la configuración predeterminada, esta herramienta solo intenta desencadenar solicitudes HTTP a través de SSRF. Pero también es posible exfiltrar datos usando DNS, cuando se inyecta un comando del sistema operativo. El payload más común es "$(hostname)". Hay algunas opciones que permiten utilizar este tipo de ataque adicionalmente.
UseExecPayload
Usando esta configuración puedes activar/desactivar ese comportamiento.
ExecPayload
Aquí puedes definir tu propio payload, por ejemplo $(uname -a)
Para facilitar un poco la identificación, se añade al payload una combinación del host actual y el método (en forma abreviada, ver Tests.py) ya sea al final o al inicio.
Position
Las opciones válidas son "append" y "prepend"!
Si se elige "append", los payloads se ven así:
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
Si se elige "prepend", los payloads se ven así:
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
También es posible usar un túnel, por ejemplo "127.0.0.1:8080" (Proxy de Burp), para monitorear todo el tráfico dentro de Burp.
Active
Configurar esto como "true" obligará al script a usar una conexión tunelizada.
Tunnel
Establece aquí tu servidor proxy "ip:puerto".
El resultado es el siguiente, cuando abres Burp puedes ver tu historial HTTP:
Por favor, solo crea un issue y etiquétalo como solicitud de función.
¿Te gusta esta herramienta? ¿Te ayudó a obtener un bounty? ¿Quieres devolver algo/apoyarme? ¡Por qué no!