damian89/extended-ssrf-searchScanner ssrf inteligente usando diferentes métodos como força bruta de parâmetros em post e get...
Esta ferramenta busca por SSRF usando configurações predefinidas em diferentes partes de uma requisição (path, host, headers, parâmetros post e get).
Renomeie example.app-settings.conf para app-settings.conf e ajuste as configurações. A configuração mais importante é a URL de callback. Recomendo usar o burp collaborator. Então você pode adicionar suas URLs ao config/url-to-test.txt. Aqui o script aceita domínios, bem como URLs com path e parâmetros de consulta. Se quiser, você pode adicionar seus próprios cookies ao config/cookie-jar.txt e adicionar cabeçalhos adicionais para suas requisições. A lista de força bruta usada em requisições POST e GET é atualmente pequena, acho que adicionar 2000 parâmetros não é inteligente. Devemos focar naqueles com maior probabilidade de serem vulneráveis. Se você não concorda: basta adicionar os seus!
Esta ferramenta não espera nenhum argumento via CLI, então basta digitar:
python3 extended-ssrf-search.py
É possível definir muitas opções e configurações, então aqui estão algumas explicações.
O arquivo de configuração principal é o "app-settings.conf", tudo deve ser feito nesse arquivo! Além disso, existem alguns outros arquivos que permitem definir dados mais complexos, como cabeçalhos, URLs e cookies.
config/cookie-jar.txt
Use este arquivo para adicionar uma string de cookie. Eu geralmente copio aquele que você vê em toda requisição do Burp. Por favor, copie apenas o valor do cabeçalho "Cookie:". Um exemplo de entrada está no arquivo padrão.
config/http-headers.txt
Este arquivo define os cabeçalhos HTTP que são adicionados à requisição e manipulados (payload é adicionado a cada um). Os mais importantes já estão no arquivo. Mas sinta-se à vontade para adicionar mais.
config/parameters.txt
A ferramenta tem a opção de fazer força bruta em parâmetros GET e POST. Nesse caso, esses parâmetros (+ os da query string) serão usados. Cada parâmetro recebe o payload como valor. Os mais importantes já estão nesse arquivo.
config/static-request-headers.txt
Esses cabeçalhos são adicionados a cada requisição, mas não serão manipulados. Eles são estáticos. Esse é o melhor lugar para adicionar cookies de autorização ou bearer. Um (Chave: Valor) por linha!
config/urls-to-test.txt
Esse é o arquivo que você precisa! Adicione aqui seus links para escanear. Os seguintes formatos são permitidos:
Quando o último caso é detectado, um "http://" é adicionado no início. Esta ferramenta é projetada para funcionar com uma boa lista de URLs. Uma boa maneira de obter uma é exportá-la usando o Burp. Então você tem uma lista válida de URLs. Tudo que você precisa fazer é adicionar seus cookies.
O app-settings.conf define o fluxo de trabalho do programa. É o arquivo mais importante, você pode ativar/desativar diferentes módulos lá.
CallbackHost
A URL/host para a qual todas as requisições DNS e HTTP são enviadas de volta - eu geralmente uso o burp collaborator aqui, mas DNSBin ou seu próprio servidor também são perfeitos.
HTTPMethod
Define o método da requisição. Opções válidas são: GET, POST, PUT, DELETE, PATCH, GET, OPTIONS. Valores inválidos produzirão erros enormes, pois http.client não permite outros métodos! Eu não verifico se você fez algo errado aqui ;)
HTTPTimeout
Algumas requisições podem demorar. Aqui você pode definir o tempo máximo de execução de uma requisição. Recomendo valores entre 2 e 6 segundos.
MaxThreads
Quanto mais threads, mais rápido o script é - mas como estamos lidando com muitas conexões, geralmente mantenho isso abaixo de 10 no meu computador pessoal e em torno de 30 no meu VPS.
ShuffleTests
Especialmente ao lidar com uma lista GRANDE de URLs, definir isso como "true" embaralhará todos os testes criados. Dessa forma, o mesmo host não será tão atingido. Se você escanear apenas um host, não importa.
GetChunkSize
Ao trabalhar com listas de parâmetros maiores, isso pode ser útil e evitar erros 400 de entidade muito grande.
Cada ponto de inserção pode ser ativado (definir como true/1) ou desativado (definir como false/0)
InPath
O exemplo mostra uma requisição GET, mas dependendo das suas configurações, isso também pode ser POST, PUT, DELETE, ...
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
O exemplo mostra uma requisição GET, mas dependendo das suas configurações, isso também pode ser POST, PUT, DELETE, ...
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
O exemplo mostra uma requisição GET, mas dependendo das suas configurações, isso também pode ser POST, PUT, DELETE, ...
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
Aqui o método é fixo como GET.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
Aqui o método é fixo como POST.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
Aqui o método é fixo como POST.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
Nas configurações padrão, esta ferramenta apenas tenta disparar requisições HTTP via SSRF. Mas também é possível exfiltrar dados usando DNS, quando um comando do SO é injetado. O payload mais comum é "$(hostname)". Existem algumas opções que permitem usar esse tipo de ataque adicionalmente.
UseExecPayload
Usando essa configuração você pode ativar/desativar esse comportamento.
ExecPayload
Aqui você pode definir seu próprio payload, por exemplo $(uname -a)
Para tornar a identificação um pouco mais fácil, uma combinação do host atual e do método (em forma abreviada, veja Tests.py) é anexada ou prefixada ao payload.
Position
Opções válidas são "append" e "prepend"!
Se "append" for escolhido, os payloads ficam assim:
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
Se "prepend" for escolhido, os payloads ficam assim:
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
Também é possível usar um túnel, por exemplo "127.0.0.1:8080" (Burp Proxy), para monitorar todo o tráfego dentro do Burp.
Active
Definir isso como "true" forçará o script a usar uma conexão tunelada.
Tunnel
Defina aqui seu servidor proxy "ip:port".
O resultado é o seguinte: quando você abrir o Burp, poderá ver seu histórico HTTP:
Por favor, crie uma issue e marque-a como solicitação de funcionalidade.
Você gosta dessa ferramenta? Ela te ajudou a conseguir um bounty? Quer retribuir/me apoiar? Por que não!