Безопасность на реальных примерах всегда интересна.
Сегодня поговорим об SSRF атаке, когда можно заставить сервер делать произвольные запросы в Интернет через img тэг.
Итак, недавно занимался тестированием на проникновение одновременно на двух проектах, сразу на двух эта уязвимость и выявилась. Скриншоты взяты прямо из отчетов, потому вся лишняя информация замазана.
Название атаки: сервер выполняет произвольные запросы в Интернет во время генерации PDF документа.
Описание: PDF генерируется на серверной стороне из полностью отрендеренной html страницы со всеми внешними ресурсами. Документы содержали данные, введенные пользователем. Без надлежащей фильтрации можно подставить свои внешние ресурсы в серверный рендеринг. В данном случае пусть это будет файл it-band.by/10gb.blob (якобы размером 10 Gb).
Наихудший сценарий:
Оценка риска (Likelihood*Impact): Medium(5)*High(7)=High(35) (в обоих системах риск был оценен как высокий, хотя и с разными коэффициентами)
Что интересно:
1) Сделать локально вот такой файл, в попытке потом залить его полностью или частично.
2) В начале, необходимо найти уязвимые пользовательские поля.
Система 1. Удалось вставить только один img таг
Система 2. Удалось вставить сразу около 20 тагов
3) Далее выполняем генерацию PDF Документа.
Система 1. Сгенерированный PDF
Система 2. Сгенерированный PDF
4) А теперь лезем на наш сервер, чтобы посмотреть, были ли запросы на наш большой файл 10Gb.blob.
Система 1. Получаем серверный IP адрес и софт, при помощи которого генерился PDF Документ, nmap по найденному IP адресу показал ещё один открытый порт, которого раньше никто не видел.
Система 2. Видно, что сервер пытался загрузить 20 файлов по 10 гигабайт. Также получаем адрес одного из серверов и версию используемого Firefox -а.
Итог. В обеих системах ошибки уже исправлены. В первой системе вместо html purifying делается escaping и во время обработки пользовательских данных, и во время генерации PDF документа; во второй системе — режутся любые абсолютные линки на внешние ресурсы во время обработки пользовательских данных.
Обновлено.
Пока добрался до публикации статьи, прибавились кейсы еще из 2 систем.
Еще одна система (назовем Система 3) не прошла проверку на этот тип уязвимостей сразу в двух местах: через HTML Injection и CSS Injection.
Система 3. Html injection с загрузкой 20 раз живой картинки 13 Mb (в сумме 260Mb)
Система 3. CSS Injection
Система 3. Что видим на атакующем сервере при рендере PDF (все 20 загрузок картинки по 13Mb успешные)
Что на выходе получили для Системы 3:
1) Получили адреса серверов, которые занимаются рендерингом, и что они использует для рендера. В данном случае — HeadlessChrome.
2) Генерация одного PDF документа заняла около 5 минут, потом хром просто падал. Представьте, если запустить 10К таких запросов, то на время серверы по генерации в принципе перестанут отвечать на запросы других пользователей.
Система 4. SSRF атака здесь проведена не через img тэг, а через XSS, когда на сервере во время рендера выполнился мой любимый пэйлоад, и сервер запустил произвольный Javascript код во время генерации PDF Документа. По сравнению с предыдущими случаями, здесь можно проводить более сложные атаки на другие системы.
Система 4. Отрендеренный PDF с выполненным произвольным JS кодом на серверной стороне
Посыл 1. Системы требуют разработки не только правил входящего файервола, но и исходящего, либо разработки инфраструктуры с отдельными сегментами сети или серверами, из которых вообще доступа во вне нету.
Посыл 2. При нахождении даже самой маленькой уязвимости необходимо всегда искать наихудшие сценарии его использования и влияния на бизнес. Бизнес умеет работать только с рисками, техническая сторона, к сожалению, их мало интересует.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко, CISSP, Penetration Tester
Сегодня поговорим об 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) В начале, необходимо найти уязвимые пользовательские поля.
Система 1. Удалось вставить только один img таг
Система 2. Удалось вставить сразу около 20 тагов
3) Далее выполняем генерацию PDF Документа.
Система 1. Сгенерированный PDF
Система 2. Сгенерированный PDF
4) А теперь лезем на наш сервер, чтобы посмотреть, были ли запросы на наш большой файл 10Gb.blob.
Система 1. Получаем серверный IP адрес и софт, при помощи которого генерился PDF Документ, nmap по найденному IP адресу показал ещё один открытый порт, которого раньше никто не видел.
Система 2. Видно, что сервер пытался загрузить 20 файлов по 10 гигабайт. Также получаем адрес одного из серверов и версию используемого Firefox -а.
Итог. В обеих системах ошибки уже исправлены. В первой системе вместо html purifying делается escaping и во время обработки пользовательских данных, и во время генерации PDF документа; во второй системе — режутся любые абсолютные линки на внешние ресурсы во время обработки пользовательских данных.
Обновлено.
Пока добрался до публикации статьи, прибавились кейсы еще из 2 систем.
Еще одна система (назовем Система 3) не прошла проверку на этот тип уязвимостей сразу в двух местах: через HTML Injection и CSS Injection.
Система 3. Html injection с загрузкой 20 раз живой картинки 13 Mb (в сумме 260Mb)
Система 3. CSS Injection
Система 3. Что видим на атакующем сервере при рендере PDF (все 20 загрузок картинки по 13Mb успешные)
Что на выходе получили для Системы 3:
1) Получили адреса серверов, которые занимаются рендерингом, и что они использует для рендера. В данном случае — HeadlessChrome.
2) Генерация одного PDF документа заняла около 5 минут, потом хром просто падал. Представьте, если запустить 10К таких запросов, то на время серверы по генерации в принципе перестанут отвечать на запросы других пользователей.
Система 4. SSRF атака здесь проведена не через img тэг, а через XSS, когда на сервере во время рендера выполнился мой любимый пэйлоад, и сервер запустил произвольный Javascript код во время генерации PDF Документа. По сравнению с предыдущими случаями, здесь можно проводить более сложные атаки на другие системы.
Система 4. Отрендеренный PDF с выполненным произвольным JS кодом на серверной стороне
Посыл 1. Системы требуют разработки не только правил входящего файервола, но и исходящего, либо разработки инфраструктуры с отдельными сегментами сети или серверами, из которых вообще доступа во вне нету.
Посыл 2. При нахождении даже самой маленькой уязвимости необходимо всегда искать наихудшие сценарии его использования и влияния на бизнес. Бизнес умеет работать только с рисками, техническая сторона, к сожалению, их мало интересует.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко, CISSP, Penetration Tester