Крякер интернета на базе DNS-тунелинга

Мы понимаем, что нас читают не только матерые программисты, но и в перерывах между компиляцией своих кастомных ядер порой заглядывают и не менее матерые системные администраторы. Скорее именно для последних мне и хотелось сегодня подкинуть интересную задачку, которая заставит не только прокачать своих администраторские скиллы, но и как следует поломать голову над её решением. Постановка этой хакерской задачи очень проста и одновременно коварна: в данной статье я покажу, как можно получить бесплатный доступ в Интернет, в том числе через WiFi-сети, практически у любого провайдера интернет-услуг. Оговорку “практически у любого” нужно понимать с некоторой долей здорового скепсиса, потому как автор статьи не занимался целенаправленным тестированием местных провайдеров на качество настройки их сетей. Вся информация предназначена исключительно для образовательных целей. Считаю, что наиболее надежный и эффективный способ закрыть любую дыру – это просто выложить исчерпывающую информацию в паблик (как в недавней истории с известной дырой к Skype, которая, несмотря на всю свою серьезность, много месяцев не интересовала MS, пока, наконец, подробная инструкция с её описанием не была выложена в открытый доступ, что как-то сразу магически устранило её уже в течение суток). В свете планирующегося в Беларуси с 1 января подорожания услуг связи на 20%, в том числе интернет-доступа (по слухам, это не коснётся абонентов Белтелекома, который якобы готовит всем своим конечным пользователям новогодний подарок, опуская цены на свои услуги связи ровно на величину НДС, чтобы для конечных потребителей фактические цены сохранились на прежнем уровне), описанный мною сегодня технический трюк может оказаться особенно злободневным.

О чем пойдёт речь

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

Краткая теория DNS-тунелинга

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

1. Регистрируем собственный домен, для управления его зонами и субдоменами настраиваем свой DNS-сервер, авторитативный для данного домена. Очевидно, этот конец цепочки находится под вашим полным контролем, это будет сторона, выполняющая роль управляющего сервера в создаваемом DNS-туннеле (далее Сервер);
2. Специальное ПО, совмещенное и работающее согласовано с DNS-сервером, осуществляет в фоновом режиме непрерывный мониторинг всех входящих DNS-пакетов. В частности, контролирует каждый входящий запрос на наличие идентифицирующих сигнатур. Уникальная комбинация флагов или значений в служебных полях DNS-запросов могут идентифицировать обращение клиента, после чего такой “особый пакет” распаковывается Сервером согласно заранее условленному алгоритму. После его обработки формируется ответ, точно также инкапсулированный в служебную часть отсылаемого DNS-пакета;
3. С противоположной стороны, за множеством брандмауэров и сетевых фильтров находится тот, кто должен получать команды и как-то удаленно исполнять их, условно назовем его Клиент. Безотносительно к характеру предшествующей фильтрации стандартного TCP/IP-потока, такому клиенту достаточно иметь стандартную возможность резольвить (разрешать) DNS-имена, чтобы создать собственный скрытый и туннелированный канал соединения с заранее указанным и подготовленным Сервером из внешнего Интернета.

Несмотря на кажущуюся необычность схемы, всё довольно просто: метод напоминает идеи стеганографии, реализованные на базе DNS.

DNS: спецсвязь для ботнета

Поскольку пока чаще всего этот тип связи используется в современных ботнетах, давайте немного остановимся на этой теме поподробнее. Ботнет – это большая распределенная система, где на первый план в современных условиях всё чаще выходит именно надежный механизм обратной связи, который позволил бы держать постоянную связь с управляющей головой ботнета (говоря на сленге ботостроителей – с ”папой”). Даже сам ”пробив” не столько важен, как возможность после этого невозбранно ходить через чужую сеть пакетами направо и налево, оставаясь при этом полностью незамеченным. Времена использования для отправки управляющих команд классического IRC-канала ушли в прошлое. Для донесения кодированных посланий теперь чаще всего применяются сервисы типа Twitter или p2p-сети. Недостаток такого подхода в том, что современные “ортодоксальные” администраторы часто сосредоточены на фильтрации этих традиционных протоколов (главным образом http), но в большинстве случаев совершенно упускают из вида нестандартные использования стандартных протоколов. Например, возможность тунелирования TCP/IP-трафика через стандартные DNS-запросы в целях внешнего управления ботами или троянами, сидящими глубоко внутри корпоративных сетей.

