В предыдущих статьях (первая, вторая) мы рассматривали несколько типов уязвимостей на примерах устаревших версий реального программного обеспечения, рассказывали о базовом инструментарии при занятии багхантингом, о багбаунти-программах, их правилах, скоупе и исключениях.
В заключительной части цикла мы традиционно рассмотрим еще несколько классов уязвимостей на реальных примерах, а то, чего мы не успеем коснуться, оставим для самостоятельного изучения. Ведь о каком опыте и знаниях можно говорить, если не стремиться к самообразованию и саморазвитию? ???? Еще приведем пять интересных хакерских трюков, они же hack tricks , которые неплохо известны атакующим, поэтому и нам, исследователям безопасности, необходимо знать существующие, изучать новые, а также придумывать собственные. В конце дадим напутствие новичкам-багхантерам для успешного путешествия в мир багбаунти, в котором нужно стремиться делать мир безопаснее, стать одним из лучших белых хакеров, завоевывать признание среди сообщества и, конечно же, получать хорошие вознаграждения за найденные уязвимости.
Дисклеймер
Эта статья носит информационный характер. Мы призываем не к совершению противоправных действий, а к легальному поиску уязвимостей в информационных системах. Обращаем внимание на необходимость во всех случаях соблюдать действующее законодательство и правила соответствующей программы по поиску уязвимостей. Неправомерный доступ к компьютерной информации влечет за собой юридическую ответственность.
Быстрый старт на настоящих примерах
В этом разделе поговорим про уязвимости в веб-системах. Рассмотрим еще два их вида, дадим краткое описание каждого и продемонстрируем, как они могут эксплуатироваться.
Server-side request forgery (SSRF)
Server-side request forgery (SSRF) — уязвимость, позволяющая нападающим отправлять произвольные запросы со стороны сервера. Ее использование может привести к следующим проблемам:
сканированию внутренней сети и портов — это позволяет атакующему понять, какие серверы и порты доступны в локальной сети;
отправке запросов во внешнюю сеть со стороны сервера, уязвимого к SSRF-атаке. Сервер может стать одним из агентов ботнета злоумышленника и начать несанкционированно отправлять большое количество запросов к выбранной цели, чтобы вывести ее из строя;
отправке запросов во внутреннюю сеть, которая недоступна извне. В некоторых случаях это позволяет злоумышленнику выявить и скомпрометировать сервис, доступный во внутренней сети, если отправить специально подготовленный запрос;
чтению локальных файлов, что влечет за собой раскрытие содержимого как системных файлов, так и файлов приложения (в том числе конфигурационных), которые, как правило, содержат критически важную информацию: приватные ключи, адреса, логины, пароли;
извлечению чувствительной информации; например, злоумышленник может узнать название или версию сервиса, работающего внутри инфраструктуры. Эти сведения могут помочь киберпреступникам в поисках уязвимостей и эксплойтов, существующих для обнаруженного ими сервиса, или в написании собственного эксплойта нулевого дня.
Случалось ли такое, что вы исследовали систему, в которой есть функциональность генерации отчетов, чеков, билетов или накладных в формате PDF? Давайте рассмотрим API-сервис Gotenberg, который позволяет генерировать PDF-файлы на основе различных форматов, в частности HTML, Markdown, DOC (DOCX), XSL (XLSX). В версии 6.3.0 была найдена SSRF-уязвимость, которой присвоен номер CVE-2021-23345. Суть этой уязвимости заключается в том, что API-сервис принимает файл с именем index.html через POST-запрос. Отправляемый файл содержит тег iframe, который при рендеринге на сервере с запущенным уязвимым сервисом запрашивает системный файл с помощью протокола file. В этом примере запрашиваемым файлом будет системный файл /etc/passwd.
Согласно содержанию публичного эксплойта, был отправлен POST-запрос к сценарию http://192.168.1.214:3000/convert/html с прикрепленным файлом index.html.
Ответ от сервера содержит отрендеренное содержимое файла index.html в формате PDF. Если открыть полученный файл, можно увидеть, что он содержит всю информацию, которая располагается в системном файле /etc/passwd атакуемой злоумышленником системы.
XML external entity (XXE)
XML external entity (XXE) — уязвимость, позволяющая атакующим вмешиваться в работу приложения посредством обработки XML-данных, которые поступают от пользователя. Это может привести:
к выполнению SSRF-атак (о них мы рассказали выше);
чтению локальных файлов, что влечет за собой раскрытие содержимого как системных файлов, так и файлов приложения (в том числе конфигурационных), которые, как правило, содержат критически важную информацию: приватные ключи, адреса, логины, пароли;
эксфильтрации данных, при которой последние передаются с сервера уязвимого приложения на сервер, контролируемый киберпреступником;
инициированию ошибки, в которой будут содержаться запрашиваемые злоумышленником данные синтаксического анализа XML;
выполнению DoS-атаки на сервер с расходованием его вычислительных ресурсов. Один из примеров — billion laughs attack.
Приведем немного теоретической информации об XML, чтобы пример реальной уязвимости стал максимально понятен.
XML (англ. eXtensible Markup Language) — расширяемый язык разметки, предназначенный для хранения и передачи данных. Пример структуры XML-файла, в которой описывается пользователь с идентификатором:
Теперь немного изменим структуру XML-файла и расскажем, что из этого получилось:
Во-первых, во второй строке появилось определение типа документа (DTD), сообщающее синтаксическому анализатору XML о том, какая структура будет у документа. В данном случае определена пользовательская сущность с именем xxe, которая запрашивает системный файл по пути file:///etc/passwd. Во-вторых, в третьей строке вместо значения 1337 появилась ссылка на определенную выше сущность &xxe;.
Если эта структура будет обрабатываться XML-парсером с включенной обработкой сущностей в системе и, к примеру, сохранять либо отображать результат или ошибку обработки, то в значении тега id будет находится содержимое системного файла /etc/passwd системы Linux:
Мы рассмотрим эту уязвимость в общедоступной системе управления содержимым сайта с открытым исходным кодом WordPress версии ниже 5.7.1. Уязвимость была найдена исследователями из SonarSource. На эту тему они написали техническую статью WordPress 5.7 XXE Vulnerability. Для этой уязвимости с идентификатором CVE-2021-29447 есть первый и второй общедоступные эксплойты. Чтобы воспроизвести ее, нам потребуется система WordPress версии 5.7, работающая на PHP8, а также наличие аккаунта с авторскими привилегиями и возможностью загружать медиафайлы. Если коротко о том, что дает злоумышленнику эта уязвимость, то при использовании PHP8 вызов функции simplexml_load_string с флагом LIBXML_NOENT разрешал замещение сущностей.
Эксплуатация этой уязвимости помогает достичь двух целей — выполнения SSRF-атаки и чтения произвольного файла в системе. Рассмотрим шаги по воспроизведению данной уязвимости.
Создать медиафайл malicious.wav, содержащий специально сформированный XML-документ внутри. Как мы видим, в XML-структуре определена сущность, которая запрашивает внешний файл http://192.168.1.26/external.dtd.
Сам факт выполнения внутреннего или внешнего запроса через XXE-уязвимость также может считаться подвидом SSRF-уязвимости.
Создать файл external.dtd (http://192.168.1.26/external.dtd), который размещается на сервере атакующего. Запрос этого файла будет инициирован уязвимой версией системы WordPress, когда пользователь с авторскими правами загрузит файл malicious.wav и система начнет его обрабатывать, в том числе с использованием функции simplexml_load_string.
В файле external.dtd интересным является использование фильтра сжатия, который запросит у системы системный файл /etc/passwd и закодирует в формат Base64, произведет его компрессию (сжатие), после чего направит результат на сервер атакующего (http://192.168.1.26) в GET-параметре «p».
Запустить вeб-сервер на 80-м порту сервера атакующего, который при внешнем запросе вернет файл external.dtd (http://192.168.1.26/external.dtd).
Загрузить раннее сформированный файл malicious.wav и следить за тем, как на сервер атакующего придут два запроса. Первый запросит файл external.dtd, второй запрос будет с параметром «p» и закодированным в Base64 формате и сжатым содержимым файла /etc/passwd.
На скриншоте ниже представлен интерфейс панели администратора пользователя с авторскими правами, в котором проведена загрузка подготовленного файла malicious.wav.
В то же время на сервер атакующего пришло несколько внешних запросов. Первый запрос — получение файла external.dtd для дальнейшей обработки XML-парсером атакуемой системы. Второй — результат выполнения полученного файла external.dtd с последующей отправкой атакуемой системой закодированного в Base64 формате и сжатого содержимого файла /etc/passwd на сервер злоумышленника.
Раскодируем полученную нагрузку из Base64-формата и декомпрессируем ее, чтобы привести содержимое в понятный вид. Как видно на рисунке ниже, вся информация успешно получена.
Hack tricks
При поиске уязвимостей у багхантера со временем накапливается ценный опыт, а также вырабатывается собственная стратегия поиска уязвимостей. В этом разделе мы покажем лишь несколько хакерских трюков — тех самых, которые хорошо должны знать багхантеры, потому что их часто применяют злоумышленники в атаках. Но стоит понимать, что таких трюков существует огромное множество, и новые интересные техники и уязвимости появляются постоянно. Однако и про старые тоже не стоит забывать: вы можете обнаружить в скоупе багбаунти-программы давно забытый и не обновлявшийся сервис, содержащий достаточное количество различных уязвимостей, в том числе и критического уровня опасности. Приведенные далее примеры определенно стоит попробовать применять при исследовании систем на безопасность. В дополнение хотим посоветовать ресурсы, которые помогут существенно расширить опыт и кругозор начинающего багхантера: PT SWARM, HackTricks, HackTricks Cloud, Exploit Database, PayloadsAllTheThings, CVExploits, GTFOBins, Bug Bounty Tips.
Hack trick № 1
Есть ли в исследуемой системе функция загрузки изображений? Попробуйте загрузить файл с расширением .svg — этот тип файлов при просмотре в браузере поддерживает выполнение JavaScript-кода. В случае, если файл был загружен на сервер, то наверняка есть ссылка вида https://192.168.1.214/xss.svg, как в примере, по клику на которую файл откроется в браузере и выполнится внедренный JavaScript-код, что, в свою очередь, приведет к атаке Stored XSS.
Однако бывают ситуации, когда SVG-файл не открывается в браузере, а загружается на компьютер пользователя, как правило, в папку «Загрузки». Тогда выполнить JavaScript-код в рамках исследуемого домена не получится. Если файл успешно отобразился в браузере в рамках исследуемого домена, но JavaScript-код не выполнился, то это заслуга специальных заголовков Content Security Policy (CSP), возвращаемых сервером. Одной из задач этих заголовков и является предотвращение несанкционированного выполнения JavaScript-кода.
Hack trick № 2
Иногда разработчики системы забывают экранировать имя загруженного файла. Оно может отображаться в профиле пользователя, в приватном сообщении, сообщении в ветке форума или в панели администратора. В таком случае стоит попробовать внедрить в имя файла следующую нагрузку, приводящую к атаке Stored XXS.
На рисунке ниже приведен пример с системой FUDforum v3.1.1.
Hack trick № 3
Вы когда-нибудь слышали про набор программ ImageMagick? Полагаем, вы наверняка ими даже пользовались, но, скорее всего, не знали об этом. Этот набор программ предназначается для чтения и редактирования файлов различных графических форматов. Если говорить простым языком, то при обработке загруженной пользователем фотографии во многих случаях на сервере используется ImageMagick. Обработка может включать в себя различные действия над графическим файлом: изменение размера, сжатие, добавление специальных эффектов.
Увы, уязвимости не обошли стороной и ImageMagick. В качестве примера можно привести серию уязвимостей, иронично названных ImageTragick. О них можно почитать, а также посмотреть примеры на одноименном сайте ImageTragick. Уязвимости позволяют киберпреступникам выполнять много операций: выполнить удаленный код на сервере (CVE-2016-3714), провести SSRF-атаку (CVE-2016-3718), несанкционированно удалить файл (CVE-2016-3715), переместить его (CVE-2016-3716), а также прочитать (CVE-2016-3717).
Приведенные примеры уязвимостей были опубликованы в 2016 году. Это говорит нам о том, что в большинстве систем, скорее всего, ImageMagick был обновлен, и найденные уязвимости сегодня уже не сработают.
Совсем недавно, в 2022 году, была обнаружена новая уязвимость, позволяющая читать файл на сервере (CVE-2022-44268) в ImageMagick версии 7.1.0-49 и ниже при обработке PNG-файла. Примеры эксплуатации доступны в сети (1, 2, 3), и, более того, есть случаи реальной эксплуатации данной уязвимости — [CVE-2022-44268] Arbitrary Remote Leak via ImageMagick.
Представим, что на абстрактном сервере установлен ImageMagick 7.1.0-49, а также существует веб-сервис, в функциональности которого есть загрузка изображений. После загрузки изображение обрабатывается для создания превью, то есть происходит конвертация, к примеру изменение размера изображения (resize). Измененное изображение возвращается пользователю, и он может его просматривать.
Согласно описанию одного из примеров эксплуатации уязвимости, вначале необходимо подготовить специальное изображение на сервере атакующего. Это можно сделать несколькими способами. Мы рассмотрим способ с применением открытого программного обеспечения, которое используется для оптимизации фильтров PNG-изображений, — pngcrush.
Для этого возьмем любое изображение png-original.png, на основе которого будет построен специально подготовленный файл. Кроме того, необходимо указать, какой файл будет прочитан на атакуемом сервере. В данном случае — /etc/passwd. Следует понимать, что читаемым файлом могут быть и SSH-ключи, и конфигурационные файлы. Несанкционированный доступ к этим файлам может нанести критический ущерб и полностью скомпрометировать систему.
Как видно на изображении выше, подготовленный файл имеет наименование pngout.png. Теперь представим, что этот файл был успешно загружен на атакуемый сервер. Сервер начинает преобразование этого файла, изменяя его размер через конвертацию.
После преобразования появился еще один файл — result.png. Это файл и является превью изображения pngout.png и также может быть возвращен пользователю.
Багхантер, получив файл result.png, должен проверить, получилось ли проэксплуатировать уязвимость CVE-2022-44268 в ImageMagick и прочитать системный файл /etc/passwd. Для этого нужно в своей системе выполнить идентификацию файла, используя ImageMagick (можно использовать и exiftool). Она покажет всю информацию о файле.
Видим, что в поле Raw profile содержится некоторая нагрузка. Ее необходимо скопировать и декодировать следующей командой.
После выполнения декодирования становится доступно содержимое файла /etc/passwd атакуемого сервера.
Наглядную схему работы этой уязвимости можно представить следующим рисунком.
Hack trick № 4
Символическая ссылка (symlink) — особый файл в файловой системе, который не содержит данные, а является ссылкой на другой файл. При открытии символической ссылки будет возвращено содержимое того файла, на который она ссылается.
А вы знали, что можно создавать ZIP-архив, который содержит символическую ссылку? И как, вы спросите, это относится к hack tricks? А вот так: давайте представим, что существует некоторый веб-сервис, позволяющий загрузить ZIP-архив и просмотреть его содержимое. Веб-сервис распаковывает у себя ZIP-архив и отображает список файлов и их содержимое пользователю. И тут возникает вопрос, а проверяет ли этот веб-сервис распакованные файлы на признак символической ссылки? Если нет, то атакующий может прочитать системный файл и получить критически важную информацию!
Покажем, как багхантеру подготовить такой архив, чтобы проверить систему на этот баг. Допустим, мы знаем, что на изучаемом сервере в файле /tmp/secret лежит секретная фраза, и нам ее надо получить. Для этого необходимо выполнить несколько шагов:
Создать /tmp/secret-файл в своей системе с произвольным содержимым.
Создать символическую ссылку на файл /tmp/secret.
Создать архив с флагом символической ссылки. Флаг symlinks означает, что необходимо упаковать не файл, на который ссылается ссылка, а именно саму символическую ссылку.
Подготовленный ZIP-архив доставляется на целевой сервер, где распаковывается и выполняется чтение его содержимого, то есть файла secret. Как видно на рисунке ниже, при распаковке файла присутствует символьная ссылка, при прочтении которой мы увидели содержимое файла /tmp/secret исследуемого сервера.
Пример такой уязвимости также встречается в реальных условиях. Так, за ее обнаружение в GitLab исследователь получил 29.000 $.
Hack trick № 5
При исследовании веб-приложений в рамках багбаунти стоит уделять внимание заголовкам, Cookie-файлам и параметрам, которые отправляются при выполнении HTTP-запроса. Вам может попасться система, которая собирает, обрабатывает и сохраняет эту информацию. Вся собранная информация агрегируется и отображается в кабинете администратора.
Приведем пример HTTP-запроса, где можно попытаться провести инъекцию. Однако стоит помнить, что в приведенном примере это далеко не все заголовки и ключи — они могут быть произвольными. Поэтому систему нужно исследовать по ситуации.
В чем же может быть проблема? Проблема может заключаться в том, что данные во входящем запросе могут обрабатываться логикой приложения или быть сохранены в базе данных без предварительной санитизации. Это открывает злоумышленникам несколько векторов атак, а значит, багхантерам следует проверять возможность их реализации при исследовании защищенности IT-систем. Среди таких векторов:
SQL injection. При передаче в значении заголовка обратный апостроф (`), одинарной (') или двойной кавычки (") необходимо проанализировать ответ от сервера. Вернет ли он ошибку или нет, а если вернет, то какую? Например, сервер может вернуть ошибку уровня СУБД, что облегчит злоумышленнику дальнейшую эксплуатацию уязвимости. Но бывает, что при возникновении ошибки, в исключительной ситуации, бизнес-логика приложения подавляет их, используя блок try-catch или условие, и возвращает стандартный ответ, по которому ничего нельзя понять. В таких условиях пробуют применить Time-Based SQL Injection или Out-Of-Band SQL Injection;
Cross-Site Scripting (XSS) (в особенности Blind XSS) или Client-Side Template Injection (CSTI). Атакующий внедряет специальную JavaScript-нагрузку в указанные выше места, которые обозначаются маркером [TRY_INJECT]. Она сохраняется в базе данных и выводится в панели администратора в виде отчета без использования санитизации. У администратора в браузере при просмотре отчета отобразится и выполнится внедренная атакующим JavaScript-нагрузка, задача которой обратиться на сервер атакующего и дать о себе знать, то есть «сделать отстук»;
Server-Side Template Injection (SSTI).
Заключение
Вот и подошел к концу цикл статей «Как начать заниматься багхантингом веб-приложений». На протяжении трех частей мы рассматривали теорию, а также практику, реальные примеры систем, которые могут вам встретиться при багхантинге. Теперь вы будете знать, что с ними делать.
Конечно, мы затронули лишь маленькую часть той сферы наступательной кибербезопасности, которая постоянно пополняется данными о новых уязвимостях, техниками эксплуатации и хакерскими трюками. Но не стоит останавливаться только на прочитанном. В качестве домашнего задания приведем список терминов, с которыми вам нужно будет разобраться самостоятельно (он охватывает лишь небольшой процент всех типов уязвимостей и атак). Так вы начнете самообучаться, развиваться и углублять свои знания — а это дорогого стоит.
Итак, предлагаем уделить внимание следующим терминам, которые мы не успели затронуть в рамках цикла:
удаленное выполнение кода (Remote Code Execution, RCE) — особо опасный класс уязвимостей. RCE позволяет выполнять произвольные команды на сервере, что является самой опасной уязвимостью в рамках веб-приложения, так как дает злоумышленникам полный контроль над системой. Эта уязвимость может быть проэксплуатирована через инъекцию команды (Command Injection), загрузку произвольных файлов (Arbitrary File Upload), десериализацию недостоверных данных (Deserialization of untrusted data), путем включения локального либо удаленного файла (LFI / RFI), Server-Side Template Injection (SSTI) и даже через SQL injection, о которой мы говорили в одной из прошлых статей;
отравление кэша (Cache Poisoning), одним из сценариев эксплуатации которого является сохранение в веб-кэше вредоносного кода. Закэшированный вредоносный код может стать доступен другим пользователям системы, что приведет к прямой атаке на них;
JSON web token (JWT) — JSON-объект, состоящий из нескольких частей, — заголовка (header), полезные данные (payload) и подпись (signature). В заголовке содержится информация о том, как именно подпись должна рассчитываться и проверяться на сервере. Подпись, в свою очередь, нужна для того, чтобы гарантировать легитимность полезной нагрузки. И даже тут могут существовать уязвимости!
обход механизма Cross-origin resource sharing (CORS). Такие заголовки в HTTP-запросе, как Origin, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, подскажут вам, в какую сторону направить усилия;
атака на логику приложения. Существует достаточно большое количество проблем, например, состояние гонки (Race Condition), неправильные проверки нестандартных условий, отсутствие ограничений на отправку писем, СМС-сообщений, подбор 2FA-кодов, атаки на округление (в том числе денежных средств).
Полагаем, что если вы будете прилагать усилия по изучению фундаментальных материалов, подкреплять их практикой, постоянно самообучаться и не бояться развиваться, то в выигрыше будут все. С одной стороны, системы компаний, участвующих в багбаунти-программах, будут превращаться в неприступные бастионы, стены которых с каждой сданной уязвимостью будут становится все толще, а рвы — глубже. С другой стороны, вы как представители сообщества багхантеров делаете себе имя и нарабатываете репутацию, будете на острие наступательной кибербезопасности и, вдобавок, будете получать щедрые вознаграждения!
Чтобы знать, как защитить системы от хакера, исследователь безопасности должен думать, как хакер.
Удачи!
Алексей Соловьев
Старший специалист группы анализа защищенности веб-приложений компании Positive Technologies