damian89/extended-ssrf-searchУмный сканер SSRF, использующий различные методы, такие как перебор параметров в POST и GET...
Этот инструмент ищет SSRF, используя предопределённые настройки в различных частях запроса (путь, хост, заголовки, параметры POST и GET).
Переименуйте example.app-settings.conf в app-settings.conf и настройте параметры. Самая важная настройка — это callback-URL. Я рекомендую использовать Burp Collaborator. Затем вы можете добавить свои URL-адреса в config/url-to-test.txt. Скрипт принимает как домены, так и URL-адреса с путём и параметрами запроса. При желании вы можете добавить свои собственные cookie в config/cookie-jar.txt и добавить дополнительные заголовки для ваших запросов. Список для перебора, который используется в POST и GET запросах, пока небольшой; я не считаю разумным добавлять 2000 параметров. Мы должны сосредоточиться на тех, которые с наибольшей вероятностью могут быть уязвимы. Если вы считаете иначе — просто добавьте свои!
Этот инструмент не ожидает никаких аргументов через CLI, поэтому просто введите:
python3 extended-ssrf-search.py
Можно задать множество опций и настроек, поэтому вот некоторые пояснения.
Основной конфигурационный файл — это "app-settings.conf", всё должно быть настроено в нём! Кроме того, есть несколько других файлов, которые позволяют задать более сложные данные, такие как заголовки, URL и cookie.
config/cookie-jar.txt
Используйте этот файл, чтобы добавить строку cookie. Обычно я копирую ту, которую видно в каждом запросе Burp. Пожалуйста, просто скопируйте значение заголовка "Cookie:". Пример входных данных есть в файле по умолчанию.
config/http-headers.txt
Этот файл определяет HTTP-заголовки, которые добавляются к запросу и изменяются (полезная нагрузка добавляется к каждому). Самые важные уже находятся в файле. Но вы можете добавить и другие.
config/parameters.txt
Инструмент имеет возможность перебора GET и POST параметров. В этом случае используются эти параметры (плюс те, что в строке запроса). Каждому параметру присваивается значение полезной нагрузки. Самые важные уже находятся в этом файле.
config/static-request-headers.txt
Эти заголовки добавляются к каждому запросу, но не изменяются. Они статичны. Это лучшее место для добавления авторизации или Bearer cookie. Одна строка (Key: Value) на строку!
config/urls-to-test.txt
Это тот файл, который вам нужен! Пожалуйста, добавьте сюда ссылки для сканирования. Допускаются следующие форматы:
В последнем случае автоматически добавляется "http://". Этот инструмент предназначен для работы с большим списком URL. Хороший способ получить такой список — просто экспортировать его с помощью Burp. Тогда у вас будет валидный список URL. Всё, что вам нужно сделать, — это добавить свои cookie.
Файл app-settings.conf определяет рабочий процесс программы. Это самый важный файл; в нём можно включать/отключать различные модули.
CallbackHost
URL/хост, на который будут отправляться все DNS и HTTP запросы — я чаще всего использую Burp Collaborator, но DNSBin или ваш собственный сервер тоже подойдут.
HTTPMethod
Определяет метод запроса. Допустимые значения: GET, POST, PUT, DELETE, PATCH, GET, OPTIONS Недопустимые значения вызовут массу ошибок, так как http.client запрещает другие методы! Я не проверяю, ошиблись ли вы здесь ;)
HTTPTimeout
Некоторые запросы могут выполняться долго. Здесь вы можете задать максимальное время выполнения одного запроса. Я рекомендую значения от 2 до 6 секунд.
MaxThreads
Чем больше потоков, тем быстрее работает скрипт, но поскольку мы имеем дело с большим количеством соединений, я обычно оставляю это значение ниже 10 на своём личном компьютере и около 30 на VPS.
ShuffleTests
Особенно при работе с БОЛЬШИМ списком URL, установка этого параметра в "true" перетасует все созданные тесты. Таким образом, один и тот же хост не будет получать слишком много запросов. Если вы сканируете только один хост, это не имеет значения.
GetChunkSize
При работе с большими списками параметров это может быть полезно и предотвратить ошибки 400 (слишком большая сущность).
Каждая точка вставки может быть активирована (установлено true/1) или деактивирована (установлено false/0)
InPath
В примере показан GET-запрос, но в зависимости от ваших настроек это может быть также POST, PUT, DELETE, ...
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
В примере показан GET-запрос, но в зависимости от ваших настроек это может быть также POST, PUT, DELETE, ...
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
В примере показан GET-запрос, но в зависимости от ваших настроек это может быть также POST, PUT, DELETE, ...
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
Здесь метод фиксирован — GET.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
Здесь метод фиксирован — POST.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
Здесь метод фиксирован — POST.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
В настройках по умолчанию этот инструмент просто пытается вызвать HTTP-запросы через SSRF. Но также возможно извлечение данных с помощью DNS, когда внедряется команда ОС. Самая распространённая полезная нагрузка — "$(hostname)". Есть несколько опций, которые дополнительно позволяют использовать такой тип атаки.
UseExecPayload
С помощью этой настройки вы можете активировать/деактивировать такое поведение.
ExecPayload
Здесь вы можете задать свою собственную полезную нагрузку, например $(uname -a)
Чтобы упростить идентификацию, к полезной нагрузке добавляется (в начале или в конце) комбинация текущего хоста и метода (в сокращённой форме, см. Tests.py).
Position
Допустимые значения: "append" и "prepend"!
Если выбрано "append", полезные нагрузки выглядят так:
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
Если выбрано "prepend", полезные нагрузки выглядят так:
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
Также возможно использование туннеля, например "127.0.0.1:8080" (прокси Burp), для просмотра всего трафика внутри Burp.
Active
Установка этого параметра в "true" заставит скрипт использовать туннельное соединение.
Tunnel
Укажите здесь ваш прокси-сервер "ip:port".
Результат будет следующим: когда вы откроете Burp, вы сможете наблюдать историю HTTP:
Пожалуйста, просто создайте issue и добавьте метку feature request.
Вам нравится этот инструмент? Он помог вам получить баунти? Хотите отблагодарить/поддержать меня? Почему бы и нет!