Оригинал: Cyber Attacks Explained: DNS Invasions
Автор: Prashant Phatak
Дата публикации: 22 февраля 2012 г.
Перевод: А.Панин
Дата перевода: 8 декабря 2012 г.

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

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

Рисунок 1 отражает фундаментальные принципы работы службы разрешения сетевых имен. Когда приложение (такое, как браузер) хочет установить соединение с удаленной службой, оно совершает запрос IP-адреса у DNS-сервера. Этот запрос в форме пакета отправляется через порт UDP номер 53, после чего сервер возвращает ответ в форме пакета. (Следует помнить о том, что по причине ограничения размера данных в UDP-дейтаграмме 512 байтами, стек протоколов автоматически использует протокол TCP для осуществления запросов и приема ответов.) Когда клиент принимает ответ, он добавляет данные в свой локальный кэш, что позволяет ускорить последующие обращения к этому же домену. Элементы локального кэша автоматически уничтожаются после истечения их времени жизни (параметр TTL (Time to Live)).

Рисунок 1: Разрешение доменных имен

Система DNS использует такие типы записей, как A, CNAME, SOA, MX и другие. Хотя описание этих типов записей и выходит за рамки данной статьи, системным администраторам важно знать о том, когда и как их следует использовать, а перед их использованием должно проводиться исследование с точки зрения будущей безопасности системы. Перед тем, как рассмотреть атаки на систему DNS, нам необходимо рассмотреть два типа запросов - итерационные и рекурсивные.

• Итерационные запросы DNS : В то время, как клиент отправляет запрос DNS-серверу, желая получить информацию о домене, DNS-сервер может как располагать, так и не располагать информацией об этом домене. Если у DNS-сервера нет ответа, вместо завершения запроса, он отправляет имя высшего DNS-сервера, у которого может быть в распоряжении необходимая информация, клиенту. Обычно этот процесс называют перенаправлением DNS-запросов (DNS referral). Клиент отправляет запрос следующему (указанному) серверу; если у него нет ответа, он отправляет клиенту имя высшего сервера. Этот процесс продолжается до тех пор, пока клиент получает или IP-адрес, или сообщение об ошибке о невозможности выполнения запроса.
• Рекурсивные запросы DNS : В этом случае процесс начинается с того, что клиент производит запрос разрешения имени домена напрямую к DNS-серверу. Если у DNS-сервера нет ответа, предполагается, что он выполнит работу по обмену данными с высшими серверами вместо того, чтобы просто предоставить их имена клиенту. Снова, если высший сервер не обладает информацией для ответа на запрос, он переадресует запрос высшему серверу. Этот процесс продолжается до тех пор, пока запрос не доходит до корневого DNS-сервера, который должен обладать необходимой информацией и клиенту возвращается ответ, а в случае, если запрошенного имени не существует, клиенту возвращается сообщение об ошибке по цепочке серверов. В отличие от итерационного метода, рекурсивный запрос считается более агрессивным в получении результата.

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

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

Атаки на системы DNS

Было замечено, что системные администраторы тратят много времени на разработку систем безопасности для приложений, серверов и других компонентов инфраструктуры, но, к сожалению, имеют склонность забывать о системах безопасности для DNS-серверов. Рассмотрите рисунок 2, на котором показаны возможные слабые места DNS-серверов, которые делают делают их уязвимыми к атакам. Система DNS спроектирована таким образом, что большая часть обмена данными происходит по протоколу UDP, в ней не предусмотрено встроенной системы безопасности и нет встроенной поддержки аутентификации - все это делает ее более уязвимой к атакам, чем другие сетевые службы. Давайте рассмотрим несколько типов наиболее распространенных атак на DNS.

Рисунок 2: Возможные слабые места DNS-серверов

Модификация кэша DNS (DNS cache poisoning)

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

Например, если браузер пытается получить доступ к сайту с адресом http://www.cnn.com/, вместо IP-адреса CNN он получает адрес, установленный программным обеспечением взломщика, который обычно ведет на сайт, расположенный на сервере, принадлежащем взломщику, и содержащий вредоносное программное обеспечение или оскорбляющее пользователя сообщение.

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

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

