Dns туннелирование что такое

Обновлено: 04.07.2024

DNS-туннелирование превращает систему доменных имён в оружие хакеров. DNS – это, по сути, огромная телефонная книга интернета. А ещё DNS является базовым протоколом, позволяющим администраторам делать запросы в базу данных DNS-сервера. Пока вроде всё понятно. Но хитрые хакеры осознали, что можно скрытно общаться с компьютером-жертвой путём внедрения управляющих команд и данных в протокол DNS. Эта идея и лежит в основе DNS-туннелирования.

Как работает DNS-туннелирование

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

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

Предположим, злоумышленник управляет DNS-сервером. Тогда он может передавать данные — например, персональные данные, — и не обязательно будет обнаружен. В конце концов, с чего вдруг DNS-запрос может стать чем-то нелегитимным?

«Туннелирующая» часть данной атаки заключается в сокрытии данных и команд от обнаружения системами мониторинга. Хакеры могут использовать наборы символов base32, base64 и т.д., или даже шифровать данные. Такая кодировка пройдёт незамеченной мимо простых утилит обнаружения угроз, которые осуществляют поиск по открытому тексту.

И это и есть DNS-туннелирование!

История атак через DNS-туннелирование

У всего есть начало, включая идею захвата DNS-протокола для хакерских целей. Насколько мы можем судить, первое обсуждение такой атаки проводилось Оскаром Пирсаном (Oskar Pearson) в почтовой рассылке Bugtraq в апреле 1998 года.

К 2004 году, DNS-туннелирование было представлено на Black Hat как хакерский метод в презентации Дэна Каминского (Dan Kaminsky). Таким образом, идея очень быстро переросла в настоящий инструмент атаки.

На сегодня DNS-туннелирование занимает уверенные позиции на карте потенциальных угроз (и блогеров в сфере информационной безопасности часто просят его объяснить).

Слышали ли вы о Sea Turtle ? Это действующая кампания киберпреступных группировок — скорее всего, спонсируемая государством, — направленная на захват легитимных DNS-серверов с целью перенаправления DNS-запросов на собственные сервера. Это означает, что организации будут получать «плохие» IP-адреса, указывающие на поддельные веб-страницы под управлением хакеров, — например, Google или FedEx. При этом злоумышленники смогут заполучить учётные записи и пароли пользователей, которые те неосознанно введут их на таких поддельных сайтах. Это не DNS-туннелирование, но просто ещё одно скверное последствие контроля DNS-серверов хакерами.

Угрозы DNS-туннелирования

DNS-туннелирование – это как индикатор начала стадии плохих новостей. Каких именно? Мы уже рассказали о нескольких, но давайте их структурируем:

Выявление DNS-туннелирования

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

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

Утилиты DNS-туннелирования

Если вы хотите провести собственный пентест и проверить, насколько хорошо ваша компания сможет обнаружить и отреагировать на такую активность, то для этого есть несколько утилит. Все они умеют туннелировать в режиме IP-Over-DNS:

– доступна на многих платформах (Linux, Mac OS, FreeBSD и Windows). Позволяет установить SSH-шелл между целевым и управляющим компьютером. Вот неплохой гайд по настройке и использованию Iodine. – проект DNS-туннелирования от Дэна Каминского, написанный на Perl. С ним можно подключаться по SSH. – «DNS-туннель, от которого не тошнит». Создаёт зашифрованный C2-канал для отправки/скачивания файлов, запуска шеллов и т.д.

Утилиты DNS-мониторинга

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

Микро FAQ по DNS-туннелированию

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

В: Когда был осуществлена первая атака по DNS-туннелированию?
О: Мы не знаем! Если вы знаете – дайте, пожалуйста, нам знать. Насколько нам известно, первое обсуждение атаки было инициировано Оскаром Пирсаном в почтовой рассылке Bugtraq в апреле 1998 года.

Хотите, чтобы мы помогли с обнаружением DNS-туннелирования? Ознакомьтесь с нашим модулем Varonis Edge и попробуйте бесплатное демо!

Авторы этой статьи - пентестеры из команды FBK CyberSecurity. Это часть крупнейшей российской аудиторско-консалтинговой группы ФБК (Финансовые и бухгалтерские консультанты). Компания специализируется на услугах в области практической информационной безопасности.

Среди того, чем занимается FBK CyberSecurity:

тестирование на проникновение;
форензика, расследование инцидентов;
комплаенс, аудит по требованиям PCI DSS и SWIFT;
аппаратная безопасность (банкоматы, IoT и так далее);
IT-аудит и IT-консалтинг;
аудит смарт-контрактов и обеспечение ИБ при проведении ICO.

