Делать пентест злософта, наверное, так же прикольно, как экспроприировать у экспроприаторов и грабить награбленное. По заданию журнала «Хакер» мы подошли к эксплойт-паку Blackhole exploit kit v2.0.1 с несколько необычной стороны: мы попробуем расковырять связку эксплойтов и сделаем соответствующие выводы. То, чем мы будем заниматься, можно научно назвать «экспресс-анализом сценариев связки методом черного ящика» (blackbox-тестирование, подразумевает отсутствие исходных кодов веб-приложения у проверяющей стороны).
Известно, что связка эксплойтов имеет следующую архитектуру: ротатор эксплойтов и административная часть. Мы анализировали исключительно административную панель связки, так как она представляет собой веб-приложение (набор сценариев) и является наиболее критичным элементом для администратора Blackhole exploitkit — если доступ к административной части будет утерян, администратор перестанет контролировать функционирование эксплойт-пака со всемивытекающими последствиями.
Что новенького в Blackhole?
Давно мы не писали о связке с точки зрения ее внутренних процессов. Со времени последнего материала, посвященного анализу связки, ее программное обеспечение претерпело ряд существенных изменений:
1. Генерация динамического URL. Обеспечивает защиту эксплойтов от автоскачивания антивирусными компаниями.
2. Минимизация количества эксплойтов — теперь доступны только максимально свежие и эффективные экземпляры.
3. Введена captcha при авторизации администратора связки (для «защиты» администраторской панели).
4. Добавлена возможность использовать в качестве вспомогательного инструмента для производительности Memcached — это поможет снизить нагрузку при больших объемах трафика.
5. К списку ОС добавлены Windows 8 и мобильные устройства, что позволит более гибко управлять трафиком.
6. Появилась возможность использовать связку как прокладку между источником трафика и местом ее назначения. Для этого при создании потока появилась возможность указывать URL для редиректа отработанного трафика.
7. При добавлении к файлу появилась возможность указывать периодичность проверки этого файла на детект антивирусными средствами.
8. Полностью обновился раздел «Безопасность» (появилась возможность блокировать трафик без рефереров, банить ненужные рефереры, банить боты по заранее подготовленной базе из 13 000 IP, возможность банить Tor-сети и другие).
Межсайтинговый скриптинг (XSS)
Межсайтовый скриптинг (Cross Site Scripting a.k.a. XSS) – атака на клиента веб-приложения, которая реализует уязвимость некорректной фильтрации поступающего от пользователей контента (повторение – мать учения, не так ли?)
На странице загрузки «боевой нагрузки» (Раздел «Файлы», название скрипта – registers.php) имеется возможность загрузить произвольный файл. После загрузки данного файла веб-приложение отображает о нем информацию. При передаче целевого файла скрипт registers.php не осуществляет какую-либо фильтрацию строкового значения для параметров «FileUrl» (ссылка на файл после его загрузки) и «Title» (имя загружаемого файла). Таким образом, становится возможным внедрение произвольного HTML/JS кода в страницу, возвращаемую пользователю связки при переходе в раздел файлы (рисунок 2).
Рисунок 2 – Передача в параметра «FileUrl» JS-скрипта
В результате на веб-странице «Файлы» находится хранимая XSS . Результатом данной атаки может являться исполнение на клиентской стороне любого HTML-кода или произвольного JS-сценария.
Рисунок 3 – Отображение HTML-кода (вставлен тег <img> с произвольной картинкой) в результате XSS
Возможности HTML5 позволяют осуществлять различные сценарии атаки на администратора эксплойт-пака. Например, с помощью новой версии языка разметки гипертекста можно создавать страницы с определением местоположения администратора эксплойт-пака посредством интерфейса Geolocation API (рисунок 4).
Рисунок 4 – Использование HTML5 Geolocation API для реализации XSS-атаки
Рисунок 5 – Вставка произвольного текста в поле «Title» (название загруженного файла)
Атака «Session Fixation»
В данной версии «Blackhole Exploit Kit» существует возможность установки произвольного значения сookie пользователю из-за отсутствия фильтрации значений параметров «type» и «sort», передаваемых к сценарию registers.php. На рисунке 5 видно, что параметру «type» скрипта registers.php передается присваивается значение «Fake_Cookie».
Теоретически данная уязвимость может привести к установке произвольного значения сессии пользователю. Однако в данном случае нам мешает одна особенность скрипта: к устанавливаемому значению добавляется строка «+desc». К сожалению, в ходе исследования не удалось найти способ обрезать ненужную часть строки.
Рисунок 5 – Передача значения «Fake_Cookie» в параметр «sort» и получение ответа с установленным значением
Рассматривая вопрос корректности работы сценариев с пользовательскими сессиями, необходимо отметить, что значение сессии пользователя не меняется после успешной аутентификации. Данная особенность может быть использовано для проведения атак типа «session fixation», при которых пользователю принудительно присваивается выбранное значение идентификатора сессии (например, при помощи описанной выше уязвимости, при которой имеется возможность устанавливать произвольное значение cookie).
Еще одной ошибкой, связанной с обработкой сессий в связке, является отсутствие принудительной инвалидации (удаления) сессии после выхода пользователя из интерфейса при помощи «Logout». Другими словами, данная сессия, в случае ее перехвата, может быть повторно использована для авторизации в связке, несмотря на то, что пользователь попытался корректно выйти из приложения.
Подделка межсайтовых запросов
Уже на данном этапе экспресс-анализа можно сделать вывод, что создатели эксплойт-пака не беспокоятся о защите административной части своего продукта. Подтверждением этого также является отсуствие какой-либо защиты от таких атак как CSRF и UI Redressing (a.k.a. Clickjacking). Однако, для их успешной реализации требуется активные действия администратора связки (просмотр страниц, открытие ссылок и т.п.).
Общий итог исследования: разработчики топовой связки эксплойтов «Blackhole Exploit Kit» не заботятся о защите веб-приложения, а это значит, что для антивирусных компаний существует возможность перехватить управление над административной частью данного продукта и осуществить все необходимые меры для его деактивации.
Материал опубликован в журнале “Хакер” № 9/13 (176)
