Настольная книга компьютерного исследователя


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

Все кто интересуется темой безопасности в сети, и в частности 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  |    | vasya  |
         |    .   | 53    "vasya.our.ru" - x.x.x.1    53    | katya  |
         |    .   |    |        |
         |    .   | .......... . . . .                      |        |
         |    .   |    ID=7   .  INET  .                    |        |
         | 1сек   |            .      .                     |        |
         |    .   | ........... . . ..                      |        |
         |    .   |    ID=8                                 |        |
         |    .   |                                         |        |
         |    .   |  53  какой ip у  "katya.our.ru"?  1026  |        |
         |    .   |   |        |
         |        |  53    "katya.our.ru"   x.x.x.2   53    |        |
         |        |   |        |
         |        |                                         |        |
         |        |                                         |        |
         |________|          ... и т.д.                     |________|

Строим табличку по результатам.

      | изм-е t | изм-е ID
  1c  |   1сек  | 9-6=3
  2c  |   1сек  | 13-9=4
  4c  |   2сек  | 21-13=8
  5c  |   1сек  | 25-21=5
        .... и т.д.

Далее  находим усреднение изменения ID=4,  последний ID=25.  В 6-ую секунду значение  ID должно быть равно 25+4=29.  Здесь нужно посчтиать погрешность, но так как она нам даст далеко не 99% вероятность ркомендую брать (ср. изм-е ID)*2 или даже *3 то есть в итоге посылаем пакеты с ID от 25 до 37 ( 12 пакетов).

Отметим, что наша програма, устроившись слушать DNS трафик нашего сервера, посылает обычный запрос на разрешение имени, жертва выполнив процедуру удаленого поиска, запрашивает наш сервер об имени. Сохраняем пришедшеее значение ID, включаем таймер, наш сервер отвечает, нам возвращаеться значение ип адреса. Посылаем второй запрос на разрешение другого имени. В момент прихода запроса записываем время и смотрим как изменилься ID счетчик, повторяем несколько раз, состовляем таблицу как показано выше, и высчитываем когда и что отправлять. Ну и в нужный момент времени отправляем запрос и следом ответ на него с предсказанным значением ID =). Как видите нечего сложного ;).

Метод второй, не требует наличия подконтрольного DNS сервера. Но все равно необходимы администраторские права для спуфинга обратных IP адерсов. Суть метода: посылаем запрос на разрешение имени (любого которого нет в кэше сервера жертвы) и посылаем сразу ответы со значениями ID взятыми подряд. Напимер 100-110, (если канал толстый можно и 1000-2000 :) ) проверяем ответ, если получилось, значит угадали и значение ID находилось в выбраном интервале. Иначе перебираем дальше 110-120 и т.д. Оснoвые трудности этого метода  - предсказать ID невозможно, т.е. только суем и смотрим, получилось или нет. И главное, пока перебираем значение счетчика может перейти через 65535 и снова занулиться, в результате чего мы не угадаем вообще, правда, не что не мешает пройти по второму разу, третьему и т.д., однако для этого надо запастись именами =).

Есстественно, для занесения в кэш, ваши ответы должны приходить раньше ответа от реального сервера. Этого можно добиться либо флудом реального сервера тем самым замедляя его ответ, либо посылать ответы с хорошего канала, с которого ответы приходят заведомо быстрее чем от реального сервера.

Эти методы хоть и не обсуждались в рунете, разве что совсем недавная публикация в ксакэпе, где был довольно фривольный перевод ADM-овской статьи. В статье группы ADM, расматривались эти методы атак на DNS кэш, и между прочим уже давно. Там же в статье есть рабочие примеры демонстрирующие оба вида атак

Но и тут есть темный момент, дело в том, что эти способы подходят только когда в DNS кэше нет имени которому вы хотите сопоставить ваш левый IP. Если же нужно переопределить IP какого-нибудь популярного имени, тут нас ждет неудача т.к. запроса на разрешение имени не будет, из-за того, что оно уже в кэше т.е. для подмены необходимо как-то узнать, когда его не будет в кэше.

Кэш устроен следующим образом,он находиться в сегменте данных и по умолчанию может иметь размер 65 Мb, все разрешенные имена помещаться в этот кэш и удаляются только по истечению времени жизни DNS пакета — TTL, обычно, это состовляет один или несколько дней. Итак можно попытаться зафлудить сервер запросами на разрешение имен, и тем самым забить кэш нашими запросами. Но тут различные реализации DNS могут реагировать по разному, от очистки кэша до просто прекращения кэширования имен в ожидании пока по TTL какая-нибудь запись не умрет. Да и сам процесс флуда может занять очень много времени.

Наболее интересен второй способ, запрос имени с периодичностью раз в секунду. И, если канал стабильный, то через некоторое время будет заметное отклонение по времени, от обычной скорости ответа, т.к. информация в кэше устареет и для удаленого поиска потебуеться время. Из информации в пакете от DNS сервера можно узнать сколько он храниться (TTL поле). Далее выстраиваем график по нашим запросам, по информации например за неделю ;) и учитывая время жизни этого имени в кэше, с точнотью до секунды (если ярко выражено последнее
увеличение времени ответа) находим когда пакет устареет и сотреться из кэша. И к этому времени выполняем атаку на кэш по первому методу.

Естественно это не все возможные варианты, можно еще например заребутить DNS сервер =). Для тех кто решил занятся этой темой подробнее, рекомендую поисследовать исходный код named-а на предмет его работы с DNS кэшом, наверняка вы найдете там много интересного ;).

Целью этой статьи было упорядочить и досказать недосказанное (или специально утаенное?) по этой теме. Конечно, атака на изменение кэша не простая задача, и требует предварительной подготовки (толстый канал на хорошем шеле, зеркало подменяемого сайта на «левом» IP и т.д…) и обширных знаний, но результат этой атаки, к примеру на изменение IP популярной поисковой системы или бесплатного мыльного сервера, не говоря уже о банках =) , на DNS сервер крупного провайдера, трудно переоценить =).

(c) Free_Hunt



©2013 Журнал Хакера Entries (RSS) and Comments (RSS)