Мист блэйт: уязвимость SSRF

Преподаватель: gh0stkey (https://www.zhihu.com/people/gh0stkey/answers)

Автор: летающий дракон (https://github.com/)

Лицензия: CC BY-NC-SA 4.0 (http://creativecommons.org/licenses/by-nc-sa/4.0/)

Многие веб-приложения предоставляют возможность получения данных с других серверов. Используя указанный пользователем URL, веб-приложение может получать изображения, загружать файлы и считывать содержимое файлов. Если эта функция используется злоумышленниками, то они могут использовать уязвимое веб-приложение в качестве прокси для атаки на удалённые и локальные серверы. Эта форма атаки называется «подделка запросов на стороне сервера» (SSRF).

Принцип работы

<?php
$url = @$_GET['url'];
if($url) {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $co = curl_exec($ch);
    curl_close($ch);
    echo $co;
}

Этот фрагмент кода считывает параметр url из URL и затем обращается к ресурсу, указанному в url. Наконец, ресурс отображается на странице.

(Конечно, этот код несколько упрощён и не является настоящим прокси-сервером, некоторые ресурсы могут обрабатываться неправильно.)

Мы сохраняем его как ssrf.php и развёртываем. Затем мы обращаемся к localhost/ssrf.php?url=http://www.baidu.com:

Можно видеть, что отображение нормальное. Эту уязвимость также можно использовать для доступа к локальным изображениям. Мы снова обращаемся к файлу file:///C:/Windows/win.ini:

На странице отображается беспорядок, но если мы проверим исходный код, он будет отображаться нормально.

Использование

Уязвимость SSRF можно использовать для сканирования портов серверов и получения информации об их службах. Идентификация служб осуществляется путём доступа к файлам по умолчанию:

В этом изображении мы обратились к службе Tomcat по адресу 10.50.33.43. 10.50.33.43 — это внутренняя сеть, к которой мы не можем получить доступ напрямую, но можем через SSRF. Кроме того, мы определили, что на этой машине развёрнут сервис Tomcat, обратившись к файлу по умолчанию.

После определения развёрнутой службы мы можем целенаправленно атаковать приложения, развёрнутые во внутренней сети. Например, ST2 и SQL-инъекции, которые выполняются через метод GET.

Эту уязвимость также можно использовать для чтения файлов конфигурации серверов, таких как упомянутый выше win.ini.

Исследование

Следующие бизнес-сценарии подвержены этой уязвимости:

1. Приложение получает изображение с указанного пользователем URL и сохраняет его под случайным именем на жёстком диске, а затем отображает его пользователю.
2. Приложение получает данные (файлы или HTML) с указанного пользователем URL. Эта функция использует сокеты и устанавливает TCP-соединение с сервером для передачи исходных данных.
3. Приложение извлекает веб-сайт пользователя на основе предоставленного им URL и автоматически генерирует мобильный Wap-сайт.
4. Приложение предоставляет функцию измерения скорости, которая может получить доступ к целевой странице на основе указанного пользователем URL для получения скорости доступа в соответствующей широте и долготе.

Функции веб-сервисов

Из приведённого выше обзора видно, что SSRF возникает из-за функций, связанных с получением информации о других серверах на сервере. Поэтому мы можем перечислить несколько распространённых функций получения информации о других сервисах на сервере в веб-приложении.

1. Поделиться: веб-приложение получает контент веб-страницы по указанному URL-адресу и использует его для обмена.

Ранние приложения для обмена контентом, чтобы обеспечить лучший пользовательский опыт, использовали веб-приложения для сбора контента целевых URL-адресов, включая теги <title> и <meta name="description" />, для отображения и предоставления лучшего пользовательского опыта. Например, в функции обмена на Renren.com:

http://widget.renren.com/****?resourceUrl=****

Целевой URL-адрес используется для получения тегов title и соответствующего текста. Если в этой функции нет фильтрации и ограничений на диапазон целевых адресов, существует уязвимость SSRF.

Исходя из этой функции, мы видим, что многие интернет-компании имеют такую функцию. Ниже приведён снимок экрана из онлайн-платформы для сообщений о уязвимостях, который показывает, что уязвимость SSRF была обнаружена в функциях обмена многих известных компаний в Китае, таких как Tencent, Sina и Baidu.

2. Трансформация сервиса: веб-приложение преобразует контент целевой веб-страницы в соответствии с размером экрана мобильного устройства для просмотра на мобильном устройстве.

Поскольку размер экрана мобильного устройства ограничен, прямой просмотр веб-контента может вызвать неудобства. Поэтому некоторые компании предлагают услуги преобразования, которые преобразуют веб-контент в формат, подходящий для просмотра на мобильных устройствах. Например, Baidu, Tencent и Sogou предоставляют услуги онлайн-преобразования.

3. Онлайн-перевод: веб-приложение переводит текст, соответствующий целевому URL-адресу. Компании, предоставляющие такие услуги в Китае, включают Baidu и Youdao.

4. Загрузка и скачивание изображений: веб-приложение загружает или скачивает изображения по указанным URL-адресам.

Эта функция широко используется, но часто скрыта, например, некоторые компании загружают изображения с собственных серверов изображений для демонстрации. (Некоторые компании могут хранить внешние изображения на своих серверах, поэтому при чтении изображений HTTP может возникнуть проблема SSRF.)

5. Функции сбора изображений и статей: эта функция аналогична функции обмена, где контент, соответствующий URL-адресу, используется для сбора изображений или статей. Цель также состоит в том, чтобы улучшить пользовательский опыт. Сбор изображений похож на загрузку изображений.

6. Непубличные API и другие функции вызова URL: эта функция похожа на оценку веб-сайтов, предоставляемых 360, и получение XML-файлов с удалённых адресов через API для загрузки контента.

Эти функции, за исключением общедоступных услуг преобразования и трансляций, могут столкнуться с проблемами SSRF в процессе разработки корпоративных приложений.

Поиск ключевых слов URL

Основываясь на характеристиках URL-адресов с уязвимостью SSRF, после некоторого времени использования мобильного телефона мы обнаружили следующие ключевые слова:

• share
• wap
• url
• image
• link
• src
• source
• target
• u
• 3g
• display
• sourceUrl
• imageUrl
• domain

Если вы используете синтаксис Google (inurl:url=) вместе с этими ключевыми словами для поиска уязвимостей SSRF, вы всё ещё можете найти существующие уязвимости.

Проверка уязвимости

Например:

http://www.douban.com/***/service?image=http://www.baidu.com/img/bd_logo1.png

Метод исключения 1:

Вы можете напрямую щёлкнуть правой кнопкой мыши изображение, открыть его в новом окне и проверить, является ли URL-адрес в адресной строке браузера http://www.baidu.com/img/bd_logo1.png. Если это так, уязвимости SSRF нет.

Метод исключения 2:

Вы также можете использовать Burp или другой инструмент захвата пакетов для определения наличия уязвимости SSRF. Во-первых, SSRF инициируется запросом от сервера, поэтому запрос на загрузку изображения должен исходить от сервера при загрузке изображения. Таким образом, запрос на изображение не должен существовать в вашем браузере. В этом примере, если вы обновите текущую страницу, появится следующий запрос, тогда можно определить, что это не уязвимость SSRF:

А именно, изображение находится на Baidu, но вы вызываете Sogou, браузер запрашивает изображение у Baidu, тогда уязвимости SSRF не существует. Если браузер запрашивает изображение у Sogou, это означает, что сервер Sogou отправил запрос и запросил изображение у Baidu, возможно, существует уязвимость SSRF.

Здесь объясняется, почему мы используем метод исключения для определения уязвимости SSRF. Приведём пример:

Теперь большинство методов устранения уязвимости SSRF основаны на различении внутренних и внешних сетей для ограничения. Если мы запрашиваем:

http://read.******.com/image?umageUrl=http://10.10.10.1/favicon.ico

Но содержимое не отображается, мы не сможем определить, существует ли уязвимость SSRF или http://10.10.10.1/favicon.ico фильтруется или вообще не существует этого изображения. Поскольку мы заранее не знаем, существует файл или нет, мы не можем определить причину, поэтому мы используем метод исключения.

Пример проверки:

После простой проверки методом исключения мы должны проверить, действительно ли этот URL может запросить соответствующий адрес внутренней сети. В этом примере нам сначала нужно получить адрес HTTP-службы внутренней сети, на котором есть файл favicon.ico, чтобы проверить, существует ли уязвимость SSRF.