Подмена DNS-сервера (DNS hijacking)

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

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

Спуфинг DNS-запросов (DNS spoofing)

Эта атака относится к атакам перехвата с участием человека, в ходе нее взломщик получает контроль над сетью, в которой работает DNS-сервер и модифицирует ARP-кэш при помощи спуфинга пакетов. Как только получен контроль над сетью уровня MAC-адресов, взломщик вычисляет IP-адрес DNS-сервера и начинает отслеживать и модифицировать запросы, предназначенные для этого сервера.

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

Существует альтернативный способ этой атаки, называемый спуфингом идентификаторов DNS-запросов (DNS ID spoofing). Каждый DNS-запрос и ответ имеют уникальные идентификаторы, предназначенные для того, чтобы разделить между собой запросы, направленные DNS-серверу в одно и то же время. Эти уникальные идентификаторы зачастую формируются из MAC-адреса, даты и времени осуществления запроса и создаются стеком протоколов автоматически.

Взломщик использует сниффер для захвата одного или нескольких запросов и ответов с соответствующими им идентификаторами, после чего формирует запрос с соответствующим идентификатором и с подмененным IP-адресом. В результате этих действий в локальном кэше атакуемой системы сохраняется подмененный IP-адрес. После этого атакуемой системе может быть причинен ущерб путем размещения на сервере с указанным в запросе адресом вредоносного программного обеспечения.

Перезакрепление DNS (DNS rebinding)

Эта атака также имеет название "закрепление DNS" ("DNS pinnig") и является особо сложной атакой. В ходе нее взломщик сначала регистрирует свое собственное доменное имя, затем устанавливает минимальное значение времени жизни записей, которое предотвращает попадание информации об этом доменном имени в кэш.

Атаки отказа в обслуживании в отношении DNS (DNS denial of service)

Как мы узнали из первой статьи серии, бомбардировка потоком UDP- или TCP-пакетов порта 53 с запросами может привести сервер к отказу в обслуживании. Другим методом проведения этой атаки является атака потоком пинг-пакетов или TCP SYN-сегментов. Главной идеей, стоящей за этими действиями, является максимальное использование ресурсов сервера (центрального процессора и оперативной памяти) для того, чтобы сервер перестал отвечать на запросы. Хотя DNS-сервера и защищаются межсетевыми экранами, в том случае, если UDP-порты DNS не заблокированы для доступа из недоверенных сетей, система разрешения доменных имен становится доступной для данного типа атак.

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

Каждый сервер может ответить только на ограниченное число запросов в ограниченный промежуток времени (в зависимости от производительности центрального процессора и конфигурации) и в конечном счете начинает добавлять запросы в очередь. Чем больше клиентов будут подвергаться модификациям локального кэша DNS, тем больше запросов будет отправляться в очередь и в конечном итоге работа сервера будет парализована.

При другом типе данной атаки взломщик модифицирует кэш сервера DNS; вместо замены IP-адресов, соответствующих записям A или CNAME, модификации подвергаются доменные имена. Для усложнения ситуации длина каждого доменного имя может достигать нескольких сот или тысяч символов. Процесс синхронизации данных, начинающийся после внесения изменений, заключается в отправке множества килобайт данных с главного сервера имен нижестоящим серверам и в конце концов клиентам.

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

Защита систем на основе свободного программного обеспечения

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

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

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

Часто случается такое, что уязвимость в сторонней программе позволяет совершить проникновение на сервер разрешения имен. Хотя наиболее важные части сетевой инфраструктуры и защиены межсетевым экраном, унифицированными устройствами контроля (Unified Threat Management) и мощными антивирусными программами, часто необхдимо усилить защиту системой обнаружения проникновений (Intrusion Detection System). Она позволяет отражать атаки 2 и 3 уровней OSI, такие, как ARP-спуфинг, IP-спуфинг, атаки с использованием сниффера и другие типы атак.