А еще ты, возможно, уже читал статьи в «Хакере», написанные одним из специалистов FBK CS и соавтором этого материала.

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

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

dnscat2

dnscat2 — довольно популярная утилита, разработанная Роном Боузом, для создания командно-контрольного канала (C&C) через протокол DNS. Включает в себя серверную часть, написанную на Ruby, а также клиент на C. Под Windows существует версия клиента для PowerShell.

Для кодирования данных dnscat2 использует представление в шестнадцатеричном виде. Данные передаются последовательно, то есть значение AAAA аналогично A.AAA , AAA.A и так далее.

Dnscat2 поддерживает основные типы записей DNS: TXT, MX, CNAME, A и AAAA. Тип ответа соответствует типу входящего запроса:

TXT-ответ — шестнадцатеричные значения;
CNAME и MX кодируются так же, как и запрос: либо с префиксом тега, либо с помощью постфикса домена. Это необходимо, потому что промежуточные серверы DNS не будут перенаправлять трафик, если он не заканчивается соответствующим доменным именем;
A и AAAA — аналогично. TXT, данные без добавления домена или тега.

Протокол работы dnscat2

Сеанс устанавливается клиентом, отправляющим серверу SYN-пакет. Сервер отвечает аналогичным пакетом. Клиент и сервер ведут общение через пакеты MSG. Когда клиент решает, что соединение завершено, он отправляет на сервер пакет FIN, на что сервер отвечает так же. Когда сервер решает, что соединение завершено, он отвечает на MSG от клиента пакетом FIN, и сеанс прекращается.

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

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

Запуск

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

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

Аналогично запускаем клиент и видим, что сессия установлена. Отлично, вроде работает!

На сервере наблюдаем следующее.

Отлично, давай войдем в сессию.

Посмотрим, что утилита нам предоставляет.

Здорово! Для проверки запустим shell.

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

После результата для ввода новой команды нужно еще раз нажать Enter. Не интерактивно, конечно, но не страшно.

Это, конечно, все весело, но нам-то нужно пробросить туннель. Давай попробуем выгрузить к нам файл по SCP с какого-нибудь сервера через клиент, заодно проверим усредненную скорость. Пробрасываем туннель.

В сессии клиента мы указали, что надо слушать на стороне сервера порт 9090 и от клиента перенаправлять на 178.128.34.53:22 . Теперь запустим SCP. В tcpdump можно увидеть общение клиента с сервером.

В итоге получили среднюю скорость 0,8 Кбайт/с, фильмы в 4K, конечно, не посмотришь, но пробросить трафик нам все же удалось.

Давай глянем, что там насчет загрузки.

Как видим, хоть скорость и была около 10 Кбайт/с, но по факту утилита проработала долговато.

Сейчас мы запускали клиент на Kali, посмотрим, как он работает в Windows. Здесь все печально. При том же эксперименте клиент в конце концов смог установить соединение, хоть на это и ушло несчетное количество попыток.

Однако при попытке пробросить SCP клиент внезапно отваливался.

Мне даже не удалось замерить среднюю скорость канала. Клиент тестировался на Windows 7 и 10 с одинаковыми результатами.

Глянем напоследок и на клиент для PowerShell. Для этого придется перезапустить сервер с параметром --no-cache . В итоге там удалось запустить клиент и даже на какое-то время подружить его с сервером.

Один раз получилось даже так.

Однако в большинстве случаев это приводило к ситуации на скриншотах ниже.

Итого

Легкая настройка
Большой набор функций
Поддержка нескольких сессий
Компилируемые клиенты
Нестабильная работа на Windows (если это вообще можно назвать работой)
Скорость загрузки

Iodine

Iodine — утилита, разработанная Эриком Экманом. Она позволяет пробрасывать трафик IPv4 через DNS с использованием виртуальных интерфейсов. Состоит из компилируемых сервера и клиента, написанных на C. Клиенты Iodine запускаются только с правами root, но могут работать на разных архитектурах (ARM, IA64, x86, AMD64, SPARC64) многих ОС: Linux, FreeBSD, OpenBSD, NetBSD, macOS и Windows (с драйвером OpenVPN TAP32).

Установка на сервер

Чтобы установить Iodine на сервер, достаточно выполнить команду

А вот команда на запуск сервера:

Запуск клиента

Для начала работы с клиентом нужно написать что-то вроде

Теперь на клиенте появился виртуальный интерфейс dns0, клиент получит IP-адрес. Можно обращаться на этот IP, и трафик пойдет через DNS.

Попробуем подключиться по SSH.

Работает! Вот что показывает tcpdump на 53-м порте сервера Iodine.

