dns туннелирование что такое
DNS-tunneling
Материал из Xgu.ru
DNS-tunneling — техника, позволяющая передавать произвольный трафик (фактически, поднять туннель) поверх DNS-протокола. Может применяться, например, для того чтобы получить полноценный доступ к Интернет из точки, где разрешено преобразование DNS-имён.
DNS-туннелирование нельзя запретить простыми правилами брандмауэра, разрешив при этом остальной DNS-трафик. Это связано с тем, что трафик DNS-туннеля и легитимные DNS-запросы неразличимы. Обнаруживать DNS-туннелирование можно по интенсивности запросов (если трафик по туннелю велик), а также более сложными методами, используя системы обнаружения вторжений.
Содержание
[править] iodine
Существует большое количество различных программ, которые позволяет передавать трафик поверх DNS-запросов. Одна из таких программ — iodine.
Названием программа обязана двум фактам:
Для создания туннеля необходимо с одной стороны поднять сервер iodined (со стороны Интернета), а с другой стороны — с той, которая находится внутри сети, за брандмауэром — клиент iodine.
В проверочном режиме в качестве аргумента клиента указывается домен, в виде запросов по которому будет представляться туннелируемый трафик, а также обязательно IP-адрес iodine-сервера.
В нормальном режиме второй аргумент не передаётся, а определяется автоматически через DNS.
Для построения туннеля не в проверочном режиме, а в полноценном, необходимо обязательно указать, что сервер iodined является NS для какой-то определённой зоны.
Например, пусть это будет зона ns.xgu.ru. Тогда в описании зоны xgu.ru должны присутствовать строки (имена условные):
Лучше использовать по возможности короткие имена, поскольку это сокращает накладные расходы на передачу трафика, инкапсулированного внутрь DNS-пакетов.
Со стороны сервера:
Со стороны клиента:
На клиентской стороне будет установлен адрес 192.168.0.2 (последний байт плюс 1).
Если всё пройдёт успешно, то должны будут появиться сообщения:
Адреса и имена будут другими, а сообщения такими же.
После поднятия туннеля на клиентской машине появится соответствующий сетевой интерфейс. Его можно будет использовать как и любой другой — осуществлять маршрутизацию, трансляцию адресов и так далее.
[править] Пояснение к схеме DNS-туннелинга
Ноутбук клиента, осуществляющего DNS-туннелинг находится за брандмауэром. Клиент имеет возможность пользоваться кэширующим DNS-сервером. Клиент направляет кэширующему серверу запросы по зоне iodine.xgu.ru. Сервер пытается их для него разрешить, для чего выполняет рекурсивную обработку, как предписывается стандартом DNS.
В конечном счёте запросы доходят туннелинг-серверу, который находится по адресу, указанному в качестве NS для зоны iodine.xgu.ru. Туннелинг-сервер обрабатывает их. В частности, он может преобразовать их в IP-трафик и отправить дальше. Обратный трафик преобразуется в DNS-ответы и отправляется кэширующему серверу (который в свою очередь передаёт их туннелинг-клиенту).
Таким образом организуется обмен IP-пакетами ( — — — ) поверх DNS-трафика (————).
Что такое DNS-туннелирование? Инструкция по обнаружению
Как работает DNS-туннелирование
Для всего в интернете есть свой отдельный протокол. И DNS поддерживает относительно простой протокол типа запрос-ответ. Если вы хотите посмотреть, как он работает, то можете запустить nslookup – основной инструмент для подачи DNS-запросов. Вы можете запросить адрес, просто указав интересующее доменное имя, например:
В нашем случае протокол ответил IP-адресом домена. В терминах DNS-протокола, я сделал запрос адреса или запрос т.н. «А»-типа. Существуют и другие типы запросов, при этом DNS-протокол будет отвечать с различным набором полей данных, которыми, как мы это позже увидим, могут воспользоваться хакеры.
Так или иначе, по своей сути DNS-протокол занимается передачей запроса на сервер и его ответа обратно клиенту. А что, если злоумышленник добавит скрытое сообщение внутрь запроса доменного имени? Например, вместо ввода вполне легитимного URL, он введёт данные, которые хочет передать:
Предположим, злоумышленник управляет DNS-сервером. Тогда он может передавать данные — например, персональные данные, — и не обязательно будет обнаружен. В конце концов, с чего вдруг DNS-запрос может стать чем-то нелегитимным?
Управляя сервером, хакеры могут подделывать ответы и отправлять данные обратно на целевую систему. Это позволяет им передавать сообщения, спрятанные в различных полях DNS-ответа, во вредоносное ПО на заражённой машине, с указаниями наподобие поиска внутри определённой папки.
«Туннелирующая» часть данной атаки заключается в сокрытии данных и команд от обнаружения системами мониторинга. Хакеры могут использовать наборы символов base32, base64 и т.д., или даже шифровать данные. Такая кодировка пройдёт незамеченной мимо простых утилит обнаружения угроз, которые осуществляют поиск по открытому тексту.
И это и есть DNS-туннелирование!
История атак через DNS-туннелирование
У всего есть начало, включая идею захвата DNS-протокола для хакерских целей. Насколько мы можем судить, первое обсуждение такой атаки проводилось Оскаром Пирсаном (Oskar Pearson) в почтовой рассылке Bugtraq в апреле 1998 года.
К 2004 году, DNS-туннелирование было представлено на Black Hat как хакерский метод в презентации Дэна Каминского (Dan Kaminsky). Таким образом, идея очень быстро переросла в настоящий инструмент атаки.
На сегодня DNS-туннелирование занимает уверенные позиции на карте потенциальных угроз (и блогеров в сфере информационной безопасности часто просят его объяснить).
Угрозы DNS-туннелирования
DNS-туннелирование – это как индикатор начала стадии плохих новостей. Каких именно? Мы уже рассказали о нескольких, но давайте их структурируем:
Выявление DNS-туннелирования
Существует два основных метода обнаружения злоупотреблением DNS: анализ нагрузки и анализ трафика.
При анализе нагрузки защищающаяся сторона ищет аномалии в данных, передаваемых в обе стороны, которые могут быть обнаружены статистическими методами: странно выглядящие имена хостов, тип DNS записи, которая не используется настолько часто, или нестандартная кодировка.
При анализе трафика оценивается число DNS запросов к каждому домену по сравнению со среднестатистическим уровнем. Злоумышленники, использующие DNS-туннелирование, будут генерировать большой объём трафика на сервер. В теории, значительно превосходящий нормальный обмен DNS-сообщениями. И это необходимо отслеживать!
Утилиты DNS-туннелирования
Если вы хотите провести собственный пентест и проверить, насколько хорошо ваша компания сможет обнаружить и отреагировать на такую активность, то для этого есть несколько утилит. Все они умеют туннелировать в режиме IP-Over-DNS:
Утилиты DNS-мониторинга
Ниже представлен список нескольких утилит, который будет полезен для обнаружения туннелирующих атак:
Микро FAQ по DNS-туннелированию
Полезнейшая информация в виде вопросов и ответов!
В: Что такое туннелирование?
О: Это просто способ передачи данных поверх существующего протокола. Лежащий в основе протокол обеспечивает выделенный канал или туннель, который потом используется для сокрытия информации, передающейся в действительности.
В: Когда был осуществлена первая атака по DNS-туннелированию?
О: Мы не знаем! Если вы знаете – дайте, пожалуйста, нам знать. Насколько нам известно, первое обсуждение атаки было инициировано Оскаром Пирсаном в почтовой рассылке Bugtraq в апреле 1998 года.
В: Какие атаки похожи на DNS-туннелирование?
О: DNS – далеко не единственный протокол, который можно использовать для туннелирования. Например, вредоносные программы по управлению и контролю (C2) часто используют HTTP для маскировки канала взаимодействия. Как и при DNS-туннелировании, хакер скрывает свои данные, но в данном случае они выглядят как трафик обычного веб-браузера, обращающегося на удалённый сайт (контролируемый злоумышленником). Это может остаться незамеченным программами мониторинга, если они не настроены воспринимать угрозу злоупотребления HTTP-протоколом в хакерских целях.
Хотите, чтобы мы помогли с обнаружением DNS-туннелирования? Ознакомьтесь с нашим модулем Varonis Edge и попробуйте бесплатное демо!
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Чем опасен DNS Tunneling?
Снова про информационную безопасность
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Каждый раз когда приложение или человек пытается попасть на какой-нибудь веб-сайт, DNS запрашивает в образном «телефонном справочнике» IP-адрес этого ресурса и отправляет вас по нужному адресу.
Темой этой статьи будет некорректное использование службы злоумышленниками: в какой-то момент умные товарищи поняли, что DNS также является прекрасным вектором атаки и научились использовать DNS в целях передачи информации и команд на компьютер жертвы, и это, по сути является основным принципом DNS туннелирования.
Принцип работы DNS туннелирования на пальцах
Пять шагов DNS туннелирования:
В любом случае, под капотом у DNS работает простая схема клиентский запрос на сервер, который в свою очередь отвечает клиенту обратно. А что если можно было бы «зашить» сообщение внутрь запроса?
Когда возник данный тип атак?
Впервые подобный вид атак был упомянут в рассылке Buqtraq неким Оскаром Пирсоном в апреле 1998 года.
Основные опасности DNS туннелирования
Как вы уже могли понять из моей спутанной и слегка аутичной статьи, DNS туннелирование является механизмом, который является катализатором для различного вида неприятностей, а именно:
Существует два основных метода по обнаружения некорректного использования DNS службы: анализ трафика и анализ полезной нагрузки.
При анализе полезной нагрузке необходимо обращать внимание на странные и аномальные запросы, особенно если они содержат в себе странные доменные имена, странные символы и пр. Для выявления подобного используются различные статистические техники.
Утилиты для создания DNS туннеля:
Если вам хочется посмотреть, уязвима ли ваша инфраструктура к такому виду атак, то можете попробовать несколько утилит из списка ниже (только на свой страх и риск). Все эти утилиты реализуют IP-over-DNS механизм атак.
Утилиты для мониторинга DNS туннеля:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Трафик в конце туннеля или DNS в пентесте
Привет! В ходе проектов по тестированию на проникновение мы нередко сталкиваемся с жестко сегментированными сетями, практически полностью изолированными от внешнего мира. Порой, для решения данной проблемы требуется пробросить трафик через единственно доступный протокол — DNS. В этой статье мы расскажем, как решить подобную задачу в 2018 году и какие подводные камни встречаются в процессе. Также будут рассмотрены популярные утилиты и представлен релиз собственной open-source утилиты с возможностями, которых обычно так не хватает в существующих аналогичных инструментах.
Что такое DNS-туннели
На Хабре уже есть несколько статей, где объясняется, что такое DNS-туннелирование. Тем не менее, немного теории о DNS-туннелировании можно найти под спойлером.
Бывает, что доступ в сеть наглухо отрезан файрволом, а передавать данные нужно позарез, и тогда на помощь приходит техника DNS-туннелирования.
На схеме всё выглядит так:
Запросы к DNS даже при самых строгих настройках файерволла иногда все же проходят, и это можно использовать, отвечая на них со своего сервера, находящегося по ту сторону. Связь будет крайне медленной, но этого хватит для проникновения в локальную сеть организации или, например, для срочного выхода в Интернет по платному Wi-Fi за границей.
Что популярно на данный момент
Сейчас в Интернете можно найти множество утилит для эксплуатации этой техники — каждая со своими фичами и багами. Мы выбрали для сравнительного тестирования пять наиболее популярных:
Подробнее о том, как мы их тестировали, можно почитать в нашей статье на Хакере. Тут же мы приведем только результаты.
Как видно из результатов, работать можно, но с точки зрения тестирований на проникновение есть недостатки:
Из-за данных недостатков нам понадобилось разработать свой инструмент, и вот как это вышло.
Создаем свою утилиту для DNS-туннелирования
Предыстория
Всё началось во время внутреннего пентеста одного банка. В холле находился общедоступный компьютер, используемый для печати документов, справок и прочих бумаг. Наша цель: получить наибольшую выгоду от машины, которая была под управлением системы Windows 7, на борту имела “Антивирус Касперского” и разрешала заходить только на определенные страницы (но при этом была возможность резолва DNS имен).
Проведя первичный анализ и получив дополнительные данные из тачки, мы выработали несколько векторов атаки. Пути с эксплуатацией машины при помощи бинарных программ были сразу убраны в сторону, так как “великий и ужасный” “Касперский” при обнаружении исполняемого файла сразу же его тёр. Однако нам удалось получить возможность запускать скрипты от имени локального администратора, после чего одной из идей стала как раз возможность создания DNS-туннеля.
Поискав возможные способы, мы нашли клиент на PowerShell для dnscat2 (о нем мы писали ранее). Но в итоге максимум, что нам удавалось произвести, это установить соединение на небольшое время, после чего клиент падал.
Это нас, мягко говоря, сильно расстроило, так как в данной ситуации наличие интерпретируемого клиента было просто необходимо. Собственно, это и стало одной из причин разработки своего инструмента для DNS-туннелирования.
Требования
Главными требованиями к самим себе у нас стали:
Архитектура проекта
Исходя из требований, мы приступили к разработке. В нашем представлении утилита состоит из 3 частей: клиент на внутренней машине, DNS-сервер и небольшой прокси между приложением пентестера и DNS-сервером.
Для начала мы решили пробросить туннель через TXT-записи.
Принцип работы довольно прост:
Протокол общения
Рассмотрим довольно простой протокол общения сервера с клиентом.
Регистрация
При запуске клиента, он регистрируется на сервере, запрашивая TXT-запись через поддомен следующего формата:
0 — ключ регистрации
— для избежания кеширования записей DNS
— имя, заданное клиенту при запуске
— ex.: xakep.ru
В случае успешной регистрации, клиент в TXT-ответе получает сообщение об успехе, а также присвоенный ему id, который он дальше будет использовать.
Основной цикл
После регистрации клиент начинает опрашивать сервер о наличии новых данных в формате
В случае наличия новых данных, в TXT-ответе он получает их в формате
Цикл загрузки данных
DNS-сервер
DNS-сервер для туннелирования был написан на Python3 с использованием библиотеки dnslib, которая позволяет легко создать свой DNS-резолвер, унаследовавшись от объекта dnslib.ProxyResolver и переопределив метод resolve().
Великолепный dnslib позволяет создать свой ProxyDNS очень быстро:
В resolve() мы определим реакции на DNS-запросы со стороны клиента: регистрацию, запрос новых записей, обратную передачу данных и удаление пользователя.
Информацию о пользователях храним в базе данных SQLite, буфер обмена данными находится в оперативной памяти и имеет следующую структуру, в которой ключом является номер клиента:
Для помещения данных от пентестера в буфер мы написали небольшой “приемник”, который запущен в отдельном потоке. Он ловит соединения от пентестера и выполняет маршрутизацию: какому клиенту отправлять запросы.
Пользователю перед запуском сервера необходимо задать всего лишь один параметр: DOMAIN_NAME — имя домена, с которым будет работать сервер.
Клиент на Bash
Для написания клиента для Unix систем был выбран Bash, так как он чаще всего встречается в современных Unix системах. Bash предоставляет возможность установки соединения через /dev/tcp/, даже с правами непривилегированного пользователя.
Идет проверка, было ли установлено соединение, и если да, то выполняется функция reply (чтение пришедших данных от target, разбиение и отправка на сервер).
После этого уточняется, есть ли новые данные от сервера. Если они обнаружены, то мы проверяем, нужно ли сбрасывать соединение. Сам разрыв происходит, когда нам приходит информация о target с ip 0.0.0.0 и портом 00. В этом случае мы очищаем файловый дескриптор (если он не был открыт, никаких проблем не возникнет) и меняем target ip на пришедший 0.0.0.0.
Powershell клиент:
Так как нам была нужна полная интерпретируемость и работа на большинстве актуальных систем, основу клиента для Windows составляют стандартная утилита nslookup для связи через DNS и объект System.Net.Sockets.TcpClient для установления соединения во внутренней сети.
Работает все также очень просто. Каждая итерация цикла представляет собой вызов команды nslookup по протоколу, описанному ранее.
nslookup возвращает нам подобный ответ:
После чего нам нужно вытянуть все строчки в кавычках, для чего проходимся по ним регуляркой:
Теперь можно выполнять обработку полученных команд.
Каждый раз, когда меняется IP-адрес “жертвы”, выполняется создание TCP-клиента, устанавливается соединение и начинает выполняться передача данных. От DNS сервера информация base64-декодируется, и байты отправляются на жертву. Если “жертва” что-то ответила, то кодируем, делим на части и выполняем запросы nslookup согласно протоколу. Всё.
При нажатии Ctrl+C выполняется запрос на удаление клиента.
Proxy:
Прокси для пентестера представляет из себя небольшой прокси сервер на python3.
Какие трудности могут возникнуть?
Как и в любом механизме, в утилите могут возникнуть сбои. Не будем забывать, что DNS-туннель — штука тонкая, и на его работу может влиять множество факторов, начиная от архитектуры сети, заканчивая качеством коннекта до вашего рабочего сервера.
Запуск
Настраиваем NS записи на домене:
Ждем, пока кэш обновится (до 5 часов обычно).
После того, как сервер и хотя бы один клиент были запущены, мы можем обращаться к прокси, как будто это наша удаленная машина.
Попробуем смоделировать следующую ситуацию: пентестер хочет скачать файл с сервера из локальной сети организации, защищенной файерволом, при этом с помощью методов социальной инженерии он смог заставить запустить внутри сети DNS-клиент и узнать пароль SSH сервера.
Посмотрим, что получилось:
Слева вверху можно видеть DNS-запросы, которые приходят на сервер, справа сверху — трафик прокси, слева снизу — трафик с клиента, а снизу справа — наше приложение. Скорость получилась довольно приличная для DNS-туннеля: 4.9Кб/сек с использованием сжатия.
При запуске без сжатия, утилита показала скорость 1.8 kb/s:
На следующих видео вы можете наглядно рассмотреть работу утилиты в связке с meterpreter и в режиме SOCKS5.
Как организовать DNS-tunneling
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
После перезагрузки сервера, убедившись, что устройство туннелирования 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 открывает виртуальный интерфейс и слушает 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:
# gem install bundler
# git clone https://github.com/iagox86/dnscat2.git
Теперь рассмотрим возможные сценарии работы с dnscat2.
Первый случай. На атакуемой машине доступен любой DNS траффик и имеется доступ к любым серверам DNS.
При запуске dnscat2 server начинает слушать порт 53/UDP и предоставит интерактивный shell для удаленного доступа к компьютеру, с которого был запущен dnscat2 client.
Как только мы выполним подключение, dnscat2 server сообщит нам об этом ввиде номера сессии.
А далее мы можем с клиентом выполнят стандартные операции, такие как
Ниже представлен список команд, доступный атакующему:
Соответственно все команды и действия будут «заворачиваться» в DNS протокол и единственное, что выдаст атакующего, это большая генерация DNS запросов в сети.
Еще, при установке соединения с неавторизованным DNS сервером, утилита dnscat2 в составе пакета DNS отправляет свое имя, что также может быть проанализировано со стороны администраторов сети.
Второй случай. С атакуемой машины доступен DNS траффик только к легитимным DNS серверам.
В этом случае процесс построения туннеля будет аналогичен предыдущему описанию, но с использованием следующих опций:
Для сервера:
Для клиента:
Один из вариантов защиты – это запретить на компьютерах в локальной сети выполнение утилиты 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, что позволяет вам создавать свои собственные плагины и модули. Но, к сожалению, такие функции, как транспорт, являются частью ядра, а это значит, что здесь мы не отделаемся модулем. В настоящее время Meterpreter поддерживает следующие «сетевые» транспортные режимы:
Разработанные компоненты
В текущей нашей версии «pre-release» мы сделали поддержку DNS транспорта только для OS Windows (для 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, так же как он открыт для прохождения в обоих направлениях практически на любом брандмауэре, что позволяет колонии вражеских вредоносных программ, даже в глубоком тылу, не терять связь со своей «родиной».