Кроме важнейших мер предосторожности, описанных выше, существует несколько сложных методов, которые тоже следует применить. Как мы узнали ранее, каждый запрос имеет свой уникальный идентификатор и отправляется в UDP-пакете. К сожалению, из за особенностей проектирования стека DNS, описанных в стандартах RFC, эти идентификаторы легко предсказуемы, поэтому использование случайных чисел для формирования идентификаторов является хорошей идеей, помогающей предотвратить спуфинг-атаки. Аналогично,номер UDP-порта, на котором сервер разрешения имен принимает запросы и отвечает, также легко предсказуем и может быть изменен на случайно выбранный.

Для этих целей существуют программы с открытым исходным кодом, но при их использовании следует помнить, что они вносят небольшую временную задержку в процесс обработки запроса. Относительно новой и популярной технологией защиты является DNSSEC (Расширения безопасности DNS (DNS Security Extensions)). Она защищает клиенты и сервера от атак, при которых модифицируется кэш DNS, подписывая записи с использованием шифрования с открытым ключом. Работая аналогично SSL, запрашивающая данные и отвечающая стороны устанавливают доверенное соединение друг с другом, а как только оно установлено, начинается процесс разрешения имен.

Как только процесс разрешения имен завершается, сессия сбрасывается и таким образом поддерживается безопасность обоих сторон. Технология DNSSEC реализована на большинстве серверов интернет-провайдеров в мире.

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

Эта статья входит в серию статей о кибератаках, написанных тем же автором (Prashant Phatak). Другие статьи этой серии.

DNS spoofing - это простой метод обмана dns системы, блок преобразования имён dns, использующий ложную информацию, полученную от хоста, который - не отвечает за ту информацию. Каждый пакет dns имеет 16 битный id номер, id номер это чась dns пакета которая разрешает идентифицировать каждый dns пакет, который идёт через порт 53 и так же запрос может быть больше чем один раз. id это единственный способ различить различные запросы dns, связанный с этим, которое серверы dns используют, чтобы определить каков первоначальный был запрос. В случае BIND, этот номер увеличивается на 1 уровень для каждого запроса. Нападение, подобное TCP seq id может быть сделано, хотя это более трудней. Даже если BIND не может кэшировать информацию которую вы посылаете, он передаст ответ к оригинальному хосту. В случае ircd сделает запрос на PTR в ответ к хосту, соединяющемуся с ним, пакет ответа может быть сформулирован, чтобы содержать дополнительную информацию, из которой ircd будет делать внутреннее кэширование. Для этой атаки нужен доступ root"a на сервере dns, ответственном за in-addr. arpa блок информации dns. Также, ircd может кэшировать только один домен. Существует ещё одна атака, т. к. id состоит из 16 битов. Пользователь смог бы перебрать весь idspace. Для того чтобы подделать свой dns допустим на DALNet"e, нужно послать 65000 сгенерированных запросов на ns сервер, как только компьютер получает ответ на запрос, нужно будет прочитать пакет, и в нём будет написан правильный id. Как только получите id, нужно найти какой ни буть "packet creation tool" чтобы сделать dns пакет. Остается только подделать dns пакеты, послать на ns. dal. net и получаете spoofing TCP соединение.