Iodine может самостоятельно выбирать наиболее быстрый из доступных видов кодировок (Base128, Base64, Base32) и типов пакетов (NULL, TXT, MX, CNAME и A), благодаря чему скорость получается высокой — около 10 Кбайт/с при использовании SCP.

Протестируем клиент для Windows. Для этого необходимо сначала установить драйверы интерфейса TAP/TUN. Затем запускаем приложение, как и в Linux, — с учетки администратора.

Вроде бы интерфейс настроился, но при попытке передать данные — ничего.

В общем, попытки запустить клиент Iodine в Windows не увенчались успехом.

Протестируем скорость отправки и получения.

Как мы видим, скорость для DNS-туннеля отличная: 9,8 Кбайт/с на отправку и получение через SCP.

Итого

Автоматический выбор кодировок и типов пакетов
Запуск только из-под суперпользователя
Компилируемый клиент
Необходимость установки драйверов в Windows (а также сомнительная возможность работы с этой системой)
Скорость загрузки

dns2tcp

dns2tcp — инструмент для ретрансляции TCP через DNS. Клиент и сервер — компилируемые, сервер также доступен через APT. Особенность утилиты в том, что она пробрасывает трафик от клиента к серверу.

Запуск

Для начала настроим сервер. Первым делом отредактируем файл /etc/dns2tcpd.conf .

Теперь запустим сам сервак командой

Окей, теперь идем к клиенту.

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

А заодно проверим и выгрузку.

Итого

Компилируемые сервер и клиент
Работает в режиме проброса сети «внутрь»
Средняя скорость загрузки

Heyoka

Heyoka — утилита, написанная на С, причем клиент и сервер — это один и тот же исполняемый файл. Она создает двунаправленный туннель DNS. По словам авторов, утилита работает на 60% быстрее, чем другие аналогичные инструменты (по состоянию на 2009 год). На сайте проекта есть готовый исполняемый файл для Windows, а версия для Unix, размещенная на GitHub, была сделана сторонним разработчиком.

Запуск

Прочитав описание и инструкции на сайте, попробуем объездить этого скакуна. Начнем с запуска сервера на машине с Windows 10.

Отлично, вроде работает. Теперь запустим клиент.

Опаньки! Кажется, не работает, хотя запускали с правами администратора. Что ж, соберем теперь тулзу для Unix. Аналогично запускаем сервер и тестируем клиент.

Итого

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

OzymanDNS

Довольно древний инструмент для создания туннелей DNS через SSH, написанный Дэном Каминским в далеком 2005 году.

Запуск

Для начала использования нужно установить Perl и библиотеки MIME::Base32 и Net::DNS и обновить менеджер пакетов.

Качаем и распаковываем архив.

Если попробовать запустить скрипт сейчас, то он, скорее всего, упадет с ошибкой импорта. Фикс проблемы — удалить выделенный фрагмент из файла nomde.pl .

Сервер запускается очень просто:

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

Видим ошибку: Perl недоволен адресами серверов DNS. Пробуем указать свой.

Видим, что кушает сервер, но соединение не создалось.

Под впечатлением от статей и видео, где люди показывали, как у них прекрасно все работает, мы провели в возне с OzymanDNS несколько дней, но так и не смогли заставить эту тулзу передать хотя бы бит информации. Возможно, у кого-то из читателей хватит на это терпения, но есть ли смысл? У того, кто смог соединиться через OzymanDNS, скорость была 17 Кбит/с и работа была нестабильной, а если учесть скудный набор функций, то можно смело переходить с этой утилиты на что-то другое.

Результаты

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

В результате наиболее распространенная проблема — это необходимость компилировать клиент и нестабильная работа в Windows. Есть ли какой-то выход?

А вот об этом мы поговорим уже в другой раз. 🙂

Михаил Фирстов

Работаю пентестером в FBK Cybersecurity. Специализируюсь на услугах в области практической информационной безопасности.

DNS-tunneling — это метод, который позволяет передавать любой трафик (фактически инициируя туннель) по протоколу DNS. Например, его можно использовать для получения полного доступа к Интернету из точки, где разрешено изменение имен DNS.

Чтобы организовать DNS-туннель, кто-то извне (то есть в точке, куда направлен туннель) должен принять его. Точка приема — это сервер имен для определенной зоны. Изнутри сети запрашиваются имена для этой зоны. Так передаётся трафик внутрь —>.

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

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

NSTX как вариант софта для тунелинга

Протокол передачи NameServer (NSTX) — одна из самых известных и фундаментальных реализаций идеи туннеля DNS. Этот комплекс создает двусторонний IP-туннель для передачи данных на основе любого легитимного транзитного DNS-трафика.

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

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