Области злоупотребления

Кроме уже упомянутых армии ботов и троянов, DNS-тунелинг сейчас активно используют для обхода как персональных, так и корпоративных средств защиты в офисах по всему миру. В частности, я лично был впечатлён случаем, когда наблюдал ситуацию применения такой технологии для проброса ICQ/Jabber, несмотря на практически полную блокировку входящего трафика в крупную белорусскую корпоративную сеть. Интересно, что в этом случае фильтрация и мониторинг сети осуществлялись как местным админом областного филиала, так и минским специалистом из центрального офиса этой республиканской государственной структуры, где и обеспечивалось физическое подключение к интернету. Несмотря на использования разных технологических платформ на этих двух уровнях и принципиально различных методов фильтрации, механизм DNS-проброса на этом режимном объекте “с ограниченным уровнем доступа” работал очень надежно, хотя и относительно медленно (впрочем, на скорости, достаточной для сидения этого скучающего сотрудника в чате). Ещё одна область для “незаконного творчества” – это различные интернет-провайдеры, многие из которых предоставляют бесплатный доступ к своим локальным сетям или к собственным информационным сайтам, даже когда у абонента нет денег на его счету. В большинстве случаев технически это ограничение реализуется в виде фильтрации IP-адресов на пограничном брандмауэре, четко отделяя адреса своей локальной сети от Интернета. Моё выборочное тестирование провайдеров во время моих прошлогодних путешествий показывает, что все без исключения проверенные поставщики интернета (в том числе и один мобильный), дают возможность резолвить имена в гостевом режиме работы. И если даже в каких-то отдельных случаях брандмауэры или DNS настроены достаточно консервативно, например, делая невозможной передачу экзотических NULL-записей, у DNS-тунелинга есть достаточно хороший адаптационный потенциал, позволяющий переключаться на трансляцию через уж совсем обычные CNAME-запросы и так далее. Для чего используется эта повальная уязвимость – для анонимного серфинга, бесплатного чтения почты, чатов или управления зомби-сетями – вопрос, который имеет вторичное отношение к рассматриваемому нами сегодня сугубо техническому аспекту DNS-тунелинга. Поэтому, объяснив в общих чертах, как это работает и где это может быть применено, позвольте перейти к обзору самых распространенных инструментов для создания и тестирования подобных туннелей, с моими краткими пояснениями специфики каждого из них.

Общедоступные инструменты для тунелинга

Несмотря на то, что многие узкоспециализированные программы, построенные на этот принципе, реально работают по различным схемам – все они эксплуатируют одну центральную идею, применяемую для обхода стандартных средств сетевого контроля. Речь идёт об инкапсуляции своего служебного трафика в штатные DNS-запросы с последующей сборкой скрытно полученных TCP/IP-пакетов уже позади заградительного барьера на шлюзе. Существуют удобные шелл-коды, которые по этому же принципу пробрасывают внутрь подобной “защищенной” локальной сети свою консоль управления, чаще всего используя для этого DNS-запросы типа TXT. В этой связи стоит также напомнить о dnscat (эта известная утилита часто упоминается как самостоятельный инструмент, но это лишь часть пакета DNS-утилит nbtools), созданная специально для этих целей, а также о не менее известном в узких кругах NSTX (IP over DNS - NameServer Transfer Protocol). В случае с NSTX решение получается достаточно надежное, максимальный размеры пакетов, которые здесь можно передать — 512 байт по UDP, которые затем ”глубоко в тылу” собираются в полноценные IP-пакеты. Более новый, но аналогичный по идее инструмент – Heyoka, кроме тунелинга TCP/IP трафика также выполняет спуфинг адресов-источников запросов для самомаскировки. OpenSource-природа этих решений приводит к тому, что принципиальные кодовые части упомянутых программ для тунелирования сегодня обнаруживаются в “личинках” самых разных ботнетов. В частности популярный для Windows пакет Iodine, который в российских условиях часто используется для незаконного ”добывания интернета” абонентом, ранее отключенным провайдером за неуплату (DNS, как правило, при этом остаётся рабочим), применяется в коде одной из разновидностей ботнета Gheg. Другая подобная система OzymanDNS – популярна у “специалистов сетевых наук” для надежного проброса своего SSH через служебный DNS-трафик перед самым носом даже у самых строгих сисадминов. В такой схеме единственный минус (который именно для случая ботов не так существенен): DNS-клиент (зомби) может связываться с “папой” только сам и в одностороннем порядке. Статистика, собранная при наблюдении подобных “пчелиных улеев”, показывает, что “пробив” у подобной схемы чрезвычайно высок, чаще всего зомби с обратной связью на основе DNS-тунелинга надежно управляются даже из самых глубоких недр самой тщательно “зафильтрованной” корпоративной сети. Предлагаю в завершении немного избирательно остановиться лишь на двух пакетах из вышеперечисленного списка.

