Хакер №024. Спецвыпуск
ЯДОВИТЫЙ DNS: ПИВО ИЗ ДАУН!
GREEN (green@rootshell.ru)
Спецвыпуск Xakep, номер #024, стр. 024-054-1
ЗАЧЕМ НУЖНЫ ТРИ ВЕСЕЛЫХ БУКВЫ?
Иногда бывает так, что очень нужно, чтобы некий чел зашел на нашу веб-страничку, послал через нас какое-то письмо или каким-то иным образом связался с нашим серваком, сам того не желая и даже не зная этого. Поскольку лишь редкие "зубры" Инета помнят IP'шники всех используемых ими ресурсов, для остальных смертных была придумана DNS-система, которая позволяла присваивать безликим цифрам IP-адресов вполне понятные и запоминаемые имена, вроде vasechka.buhlo.ru, и преобразовывать потом эти имена в IP-адреса. Не будем слишком глубоко рассматривать, как устроен DNS (иначе мы с тобой прямо тут костьми и поляжем), обойдемся лишь базовыми сведениями: у каждого DNS сервера есть своя "зона ответственности" - это те записи о соответствии имя -> IP-адрес, которые забиты в файлах его конфигурации. Часть серверов также содержит ссылки на адреса других DNS серверов для имен, входящих в зону их ответственности, но не обслуживаемых непосредственно ими (так называемые поддомены).
Рассмотрим домен mydomain.net.ru. DNS-сервер, отвечающий за зону ru, содержит ссылку на сервера второго уровня, которые знают про зону net.ru, а те, в свою очередь, уже укажут на сервера третьего уровня, которые знают про mydomain.net.ru и его содержимое.
Также, для минимизации сетевого траффика, DNS-серверы часто имеют включенный кеш для запоминания ответов других серверов. При поступлении соответствующего запроса для определения IP-адреса sexygirls.mydomain.net.ru DNS-сервер (обычно провайдерский), к которому обратился сетевой клиент, узнает адрес сервера, ответственного за домен ru у специальных "корневых" доменных серверов. Знания о них заложены в него при конфигурации, а применять он их будет только в случае, если sexygirls.mydomain.net.ru не находится в его зоне ответственности. Его запрос проходит по цепочке нейм серверов, пока не достигнет нужного сервака, который определенно сможет сказать: какой же IP-адрес у нужного хоста. Все полученные ответы попутно сохраняются в кеше (время сохранения ответов в кеше прописано в каждой зоне свое).
DNS CACHE POISONING
Первая проблема с таким подходом была опубликована в ноябре 1998 года и тогда же была исправлена во многих DNS-серверах (но далеко не во всех!). Проблема заключалась в том, что достаточно было послать некоему DNS-серверу DNS-ответ с информацией о каком-нибудь домене, и, несмотря на то, что сервер не посылал такого запроса, этот ответ все равно попадал в его кеш, и при последующих запросах сервак отдавал закешированный ответ, а не тот, который нужно. Вот сервера с таким багом: дефолтовая инсталляция Windows 2000 (но в настройках это можно выключить, если, конечно, знать про этот баг и где, собственно, выключать), BIND версий до 4.9.1, BIND 8.1 (подвержен модифицированной версии атаки). Тулзы для юзания этой весьма полезной фичи можно взять тут:
http://www.insecure.org/sploits/dns.cache-poison.cname.html http://packetstormsecurity.org/spoof/unix-spoof-code/
http://www.team-teso.net/releases/zodiac-0.4.9.tar.gz
Содержание Вперед на стр. 024-054-2
