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-сервера без перехвата траффика практически нереальна.
P.S. Когда есть возможность устроить ARP-Poisoning (т.е. когда цель находится в том же физическом сегменте сети), DNS-Hijacking - это уже даже и не интересно. Пропуская через себя чужой траффик можно сделать все что угодно. Но те тулзы, что я находил, нацелены именно на такой принцип работы.
Для интереса посмотрел как оно работает. Скомпилил dsniff, запустил arpspoofer + fragrouter, затем запустил dnshijacker - получилось. Но это уже все не то…
Октябрь 28th 2007 in Безопасность
Комментариев: 6 к записи “Mythbusters: шторм ложных DNS-ответов (DNS hijacking)”
DNS hijacking, spoofing, injection, poisoning - атаки на ДНС (шторм ложных ответов)
Фото Москвы: ночная москва, красная площадь, вднх - фонтаны.
Случайные записи: достопримечательности Москвы, gps навигация
Maniac сказал 28 Окт 2007 at 19:16 #
Чего перестал в блог писать?
Раньше каждый день новый пост был
Да состояние такое, блин. Несколько раз открывал блог, чтоб кое-что написать, но через пару минут закрывал.
Плюс еще и приболел.
Niko сказал 29 Окт 2007 at 13:09 #
да… только пока клиент будет обрабатывать фейк ответы, родной ответ может и затеряться…и днс перейдет на tcp/ip (или когда он наго переходит?)
Всяк ли человеком рожденный, человек? | Продвижение и оптимизация сайтов сказал 29 Окт 2007 at 18:02 #
[…] прочитать некоторые творения Маулнета, читая KMiNT21 о безопастности и hjiacking имногих других блогеров, которых я к сожалению не […]
> днс перейдет на tcp/ip
Niko, TCP и UDP - подуровни IP.
А по поводу перехода на TCP, уточнил вот:
“TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса”.
izlesa сказал 04 Дек 2008 at 15:44 #
Ну тут вы не совсем правы. В действительности создать общую методику этой атаки невозможно, но можно воспользоваться некоторыми техниками, ктр в частных случаях упрощают проведение атаки (гым если учесть что подавляющее количество dns-серверов это bind, то это сильно упрощает дело). Ну и ещё при межсегментной атаке проще атаковать именно dns-сервер чем конечный резолвер. Bithday-атаки, предсказание (а точнее сужение диапазона перебора) transaction id (честно говоря эти подтипы известны достаточно давно, так что нужно проверять их и если не получится, проверять на криптостойкость генераторы ПСЧ для tID в том же Бинде - копатся в программном коде, тем более у Криса Касперски встречал упоминание о не сильной их криптостойкости). Для точного определения времени начала атаки можно принудительно заставить клиента (либо сервер) резольвить нужное нам доменное имя(для клиента например можно послать письмо хтмл с картинкой на удаленном сервере, для сервака, если там есть smtp-сервак настроенный на прием запросов извне, можно с помощью него отрезолвить). Для увелечения вероятности успеха можно провести DDoS на какойто либо dns-сервер в цепочке. Да сейчас, методика проведенния этой атаки усложнилась по сравнению с 93 годом (когда дополнительные записи ресурсов тоже кэшировались и не было практически никакой криптостойкой аутентификации между резолвером и серваком с помощью tID ^_____^ вот лафа была, по типу хакни интернет …). Я правда только в этом во всём разбираюсь и пытаюсь написать пока классический спуффер, так что гдето могу ошибатся, но пока я ничего нереального невижу, только необходимо опять же распределенное нападение и применение нескольких техник.