Общая постановка проблемы В связи с бурным ростом сети Internet, проблема защиты информационных ресурсов ставиться все более значимой. Если вы подключены к Internet, ваша система может быть атакована. Рассмотрим работу DNS. Внешнесегментная адресация осуществляется по IP-адресам, но обращения к серверам, как правило, осуществляется по доменным именам. В этой связи была создана система преобразования (сопоставления) доменных имен в IP адреса – DNS-серверов (Domain Name System). Эта система отвечает за нахождение IP-адреса удалённого хоста по его имени. Принцип функционирования DNS системы следующий – удаленный хост посылает на IPадрес ближайшего DNS-сервера специальный запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти. Получив запрос, DNS-сервер просматривает свою базу данных на наличие запрашиваемого доменного имени. В случае если имя найдено, DNS-сервер возвращает ответ, в котором указывает искомый IP-адрес. В случае если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов и описанная в этом пункте процедура повторяется, пока имя не будет найдено. Рассмотрим обобщенную схему работы ложного DNS - сервера: ожидание DNS-запроса; получив DNS-запрос, извлечение из него необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера; в случае получения пакета от хоста, изменение в IPзаголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть, ложный DNS-сервер ведет работу с сервером от своего имени); в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).

Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и тем более в межсегментный канал связи атакующему скорее всего не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet. Результатом данной атаки является внесение навязываемого соответствия между IP адресом и доменным именем в кэш DNS сервера. В результате успешного проведения такой атаки все пользователи DNS севера получат неверную информацию о доменных именах и IP адресах. Данная атака характеризуется большим количеством DNS пакетов с одним и тем же доменным именем. Это связано с необходимостью подбора некоторых параметров DNS обмена.

Как показывает анализ существующих приемов защиты, противодействие атакам может осуществляться следующими методами. Путем перевода работы DNS на работу по протоколу TCP Переход от UDP к TCP несколько замедлит систему. При использовании ТСР требуется создание виртуального соединения, а так же стоит учесть, что, конечные сетевые ОС вначале посылают DNSзапрос с использованием протокола UDP и в том случае, если им придет специальный ответ от DNSсервера, то тогда сетевая ОС пошлет DNS-запрос с использованием ТСР. Использование протокола ТСР усложнит атаку путем подмены пакетов, но замедлит работу. Путем анализа DNS трафика. Противодействовать атакам можно путем анализа трафика. На DNS-сервер постоянно посылаются ложные пакеты с ложными IP адресами. Если полученный ложный пакет совпал по значениям с запросом, то ложный IP принимается как истинный. Если перехвата пакета от сервера не произошло, то атака характеризуется большим количеством DNS пакетов с одним и тем же именем. Это связано с необходимостью подбора некоторых параметров DNS обмена. Анализируя DNS трафик можно игнорировать такие пакеты, что бы избежать подмены IP адреса.

Выводы Изучив работу DNS-сервера можно увидеть, что текущая версия является достаточно неоптимальной и уязвимой для атак разного рода. Противодействовать атакам можно путем анализа DNS трафика или переводом работы DNS с UPD на TCP. Ни один из методов не дает полной защиты от атак, оба метода всего лишь усложняют возможность произведения атаки. Оба метода требуют дополнительных ресурсов от сервера. В случае с переводом работы DNS-сервера на TCP, увеличивается и время обмена между серверами, т. к. протокол UDP более быстрый, нежели TCP протокол. На данный момент, предложенные модели противодействия являются наиболее эффективными и их целесообразно использовать в комплексе для достижения максимально возможной защищенности.

DNS-заражение или DNS-спуфинг – это тип кибератак, в которых используются системные уязвимости в DNS-сервере с целью перенаправить трафик с легитимных серверов на поддельные.

Как работает DNS-заражение или DNS-спуфинг

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

Риски

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

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

IDN spoofing - это генерация доменных имён «похожих» на выбранное, обычно применяемая с целью заставить пользователя перейти по ссылке на ресурс злоумышленника. Далее рассмотрим более конкретный вариант атаки.

Представим, что атакуемая компания владеет доменом organization.org, и внутри этой компании используется внутренний ресурс portal.organization.org. Цель злоумышленника -получить учётные данные пользователя, и для этого он присылает ссылку через e-mail или используемый в компании мессенджер.

Получив подобное сообщение с большой вероятностью можно не заметить, что ссылка ведёт куда-то не туда. После перехода по ссылке будет запрошен логин\пароль, и жертва, думая, что находится на внутреннем ресурсе, введёт данные своей учётной записи. Шансы злоумышленника особенно высоки, если он уже проник за периметр, скомпрометировав систему любого сотрудника, и теперь борется за привилегии системного администратора.

Абсолютной «защиты от дурака» тут придумать не получится, но можно пробовать перехватить эту атаку на этапе разрешения имени через dns-запрос.