Iodine

Как и все предыдущие инструменты, Iodine позволяет передавать IPv4 через DNS-трафик. Давайте перечислим основные отличия, которые делают его без сомнения очень интересной реализацией DNS-тунелинга:

• Впервые используются экспериментальные NULL-пакеты (см. NULL RDATA format из RFC 1035), что позволяет существенно ускорить трансфер данных, доведя размер одного пакета до 1Кб полезных данных;
• Iodine спроектирован очень универсально – он прекрасно работает как на Win32-системах, так и практически на всех Unix-системах. Таким образом, это даёт возможность запустить клиента, например, в среде Windows, а принимающий сервер настроить уже под любимой FreeBSD;
• Пакет содержит достаточно хорошую встроенную систему безопасности. Например, он использует аутентификацию на базе MD5-хеша, а также принимает пакеты только с тех IP-адресов, которые сначала прошли аутентификацию, отбрасывая любые другие, какие бы команды они не содержали;
• Iodine максимально автоматизирует и упрощает свою настройку. Например, он сам настраивает свой интерфейс во время инсталляции, сам тестирует и выбирает оптимальный по скорости режим передачи данных из множества доступных и так далее. Кстати говоря, здесь на одном сервере может “висеть” одновременно до 16 пользователей-клиентов;
• Проект достаточно активно развивается, также доступны его полные исходные коды, есть репозитарий, прекрасно документированы спецификации всех используемых протоколов.

