Обход защиты SSRF

Привет,

Прошло некоторое время с тех пор, как я последний раз писал. Я хотел поделиться изящным обходом SSRF, который я нашел во время охоты на частную программу.

SSRF означает подделку запросов на стороне сервера. Подделка запросов на стороне сервера позволяет злоумышленнику злоупотреблять HTTP-запросами для запроса информации о сервере внутри или во внутренней сети.

На что обратить внимание? Такие параметры, как url=next=host=image=img= и т. д. Все, что выглядит как отправка веб-запроса на сервер. Затем этим можно злоупотребить, чтобы указать запрос внутри.

Как я нашел уязвимую конечную точку?

Во время охоты по частной программе я проводил обширную разведку. Я собрал огромный список поддоменов, в основном взятых из censys. После этого у меня был брутфорс и поиск в обратном пути URL-адресов на всех хостах. В то время я сосредоточился на ssrf, поэтому я собрал свой каталог и выходные данные конечной точки и поискал «proxy.php». К счастью, у меня был хит.

При изучении запроса это был исходящий HTTP-запрос на указанный URL-адрес. Если я ввел ссылку на burp colaborator, я не получил поиск. Я попробовал обычные основы, введя 127.0.0.1 и IP-нотации внутренних хостов, каждый запрос блокировался, если в запросе не было имени хоста веб-сайта.

Здесь все становится техническим. при отправке такого запроса моему коллеге по burp, наряду с форматированием учетных данных браузера, например, url=https: //hostnameofwebsite.com@myburpcollablink , я получил ответный удар.

Затем я попытался использовать это, изменив его, потому что в настоящее время вышеперечисленное использовало браузер для отправки hostnameofwebsite в качестве учетных данных на myburpcollablink, что было бесполезно.

Недавно я только что видел видео ssrf в Google, где объяснялось, что если вы используете \, это прекратит синтаксический анализ на бэкэнде после первого хоста. Внешний интерфейс будет интерпретировать запрос как hostnameofwebsite как учетные данные для myburpcollablink, но бэкенд будет обрабатывать только внешний запрос, поэтому hostnameofwebsite. Здесь я изменил его и использовал url=http://169.254.1698.254\@hostnameofwebsite.

Давайте объясним. 169.254 — это внутренний IP-адрес метаданных AWS. Внешний запрос видит это как 169.254 в качестве учетных данных для hostnameofwebsite, который проходит проверку внешнего интерфейса, поскольку hostnameofwebsite должен быть в запросе. Серверная часть игнорирует этот формат и обрабатывает какhttp://169.254.169.254\который затем обрезает и передает только запрос.

Закрыто как решено