В силу популярности именно этого варианта туннелирования, совсем немного остановлюсь на установке и настройке его клиента (на примере Debian). Для начала устанавливаем весь пакет NSTX:

После чего в файле-настройке /etc/default/nstx следует сначала добавить адрес принимающего DNS-сервера (параметр NSTX_DOMAIN ), а затем включить работу этого демона путем присвоения обоим параметрам ifup_tun0 и start_nstxd значения «yes».

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

iface tun0 inet static

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

Dns2tcp

Практически полный аналог NSTX, за исключением того, что он только пересылает TCP-трафик. Автор этой утилиты Оливер Дибауэр попытался максимально «упростить» реализацию идеи DNS-туннелирования: не нужно устанавливать новые драйверы или интерфейсы для запуска и инициализации соединения на стороне клиента, и права администратора не требуются.

Настроить Dns2tcp намного проще, чем NSTX, поэтому отмечу лишь, что документация по этому проекту доступна здесь. Из-за простоты Dns2tcp в нем отсутствуют встроенные механизмы аутентификации и шифрования, поэтому его часто используют вместе с оболочкой из туннеля ssl, парная конфигурация которого отражена в большинстве примеров из официальной документации. Эта утилита входит в набор серверов и клиентов, доступных для автоматической компиляции в любой системе Unix.

Утилита lodine

Программа Iodine осуществляет туннелирование IPv4-трафика через DNS-сервер. Она может пригодиться в ситуации, когда доступ в интернет ограничен, но DNS-запросы разрешены.

Проект получил название по символам аббревиатуры IOD (IP Over DNS), а также в связи с тем, что йод в таблице Менделеева имеет 53-й порядковый номер, и это совпадает с 53-м портом, на котором работает служба DNS.

Iodine прост в использовании и не нуждается в особом конфигурировании. Программу нужно установить на сервере и клиенте, затем на сервере требуется делегировать программе какой-нибудь поддомен. Например, в случае использования BIND нужно добавить пару строчек.

t1ns IN A 10.15.213.99

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

Установка на сервере:

В клиенте запускаем команду:

Сервер iodined открывает виртуальный интерфейс и слушает DNS-запросы на UDP-порту 53.

Разработчики предупреждают, что трафик в этом туннеле никак не шифруется, поэтому желательно использовать VPN (то есть двойное туннелирование) или SSH.

Еще один вариант создания DNS-тунелинга с помощью dnscat2

Эта популярная небольшая утилита включена в пакет DNS nbtools. Его разработка выделена в условно отдельный проект, который поддерживает создатель Рон Бовис. Как следует из названия, Dnscat пытается дублировать уже известные функции основного сетевого инструмента netcat с тем важным отличием, что весь трафик данных здесь передается через протокол DNS. Ресурсы Dnscat в основном ограничены двумя точками:

Интересной особенностью этой утилиты является то, что она может быть довольно всеядной. С одной стороны, это позволяет вам работать через обычный рекурсивный DNS (по умолчанию) с авторитетным сервером «волшебный домен», с другой — есть режим прямого подключения к DNS серверу, в этом случае вы можете работать в стандартный клиент-серверный режим (выполняется с аргументом —dns). В последнем варианте снижается скрытность и универсальность работы утилиты, но в качестве приятного бонуса резко возрастает скорость и надежность соединения, кроме того, на принимающей соединение стороне уже не нужно иметь именно авторитативный сервер имен.

Утилита поставляется вместе с исходниками в составе пакета nbtool (сразу с клиентской и серверной частью), и может быть скомпилирована под Linux, FreeBSD и Windows.

Тулза dnscat2 разработанна для создания командно-контрольного канала (C&C) через DNS протокол. Включает в себя серверную и клиентскую части.

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

Если у вас нет авторизованного DNS сервера, вы можете использовать соединение на свой хост по UDP/53 или любой другой выбранный порт.

Данные запросы будут отправляться быстро и будут выглядеть как обычный DNS траффик.

Серверная часть разработана для того, чтобы работать на авторизованном DNS сервере. При запуске, слушает UDP/53.

Установка dnscat2 server:

Теперь рассмотрим возможные сценарии работы с dnscat2.

Первый случай. На атакуемой машине доступен любой DNS траффик и имеется доступ к любым серверам DNS.

Запускаем dnscat2 server на машине атакующего:

При запуске dnscat2 server начинает слушать порт 53/UDP и предоставит интерактивный shell для удаленного доступа к компьютеру, с которого был запущен dnscat2 client.

Теперь запускаем dnscat2 client на удаленной машине.

Как только мы выполним подключение, dnscat2 server сообщит нам об этом ввиде номера сессии.

