|
Атака на DNS //Геннадий
Карпов Введение Введение В данной статье рассматривается межсегментная удаленная атака на DNS-сервер, не требующая выполнения каких либо жестких условий и допускающая эффективную практическую реализацию. 1. DNS с высоты птичьего полета Первичным источником информации о каждом домене является ответственный за данный домен DNS-сервер (на самом деле их может быть несколько). Ответственность за часть доменной информации (поддомены) может быть делегирована другим серверам Клиентская часть DNS называется резолвером (resolver), доступ к которому прикладные программы получают через API операционной системы. При взаимодействии резолвера с сервером в качестве транспортного протокола используется UDP, не предусматривающий формирования виртуального канала. Запросы, генерируемые резолвером, являются рекурсивными, т.е. в качестве ответа на такой запрос возвращается либо искомая информация, либо сообщение о ее отсутствии. Получив запрос от резолвера, сервер либо сразу же возвращает ответ (при условии наличия искомой информации в локальной базе), либо формирует запрос к другому серверу. Этот запрос обычно является итеративным и, в отличие от рекурсивного, допускает ответ в виде ссылки на другой сервер, который лучше осведомлен о месте расположения искомой информации. В общем случае поиск начинается с корневого сервера, который возвращает информацию о серверах, ответственных за домены верхнего уровня, после чего формируется новый итеративный запрос к одному из этих серверов и т.д. Результатом такой цепочки вопросов-ответов является либо получение искомой информации, либо вывод о ее отсутствии, после чего полученный ответ возвращается резолверу. Вся накопленная сервером в процессе работы информация кэшируется с целью ускорения обслуживания последующих запросов и минимизации сетевого трафика. 2. Межсегментная удаленная атака на DNS-сервер При наличии у атакующего возможности перехвата сообщений, которыми обмениваются клиент и сервер (внутрисегментная атака) реализация атаки не представляет каких либо трудностей. Однако этот вариант не представляет и значительного практического интереса, поскольку возможность внутрисегментной атаки предполагает наличие определенного взаимного расположения клиента, сервера и хоста атакующего (например, атакующий и целевой 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. Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырех условий: IP адрес отправителя ответа должен соответствовать IP-адресу
запрашиваемого сервера (в нашем случае ns.coolsite.com); Идентификатор (id) запроса представляет собой двухбайтовое число, указываемое сервером в запросе с целью однозначной идентификации ответа на данный запрос. Это число инкрементируется с каждым новым запросом. Незнание текущего значения идентификатора приводит к необходимости посылки множества ложных ответов с различными значениями id. Именно это обстоятельство делает практическую реализацию данной атаки очень трудноосуществимой. Действительно, ложный ответ должен быть получен целевым сервером в промежуток времени с момента посылки запроса и до момента прихода ответа от настоящего сервера, что на практике составляет не более нескольких секунд. За этот интервал времени атакующему необходимо послать 216 ложных ответов со всеми возможными значениями id, а в случае незнания порта эта цифра увеличивается еще в несколько десятков раз. Поскольку размер IP-пакета, содержащего ложный ответ, составляет около 100 байт, то перед атакующим ставится задача пересылки нескольких мегабайт информации за несколько секунд, что в подавляющем большинстве случаев неосуществимо. 3. Метод определения номера порта и текущего идентификатора
запроса При наличии контролируемого сервера описанная атака может быть модифицирована следующим образом. Предположим для определенности, что атакующий контролирует сервер ns.hacker.com, ответственный за домен hacker.com. В первой фазе атаки мы провоцируем сервер ns.victim.com на обращение к ns.hacker.com путем посылки рекурсивного запроса на поиск информации о любом имени (не обязательно реальном) в домене hacker.com. Поскольку ns.hacker.com находится под контролем атакующего, он может перехватить этот запрос и извлечь из него информацию о номере порта и текущем id. Последующие две фазы атаки не отличаются от описанных, с той лишь разницей, что теперь атакующему достаточно послать всего несколько ложных ответов, поскольку он точно знает номер порта и может с высокой степенью точности предсказать значение идентификатора запроса к ns.coolsite.com. 4. Метод косвенной провокации С целью обхода этого ограничения можно предложить простой метод, который условно назовем "косвенной провокацией". Основная идея этого метода заключается в использовании любого общедоступного сервиса, являющегося клиентом целевого DNS-сервера, для формирования необходимого провоцирующего запроса. Наиболее подходящим кандидатом представляется общедоступный сервер электронной почты, который по определению должен принимать соединения с любого компьютера Internet. Предположим, что резолвер компьютера mail.victim.com настроен на использование сервера ns.victim.com, причем последний принимает рекурсивные запросы только от домена victim.com. Приведенный ниже SMTP-диалог провоцирует ns.victim.com на поиск информации о имени any-name.any-domain.com:
Таким образом, применение метода "косвенной провокации" позволяет осуществить атаку без прямой посылки запросов целевому DNS-серверу. 5. Как возникают эпидемии Под некорректным делегированием понимается ситуация, когда ответственность за домен делегируется серверу, не обладающему локальной копией доменной информации. Это приводит к тому, что в ответ на итеративные запросы других серверов вместо искомой информации он возвращает ссылки на другие сервера (иногда и на себя), которые, с точки зрения данного сервера, располагают нужными сведениями. Рассмотрим ситуацию, когда для домена 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, простирается от "отказа в обслуживании" и подмены web-сайтов до перехвата сообщений электронной почты и полного контроля над информацией, передаваемой между произвольно выбранными хостами Internet. При всем этом атакующий практически не оставляет следов, поскольку ему нет необходимости посылать провоцирующие запросы и ложные ответы с собственного IP-адреса. 7. Взгляд с другой стороны баррикады К сожалению, желаемый результат может дать только широкомасштабное внедрение новых протоколов, которое сопряжено со значительными организационными трудностями и не может быть проведено за короткое время. Несколько затруднить осуществление атаки может запрет на обслуживание DNS-сервером рекурсивных запросов, поступающих не от "своих" клиентов. Это может быть сделано как средствами самого сервера (например, BIND8 обладает такими возможностями), так и средствами межсетевого экрана. Следует обратить внимание на настройку "антиспуффинговых" правил фильтрации на межсетевом экране, поскольку атакующий в качестве IP-адреса отправителя запроса может указать любой адрес, в том числе и легального клиента. При использовании данного метода не следует забывать, что подобная защита может быть достаточно легко преодолена использованием описанного метода косвенной провокации. Заключение В то же время по характеру и масштабности результатов данная атака вполне может быть причислена к информационному оружию массового поражения. Отсутствие адекватных средств защиты, очень слабо выраженные следы и трудность устранения последствий атаки еще больше усугубляют ситуацию. Несколько удивляет тот факт, что данная удаленная атака широко не применяется взломщиками (по крайней мере, автор не располагает такой информацией). Вполне возможно, это объясняется просто недостаточной квалификацией подавляющего числа людей, называющих себя хакерами. Сетевым администраторам остается только надеяться, что уязвимость протоколов DNS к данной атаке будет устранена прежде, чем они почувствуют на себе ее последствия. |
Дизайн и техническая
поддержка: Мишин Олег (mishinoleg@mail.ru)
При использовании информации ссылка на автора обязательна. Коммерческое использование информации без согласия автора запрещается. |