Для защиты нам понадобится последовательно запоминать встречаемые имена в перехваченных dns-запросах. В компании пользуются её внутренними ресурсами, значит мы достаточно быстро обнаружим в запрос на portal.organization.org. Как только мы встретили имя «похожее» на ранее встречавшееся, мы может подменить dns-ответ, вернув ошибку вместо ip-адреса атакующего.
Какие могут быть алгоритмы определения «похожести»?

• UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) Юникод - это не только ценный мех таблица символов, но ещё и куча стандартов и рекомендаций. В UTS39 определен алгоритм нормализации unicode строки, при котором строки, отличающиеся омоглифами (например русская „а“и латинская „a“) будут приведены к одинаковой форме
• Слова отличающиеся перестановками внутренних букв. Довольно легко спутать organization.org и orgainzation.org
• Замена домена первого уровня. Первый уровень имени обычно не несёт никакого смысла и сотрудник компании увидев «organization» может проигнорировать разницу в.org или.net, хотя тут возможны исключения

Вероятнее всего корпоративным сервером будет не bind, который стандарт скорее для web-хостеров или провайдеров, а microsoft dns server из-за повсеместного использования active directory. И первая проблема, с которой я столкнулся при написании фильтра к microsoft dns server – API для фильтрации dns-запросов я не нашёл. Эту проблему можно решать разными способами, я выбрал инжект dll и IAT хук на api работы с сокетами.

Для понимания методики будет необходимо знание PE-формата, подробнее можно прочитать, например, . Исполняемый файл состоит из заголовков, таблицы секций и самих секций. Сами секции – это блок данных, который загрузчик должен отобразить в память по относительному адресу (Relative Virtual Address – RVA), и все ресурсы, код, прочие данные содержатся внутри секций. Также внутри заголовка присутствуют ссылки (RVA) на ряд необходимых для работы приложения таблиц, в рамках этой статьи будут важны две –таблица импорта и таблица экспорта. Таблица импорта содержит список функций, которые необходимы для работы приложения, но находятся в других файлах. Таблица экспорта – это «обратная» таблица, в которой содержится список функций, которые экспортируются из этого файла, либо, в случае export forwarding, указывается имя файла и имя функции для разрешения зависимости.

Инжект dll будем делать без всем надоевшего CreateRemoteThread. Я решил использовать PE export forwarding – это давно известный приём, когда для того, чтобы загрузится в нужный процесс, в каталоге с exe-файлом создаётся dll с именем равным имени любой dll из таблицы импорта exe-файла (главное не использовать HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs). В созданной dll копируется таблица экспорта из целевой dll, но вместо указателя на код экспортируемой функции, нужно записать RVA на forward-строку вида «endpoint!sendto». Сам microsoft dns server реализован в виде сервиса HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS, который находится в %systemroot%\system32\dns.exe

Итоговый алгоритм инжекта в dns сервер будет таким:

• Создаём каталог %systemroot%\system32\dnsflt (можно любой другой, нахождения каталога именно в system32 необязательно).
• Копируем туда %systemroot%\system32\dnsapi.dll – это dll из которой dns.exe что-то импортирует, можно выбрать любую другую “не knowndll”.
• Переименовываем скопированную dll в endpoint.dll - это имя будем использовать в forward-строке.
• Берём нашу инжектируемую dll и дописываем в неё правильную таблицу экспорта, копируем нашу dll в %systemroot%\system32\dnsflt
• В реестре в ключе HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS меняем в ImagePath новый адрес бинарника %systemroot%\system32\dnsflt\dns.exe
• Создаём симлинк из %systemroot%\system32\dnsflt\dns.exe в %systemroot%\system32\dns.exe