Доступ к установленной сессии мы получим с помощью команды: session -i 5965

А далее мы можем с клиентом выполнят стандартные операции, такие как

Скачивание файлов
Загрузка файлов
Выполнение команд на жертве
Переход в шелл

Ниже представлен список команд, доступный атакующему:

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

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

Второй случай. С атакуемой машины доступен DNS траффик только к легитимным DNS серверам.

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

Для сервера:

Для клиента:

Один из вариантов защиты – это запретить на компьютерах в локальной сети выполнение утилиты dnscat2 client или посторонних бинарных программ.

Но на этот случай мы можем воспользоваться методом запуска программ с помощью стандартного Windows Power Shell.

Соответственно, запускаем этот скрипт как показано на рисунке ниже.

В данном случае, у нас должны быть административные права для работы с powershell и запущен dnscat2 server. При выполнении скрипта мы получим shell нашей жертвы.

Вот мы и рассмотрели еще одну утилиту для сокрытия траффика.

DNS туннель для Meterpreter

Meterpreter — довольно известный и популярный агент удаленного управления в составе фреймворка Metasploit. Этот агент довольно гибкий и удобный, с множеством модулей и плагинов, а также типов API, что позволяет вам создавать свои собственные плагины и модули. Но, к сожалению, такие функции, как транспорт, являются частью ядра, а это значит, что здесь мы не отделаемся модулем. В настоящее время Meterpreter поддерживает следующие «сетевые» транспортные режимы:

Разработанные компоненты

В текущей нашей версии «pre-release» мы сделали поддержку DNS транспорта только для OS Windows (для x64 и x86), который реализован в следующих компонентах:

(по сути «прокси»)

(реализация транспорта в агенте)

(шеллкоды, x64/x86)

DNS-мост MSF — один из ключевых компонентов системы. На самом деле это сценарий Python, который работает как служба DNS, которая будет отвечать за разрешение имен и возврат данных агенту в виде записей RR. Этот интерфейс является сутью организации DNS-туннеля для шеллкода или агента Meterpreter. В то же время эта же служба откроет обычный TCP-порт для подключения из консоли Metasploit через простой TCP.

Таким образом, пентестеру не нужно думать о том, как сделать обработчик MSF и портативный компьютер доступными для DNS. Вся работа заключается в том, чтобы сбросить этот скрипт на свой сервер (AWS Ec2), создать свой собственный домен, записи NS на нем и не беспокоиться о том, где и как работает пентестер — это чрезвычайно удобно (на мой вкус). Более того, это решение позволяет нескольким пентестерам работать с одним и тем же DNS, но с разной нагрузкой одновременно. Текущая версия поддерживает до 26 открытых сеансов счетчика одновременно. На данный момент у нас нет встроенной поддержки Ruby DNS в самой MSF, но работа над ней уже ведется сообществом Metasploit (в частности, RageLtMan).

Сам же туннель организован через два типа RR записей (на выбор): DNSKEY RR and AAAA RR. Это значит что все эти реализации запилины во всех компонентах, включая шеллкоды.

Собственно работа транспорта такова: обработчик MSF (пентестер) подключается к нашему сервису, отправляет полезную нагрузку (например бодипретер счетчика) в наш DNS и ждет … Затем традиционно эксплойт и наш шелл-код где-то запускаются, и кто-то использует туннель DNS, получает meterpreter, запускает его в контексте того же процесса, а сам meterpreter, используя тот же транспорт и DNS, устанавливает дуплексную связь с обработчиком MSF (пентестером). Затем пентестер может делать все, что захочет — мигрировать в другой процесс, открывать интерактивную командную оболочку, использовать mimikatz и т. д. и т.п. — все это будет скрыто нашим туннелем. На протяжении всего этапа killchain (после операции) мы используем один и тот же транспорт, и нам не нужно загружать дополнительные двоичные файлы DNScat2 на целевую машину или запускать Powershell, мы скрыты туннелем с самого начала. Кроме того, у нас нет накладных расходов на туннелирование самого TCP / IP (заголовков), только пакеты TLV и измеритель данных.

Отдельно добавлю несколько слов об организации туннеля со стороны шеллкода и измерителя. Если, например, DNSCat2 использует реальную реализацию разрешения имен (то есть сам реализует TCP / UDP-соединение), то в нашем случае мы используем Windows API: DnsQuery, который позволяет нам изменять реализацию сети. соединение с MS DNSCache, то есть сетевое соединение будет реализовано непосредственно из svchost.exe, а не через скомпрометированный или бэкдорный процесс (meterpreter). Это очень хорошая «функция», которая позволит вам обойти ряд проблем с EPP / AV и персональным брандмауэром, которые активно работают на «жертве» и отслеживают новые подозрительные соединения. Вот как это выглядит:

