.:С.П.А.Х.Б.Халява:.Атака на DNS

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

Путешествуя по Интернету, мы очень часто наталкивались на мольбы пользователей дать им халявного интернета. Цель данного хелпа – показать как «хакеры» используют различные бреши в продукции компании Майкрософт с целью получения «бесплатного» интеренета, а также научиться защищаться от данного вида атак.

Атака на DNS

Введение

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

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

1. DNS с высоты птичьего полета

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

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

Клиентская часть DNS называется резолвером (resolver), доступ к которому прикладные программы получают через API операционной системы. При взаимодействии резолвера с сервером в качестве транспортного протокола используется UDP, не предусматривающий формирования виртуального канала. Запросы, генерируемые резолвером, являются рекурсивными, т.е. в качестве ответа на такой запрос возвращается либо искомая информация, либо сообщение о ее отсутствии.

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

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

2. Межсегментная удаленная атака на DNS-сервер

Возможность атаки на DNS путем фальсификации ответа DNS-сервера известна довольно давно (см., например, Медведовский И.Д., Семьянов П.В., Платонов В.В. Атака через Internet. - СПб.: "Мир и семья-95", 1997.). Объектом атаки может являться как резолвер, так и DNS-сервер. Причины успеха подобных атак кроются в легкости подделки ответа сервера. Протоколы DNS, используемые в настоящее время, не предусматривают каких либо средств проверки аутентичности полученных данных и их источника, полностью полагаясь в этом на нижележащие протоколы транспортного уровня. Используемый транспортный протокол (UDP) с целью повышения эффективности не предусматривает установления виртуального канала и использует в качестве идентификатора источника сообщения IP-адрес, который может быть элементарно подделан.

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

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

Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является "подмена" IP-адреса web-сервера www.coolsite.com на IP-адрес сервера www.badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации о IP-адресе www.coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен coolsite.com. В ложном ответе вместо реального IP-адреса www.coolsite.com указывается IP-адрес www.badsite.com. Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера www.coolsite.com попадают на www.badsite.com.

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

Большинство используемых в настоящее время реализаций DNS-сервера (BIND4, MS DNS) используют для исходящих запросов 53 порт, так что можно "на удачу" послать ложный ответ на этот порт. Однако данный метод будет срабатывать не всегда, поскольку, например, BIND8 может использовать для исходящих запросов любой случайно выбранный непривилегированный порт.

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

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

3. Метод определения номера порта и текущего идентификатора запроса

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

При наличии контролируемого сервера описанная атака может быть модифицирована следующим образом. Предположим для определенности, что атакующий контролирует сервер ns.hacker.com, ответственный за домен hacker.com. В первой фазе атаки мы провоцируем сервер ns.victim.com на обращение к ns.hacker.com путем посылки рекурсивного запроса на поиск информации о любом имени (не обязательно реальном) в домене hacker.com. Поскольку ns.hacker.com находится под контролем атакующего, он может перехватить этот запрос и извлечь из него информацию о номере порта и текущем id.

4. Метод косвенной провокации

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

С целью обхода этого ограничения можно предложить простой метод, который условно назовем "косвенной провокацией". Основная идея этого метода заключается в использовании любого общедоступного сервиса, являющегося клиентом целевого DNS-сервера, для формирования необходимого провоцирующего запроса. Наиболее подходящим кандидатом представляется общедоступный сервер электронной почты, который по определению должен принимать соединения с любого компьютера Internet. Предположим, что резолвер компьютера mail.victim.com настроен на использование сервера ns.victim.com, причем последний принимает рекурсивные запросы только от домена victim.com. Приведенный ниже SMTP-диалог провоцирует ns.victim.com на поиск информации о имени any-name.any-domain.com:

$ telnet mail.victim.com 25
Trying...
Connected to 
mail.victim.com.
Escape character is '^]'.
220 mail.victim.com ESMTP 
Sendmail 8.8.0/8.8.0; Wed, 5 May 1999 21:30:42
helo 
I.am.cracker
250 mail.victim.com Hello crack.hacker.com [1.1.1.1], 
pleased to meet you
mail from: user@any-name.any-domain.com
250 
user@any-name.any-domain.com... Sender ok
quit
221 mail.victim.com 
closing connection
Connection closed.

5. Как возникают эпидемии

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

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

Рассмотрим ситуацию, когда для домена victim.com существуют два ответственных сервера - ns.victim.com и ns2.victim.com, причем для ns2.victim.com делегирование выполнено некорректно. Применяя описанные методы, атакующий может "заразить" кэш сервера ns2.victim.com ложной информацией о именах в домене victim.com, например, подменить IP-адрес web-сервера www.victim.com на IP-адрес www.very-bad-site.com. Поскольку ns2.victim.com считается ответственным за домен victim.com, другие сервера в Internet будут обращаться к нему за информацией о именах в этом домене. Не располагая локальной копией доменной информации о victim.com, данный сервер будет возвращать в ответ ранее кэшированную ложную информацию, приводя к "заражению" всех обратившихся к нему серверов.

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

6. Реализация и полевые испытания

Программа, реализующая атаку на DNS-сервер с использованием контролируемого сервера, стала доступна в Internet примерно в феврале 1999 года. К счастью, использование этой программы не сводится к вводу в окошко IP-адреса целевого сервера и нажатию кнопки "Infect It!", а требует достаточно глубокого понимания принципов работы DNS, что сразу же отсеивает 99% потенциальных пользователей. Кроме того, в известной автору реализации сделано далеко не все для повышения вероятности успеха атаки.

С целью обеспечения чистоты эксперимента "полевые испытания" были проведены на трех неподконтрольных автору корпоративных сетях. Естественно, администраторы этих сетей были поставлены в известность и не возражали против проведения эксперимента. Как это ни печально, во всех трех случаях атака была успешной.

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

7. Взгляд с другой стороны баррикады

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

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

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

Заключение

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

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

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