Aтака на DNS

Общеизвестное недосказанное или атака на DNS кэш by Free_Hunt.

Все кто интересуется темой безопасности в сети, и в частности DNS протоко- лом, давно знают о существовании атаки на DNS кэш . Эта тема широко описыва- лась в РУнете (статья на Хакзоне,книги "Атака на\через Интернет"). Суть ата- ки ,как всем известно , заключается в спуфинге (подделке) ответа от DNS сер- вера ,что приводило к неправильному разрешению (resolving) имени , т.е. воз- можности изменения соответствия ИМЯ - IP адрес. Однако в этих статьях расматривались только внутрисегментные атаки (хакер и жертва в одном сегменте сети),что позволяло прослушать трафик жертвы и вы- тащить из DNS пакета ID поле или номер порта в случае атаки на пользователя. Для атак на просторах интернета предлагалось "угадать" DNS ID перебором всех вариантов :) , что не реально, так как требует посылки около 6 мегабайт ин- формации в миллисекунды. Итак , как можно узнать значение DNS ID не слушая трафик жертвы? Известно две возожности.Первая - требует наличия подконтрольного primary DNS сервера. В этом случае для внесения неверных данных в DNS кэш сервера жертвы, необхо- димо узнать его текущее значение ID, которое увеличивается на единицу с каж- дым новым запросом. Для осуществления этого посылаем запрос к серверу жертве на разрешение имени любой машины из DNS зоны за которую отвечет наш подконт- рольный сервер.В следствии этого если в DNS кэше жетвы нет информации о дан- ном имени произойдет процедура удаленого поиска в DNS(запрос корневых серве- ров, и далее по нисходящей до авторитетного) , которая в конце концов приве- дет к запросу от жертвы на наш подконтрольный DNS сервер о машине из его DNS зоны(это обязательно произойдет,т.к. только он будет авторитетным для данной зоны) , причем в запросе будет содержаться значение ID сервера жертвы, а так как наш сервер под контролем мы можем прослушать его трафик и выловить это значение. Таким образом мы будем знать , что в такую-то секунду у DNS сервера жертвы было такое-то зачение ID . Но за время запроса-ответа это значение могло из- мениться , если кто-то в это время еще запрашивал разрешение имени которого нет в кэше. Как узнать на сколько оно изменилось ? Правильно, статистика :) , идем почти как по Митнику,только намного проще. Запрашиваем разрешение имени любой другой машины из зоны нашего подконтроль- ного сервера, опять получаем значение ID, но теперь уже засекаем время между ответом на первый запрос и на второй .

Повторяем эту процедуру несколько раз (чем больше тем лучше :) ), в итоге получим некоторое среднее значение изме- нения ID счетчика в некотором интервале времени,например в секунду(если зна- чение изменяется сильно то лучше взять меньший интервал).Таким образом, мы с некоторой вероятностью можем предсказать значения счетчика в ближайшее время. Выбераем время , расчитыаем значение ID , которое должно быть в эту секунду, берем 10 или 100 значений в зависимости от быстроты изменения. И посыла- ем запрос об имени чей IP мы хотим изменить,вместе с нашими ответами,в кото- рых подставлен левый IP адрес на запрашиваемое имя , и если все подсчитано верно и статистика не подведет в кэше DNS сервера жертвы окажеться соответс- твие имя - наш левый IP =) . Проверить это просто,посылаем обычый запрос о разрешении имени,если в от- вете будет наш IP, то все получилось иначе повторяем все сначала =). Схема атаки на DNS кэш. ................ . КОРНЕВЫЕ С-РА. .............. .......? ....... . Сервера . / . зоны РУ . / /........................... ID=6 / / где искать"ru"? / / ID=6 / / а где"our.ru" ? ________ port / / port ________ | | 53 какой IP у "vasya.our.ru"? 1025 | | | DNS | <--------------------------------- | "НАШ" | | ЖЕРТВА | / / | DNS | | |../ / |(our.ru)| | ID=6 | ..../ | | | | 53 ID=6 кто "vasya.our.ru" ? 53 | в зоне | | ....| --------------------------------> | vasya | | . | 53 "vasya.our.ru" - x.x.x.1 53 | katya | | . | <----------------------------- | ...итд | | . | 53 "vasya.our.ru" - x.x.x.1 1025 | | | . | ----------------------------> | | | . | .......... . . . . | | | . | ID=7 . INET . | | | 1сек | . . | | | . | ........... . . .. | | | . | ID=8 | | | . | | | | . | 53 какой ip у "katya.our.ru"? 1026 | | | . | <------------------------------ | | | . | 53 ID=9 кто "katya.our.ru" ? 53 | | | ....| ------------------------------> | | | | 53 "katya.our.ru" x.x.x.2 53 | | | | <----------------------------- | | | | 53 "katya.our.ru" - x.x.x.2 1026 | | | | ----------------------------> | | | | | | | | | | |________| ... и т.д. |________| Строим табличку по результатам. Далее... | изм-е t | изм-е ID Находим усреднение изм-я ID=4 1c | 1сек | 9-6=3 Последний ID=25 2c | 1сек | 13-9=4 В 6-ую секунду значение 4c | 2сек | 21-13=8 ID должно быть равно 25+4=29 5c | 1сек | 25-21=5 Здесь нужно посчтиать погрешность, .... и т.д. но так как она нам даст далеко не 99% вероятность ркомендую брать (ср. изм-е ID)*2 или даже *3 то есть в итоге посылаем пакеты с ID от 25 до 37 ( 12 пакетов). *remark: Наша програма, устроившись слушать DNS трафик нашего сервера, посылает обычный запрос на разрешение имени, ЖЕРТВА выполнив процедуру удаленого поиска , запрашивает наш сервер об имени. Сохраняем пришедшеее значение ID , включаем таймер,наш сервер отвечает , нам возвращаеться значение ип адреса. Посылаем вто- рой запрос на разрешение другого имени. В момент прихода зап- роса записываем время и смотрим как изменилься ID счетчик,пов- торяем несколько раз, состовляем таблицу как показано выше, и высчитываем когда и что отправлять. Ну и в нужный момент вре- мени отправляем запрос и следом ответ на него с предсказанным значением ID =).