В последнее время появилось огромное количество вирусов и троянов, использующих протокол DNS в его ненормальном режиме работы. Использование стандартных DNS-запросов в качестве транспорта позволяет им эффективно преодолевать практически любые системы безопасности, которые тщательно создаются администраторами на входе в корпоративную сеть. Действительно, трафик DNS плохо (или почти не анализируется) стандартными системами IDS, так же как он открыт для прохождения в обоих направлениях практически на любом брандмауэре, что позволяет колонии вражеских вредоносных программ, даже в глубоком тылу, не терять связь со своей «родиной».

Во многих случаях вредоносным программам для выполнения своих функций нужно сетевое взаимодействие с командными центрами управления (С&C). Но на их пути могут встать продукты сетевой безопасности, которые применяются в компании — например, брандмауэры, защищённые веб-шлюзы и антивирусы. Тогда, пытаясь продлить работу, нежелательный объект связывается со своим сервером C&C по скрытому каналу. В качестве такового злоумышленники нередко используют протокол системы доменных имён DNS; это позволяет им не только обеспечить соединение, но и управлять кражей данных и перенаправлением трафика.

Введение

Распространённость DNS (и слабого контроля над ним) обеспечивает злоумышленников элегантными и тонкими методами для установки соединений и обмена данными.

Рисунок 1. Роль DNS в атаках

Как скрывать следы, используя DNS

Проникая в систему, вредоносные программы обращаются к DNS, чтобы обнаружить свои центры управления. Например, это позволяет сделать технология Fast Flux, которая подразумевает быстрое многократное внесение изменений в записи ресурсов в зоне DNS. Злоумышленники используют Fast Flux вместе с ботнетом, чтобы скрывать следы и преодолевать провайдерские фильтры, блокирующие доступ по IP-адресам.

Fast Flux назначает любому полнофункциональному доменному имени множество сотен, а иногда и тысяч IP-адресов. Переключение между ними в потоке происходит очень быстро. При этом используется комбинация циклического набора сетевых идентификаторов и очень маленького значения TTL для каждой отдельной записи в DNS. Список IP-адресов, связанный с именем домена, меняется каждые пять секунд. В результате данный домен постоянно остаётся в сети, продлевая жизнь мошеннических сайтов, вредоносных площадок и C&C-серверов.

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

Основные признаки Fast Flux:

множество IP-адресов у одного доменного имени из разных AS;
частая смена IP-адресов и name-серверов доменных имён;
принадлежность IP-адресов ко множеству различных блоков, выделенных различным провайдерам (allocated);
очень короткое время жизни для каждой отдельной записи в DNS;
небольшой возраст домена;
наличие сервера NGINX в качестве реверсивного прокси-сервера;
управление аккаунтом регистранта без авторизации;
уровень fast-flux домена ниже второго.

Рисунок 2. Основные признаки Fast Flux

Domain Generation Algorithms — ещё одна технология, которая используется для скрытия заражений. Она применяется для того, чтобы вычислять последовательности доменных имён, к которым могут подключаться заражённые машины.

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

Рисунок 3. Взаимодействие вредоносного агента с командным центром

Один из примеров — обнаруженная командой Qihoo 360 Netlab рекламная сеть, которая скрывала криптовалютные майнеры внутри баннеров на клиентских сайтах. В дополнение её создатели нашли способ обходить блокировщики рекламы. Сеть использовала DGA для регистрации уникальных доменных имён, к которым заражённый хост подключался с целью получения новых команд от главного сервера С&C.

Для проверки этого факта исследователи посетили один из веб-сайтов. Как только они перешли на страницу, загрузка процессора взлетела до 100%. Если у пользователя не было блокировщика объявлений, то он получал рекламу непосредственно с основных доменов. Затем сеть выгружала копию Coinhive для майнинга Monero на сайте. Если же пользователь имел блокировщик, то реклама могла загружаться с альтернативного домена, сгенерированного с помощью DGА. Эффективность метода была обусловлена тем, что пока блокировщик обнаруживал другие домены, из которых идёт реклама, сеть успевала сгенерировать новые. Таким образом, в наличии всегда была дополнительная порция доменов, не внесённых в чёрный список.

