The Prodigy

Mythbusters: шторм ложных DNS-ответов (DNS hijacking)

Давно в голове у меня зрело желание поиграться с атаками на DNS, а вчера, наконец, дошли руки. Материала в интернете на эту тему прилично, так что и мимо меня это в свое время ”пролетало”, правда подробности уже подзабылись. 

Итак, будем рассматривать вариант, когда перехватывать траффик невозможно.

DNS траффик выглядит примерно так (UDP-пакеты): 

Клиент: Эй, ДНС-сервер, какой IP у адреса msn.com? ID запроса = ABCD.

Сервер: Ответ на запрос с ID=ABCD: для сайта msn.com IP=XX.XX.XX.XX

Я думал, все, что нужно сделать, это угадать ID запроса (16 бит) и ответить раньше настоящего DNS-сервера. 

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

Мы не знаем ID запроса. Потому мы просто отошлем жертве сразу кучу пакетов с разыми ID - авось какой-то да совпадет. Длина этого идентификатора всего 16 бит, потому пакетов не так много. Примерно так может это выглядеть:

Сервер: Ответ на запрос с ID=0: для сайта msn.com IP=faked.IP

Сервер: Ответ на запрос с ID=1: для сайта msn.com IP=faked.IP

Сервер: Ответ на запрос с ID=2: для сайта msn.com IP=faked.IP

Сервер: Ответ на запрос с ID=3: для сайта msn.com IP=faked.IP

Сервер: Ответ на запрос с ID=4: для сайта msn.com IP=faked.IP

Сервер: Ответ на запрос с ID=2134: для сайта msn.com IP=faked.IP

Но есть еще один “маленький” ньюанс. :) Нужно знать source port, откуда был послан UDP-запрос. Потому, получается уравнение с двумя неизвестными: source port и ID. Даже если сузить диапазон портов, данная атака все равно видится нереальной - настоящий DNS-сервер всегда ответит быстрее. 

Вывод: атака на конкретный хост путем беспрерывной отсылки фальшивых DNS-ответов от имени DNS-сервера без перехвата траффика практически нереальна.

myth busted 

P.S. Когда есть возможность устроить ARP-Poisoning (т.е. когда цель находится в том же физическом сегменте сети), DNS-Hijacking - это уже даже и не интересно. :) Пропуская через себя чужой траффик можно сделать все что угодно. Но те тулзы, что я находил, нацелены именно на такой принцип работы.

Для интереса посмотрел как оно работает. Скомпилил dsniff, запустил arpspoofer + fragrouter, затем запустил dnshijacker - получилось. Но это уже все не то…



Октябрь 28th 2007 in Безопасность

Комментариев: 6 к записи “Mythbusters: шторм ложных DNS-ответов (DNS hijacking)”

  1. Maniac сказал 28 Окт 2007 at 19:16 #

    Чего перестал в блог писать?
    Раньше каждый день новый пост был ;)

  2. сказал 28 Окт 2007 at 19:44 #

    Да состояние такое, блин. Несколько раз открывал блог, чтоб кое-что написать, но через пару минут закрывал. :) Плюс еще и приболел.

  3. Niko сказал 29 Окт 2007 at 13:09 #

    да… только пока клиент будет обрабатывать фейк ответы, родной ответ может и затеряться…и днс перейдет на tcp/ip (или когда он наго переходит?)

  4. Всяк ли человеком рожденный, человек? | Продвижение и оптимизация сайтов сказал 29 Окт 2007 at 18:02 #

    […] прочитать некоторые творения Маулнета, читая KMiNT21 о безопастности и hjiacking имногих других блогеров, которых я к сожалению не […]

  5. сказал 30 Окт 2007 at 02:09 #

    > днс перейдет на tcp/ip

    Niko, TCP и UDP - подуровни IP.

    А по поводу перехода на TCP, уточнил вот:

    “TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса”.

  6. izlesa сказал 04 Дек 2008 at 15:44 #

    Ну тут вы не совсем правы. В действительности создать общую методику этой атаки невозможно, но можно воспользоваться некоторыми техниками, ктр в частных случаях упрощают проведение атаки (гым если учесть что подавляющее количество dns-серверов это bind, то это сильно упрощает дело). Ну и ещё при межсегментной атаке проще атаковать именно dns-сервер чем конечный резолвер. Bithday-атаки, предсказание (а точнее сужение диапазона перебора) transaction id (честно говоря эти подтипы известны достаточно давно, так что нужно проверять их и если не получится, проверять на криптостойкость генераторы ПСЧ для tID в том же Бинде - копатся в программном коде, тем более у Криса Касперски встречал упоминание о не сильной их криптостойкости). Для точного определения времени начала атаки можно принудительно заставить клиента (либо сервер) резольвить нужное нам доменное имя(для клиента например можно послать письмо хтмл с картинкой на удаленном сервере, для сервака, если там есть smtp-сервак настроенный на прием запросов извне, можно с помощью него отрезолвить). Для увелечения вероятности успеха можно провести DDoS на какойто либо dns-сервер в цепочке. Да сейчас, методика проведенния этой атаки усложнилась по сравнению с 93 годом (когда дополнительные записи ресурсов тоже кэшировались и не было практически никакой криптостойкой аутентификации между резолвером и серваком с помощью tID ^_____^ вот лафа была, по типу хакни интернет …). Я правда только в этом во всём разбираюсь и пытаюсь написать пока классический спуффер, так что гдето могу ошибатся, но пока я ничего нереального невижу, только необходимо опять же распределенное нападение и применение нескольких техник.

DNS hijacking, spoofing, injection, poisoning - атаки на ДНС (шторм ложных ответов)






   Фото Москвы: ночная москва, красная площадь, вднх - фонтаны.

   Случайные записи: достопримечательности Москвы, gps навигация
Другие посты блога: Дизайн квартиры: комнаты, кухня, спальня, ванная комната (фото),     Секреты техподдержки программного обеспечения,     Виртуализация - VMWare Workstation, VMWare образы,     ZX Spectrum,     Сетевое программирование, программирование сокетов, winsock,     Сон и наука сна: фазы, циклы и сновидения,     спектрум,