ошибки BIND при кэшировании запросов

•	Главная
•	Архив новостей
•	Безопасность в Unix
•	Безопасность в Windows
•	Сборник FAQ'ов
•	Телефония, фрикинг
•	Кредитные карты
•	Криптография
•	Истории о хакерах
•	Программы, утилиты

_el@sp.sz.ru

ошибки BIND при кэшировании запросов

Если у вас запущен Bind 8.2.2 и у вас в кэше содержится, к примеру, доменное имя victim.dom, а сервер victim.dom поменял свой адрес, то любой пользователь, который может делать рекурсивные запросы к кэшу, может заставить сервер не делать запросы на новое местоположение victim.dom до тех пор, пока старая запись не будет сброшена по тайм-ауту.

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

ДЕТАЛИ

Положим, что сайт www.victim.dom имеет два NSserver'a - sun37.victim.dom и pc5.victin.dom, их IP-адреса - 1.2.3.4 и 5.6.7.8 соответственно. Новые сервера - ns1.victim.dom и ns2.victim.dom (1.2.3.5 и 5.6.7.9 соответственно). После настроек новых серверов, администратор производит обновление базы Internic'a, но старые сервера всё ещё функциониуют некоторое время. Затем база interneic обновляется, и нзаписи меняют своё содержание на следующее:

   victim.dom       259200 NS ns1.victim.dom
   victim.dom       259200 NS ns2.victim.dom
   ns1.victim.dom   259200 A 1.2.3.5
   ns2.victim.dom   259200 A 5.6.7.9

Несмотря на это, в вашем кэше всё ещё содержится следующая информация :

   victim.dom       258437 NS sun37.victim.dom
   victim.dom       258437 NS pc5.victim.dom
   sun37.victim.dom 258437 A 1.2.3.4
   pc5.victim.dom   258437 A 5.6.7.8

Теперь атакующий может перейти непосредстредственно к действию. Всё, что ему надо сделать - это сделать запросы к вашему кэшу на адреса серверов sun32.victim.dom и pc5.victim.dom несколько сотен раз. BIND присваивает каждому запросы приоритет, и с каждым запросом понижает TTL на 5%:

   victim.dom       258435 NS sun37.victim.dom
   victim.dom       258435 NS pc5.victim.dom
   sun37.victim.dom 5 A 1.2.3.4
   pc5.victim.dom   5 A 5.6.7.8

Итак, через несколько секунд адресные записи сбросятся, и останутся лишь NS-записи, которые будут содержаться в кеше ещё несколько дней.

Теперь пользователь запрашивает ваш кеш об адресе blah.victim.dom. Ваш кеш считает, что представляется возможным получить ответ от primary & secondary name-server'ов sun37.victim.dom & pc5.victim.dom. Но всё - данные адреса более не являются NS для victim.dom и пользователь получает ответ о том, что victim.dom не существует.

Итак, кажущийся совсем незначительным баг в BIND привёл к тому, что запрос был сброшен. Кеш думает, что информация о текущем полодении victim.dom до сих пор находится на pc5 и sun37, и что запрос, сделанный к ним будет обработан успешно.

С дургой стороны, находил ли ваш кеш действительные адреса pc5.victim.dom и sun37.victim.dom ? Ведь все запросы к .victim.dom не приносят желаемого результата. К счастью, в данном случае кеш способен избежать зацикливания и делает запрос уже в зоне .dom, т.е. непосредственно в базе Internic.

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

Team Void