Как и вредоносные программы, DGA развиваются, тем самым усложняя и без того запутанные игры в кошки-мышки между преступниками и безопасниками. Один из этапов эволюции DGA был замечен в ботнете Matsnu, чей алгоритм выбирал существительные и глаголы из встроенного списка, содержавшего более 1 300 слов, для формирования доменов, состоявших из 24-символьных последовательностей. В отличие от других DGA, ботнет Matsnu использовал комбинацию «существительное-глагол-существительное-глагол», чтобы обмануть лингвистические алгоритмы, разработанные для поиска бессмысленных доменных имён. Новые варианты DGA помогали троянским программам обманывать системы безопасности, полагающиеся на рейтинги репутаций доменных имён, чёрные списки и сигнатуры.

Как обеспечить передачу данных в DNS

Канал C&C часто служит двум целям атакующего. Во-первых, он может выступать в качестве маяка, указывающего на то, что удалённая «полезная» нагрузка всё ещё работает, так как она передаёт сигналы на свой сервер. Во втором случае скомпрометированная система создаёт странные строки запроса для отправки по DNS. Подобные запросы по-прежнему действуют как маяк, однако они также предоставляют некоторые основные метаданные о жертве и, что важно, способы её уникальной идентификации.

Этот механизм весьма прост в реализации, имеет децентрализованный характер и легко обходит различные брандмауэры, вовлекая местные DNS-резолверы (серверы, преобразующие доменные имена в сетевые идентификаторы) в распространение запросов. Как правило, злоумышленнику нужен работающий авторитетный сервер имён (NS), обслуживающий основной домен. Следовательно, «полезная» нагрузка кодируется и / или зашифровывается на уровне субдомена.

Рисунок 4. Реализация рекурсивного запроса к домену третьего уровня

Некоторые из метаданных скомпрометированного хоста могут быть отправлены в виде открытого текста, но тогда они будут выглядеть более подозрительно для любого, кто видит такие строки в DNS-запросе. Кроме того, во многих случаях информация будет содержать символы, не поддерживаемые DNS. Поэтому злоумышленники прибегают к кодированию данных, чаще всего используя для этого стандарт Base64.

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

Более сложная версия передачи данных в DNS-туннелировании включает отправку команд, двоичного кода или файлов на заражённую машину. В этом случае C&C-сервер атакующего отвечает на запрос своими «полезными» данными в кодировке base64 в пакете ответа DNS, используя поле RDATA различных типов записей DNS-ресурсов. Записи TXT, NULL и CNAME чаще всего применяются при туннелировании DNS. Соответственно, все команды и действия будут «заворачиваться» в DNS-протокол, и единственное, что выдаст атакующего, — большая генерация таких запросов в сети. Кроме пересылки команд атакующие могут покомпонентно загружать шелл-код вредоносной программы. Для этого обычно используют ресурсные записи TXT, в которые записывается код скрипта.

Приведём пример подгружаемого вредоносного скрипта. Троянский установщик (дроппер) отправляет DNS-запросы на подконтрольный злоумышленнику сервер; ответы приходят в виде разделённых на 4 части TXT-записей. Дроппер, получив ответ, преобразует код в исходный вид; после успешной передачи всех данных скрипт собирается воедино и выполняет дальнейшую вредоносную активность.

Рисунок 5. Преобразование скрипта в исходный вид

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

Как обнаружить подозрительную активность в DNS

Основные индикаторы — следующие:

большое количество поисков различных и в основном бессмысленных поддоменов для домена второго уровня;
большой размер ответа при поиске таких поддоменов;
большое количество или необычные типы запросов (MX, TXT);
«оторванные» DNS-запросы, т.е. ответы, которые присылаются без запросов или наоборот;
низкое значение TTL и множество IP-адресов у одного доменного имени;
неудачные DNS-запросы (ответы NXDomain);
DNS-трафик в обход DNS-серверов по умолчанию.

Также стоит использовать дополнительные инструменты для большего охвата зоны мониторинга. Так, по состоянию на 2019 год более 1000 доменов верхнего уровня существуют в списке TLD, поддерживаемых Internet Assigned Numbers Authority (IANA). Проведя исследования, эксперт по информационной безопасности из института SANS Сет Мисенар пришёл к выводу, что некоторые из этих TLD не содержат ничего, кроме вредоносных сайтов. Конечно, самый простой вариант — заблокировать известные «плохие» TLD; однако он не является лучшим из возможных. В качестве минимальной меры компании могут наблюдать за странными TLD и отправлять предупреждение, чтобы проверить, легитимны ли запросы к ним, или же обусловлены действиями вредоносных программ.

Аналитики SANS также пришли к ещё одному интересному факту: «если доменное имя существует менее 24 часов, то, возможно, оно является вредоносным».Как уже говорилось, атакующие используют генерационные алгоритмы для создания новых доменных имён и быстрого доступа к ним в интернете. Часто домены, содержащие вредоносный контент, блокируются или аннулируются, и в этом случае злоумышленники опять же будут заменять их недавно созданными. Не исключено, что полная блокировка обращений к новым доменным именам — лучшая политика, и если вам нужен доступ к только появившемуся в Сети домену, то вы можете просто добавить его в белый список.

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

