Лазейка под файрволом. Тестируем пять популярных средств, которые пробрасывают интернет по DNS

 

Об авторах

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

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

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

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

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

Другие статьи в выпуске:

Xakep #234. Взломать iPhone

• Содержание выпуска
• Подписка на «Хакер»-60%

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

dnscat2

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

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

Также протокол нечувствителен к регистру, то есть a1 и A1 — одно и то же. Для использования утилиты нужно иметь подконтрольный сервер с доменом, NS-записи которого ссылаются на конкретную машину. Клиент может выбрать, добавлять ли доменное имя или добавлять в сообщение тег dnscat. для отправки данных.

Сообщения представлены как <encoded data>.<domain> или <tag>.<encoded data>. В случае если данные представлены иначе, передаются через неподдерживаемый тип записей или домен неизвестен, сервер может отбросить их либо перенаправить к вышестоящему серверу DNS.

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.

Супер! Сессия с шеллом создана, хоть и получили не сообщение, а bad sequence. Для выхода из сессии жмем Ctrl-Z и идем в сессию 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

Iodine

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

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

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

$ sudo apt-get install libz-dev && git clone https://github.com/yarrick/iodine.git && cd Iodine && make && make install

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

$ sudo ./iodined -f -c -P secretpassword 172.17.0.1 oversec.ru

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

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

$ ./iodine -f -P secretpassword oversec.ru

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

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

$ ssh root@172.17.6.2

Работает! Вот что показывает 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 (а также сомнительная возможность работы с этой системой)
• Скорость загрузки ~9,8 Кбайт/с
• Скорость выгрузки ~9,8 Кбайт/с

dns2tcp

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

Запуск

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

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

$ dns2tcpd -f /etc/dns2tcpd.conf

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

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

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

Итого

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

Heyoka

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

Запуск

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

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

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

Итого

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

OzymanDNS

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

Запуск

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

$ sudo perl -MCPAN -e shell
cpan[1]> install CPAN
cpan[2]> reload cpan
cpan[3]> install MIME::Base32
cpan[3]> install Net::DNS

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

$ wget https://github.com/mubix/stuff/blob/master/stolen/ozymandns_src_0.1.tgz?raw=true
$ tar -xf ozymandns_src_0.1.tgz?raw=true

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

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

$ perl ./nomed.pl -i 0.0.0.0 oversec.ru

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

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

$ ssh -D 8080 -C -o ProxyCommand="perl droute.pl lol.oversec.ru" oversec.ru

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

$ ssh -D 8080 -C -o ProxyCommand="perl droute.pl -r 138.197.178.150 lol.oversec.ru" oversec.ru -v

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

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

Результаты

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

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

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