Безопасность на реальных примерах всегда интересна.
Сегодня поговорим об SSRF атаке, когда можно заставить сервер делать произвольные запросы в Интернет через img тэг.
Скриншоты взяты прямо из отчетов, потому вся лишняя информация замазана. Итак, недавно занимался тестированием на проникновение одновременно на двух проектах, сразу на двух эта уязвимость и выявилась.
Описание атаки
Название атаки: сервер выполняет произвольные запросы в Интернет во время генерации PDF документа.
Документы содержали данные, введенные пользователем. Описание: PDF генерируется на серверной стороне из полностью отрендеренной html страницы со всеми внешними ресурсами. В данном случае пусть это будет файл it-band.by/10gb.blob (якобы размером 10 Gb). Без надлежащей фильтрации можно подставить свои внешние ресурсы в серверный рендеринг.
Наихудший сценарий:
- Ddos атака изнутри, когда системе для рендера необходимо загрузить 100 гигабайт данных, чтобы отрендерить несколько PDF документов одновременно. В итоге это приводит к нехватке ресурсов сети или памяти, что в свою очередь может привести к system down.
- Злонамеренный пользователь может использовать сервер как платформу для атаки на другие ресурсы.
- Злонамеренный пользователь получает внешние IP адреса внутренних серверов для прямых атак, обходя web application файерволы (WAF) и балансировщики.
Оценка риска (Likelihood*Impact): Medium(5)*High(7)=High(35) (в обоих системах риск был оценен как высокий, хотя и с разными коэффициентами)
Что интересно:
- Одна система использовала wkhtmltopdf для рендера html2pdf, вторая — запускала Firefox, загружала туда страницу и делала скриншот. В любом случае обе системы сразу рендерят обе страницы, выполняют весь код там и только потом делают из этого PDF.
- Серверная XSS защита стояла в обоих системах, но обе системы вместо escape-а входных данных использовали html purifying, который чистил все iframe, scripts, css, forms и так далее. Но html purifying в обоих системах считал
img src="https://it-band.by/10Gb.blob?t=12345.1"/безопасным html кодом.
А теперь пройдёмся по шагам и скриншотам
1) Сделать локально вот такой файл, в попытке потом залить его полностью или частично.
2) В начале, необходимо найти уязвимые пользовательские поля.
Удалось вставить только один img таг Система 1.
Удалось вставить сразу около 20 тагов Система 2.
3) Далее выполняем генерацию PDF Документа.
Сгенерированный PDF Система 1.
Сгенерированный PDF Система 2.
4) А теперь лезем на наш сервер, чтобы посмотреть, были ли запросы на наш большой файл 10Gb.blob.
Получаем серверный IP адрес и софт, при помощи которого генерился PDF Документ, nmap по найденному IP адресу показал ещё один открытый порт, которого раньше никто не видел. Система 1.
Видно, что сервер пытался загрузить 20 файлов по 10 гигабайт. Система 2. Также получаем адрес одного из серверов и версию используемого Firefox -а.
В первой системе вместо html purifying делается escaping и во время обработки пользовательских данных, и во время генерации PDF документа; во второй системе — режутся любые абсолютные линки на внешние ресурсы во время обработки пользовательских данных. Итог. В обеих системах ошибки уже исправлены.
Обновлено.
Пока добрался до публикации статьи, прибавились кейсы еще из 2 систем.
Еще одна система (назовем Система 3) не прошла проверку на этот тип уязвимостей сразу в двух местах: через HTML Injection и CSS Injection.
Html injection с загрузкой 20 раз живой картинки 13 Mb (в сумме 260Mb) Система 3.
CSS Injection Система 3.
Что видим на атакующем сервере при рендере PDF (все 20 загрузок картинки по 13Mb успешные) Система 3.
Что на выходе получили для Системы 3:
В данном случае — HeadlessChrome. 1) Получили адреса серверов, которые занимаются рендерингом, и что они использует для рендера.
Представьте, если запустить 10К таких запросов, то на время серверы по генерации в принципе перестанут отвечать на запросы других пользователей. 2) Генерация одного PDF документа заняла около 5 минут, потом хром просто падал.
По сравнению с предыдущими случаями, здесь можно проводить более сложные атаки на другие системы. Система 4. SSRF атака здесь проведена не через img тэг, а через XSS, когда на сервере во время рендера выполнился мой любимый пэйлоад, и сервер запустил произвольный Javascript код во время генерации PDF Документа.
Отрендеренный PDF с выполненным произвольным JS кодом на серверной стороне Система 4.
Системы требуют разработки не только правил входящего файервола, но и исходящего, либо разработки инфраструктуры с отдельными сегментами сети или серверами, из которых вообще доступа во вне нету. Посыл 1.
При нахождении даже самой маленькой уязвимости необходимо всегда искать наихудшие сценарии его использования и влияния на бизнес. Посыл 2. Бизнес умеет работать только с рисками, техническая сторона, к сожалению, их мало интересует.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко, CISSP, Penetration Tester