Самое главное — знать, что является нормальным для вашего бизнеса, и смотреть на вещи из ряда вон выходящие. Например, если вы обычно не обращаетесь к предприятиям в других странах, и вдруг вы замечаете, что это происходит часто, исследуйте такие запросы. Если исходящие и входящие данные DNS внезапно меняются по частоте и размеру, убедитесь, что они являются законными. Предложить какие-то универсальные индикаторы здесь не удастся, поскольку каждый бизнес уникален, и трафик, который является ненормальным для одного бизнеса, может быть нормальным для другого. Перечисленное выше — это всего лишь несколько доступных командам ИТ и ИБ вариантов использования журналов DNS для поиска индикаторов компрометации, указывающих на проблему безопасности. DNS — это часто игнорируемый и недооценённый вектор атаки в сети, так что, ограничивая доступ к ненужным адресам и отслеживая журналы DNS для выявления подозрительной активности, вы можете предотвратить или обнаружить проблемы безопасности в своих сетях.

Чем мониторить

Каким же образом можно отслеживать подозрительный DNS-трафик с помощью систем безопасности и резолверов?

Один из простейших вариантов — это использование анализаторов трафика, таких как Wireshark или tcpdump. С их помощью аналитик может выявить вредоносные потоки данных. Для этого стоит записать и открыть фильтр DNS-трафика между клиентами и собственным DNS-сервером, а затем сохранить его в файле PCAP и создать скрипты для поиска образцов подозрительных действий. Но это — весьма объёмный ручной труд, а файлы PCAP требуют большого количества свободного пространства на диске.

Современные NGFW охватывают большой набор средств детектирования аномалий и защиты от них в DNS-трафике. Помимо предотвращения DDoS-атак с использованием DNS настраиваемые политики позволяют обнаружить DNS-запросы в обход серверов, используемых по умолчанию. Ежедневно обновляемые репутационные базы дают возможность детектировать соединения с известными C&C-серверами. Механизм DNS Sinkholing помогает идентифицировать заражённые хосты в защищённой сети с использованием трафика DNS в ситуациях, когда брандмауэр не может видеть DNS-запрос инфицированного клиента (или, точнее, не может видеть отправителя DNS-запроса); он используется для подмены DNS-серверов, предотвращая разрешение имён узлов указанных URL-адресов. Этого можно добиться настроив переадресацию DNS, чтобы вернуть ложный IP-адрес в ответ на запрос по определённому URL-идентификатору. Большинство вендоров активно внедряет в свои продукты NGFW дополнительные модули анализа DNS-трафика в режиме реального времени, в том числе — используя технологии машинного обучения, что позволяет контролировать нежелательные домены, командные серверы, DNS-туннели и вредоносные программы, использующие DGA.

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

Функциональные возможности названных выше систем «из коробки» не всегда удовлетворяют запросы потребителя. В таких случаях оптимальным решением будет сбор журналов DNS в системы лог-менеджмента или анализа событий, такие как SIEM или ELK. С их помощью возможно создать собственные настройки правил мониторинга, а также проводить профилирование своей инфраструктуры для выявления аномалий в DNS-трафике.

Как предостеречь

В широком доступе есть огромное разнообразие публичных альтернативных служб DNS со встроенной блокировкой угроз. Эти серверы обычно отвечают ложным IP-адресом, указывающим на информативную страницу «ЭТОТ САЙТ ЗАБЛОКИРОВАН».

Рисунок 6. Список служб DNS, предлагающих пользователям блокировку вредоносных программ и фишинга

блокировка коммуникации ботнетов с управляющими центрами (C&C);
снижение нагрузки на кеширующий DNS и канал связи;
блокировка доступа по списку «запрещённых» сайтов (как для предприятий, так и для провайдеров);
перенаправление пользователей на локальные ресурсы.

Рисунок 7. Схема работы с RPZ

предупреждения пользователей о том, что их компьютеры заражены вредоносными программами или ботнет-агентами, или вывода соответствующих уведомлений при обращении к сайтам, которые распространяют инфекции (дополнительно провайдеры могут показать рекламу антивируса, а администраторы на предприятиях — указать телефон и электронный адрес IT-службы);
предупреждения пользователей о том, что данный ресурс заблокирован (с указанием причины);
перенаправления пользователей на внутренние ресурсы или локальные (серые) IP-адреса серверов.

Выводы

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

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

Читайте также: