Отступление Данная статья не претендует на особую оригинальность и новизну. Тема спуфинга была раскрыта много раз, в основном нашими англо американскими друзьями ) Перед написанием статьи были прочитаны (а не переведены!) множество источников, самыми интерестными из которых мне показались - http://www.giac.org/practical/gsec/Doug_Sax_GSEC.pdf (NS Spoofing (Malicious Cache Poisoning)) http://www.cert.org/advisories/CA-1997-22.html (интерстный эдвайзор про бинд и днс спуфинг ) а также гениальная по своему содержанию, практике и всему всему статья от ADM Crew http://packetstormsecurity.nl/groups/ADM/ADM-DNS-SPOOF/ADMID.txt ЗЫ также пытался прочитать аналогичную статью на секлабе .. так погряз в сухом языке и теории)) дочитал до второго абзаца и забил) ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------- В данном небольшом обзоре я постарался простым и понятным языком обьяснить весь смысл и всю технику данного вида атаки =) Как известно каждому еще с раннего детства - за каждым доменным именем закреплен определенный айпи адрес. Он может быть как динамический (используя технологию dynamic dns), либо постоянный статический, привязанный к какому-либо (а их как вы знаете великое множество) днс серверу. Первым регером доменов в интернете был Netwrok Solutions™, которые и на сегоднящний день являются крупнейшими регистрантами, к чьим нэйм сервам прикреплено неимоверное количество доменов. Можно смело сказать что жизнь интернета сильно зависит от этих днс-ок. Все помнят недавний случай с античатом, когда при заходе на него мы видели якобы "дефэйс эстонских хакеров". На самом же деле все данные на сервере античата оставались целыми, проникновения на сервак не наблюдалось, админы спали спокойно =) Как же они это сделали? DNS sppofing - скажите вы и не ошибетесь... Многие знают про этот виж атак, но не многие знают ее смысл, а уж людей, пробововших успешно из вас вероятно вообще единицы =) Поговрим сначала о теории, а в конце немного попрактикуемся =) ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------- Сразу оговорим небольшие замечания. Да, мы подменяем запрос, но в то же время, настоящий запрос тоже должен дойти до нэймсервера.. А что это значит? именно! мы должны успеть послать наш поддельный запрос раньше, чем прийдет настоящий, а чтобы успеть сделать это раньше.. нужно как минимум быть в той же подсети, где и находится днска, чтобы успевать принимать пакеты, изменять и сразу же отправлять их. ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------- Рассмотрим две основные принятые разновидности этой атаки. 1. Первый тип называется DNS Cache Poisoning. Предположим... Мы вбиваем в адресную строку адрес своего любимого сайта, надеясь его увидеть.. но не тут то было. Днс сервер отправляет нам ответ в виде совсем другого домена, который и высвечивается у нас в браузере. Допустим существуют два домена: coolsite.net (192.168.0.1) и someshit.net (192.168.0.2), првязанные к нс-кам, соответственно на ns.coolsite.net и ns.someshit.net . Атакующий изменил первую днс-ку (ns.coolsite.net) так, чтобы она отвечала на рекурсивный запрос (запрос который берется из кэша днс сервера) "фальшивой записью", в которой говорится что домен coolsite.net расположен на 192.168.0.1, а не 192.168.0.2 . Атакующий посылает запрос на нэйм сервер coolsite.net-а (ns.coolsite.net), в котором он у этой нс-ки прямо в самом запросе указывает на то что ему нужен someshit.net, якобы привязанный к айпишнику . Первый неймсервер обрабатывает запрос и из-за свойе слабой защищенности отправляет атакующему ответ, что к 192.168.0.1 привязан уже someshit.net . Если брать в расчет, что каждый запрос кэшируется (для уменьшения нагрузки на нс-ку, ведь она не может хранить записи о всех доменах, поэтому она использует записи и других нэйм серверов). Теперь вплоть до следующего обновления нс-сервера каждый, запросивший coolsite.net будет видеть содержимое someshit.net . То есть грубо говоря происходит обмен между двумя нэймсерверами, при котором ответ атакующего нейм серва кэшируется в памяти нэймсерва-жертвы. Тут естественно загвоздка в том, что атакующий должен иметь свой собственный нейм сервер, желательно в абузоустойчивой зоне, так как при реализации атаки скрыть его не представляется возможным.. 2. Второй тип обычно называют DNS ID Spoofing. Возможен и другой случай, когда атакующий подменяет нс-ку. ДНС-ки используют удп протокол (который кстати не имеет не малейшей защиты против спуфинга, в отличие от тисипишного) , причем у каждого запроса есть уникальный айди, который задается хостом при соединении с нской. Атакующий (someshit.net) посылает запрос к coolsite.net, причем запрашивая свой собственный домен. Нэйм серв coolsite.net отклоняет запрос. Атакующий посылает правильный ответ о себе к ns.coolsite.net, который передает ее хосту атакующего (который инициализировал сам запрос). Для проведения этой атаки нужно как минимум знать айди запроса, который в свою очередь может быть найден, просто снифая данные, отсылаемые и принимаемые при запросе. Все дело в том что неймсервер принимает запрос только в случае совпадения айдишника отправленного и полученного запроса, иначе она его просто игнорирует, своего рода защита =) Как только у нас есть этот айди, атакующий создает ложный ответ к днс-ке, создавая его так, как будто он пришел от правильного нейм сервера. Атакующий посылает запрос к ns.coolsite.net, запрашивая coolsite.net и вставляет модифцированную информацию в качестве ответа. И опять незащищенный нэйм серв принимает и сохраняет в кэше информацию. Рассмотрим вариант, когда мы находимся в подсети + мы имеем очень(!!!) широкий канал, а также на неймсервере нет слишком строго настроенного файра. Айди запроса кодируется двумя байтами, что означает что всего существует 65535 возможных значений. то есть мы вполне может обойтись без постоянного прослушивания трафика, а просто напросто отсылаем 65535 запросов, один из них со 100 процентной вероятностью бует иметь нужный нам номер. Загвоздка в том, что нам сложно будет узнать, когда это надо делать, не будем же мы послыать все 65к запросов постоянно.. это получается уже не днс спуфинг, а попытка заддосить серв =) ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------- Предположим, что атакующий не умеет пользоваться снифферами, а чтобы заиметь свой нэймсервер ему нужно слишком долго экономить в школе на завтраках =) Это совсем не означает что он не сможет навредить нам. Как уже было сказано удп протокол всвязи со своей спецификацией не умеет создавать сессии, в отличие от tcp, а позволяет лишь посылать и принимать запросы. Так чисто в теории подумаем зачем нам нужен свой неймсервер, если можно просто напросто запросить домен у днс сервера, а затем сразу отправить фейковый ответ от имени неймсервера. Звучит не очень убедительно.. Опять же сталкиваемся с проблемой получения айди запроса.. в точку! посылаем 65к запросов, один из них попадет в цель. Опять сталкиваемся с небольшой проблемой. Мы посылаем 1000 запросов на резолв. Затем для того чтобы проспуфить создаем фейковые ответы.. получается 65535*1000 = 65535000 (6 с половиной лямов) запросов. проблема в том, успеет ли сервер отсортировать и обработать именно наши ответы, раньше чем прийдут настоящие. Существует и проблема с портами - нужно знать на какой порт нэймсерв принимает ответы.. Исключается она лишь тогда, когда нс-ка имеет один статический порт, на который все и приходит. Хотя проблема и решается банальным извлечением номера порта из заголовка удп запроса, имеющего вид: Code: //откуда идет Source address : ns.coolsite.net //куда идет Destination address : ns.someshit.com //порт отправки Source port : 53 //порт принятия Destination port : 31337 //информация, которую несет запрос Data : (тут инфа о том, к какому айпишнику привязан домен) Каковы же шансы успешно провести данную атаку? В одной из вышеперечисленных статей был приведен очень интерестный расчет. Возьмем к расчету что мы посылаем 65535 пакетов при каждом запросе. Тогда при кол-ве самих запросов больше 550 получается что шансы растут от 90% и бесконечно стремятся к 100%, никогда не достигая единицы. ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------- А теперь я попробую вручную в небольшой собственноручно организованной локальной сети провести мини спуф. Естественно я не нарушал никаких прав, спуфил свою же днску, со своим же сайтом =) Все, что я использовал, можно свободно найти в гугле. Вообще честно говоря, используя нижеописанную утилиту вместе с плагином, участие человека с атаке сводится к нажатию нескольких кнопочек. Для этого воспользуемся ettercap-ом, версией под винду, с удобным гуи интерфейсом, что упрощает атаку в несколько раз. Открываем файл etter.dns (конфиг для плагина для спуфа). Прописываем что и на что будем спуфить (в конфиге есть примеры в виде Microsoft.com =)) ) Далее не забываем включить поддержку самого плагина во вкладке Plugins и начинаем доооооолго сканировать подсеть на диапозон айпишников ( около 5 минут, зависит от количесвта машин в сети ). Ну да ладно. В хост лист видим все существующие адреса подсети и мак адреса для каждого из них. Arp-poisoning -> Sniff remote connections Start -> Start sniffing Все. Направив пару раз браузер на домен, спуф которого мы прописали в конфиге (первые 2-3 раза почему то теряются вообще все пакеты), постепенно замечаем надпись в еттеркапе - site.com dns spoofed! и уже через пару минут любуемся на страничку, совсем не относящуюся к данному сайту. В принципе если исходить из более массовых атак (не так как у меня 12 компьютеров), то дело сводится к значительному увеличению времени скана, спуфанья и всего остального. ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------- Conclusion. Вообще по статистике каждый третий нэймсервер в инернете уязвим для данного вида атаки. Какую выгоду получает атакующий при этом? Заспуфив днс-ку, к которой прикреплен домен банка, он может повесить у себя фейк и запросто собирать аккаунты, пины и все подобное.. Либо сделать то, что недавно произошло с нашим любимым античатом - устроить "псевдо-дефейс". Все проблемы вытекают из-за неприспособленности удп протокла для днс системы, а также от несовершенства самих серверов. Секьюрити специалисты всерьез озадачились этой проблемой примерно в 1998 году, в 99ом-2000 как мелкомягкие, так и множество специализированных sec - компаний впустили адвайзоры по обнаружению, предотвращению и устранению последствий после днс спуфинга. Но до сих пор, практически через 8 лет, невозможно найти 100% защиту от этого. Ждем чего-то особенного от ipv6 ? TEH EDN.