Хочу упомянуть, что кроме уже названных поддерживаемых платформ Linux/*BSD/Win32, также имеются рабочие клиенты под Android, Maemo, WinMobile, Mac OS X (дополнительно нужен драйвер tuntap), BeOS и Solaris. Есть также готовые скрипты, которые полностью развёртывают систему. Я не буду “сильно зарываться”, рассказывая о технической настройке в этой обзорной статье, об этом достаточно подробно написано вот здесь или здесь. В заключение дам полезный совет: часто уменьшение на стороне клиента значения MTU (для интерфейса dns0, например до 700) существенно ускоряет обмен данными в таком туннеле.

OzymanDNS

Этот инструмент от очень известного специалиста по безопасности Дэна Каминского (Dan Kaminsky), которого часто величают как “DNS guru”. Главная особенность OzymanDNS – это изначальная “заточенность” на проброс именно SSH-трафика. Автор утилиты призывает далее в зависимости от конкретной необходимости туннелировать необходимый трафик уже через SSH (для примера, вот настройка работы с Tor через туннель SSH/DNS). Сам Дэн выполнил черновую реализацию и тестирование концепции “SSH через DNS” (proof-of-concept), а также открыл исходники своего проекта (кстати, полностью написанного на Perl). У OzymanDNS уже появились последователи – независимые сторонние доработки. В частности, я хотел бы порекомендовать обновленную неофициальную версию этого инструмента, где автор реализовал иной алгоритм переупаковки трафика, который, по его словам, в среднем работает в два раза быстрее оригинального. Также интересен вариант совместного использования браузера и OzymanDNS, которые можно настроить работать через SSH-прокси и браузерные плагины со стороны клиента (такие как ProxySwitchy для Google Chrome или FoxyProxy для Mozilla Firefox). OzymanDNS написан на Perl, поэтому он может быть запущен во всех средах, где поддерживается этот интерпретатор (оригинальный набор скриптов был написан и протестирован в Linux). На Mac OS X можно использовать клиент в сочетании с заранее установленными Xcode и всеми необходимыми Perl-модулями (как минимум нужны MIME::Base32 и Net::DNS). Для клиента в Windows можно взять Cygwin (в котором самостоятельно скомпилировать и настроить всю рабочую среду) или проект Strawberry Perl. Кроме всего этого, для любой из клиентских сред должны быть установлены и настроены внешние сервера SOCKS 5 и SSH. Прочитать подробную инструкцию по установке OzymanDNS для множества ОС можно здесь.

Выводы и заключение

По итогам всего вышеизложенного у меня есть два типа новостей. Хорошие новости

1. DNS-тунелинг позволяет “добывать интернет” – то есть невозбранно пользоваться интернетом через гостевые режимы работы провайдеров (в том числе WiFi-сетей) без какой-либо авторизации и идентификации (и соответственно оплаты этой услуги);
2. DNS-тунелинг позволяет скрытно (беспрепятственно) пробрасывать (и получать обратно) любые пакеты практически в любой защищенной сети, если вы находитесь уже внутри. Это свойство также может являться и мощным средством защиты информации – множественная и нестандартная инкапсуляция потребует серьёзного реверс-инжениринга;
3. DNS-тунелинг – это замечательное средство полной личной анонимизации, особенно при использовании подключений через сети Wi-Fi;
4. Есть огромное количество готовых клиентов, как под все ОС, так и под ведущие мобильные платформы, которые позволяют использовать этот “хитрый интернет” прямо “из коробки”;
5. Применять этот метод связи очень удобно и практично в гостиницах, аэропортах и вокзалах – словом везде, где с одной стороны понатыкано куча WiFi-сетей, а с другой вы находитесь там буквально пару часов, и нет смысла покупать припэйд-карту для штатного доступа к Wi-Fi. А почитать в этот часик новости или написать пару твитов хочется;
6. Последний пункт – этот метод работает практически всегда и везде. Это касается как выборочно опробованных зарубежных сетей Европы, так и… возможно, и у оператора прямо под твоим боком.

Плохие новости

1. Такой вид тунелинга обеспечивает низкую скорость передачи данных, и это практически никак не зависит от скорости твоего подключения – это жесткие, чисто программные ограничения трансляции (“проброса”) трафика через DNS-пакеты, свободное место в каждом запросе которых весьма ограничено. В реальной жизни это вполне позволяет чатиться, просматривать веб-страницы, получать RSS-новости и так далее – но не смотреть фильмы, страницы, насыщенные графикой и медиа, не скачивать большие файлы;
2. Заранее на стороне внешнего интернета требуется установка и настройка собственного принимающего сервера, который будет выполнять роль гейта для вас во внешний Интернет. Также требуются какое-то базовое понимание устройства интернета;
3. Это – незаконно (!) (хотя этот вопрос не так однозначен и, можно сказать, что открыт). Если местный провайдер пропускает DNS-трафик для всех желающих, никак не тарифицируя его, никак не фильтруя и не контролируя – чьи это проблемы?

В заключение напоминаю админам, что не надо зацикливаться только на вышеописанном, – не забывайте об аналогичных методиках-вариациях, использующих, к примеру, проброс IP через ICMP или PPP через Jabber. Следует более тщательно продумывать правила фильтрации пакетов даже для самых безобидных с первого взгляда протоколов (типа DHCP). Будем надеяться, что эта обзорная статья по тунелингу поможет задуматься и сделать шаг именно в этом направлении.

Место солидарности беларусского ИТ-комьюнити

Далучайся!