Безопасность на реальных примерах всегда интересна.
Сегодня поговорим об SSRF атаке, когда можно заставить сервер делать произвольные запросы в Интернет через img тэг.
![image](https://habrastorage.org/getpro/habr/post_images/c1a/e7e/e3d/c1ae7ee3d053f0809e9d22c320924a18.jpg)
Итак, недавно занимался тестированием на проникновение одновременно на двух проектах, сразу на двух эта уязвимость и выявилась. Скриншоты взяты прямо из отчетов, потому вся лишняя информация замазана.
Название атаки: сервер выполняет произвольные запросы в Интернет во время генерации PDF документа.
Описание: PDF генерируется на серверной стороне из полностью отрендеренной html страницы со всеми внешними ресурсами. Документы содержали данные, введенные пользователем. Без надлежащей фильтрации можно подставить свои внешние ресурсы в серверный рендеринг. В данном случае пусть это будет файл it-band.by/10gb.blob (якобы размером 10 Gb).
Наихудший сценарий:
Оценка риска (Likelihood*Impact): Medium(5)*High(7)=High(35) (в обоих системах риск был оценен как высокий, хотя и с разными коэффициентами)
Что интересно:
1) Сделать локально вот такой файл, в попытке потом залить его полностью или частично.
![image](https://habrastorage.org/getpro/habr/post_images/b8e/526/93f/b8e52693f2ad426797e6782d1ab8e157.jpg)
2) В начале, необходимо найти уязвимые пользовательские поля.
Система 1. Удалось вставить только один img таг
![image](https://habrastorage.org/getpro/habr/post_images/22e/ca3/6df/22eca36dfe17b1291627cca7f1192f5d.jpg)
![image](https://habrastorage.org/getpro/habr/post_images/226/53e/ccc/22653eccc53b3ea8ed3940c6b9ef7309.jpg)
Система 2. Удалось вставить сразу около 20 тагов
![image](https://habrastorage.org/getpro/habr/post_images/c1d/fbf/5fb/c1dfbf5fb9f33837714bb2c9521000fc.jpg)
3) Далее выполняем генерацию PDF Документа.
Система 1. Сгенерированный PDF
![image](https://habrastorage.org/getpro/habr/post_images/54a/f8f/ad9/54af8fad96135721b3989753d39c44ff.jpg)
Система 2. Сгенерированный PDF
![image](https://habrastorage.org/getpro/habr/post_images/a00/76f/ded/a0076fded6ad1a8688d856ffa751544b.jpg)
4) А теперь лезем на наш сервер, чтобы посмотреть, были ли запросы на наш большой файл 10Gb.blob.
Система 1. Получаем серверный IP адрес и софт, при помощи которого генерился PDF Документ, nmap по найденному IP адресу показал ещё один открытый порт, которого раньше никто не видел.
![image](https://habrastorage.org/getpro/habr/post_images/df7/0ee/24b/df70ee24b6efad45cbe9553b8bdf392b.jpg)
Система 2. Видно, что сервер пытался загрузить 20 файлов по 10 гигабайт. Также получаем адрес одного из серверов и версию используемого Firefox -а.
![image](https://habrastorage.org/getpro/habr/post_images/3e6/c80/aa0/3e6c80aa0358911d5c9bd00e79209901.jpg)
Итог. В обеих системах ошибки уже исправлены. В первой системе вместо html purifying делается escaping и во время обработки пользовательских данных, и во время генерации PDF документа; во второй системе — режутся любые абсолютные линки на внешние ресурсы во время обработки пользовательских данных.
Обновлено.
Пока добрался до публикации статьи, прибавились кейсы еще из 2 систем.
Еще одна система (назовем Система 3) не прошла проверку на этот тип уязвимостей сразу в двух местах: через HTML Injection и CSS Injection.
Система 3. Html injection с загрузкой 20 раз живой картинки 13 Mb (в сумме 260Mb)
![image](https://habrastorage.org/getpro/habr/post_images/fca/8f2/5bd/fca8f25bd0092de64280c0d0cc6d6020.jpg)
Система 3. CSS Injection
![image](https://habrastorage.org/getpro/habr/post_images/df2/cfb/584/df2cfb584b9ed09f2d1250c63a70086a.jpg)
Система 3. Что видим на атакующем сервере при рендере PDF (все 20 загрузок картинки по 13Mb успешные)
![image](https://habrastorage.org/getpro/habr/post_images/a80/ed7/18b/a80ed718b82bb5c5862c0c7ea343942b.jpg)
Что на выходе получили для Системы 3:
1) Получили адреса серверов, которые занимаются рендерингом, и что они использует для рендера. В данном случае — HeadlessChrome.
2) Генерация одного PDF документа заняла около 5 минут, потом хром просто падал. Представьте, если запустить 10К таких запросов, то на время серверы по генерации в принципе перестанут отвечать на запросы других пользователей.
Система 4. SSRF атака здесь проведена не через img тэг, а через XSS, когда на сервере во время рендера выполнился мой любимый пэйлоад, и сервер запустил произвольный Javascript код во время генерации PDF Документа. По сравнению с предыдущими случаями, здесь можно проводить более сложные атаки на другие системы.
![image](https://habrastorage.org/getpro/habr/post_images/28a/5ac/d5b/28a5acd5ba920b65add4b1b51819a0a2.jpg)
Система 4. Отрендеренный PDF с выполненным произвольным JS кодом на серверной стороне
![image](https://habrastorage.org/getpro/habr/post_images/55f/f3c/8b2/55ff3c8b29a5d6cd83e1c5736bd0a480.jpg)
Посыл 1. Системы требуют разработки не только правил входящего файервола, но и исходящего, либо разработки инфраструктуры с отдельными сегментами сети или серверами, из которых вообще доступа во вне нету.
Посыл 2. При нахождении даже самой маленькой уязвимости необходимо всегда искать наихудшие сценарии его использования и влияния на бизнес. Бизнес умеет работать только с рисками, техническая сторона, к сожалению, их мало интересует.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко, CISSP, Penetration Tester
Сегодня поговорим об SSRF атаке, когда можно заставить сервер делать произвольные запросы в Интернет через img тэг.
![image](https://habrastorage.org/getpro/habr/post_images/c1a/e7e/e3d/c1ae7ee3d053f0809e9d22c320924a18.jpg)
Итак, недавно занимался тестированием на проникновение одновременно на двух проектах, сразу на двух эта уязвимость и выявилась. Скриншоты взяты прямо из отчетов, потому вся лишняя информация замазана.
Описание атаки
Название атаки: сервер выполняет произвольные запросы в Интернет во время генерации 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) Сделать локально вот такой файл, в попытке потом залить его полностью или частично.
![image](https://habrastorage.org/getpro/habr/post_images/b8e/526/93f/b8e52693f2ad426797e6782d1ab8e157.jpg)
2) В начале, необходимо найти уязвимые пользовательские поля.
Система 1. Удалось вставить только один img таг
![image](https://habrastorage.org/getpro/habr/post_images/22e/ca3/6df/22eca36dfe17b1291627cca7f1192f5d.jpg)
![image](https://habrastorage.org/getpro/habr/post_images/226/53e/ccc/22653eccc53b3ea8ed3940c6b9ef7309.jpg)
Система 2. Удалось вставить сразу около 20 тагов
![image](https://habrastorage.org/getpro/habr/post_images/c1d/fbf/5fb/c1dfbf5fb9f33837714bb2c9521000fc.jpg)
3) Далее выполняем генерацию PDF Документа.
Система 1. Сгенерированный PDF
![image](https://habrastorage.org/getpro/habr/post_images/54a/f8f/ad9/54af8fad96135721b3989753d39c44ff.jpg)
Система 2. Сгенерированный PDF
![image](https://habrastorage.org/getpro/habr/post_images/a00/76f/ded/a0076fded6ad1a8688d856ffa751544b.jpg)
4) А теперь лезем на наш сервер, чтобы посмотреть, были ли запросы на наш большой файл 10Gb.blob.
Система 1. Получаем серверный IP адрес и софт, при помощи которого генерился PDF Документ, nmap по найденному IP адресу показал ещё один открытый порт, которого раньше никто не видел.
![image](https://habrastorage.org/getpro/habr/post_images/df7/0ee/24b/df70ee24b6efad45cbe9553b8bdf392b.jpg)
Система 2. Видно, что сервер пытался загрузить 20 файлов по 10 гигабайт. Также получаем адрес одного из серверов и версию используемого Firefox -а.
![image](https://habrastorage.org/getpro/habr/post_images/3e6/c80/aa0/3e6c80aa0358911d5c9bd00e79209901.jpg)
Итог. В обеих системах ошибки уже исправлены. В первой системе вместо html purifying делается escaping и во время обработки пользовательских данных, и во время генерации PDF документа; во второй системе — режутся любые абсолютные линки на внешние ресурсы во время обработки пользовательских данных.
Обновлено.
Пока добрался до публикации статьи, прибавились кейсы еще из 2 систем.
Еще одна система (назовем Система 3) не прошла проверку на этот тип уязвимостей сразу в двух местах: через HTML Injection и CSS Injection.
Система 3. Html injection с загрузкой 20 раз живой картинки 13 Mb (в сумме 260Mb)
![image](https://habrastorage.org/getpro/habr/post_images/fca/8f2/5bd/fca8f25bd0092de64280c0d0cc6d6020.jpg)
Система 3. CSS Injection
![image](https://habrastorage.org/getpro/habr/post_images/df2/cfb/584/df2cfb584b9ed09f2d1250c63a70086a.jpg)
Система 3. Что видим на атакующем сервере при рендере PDF (все 20 загрузок картинки по 13Mb успешные)
![image](https://habrastorage.org/getpro/habr/post_images/a80/ed7/18b/a80ed718b82bb5c5862c0c7ea343942b.jpg)
Что на выходе получили для Системы 3:
1) Получили адреса серверов, которые занимаются рендерингом, и что они использует для рендера. В данном случае — HeadlessChrome.
2) Генерация одного PDF документа заняла около 5 минут, потом хром просто падал. Представьте, если запустить 10К таких запросов, то на время серверы по генерации в принципе перестанут отвечать на запросы других пользователей.
Система 4. SSRF атака здесь проведена не через img тэг, а через XSS, когда на сервере во время рендера выполнился мой любимый пэйлоад, и сервер запустил произвольный Javascript код во время генерации PDF Документа. По сравнению с предыдущими случаями, здесь можно проводить более сложные атаки на другие системы.
![image](https://habrastorage.org/getpro/habr/post_images/28a/5ac/d5b/28a5acd5ba920b65add4b1b51819a0a2.jpg)
Система 4. Отрендеренный PDF с выполненным произвольным JS кодом на серверной стороне
![image](https://habrastorage.org/getpro/habr/post_images/55f/f3c/8b2/55ff3c8b29a5d6cd83e1c5736bd0a480.jpg)
Посыл 1. Системы требуют разработки не только правил входящего файервола, но и исходящего, либо разработки инфраструктуры с отдельными сегментами сети или серверами, из которых вообще доступа во вне нету.
Посыл 2. При нахождении даже самой маленькой уязвимости необходимо всегда искать наихудшие сценарии его использования и влияния на бизнес. Бизнес умеет работать только с рисками, техническая сторона, к сожалению, их мало интересует.
Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.
Денис Колошко, CISSP, Penetration Tester
Комментарии (6)
arkamax
10.10.2019 20:37-1На DEF CON в этом году был доклад про SSRF в онлайновых PDF-генераторах, правда там выхлоп был интереснее — ребята унесли ключи от AWS инстансов, на которых крутился тот headless Chrome. Линк на слайды не выкладываю (кто его знает, что там в голове у товарища майора), гуглится за минуту по ключевым словам.
mogaika
это pdf настолько топовый что чтобы его отрендерить люди доходят до того чтобы запускать firefox и делать его скриншот? или есть более адекватные пути?
Vamp
Он кроссплатформенный. PDF документы выглядят одинаково на любых устройствах и на печати. Крайне полезное качество для всякого документооборота.
JohnSmith2
Нет, не одинаково, частенько не хватает шрифтов, при просмотре через браузер например.
CAJAX
Для этого в PDF есть встраивание шрифтов. Хотя, может это не везде поддерживается.