Как видите нечего сложного ;). Метод второй, не требует наличия подконтрольного DNS сервера. Но все равно необходимы администраторские права для спуфинга обратных IP адерсов. Суть метода: Посылаем запрос на разрешение имени(любого которого нет в кэ- ше сервера жертвы ) и посылаем сразу ответы со значениями ID взятыми подряд. Напимер 100-110 ,(если канал толстый можно и 1000-2000 :) ) проверяем ответ, если получилось, значит угадали и значение ID находилось в выбраном интерва- ле . Иначе перебираем дальше 110-120 и т.д. Оснoвые трудности этого метода - предсказать ID невозможно, т.е. только суем и смотрим, получилось или нет. И главное, пока перебираем значение счетчика может перейти через 65535 и снова занулиться, в результате чего мы не угадаем вообще, правда, не что не мешает пройти по второму разу,третьему и т.д., однако для этого надо запастись име- нами =). Есстественно, для занесения в кэш, ваши ответы должны приходить раньше от- вета от реального сервера. Этого можно добиться либо флудом реального серве- ра тем самым замедляя его ответ , либо посылать ответы с хорошего канала ,с которого ответы приходят заведомо быстрее чем от реального сервера. Эти методы хоть и не обсуждались в РУнете , разве что совсем недавная пуб- ликация в ксакэпе, где был довольно фривольный перевод ADM-овской статьи. В статье группы ADM, расматривались эти методы атак на DNS кэш, и между прочим уже давно.Там же в статье есть рабочие примеры демонстрирующие оба вида атак http://adm.freelsd.net/ADM/ADMID.txt Но и тут есть темный момент , дело в том , что эти способы подходят только когда в DNS кэше нет имени которому вы хотите сопоставить ваш левый IP. Если же нужно переопределить IP какого-нибудь популярного имени, тут нас ждет не- удача т.к. запроса на разрешение имени не будет , из-за того , что оно уже в кэше т.е. для подмены необходимо как-то узнать, когда его не будет в кэше. Кэш устроен следующим образом,он находиться в сегменте данных и по умолча- нию может иметь размер 65 Мb , все разрешенные имена помещаться в этот кэш и удаляются только по истечению времени жизни DNS пакета - TTL,обычно,это сос- товляет один или несколько дней. Итак можно попытаться зафлудить сервер зап- росами на разрешение имен , и тем самым забить кэш нашими запросами . Но тут различные реализации DNS могут реагировать по разному , от очистки кэша до просто прекращения кэширования имен в ожидании пока по TTL какая-нибудь за- пись не умрет. Да и сам процесс флуда может занять очень много времени. Наболее интересен второй способ, запрос имени с периодичностью раз в секу- нду. И , если канал стабильный, то через некоторое время будет заметное отк- лонение по времени, от обычной скорости ответа, т.к. информация в кэше уста- реет и для удаленого поиска потебуеться время .Из информации в пакете от DNS сервера можно узнать сколько он храниться (TTL поле). Далее выстраиваем гра- фик по нашим запросам , по информации например за неделю ;) и учитывая время жизни этого имени в кэше, с точнотью до секунды(если ярко выражено последнее увеличение времени ответа) находим когда пакет устареет и сотреться из кэша. И к этому времени выполняем атаку на кэш по первому методу. Естественно это не все возможные варианты , можно еще например заребутить DNS сервер =).Для тех кто решил занятся этой темой подробнее ,рекомендую по- исследовать исходный код named-а на предмет его работы с DNS кэшом, наверня- ка вы найдете там много интересного ;). Целью этой статьи было упорядочить и досказать недосказанное(или специаль- но утаенное ? :) ) по этой теме. Конечно, атака на изменение кэша не простая задача, и требует предварительной подготовки (толстый канал на хорошем шеле, зеркало подменяемого сайта на "левом" IP и т.д...) и обширных знаний, но ре- зультат этой атаки , к примеру на изменение IP популярной поисковой системы или бесплатного мыльного сервера, не говоря уже о банках =) , на DNS сервер крупного провайдера,трудно переоценить =). О том как подготовить зеркало для подменяемого сайта, и о некоторых других полезностях мирроринга читайте в моей статье "Зазеркалье".


Обсудить статью в форуме



Copyright © "HACK-INFO" "crypt@hack-info.ru"
При использовании материалов обязательна ссылка на http://hack-info.ru.