А зачем последний шаг? Дело в том, что в windows есть встроенный firewall, и, по умолчанию, в windows server право слушать 53 порт есть только у приложения %systemroot%\system32\dns.exe. При попытке запустить его из другого каталога прав на доступ к сети не будет. А зачем я его вообще копировал? Для того, чтобы минимизировать воздействие на всю систему и не трогать оригинальный dnsapi.dll. Получается, что если уметь создавать symlink на приложение, то можно получать его сетевые права. По умолчанию, права на создание symlink есть только у администраторов, но достаточно неожиданно обнаружить, что выдав пользователю право на создание symlink, ты даёшь ему возможность обходить встроенный firewall.

После того как загрузились внутрь процесса из DllMain, можно будет создать поток и установить перехват. В самом простом случае наш dns сервис будет сообщать клиенту ip-адрес для имени через отправку UDP-пакета с 53 порта через фукнцию sendto из ws2_32.dll. Стандарт предполагает возможность использования 53 TCP-порта, если ответ слишком большой, и очевидно, что перехват sendto в этом случае будет бесполезен. Однако, обработать случай с tcp хоть и более трудоёмко, но можно аналогичным способом. Пока расскажу самый простой случай с UDP. Итак, мы знаем, что код из dns.exe импортирует из ws2_32.dll функцию sendto и будет использовать её, чтобы ответить на dns-запрос. Для перехвата функций тоже достаточно много разных способов, классический это сплайсинг, когда первые инструкции sendto заменяются на jmp в свою функцию, а после её завершения осуществляется переход на сохранённые ранее инструкции sendto и далее внутрь функции sendto. Сплайсинг будет работать даже если для вызова sendto будет использован GetProcAddress, а не таблица импорта, но если используется таблица импорта, то вместо сплайсинга проще использовать IAT-хук. Для этого нужно найти в загруженном образе dns.exe таблицу импорта. Сама таблица имеет несколько запутанную структуру и за деталями придётся ходить в описание PE формата.

Главное - что система в процессе загрузки образа запишет в таблицу импорта указатель на начало функции sendto. Это значит, что для того, чтобы перехватить вызов sendto, надо просто заменить в таблице импорта адрес оригинальной sendto на адрес своей функции.

Итак, мы установили перехват и начали получать данные. Прототип функции sendto выглядит так:

Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen);
Если s – это сокет на 53 порту, то по указателю buf будет лежать dns-ответ размером len. Сам формат описан в RFC1035 , я кратко опишу, что нужно сделать, чтобы добраться до интересующих данных.

Структура сообщения в стандарте описана так:

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

Struct DNS_HEADER { uint16_t id; // identification number uint8_t rd: 1; // recursion desired uint8_t tc: 1; // truncated message uint8_t aa: 1; // authoritive answer uint8_t opcode: 4; // purpose of message uint8_t qr: 1; // query/response flag uint8_t rcode: 4; // response code uint8_t cd: 1; // checking disabled uint8_t ad: 1; // authenticated data uint8_t z: 1; // its z! reserved uint8_t ra: 1; // recursion available uint16_t q_count; // number of question entries uint16_t ans_count; // number of answer entries uint16_t auth_count; // number of authority entries uint16_t add_count; // number of resource entries };
Секцию Question придётся разобрать для того, чтобы добраться до Answer. Сама секция состоит из такого количества блоков, которое указано в заголовке (q_count). Каждый блок состоит из имени, типа и класса запроса. Имя закодировано в виде последовательности строк, каждая из которых начинается с байта с длиной строки. В конце находится строка нулевой длины. Например, имя homedomain2008.ru будет выглядеть так:

Секция Answers выглядит похожим образом: блок состоит из имени, типа, класса, ttl и дополнительных данных. IP-адрес будет содержатся в доп. данных. С разбором имени возникает ещё одна сложность. Видимо, для уменьшения размера сообщения, вместо длины метки, можно встретить ссылку на другую область данных. Закодирована она так: если 2 старших бита длины равны 11, то следующий байт, а также младшие биты длины, следует интерпретировать как смещение в байтах относительно начала сообщения. Дальнейший разбор имени нужно совершать, перейдя по этому смещению.

Итак, мы перехватили нужное API, разобрали dns-ответ, теперь нужно принять решение: пропускать дальше этот ответ или вернуть ошибку. Для каждого имени, которое ещё не присутствует в базе, из ответа нужно проверить, является ли оно «подозрительным» или нет.
Будем считать «подозрительным» такие имена, для которых результат функции skeleton из Unicode Technical Standard tr39 совпадает с результатом от любого из имён из базы, или те имена, которые отличаются от присутствующих в базе перестановкой внутренних букв. Для реализации проверок будем хранить 2 таблицы. Первая будет состоять из результатов skeleton для всех имён из базы, во вторую таблицу запишем строки, которые были получены из строк базы путём удаления первого и последнего символа из каждой метки кроме первого уровня, а затем сортировки оставшихся символов каждой метки. Теперь, если новое имя входит в одну из двух таблиц, то считаем его подозрительным.

Смысл функции skeleton в определении похожести двух строк, для этого для каждой строки производится нормализация символов. Например, Xlœ будет преобразовано в Xloe, и таким образом, сравнивая результат функции, можно определить похожесть unicode-строк.

С примером реализации описанного выше можно ознакомится на github .
Очевидно, что изложенное решение на практике предоставить нормальную защиту не может, т. к. помимо мелких технических проблем с перехватом, есть ещё большая проблема с детектированием «похожих» имён. Было бы неплохо обработать:

• Комбинации перестановок и омоглифов.
• Добавление\замену символов не учитываемых skeleton.
• UTS tr39 не исчерпывается skeleton, можно ещё ограничивать смешивание наборов символов в одной метке.
• Японскую полноширинную точку и другие label separator.
• А так же такие прекрасные вещи, как

Подмена DNS (DNS Spoofing)

Система DNS (Domain Name System ) преобразует доменное имя (например, www.test.com) в его IP-адрес (например, 192.168.0.1) и наоборот. Данная атака использует технологию отправки фальшивых ответов на DNS-запросы жертвы. Атака основывается на двух основных методах.

Подмена DNS ID (DNS ID Spoofing)

Заголовок пакета DNS-протокола содержит идентификационное поле для соответствия запросов и ответов. Целью подмены DNS ID является посылка своего ответа на DNS-запрос до того, как ответит настоящий DNS-сервер. Для выполнения этого, нужно спрогнозировать идентификатор запроса. Локально это реализуется простым прослушиванием сетевого трафика. Однако, удаленно выполнить эту задачу гораздо сложнее. Существуют различные методы:

проверка всех доступных значений идентификационного поля. Не очень практично, поскольку общее количество возможных значений составляет 65535 (размер поля 16 бит);

посылка нескольких сотен DNS-запросов в правильном порядке. Очевидно, что этот метод не очень надежен;

нахождение сервера, генерирующего прогнозируемые идентификаторы (например, увеличивающиеся на 1). Этот тип уязвимости присущ некоторым версиям Bind и системам Windows 9x.

В любом случае, необходимо ответить до настоящего DNS-сервера. Этого можно достичь, например, выполнив против сервера атаку типа "отказ в обслуживании".

Для проведения успешной атаки, злоумышленник должен контролировать DNS-сервер (ns.attaquant.com), авторитетный для зоны attaquant.com . Целевой DNS-сервер (ns.cible.com) предположительно генерирует прогнозируемые идентификационные номера (увеличивающиеся на 1 при каждом запросе).

Атака требует выполнения четырех шагов:

В результате, кэш целевого DNS-сервера будет содержать соответствие, необходимое злоумышленнику и следующим клиентам запрашивающим адрес www.spoofed.com будет сообщен адрес машины злоумышленника. На ней может быть размещена копия настоящего сайта, с помощью которого злоумышленник может красть конфиденциальную информацию.

Изменение DNS Cache Poisoning

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

Используем те же данные, что и в предыдущем примере. Вот ключевые моменты этого варианта атаки:

послать DNS-запрос на разрешение имени www.attaquant.com DNS-серверу домена cible.com ;

целевой DNS-сервер шлет запрос на разрешение имени www.attaquant.com DNS-серверу злоумышленника;