ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора 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-туннелирование
Для всего в интернете есть свой отдельный протокол. И 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 и попробуйте бесплатное демо!
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-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, так же как он открыт для прохождения в обоих направлениях практически на любом брандмауэре, что позволяет колонии вражеских вредоносных программ, даже в глубоком тылу, не терять связь со своей «родиной».
