DNS poisoning

Иногда бывает так что очень нужно чтобы некий чел зашел на нашу веб страничку, послал через нас какое-то письмо или каким-то иным образом связался с нашим серваком сам того нежелая/незная.
Поскольку лишь редкие "зубры" инета помнят IP всех используемых ими ресурсов, для всех остальных был придуман DNS - система которая позволяла присваивать безликим цифрам IP адресов вполне понятные и запоминаемые имена, и преобразовывать потом эти имена в IP адреса. Не будем слишком глубоко рассматривать как устроен DNS, обойдемся лишь базовыми сведениями: у каждого DNS сервера есть своя "зона ответственности" - это те соответствия имя -> адрес которые в файлах его конфигурации. Часть серверов так же содержат ссылки адреса другие DNS серверов для имен входящих внутрь зоны их ответственности, но не обслуживаемые непосредственно ими (поддомены).
Рассмотрим домен mydomain.net.ru, DNS сервер отвечающий за зону ru содержит ссылку на сервера воторые знают про зону net.ru, а те в свою очередь уже укажут на сервера которые знают про mydomain.net.ru и ее содержимое.
Так же для минимизации сетевого траффика, DNS серверы часто имеют включенный кеш для запоминания ответов других серверов.
При поступлении запроса для определения IP адреса sexygirls.mydomain.net.ru, DNS сервер (к которому обратился сетевой клиент), если sexygirls.mydomain.net.ru не находится в его зоне ответственности, узнает адрес сервера ответственного за домен ru у специальных "корневых" доменных серверов, знания о которых заложены в него при конфигурации, а затем проходит по цепочке нейм серверов пока не достигнет сервера который определенно сможет сказать какой-же адрес у нужного хоста. Все полученные ответы попутно получаются в кеш. (время сохранения ответов в кеше прописана в каждой зоне)

DNS cache poisoning

Первая проблема с таким подходом была опубликована в ноябре 1998го года, и тогда же была исправлена во многих DNS серверах (но далеко не всех!). Проблема заключалась в том, что достаточно было послать некому DNS серверу DNS ответ c информацией о каком-нибудь домене, и несмотря на то что сервер не посылал такого запроса, этот ответ все равно попадал в его кеш и при последующих запросах отдаст закешированный ответ. (Сервера с таким багом: Дефолтовая инсталляция 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

DNS poisoning

Вторая возможность - подделать ответ от одного из серверов в цепочке. Сначала нужно узнать с какого адреса посылаются ответы про домен, информацию о котором нужно подделать, затем выяснить адрес DNS сервера используемого жертвой (обычно сделать это можно так - зарегистрировать какой-нибудь домен и послать с адреса в этом домене мыло внутрь сетки чела, для которого мы подделываем инфу о домене, mail server начнет резолвить домен, и мы увидим их запрос в логе нашего DNS сервера, или в выводе банального tcpdump'а). Дальше все просто - начинаем бомбардировать их DNS сервер ответами якобы от DNS сервера ответственного за подделываемую зону (само собой с подделанным исходящим IP адресом). Когда тот сервер посылает запрос - ему тут же приходит наш ответ.
Ситуация в этой области может быть представленна как постоянная борьба админов с хакерами. Вот как это описывает Daniel F. Boyd с точки зрения воровства пива: