Подделка запроса на стороне сервера (Server Side Request Forgery)

Описание

Подделка запроса на стороне сервера (Server side request forgery или SSRF) это уязвимость, позволяющая взломщику использовать целевой сервер для отправки HTTP запросов от своего имени. Это похоже на межсайтовую подделку запроса (CSRF) тем, что в обеих уязвимостях мы отправляем HTTP запросы без ведома жертвы. Только в случае с SSRF жертвой является сам уязвимый сервер, а в случае с CSRF - это браузер пользователя.

Потенциал такого метода очень обширен и включает в себя:

•Получение информации. Мы обманываем сервер, дабы он раскрыл информацию о себе, как это описано в Примере 1, используя метаданные AWS EC2.

•Межсайтовый скриптинг (XSS) в случае, если мы можем удаленно рендерить HTML файл, содержащий Javascript.

Примеры

1. SSRF атака на ESEA и запрос метаданных

AWS

Сложность: средняя

Url: https://play.esea.net/global/media_preview.php?url=

Ссылка на отчёт: http://buer.haus/2016/04/18/esea-server-side- request-forgery-and-querying-aws-meta-data/

Дата отчёта: 18 апреля 2016 Выплаченное вознаграждение: $1000 Описание:

E-Sports Entertainment Association (ESEA) - это соревнователь-

ная киберспортивная площадка, основаная E-Sports Entertainment Association (ESEA). Недавно они запустили программу по поощрения белых хакеров, и Брет Бурхас нашел замечательную SSRF уязвимость.

Используя Google Dorking, Брет искал по запросу site:https://play.esea.net/ ext:php. Тем самым Google искал все файлы домена play.esea.net

с расширением PHP. Результаты запроса включали в себя файл https://play.esea.net/global/media_preview.php?url=.

При взгляде на URL кажется, будто ESEA может рендерить содержимое, полученное из внешних сайтов. Это красная лампочка, если мы ищем SSRF уязвимость. Как описано в отчёте,

Брет попробовал вписать туда свой домен: https://play.esea.net/global/media_preview.php?url=http://ziot.org. Неудача. Оказалось, что ESEA

принимает файлы изображений, и тогда он попробовал отправить запрос содержащий картинку, сначала используя Google

как домен, потом - свой собственный, https://play.esea.net/global/media_preview.php?url=http://ziot.org/1.png.

Успех.

Реальная уязвимость заключается в обмане сервера, чтобы тот отрендерил содержимое, отличное от картинок. В своём отчёте Брет детально описал обычные методы для обхода этого ограничения, например использование символа пустого

http://buer.haus/2016/04/18/esea-server-side-request-forgery-and-querying-aws- meta-data/

байта (%00), дополнительные слеши и знаки вопроса, чтобы обойти или обмануть сервер. В его случае был добав-

лен знак вопроса (?) в url: https://play.esea.net/global/media_preview.php?url=http://ziot.org/?1.png.

Этими действиями мы превратили ту часть url, конкретно указывающую на файл 1.png, в параметр. В результате ESEA отрендерила страницу Брета. Другими словами он обманул проверку расширения из своей первой попытки.

Теперь мы можем применить межсайтовый скриптинг, как это описал Брет. Создаём простую HTML страницу с Javascript, отправляем на сайт жертвы для рендера и готово. Но он пошел дальше. При участии Бена Садежипура (которого мы помним по Hacking Pro Tips Interview #1 на моём YouTube канале и

Polyvore RCE), он протестировал запросы на метаданные ин-

станса AWS EC2.

EC2 - это облачный сервер амазона. Они предоставляют возможность отправить запрос к своему сервису, чтобы получить метаданные об инстансе. Очевидно, что такие привилегии недоступны для самого инстанса, но поскольку Брет имеет возможность контролировать откуда сервер загружает содержимое, он может заставить сервер получить эти метаданные.

Документация ec2 находится тут: http://docs.aws.amazon.com/AWSEC2/latest/ instance-metadata.html. Есть несколько интересных мест, ко-

торые вы можете взять на вооружение.

Выводы

Google Dorking - отличный инструмент, позволяющий сэкономить вам время исследования возможных путей взлома. В случае выше это было просто url= что несомненно является везением.

Во-вторых, не отступайте после первых полученных выводов. Брет мог бы указать в отчете только возможность межсерверного скриптинга, что не было бы так эффектно. Копнув чуть-чуть поглубже, он смог понять настоящий потенциал этой уязвимости. Но разбирая уязвимость будьте осторожны, важно не зайти слишком далеко.

Итог

Подделка запроса на стороне сервера (SSRF) становится возможной, когда сервер позволяет совершать запросы от лица злоумышленника. Однако не все запросы могут быть использованы для атаки. Например то, что сайт позволяет вам вписать URL ведущий к картинке, которая будет скопирована и использована на самом сайте (как в примере с ESEA выше), не значит, что сервер уязвим. Найти эту возможность - лишь первый шаг, после которого вам нужно выявить весь потенциал уязвимости. Со всем уважением к ESEA, хотя их сайт через url принимал файлы с картинками, он не проверял получаемый контент на предмет XSS или HTTP запросов к своим же метаданным EC2.