Серия SSRF — Назад к основам
@Ent_TranslateIBЧто такое SSRF?
SSRF или Server Side Request Forgery - это уязвимость, при которой злоумышленник может заставить сервер обратиться к непредусмотренному URL. Сейчас это не имеет прямого воздействия, однако потенциально это может использоваться для утечки конфиденциальной информации/учетных данных или загрузки вредоносных файлов, что приводит к критическим уязвимостям, таким как RCE.
Воздействие на сервер
Начнем с самого базового сценария - вы находите API, которому можно передать URL. Сервер получает содержимое из URL и возвращает его обратно.
POST /v1/api HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 url=http://some-website.com
Злоумышленник может сделать следующее, используя вышеупомянутый API:
Обход авторизации
- Измените URL, чтобы он указывал на страницу администратора. Иногда авторизация обходится, зная, что вызов API осуществляется из доверенного источника.
POST /v1/api HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 url=http://localhost/admin
Утечка конфиденциальных учетных данных
- Если приложение размещено на каком-либо популярном облачном сервисе, измените url на http://169.254.169.254 (AWS, Azure или GCP - см. здесь). Злоумышленник потенциально может извлечь учетные данные для получения доступа к облачной среде!
POST /v1/api HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 url=http://169.254.169.254/latest/user-data
Сканирование сети
- Злоумышленник может также использовать это для поиска внутренних систем, недоступных для обычных пользователей. Как правило, внутренние сети не защищены от атак, если учесть, какие усилия потребуются для проникновения в систему.
POST /v1/api HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 url=http://192.168.1.100/admin
Обходите распространенные способы защиты
Несмотря на то, что во многих случаях все просто! Но иногда разработчики ужесточают защиту, чтобы убедиться, что это невозможно использовать так просто.
Задача 1: Идентификация параметра
Один из бесспорно верных способов найти SSRFs - это пробовать каждый параметр, который попадается на пути, и ждать ответа OOB. Однако один из способов систематического выполнения этой задачи - это анализ параметров.
Я лично предпочитаю использовать tomnomnom's gf для хранения/использования этих списков, чтобы определить, присутствуют ли они в API, регистрируемых во время разведки, или добавить их в запросы (см.: The Accidental SSRF).
Задача 2: URL-адреса, занесенные в черный список
Обычно распространенные URL-адреса заносятся в черный список. Чтобы обойти это, мы можем использовать следующие обходные пути - PayloadsAllTheThings.
Каждый язык программирования и каждая библиотека по-своему разбирают URL. Например, в python мы можем использовать либо httplib, urllib, urllib2 или requests. Для приведенного ниже URL-адреса каждая библиотека будет разрешать разные части URL-адреса!
Еще несколько примеров от 0xn3va:
foo@evil-host:80@expected-host foo@evil-host%20@expected-host evil-host%09expected-host 127.1.1.1:80\@127.2.2.2:80 127.1.1.1:80:\@@127.2.2.2:80 127.1.1.1:80#\@127.2.2.2:80 ß.evil-host
Это только некоторые способы использования SSRF. Больше в ближайших статьях!
Надеюсь, вам понравилось. Спасибо за чтение. Следите за обновлениями!
Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.
Перевод статьи был выполнен проектом перевод энтузиаста:
- 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
- 🔥 @Ent_Translate - Инстаграм проекта