взято отсюда
Злорадства DNS-сервера
Крис Касперски
Хитрый способ перехвата паролей в локальных сетях
Вот ведь какая штука! Локальные сети, которые есть сейчас буквально везде, начиная от твоего дома и заканчивая больницей, где ты лечишься, оказались совершенно беззащитными перед DNS-атаками, позволяющими перехватывать чужой трафик, а также скрыто перенаправлять жертву на подложные сайты, занимающиеся сбором паролей или другой хакерской деятельностью. Как реализуются такие атаки? Можно ли от них защититься? Вот об этом мы сейчас и поговорим!
Не будем объяснять читателю, что такое «доменные имена» и зачем они применяются. Читатель не дурак и сам об этом прекрасно догадывается. Каждый раз, когда мы подключаемся к какому-нибудь сетевому ресурсу, наш узел отправляет доменное имя DNS-серверу (адрес которого автоматически выдается провайдером при входе в интернет или жестко прописывается в настройках TCP/IP-соединения). В ответ возвращается один из нескольких IP-адресов удаленного сетевого ресурса или сообщение, что узел с таким именем не существует.
«Что значит «один из IP-адресов»?» — может спросить читатель. А то, что с одним доменным именем может быть ассоциировано множество IP-адресов, что позволяет равномерно распределять нагрузку между узлами, а также продолжать нормальную работу, если один из серверов ушел в отказ. Но это уже технические детали.
Еще существует файл hosts, находящийся в папке \WINNT\system32\drivers, который занимается сопоставлением доменных имен/IP-адресов и имеет более высокий приоритет, чем DNS-сервер. Это простой текстовой файл, который может изменять как сам пользователь компьютера, так и засланная туда программа, например вирус, подменяющий истинный IP-адрес службы Windows Update хакерским узлом со всеми вытекающими. Или же присваивающий подложные IP-адреса службам mail.ru, webmoney.ru… Однако, чтобы сделать это, в компьютер жертвы необходимо как-то забраться, что не так-то просто, особенно если за ним сидит не лох, а продвинутый гуру, следящий за своей безопасностью, пользующийся антивирусами и регулярно скачивающий свежие заплатки. Хотя на самом деле можно подломать и гуру, причем так, что тот даже не заметит ничего подозрительного!
DNS-атаки: фундаментальные основы
Обмен данными между DNS-сервером и DNS-клиентом (встроенным в каждый компьютер) может происходить как по UDP-, так и по TCP/IP-протоколу. По умолчанию выбирается UDP, как наиболее быстродействующий и не требующий установки соединения, однако чрезвычайно уязвимый к атакам. И вот почему. Отправив запрос DNS-серверу, узел жертвы охотно принимает фальшивый ответ, если только пакет, сконструированный хакером, отвечает определенным требованиям. Так что же это за требования?
Прежде всего, узел жертвы формирует «порт отправителя», на который и ожидает получить ответ от DNS. Алгоритм формирования порта отправителя не стандартизирован, но в общем случае дело происходит так: при первом запросе порт отправителя устанавливается в 1023 и затем увеличивается на единицу с каждым DNS-запросом, а при исчерпании 16-битного счетчика снова сбрасывается в 1023. DNS-запрос размещается в UDP-пакете и помимо прочего содержит идентификатор запроса (ID) и доменное имя узла, IP-адрес которого нужно разрешить. DNS-сервер в своем ответе возвращает идентификатор запроса и доменное имя вместе с IP-адресом (ну или адресом более компетентного DNS-сервера, к которому следует обратиться за вопросом, но это опять-таки детали).
Суть в том, что для отправки поддельного DNS-ответа нам необходимо знать (угадать, перехватить, подобрать) порт отправителя, идентификатор запроса и доменное имя узла. Проницательным хакерам удавалось осуществлять даже «слепые» межсегментные атаки, когда атакующий находился на одном конце Земли, а жертва — на другом. Атака обычно осуществляется направленным штормом DNS-ответов с различными параметрами в надежде, что хоть один из них да подойдет. А чтобы настоящий DNS-сервер не успел послать свой ответ вперед хакера, он временно выводится из строя (например, путем DoS/DDoS-атаки).
Системы обнаружения вторжений, установленные на магистральных каналах связи, легко распознают такой вид атак и щемят хакеров только так. Но в приватных локальных сетях ситуация совершенно иная.
ARP-атаки в локальных сетях
Локальные сети, собранные на коксиале, позволяют беспрепятственно перехватывать чужой трафик, поскольку он физически проходит через все машины того же сегмента сети. Пакет, отправленный в сеть, принимается даже теми сетевыми картами, которым он не предназначен. Сетевая карта просто сверяет свой MAC-адрес с MAC-адресом получателя пакета, прописанного в Ethernet-заголовке, и либо обрабатывает его (в случае совпадения адресов), либо же отбрасывает. Однако существует возможность программного перевода карты в так называемый «неразборчивый» режим, в котором она кушает все пакеты. Именно по этой технологии работают сетевые сниферы (sniffers), как хакерские, так и вполне легальные, предназначенные для диагностики сети.
Но с переходом на витую пару и интеллектуальные маршрутизаторы (а других сегодня, пожалуй, нигде, кроме как в музее, и не найти) доставляют пакет только тому получателю, чей MAC-адрес совпадает с MAC-адресом, прописанным в заголовке, то есть чужой трафик так просто не перехватить! Но тут есть один деликатный момент. Физически Ethernet-сети работают на MAC-адресах, что расшифровывается как Media Access Control address (управление доступом к носителю), в то время как в интернете рулят IP-адреса.
Каждый узел локальной сети, работающий с TCP/IP-протоколом, имеет специальную ARP-таблицу (Address Resolution Protocol — протокол разрешения адресов), предназначенную для преобразования IP-адресов в MAC-адреса, а самим преобразованием занимается ARP-протокол, работающий по следующей схеме: если MAC-адрес получателя неизвестен, в локальную сеть отправляется широковещательный запрос типа: «Обладатель данного IP, сообщите свой MAC-адрес». Полученный ответ заносится в уже упомянутую ARP-таблицу, кстати говоря, периодически обновляющуюся. Временные интервалы между обновлениями зависят от типа операционной системы, а также ее конфигурации и варьируется от 30 секунд до 20 минут.
Никакой авторизации для обновления ARP-таблицы не требуется. Более того, большинство операционных систем заглатывает подложные ARP-ответы, даже если им не предшествовали никакие ARP-запросы. Таким образом, для того чтобы маршрутизатор пересылал чужой трафик на хакерский Ethernet-порт, атакующий должен модифицировать ARP-таблицу жертвы, что осуществляется посылкой подложного направленного или широковещательного ARP-ответа, в котором содержится IP-адрес DNS-сервера провайдера и… свой собственный MAC-адрес!
Жертва послушно обновляет ARP-таблицу, после чего все DNS-запросы поступают прямиком на хакерский узел. Что будет делать с ними хакер?! Да ничего особенного, просто установит у себя любой бесплатный DNS-сервер из многих имеющихся и будет исправно разрешать доменные имена. Вот только для некоторых особо интересных доменных имен будет сделано исключение, и в настойках DNS-сервера хакер пропишет фальшивые IP-адреса, которыми, как нетрудно догадаться, окажутся адреса подконтрольных ему узлов с установленными «копиями» web-серверов или просто proxy-серверами, грабящими весь проходящий трафик. Однако следует помнить, что если соединение осуществляется по протоколу HTTPS, то в логах proxy не окажется ничего интересного, так что возводить подложные web-серверы все же намного более предпочтительно (хоть полное копирование интерфейса чужого сервера и не самое простое занятие).
Технические аспекты реализации атаки
Для успешного хакерствования в водах Карибского моря нам потребуются три вещи: утилита, формирующая поддельные ARP-запросы, DNS-сервер и web-сервер. Естественно, если мы хотим перехватывать почтовый трафик, передаваемый по протоколам POP3/SMTP, то и почтовый сервер нам тоже понадобится.
Раздобыть ARP-утилиту можно, например, на Packet Storm (www.packetstormsecurity.org). Просто вводим в строку поиска слово «ARP» и выбираем себе бифштекс по вкусу, благо выбирать там есть из чего. Большинство утилит поставляется непосредственно в исходных текстах и работает только в UNIX-подобных системах, но… с появлением виртуальных машин типа VMware это обстоятельство перестало быть существенной проблемой.
Просто ставим себе VMware (если не сделали этого ранее) и натягиваем любой Linux (внимание: некоторые ARP-утилиты работают только со строго определенными дистрибутивами Linux’а или BSD, так что чтение инструкции перед установкой — это рулез). Запусти атакующую ARP-утилиту и укажи в командной строке свой собственный MAC-адрес и адрес DNS-сервера провайдера, отправив в сеть широковещательный подложный ARP-ответ (смотри справку по ключам соответствующей ARP-утилиты).
Как узнать свой MAC-адрес? Запусти штатную утилиту ipconfig.exe с ключом /all, и она выдаст всю необходимую информацию (MAC-адрес будет прописан в графе «Физический адрес» для каждой сетевой карты).
А как узнать IP-адрес настоящего DNS-сервера? Нет ничего проще! Вызываем штатную Windows-утилиту nslookup.exe, и она тут же сообщает Default DNS Server (сервер по умолчанию) вместе с его IP-адресом.
Но, прежде чем запускать ARP-утилиту, заставляющую всех членов этого сегмента локальной сети забыть о настоящем DNS и валить DNS-запросы на наш хакерский узел, нам, естественно, необходимо установить свой собственный DNS-сервер, который эти самые запросы и будет обрабатывать, иначе произойдет сплошной облом.
Из бесплатных DNS-серверов, работающих под Windows, автор рекомендует Small HTTP Server, включающий в себя: web-сервер, HTTP-сервер, DNS-сервер, DHCP-сервер, FTP-сервер, SMTP-сервер, POP3-сервер и много всякой всячины. Ну разве не здорово?! Лежит это добро на smallsrv.com и настраивается с полпинка.
«Ну и как он настраивается?! Поконкретнее, пожалуйста», — попросит придирчивый читатель. Короче, значит, запускам инсталлятор, который ничем не отличается от миллионов других точно таких же инсталляторов, и никаких вопросов на этом этапе установки у нас не возникает. Затем, зарегистрировав сервер на «гражданина бывшего СНГ» (регистрация бесплатна и описана в документации), запускам файл http.exe, щелкаем правой кнопкой мыши по иконке, появившейся в системном трее, и выбираем в контекстном меню пункт Settings («Установки»).
На экран вылезает разлапистое диалоговое окно. Находим в нем DNS. Там будет пункт «Host file. File with host names and IP address for DNS server» («Хост-файл. Файл с доменными именами и IP-адресами, используемый DNS-сервером»).
Хост-файл имеет достаточно сложную структуру, и, чтобы не грузить читателя лишними детали, автор приводит готовый листинг, заставляющий наш локальный DNS-сервер обращаться к корневым DNS-серверам. Просто создай хост-файл в любом месте диска, скопируй в него следующий текст и укажи путь к файлу в настройках DNS-сервера.
Строки, которые необходимо добавить в хост-файл, чтобы наш DNS-сервер обращался за разрешением запросов к корневым DNS-серверам
. IN NS a.root-servers.net
a.root-servers.net IN A 198.41.0.4
. IN NS b.root-servers.net
b.root-servers.net IN A 128.9.0.107
. IN NS c.root-servers.net
c.root-servers.net IN A 192.33.4.12
. IN NS d.root-servers.net
d.root-servers.net IN A 128.8.10.90
. IN NS e.root-servers.net
e.root-servers.net IN A 192.203.230.10
. IN NS f.root-servers.net
f.root-servers.net IN A 192.5.5.241
. IN NS g.root-servers.net
g.root-servers.net IN A 192.112.36.4
. IN NS h.root-servers.net
h.root-servers.net IN A 128.63.2.53
Теперь, получив запрос на разрешение доменного имени от одного из клиентов, наш сервер обратится к одному из корневых DNS-серверов и вернет ответ жертве, как будто бы она обратилась к настоящему DNS-серверу, предоставленному провайдером. Ну и какой в этом кайф?! Фактически мы будем обслуживать чужие DNS-запросы на халяву. А навар?!
А вот и навар! Добавим в хост-файл одну или несколько строк вида «83.239.33.46 www.sysinternals.com», мы сможем изменить IP-адрес узла www.sysinternals.com на любой другой IP-адрес. Например, адрес порносервера или нашего собственного web-сервера, который можно создать с помощью того же Small HTTP сервера или Microsoft Personal web-сервера. Тут, как говорится, на вкус и цвет товарищей нет, ну а техника сайтостроения — это уже совсем другая тема, которой посвящены сотни книг и тысячи статей.
Проведем небольшой эксперимент. После добавления в хост-файл указанной выше строки запустим браузер и наберем www.sysinternals.com и… вместо ожидаемой странички мы попадем на… наш сервер! То же самое произойдет и со всеми остальными атакованными пользователями приватной локальной сети.
При этом следует помнить о двух вещах. Первое: поскольку ARP-таблицы периодически обновляются и хакнутый MAC-адрес вновь заменяется правильным, атакующую ARP-утилиту следует закинуть в планировщик (кури инструкцию к штатной Windows-команде at).
Второе: у некоторых провайдеров стоит система обнаружения вторжений, просекающая попытки (успешные, разумеется) вторжения в ARP-таблицы, после чего провайдерам остается установить вектор атаки, то есть определить Ethernet-порт хакера, и надавать ему по ушам. Однако в подавляющем большинстве случаев никакой защиты нет.
Возведение защитных сооружений
Хачить чужие компьютеры — это хорошо. Ой, что за чушь я несу?! Это плохо и вообще противозаконно, но еще хуже, когда кто-то захачит нас. Надо же как-то защищаться?! А защититься можно (и нужно) с помощью все того же Small HTTP сервера, установив свой собственный DNS-сервер, напрямую обращающийся к корневым DNS-серверам через TCP-протокол. Тогда нас никакой хакер не взломает! Для этого нужно установить Small HTTP сервер на свой компьютер, активировать DNS по методике, описанной выше, и назначить его основным DNS-сервером, выбросив DNS-сервер провайдера на фиг за полной ненадобностью.
Вообще-то, обращение к корневым серверам — процедура небыстрая и слегка замедляющая web-серфинг, по крайней мере теоретически. Практически же Small HTTP сервер кэширует DNS-запросы, так что задержка возникает лишь при первом посещении данного ресурса, зато потом ответ от локального сервера возвращается практически мгновенно, намного быстрее, чем от DNS-сервера провайдера. Более того, у многих провайдеров DNS-серверы не только тормозят, но еще и косячат, то есть отвечают, что нет, мол, узла с таким именем, даже если такой узел заведомо есть. В общем, мыщъх уже больше года работает исключительно через локальный DNS и страшно доволен. Исчезли многие глюки и тормоза, так достававшие его ранее.
В настройках Small HTTP сервера выбираем меню DNS, находим поле «Size of cache for names (in bytes)» («Размер кэша имен в байтах») и увеличиваем его насколько не жалко. Чем больше размер кэша, тем больше доменных имен в нем поместится и тем реже будут происходить повторные обращения к корневым DNS-серверам. Изменение размера кэша возымеет действие только после перезапуска Small HTTP сервера — просто закрой его, а потом запусти вновь.
Самое главное — необходимо взвести галочку «Enable DNS over TCP» («Использовать TCP-протокол для DNS-запросов»), что в 99,999% случаев гарантирует невозможность создания подложного пакета, который бы DNS-сервер воспринял как правильный.
Остается только прописать адрес нашего локального DNS-сервера (всегда равный 127.0.0.1) в качестве основного. На первый взгляд кажется, что нет ничего проще! Находим в «Панели управления» папку «Сеть и удаленный доступ к сети», выбираем нужное сетевое соединение, в контекстом меню заходим в «Свойства», лезем в настройки протокола TCP/IP, переводим радиокнопку из положения «Получать адрес DNS-сервера автоматически» в положение «Использовать следующие адреса DNS-серверов» и пишем в нижеследующей графе «127…». И вот тут-то нас ждет облом-с! Windows ехидно сообщает: «IP-адреса, начинающиеся с 127, не являются допустимыми, поскольку они зарезервированы для адресов замыкания на себя. Укажите другое, допустимое значение в диапазоне от 1 до 223».
Обладатели статических IP-адресов могут просто махнуть рукой и прописать свой реальный IP-адрес (который можно узнать с помощью штатной утилиты ipconfig.exe), однако как быть тем, у кого IP-адрес назначается провайдером динамически и меняется при каждом входе в сеть?! Приходится прибегать к прямому редактированию реестра. Запускаем regedit.exe (с правами администратора), захотим в следующую ветвь системного реестра: HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\, где видим все имеющиеся у нас сетевые интерфейсы, а точнее, соответствующие им идентификаторы вида {13D988FF-8252-4F2A-94CC-BC36E90EDFA0}. Как найти в них нужный?!
Поочередно открывая ветви идентификаторов один за другим, смотрим на поле NameServer, в котором содержится IP-адрес DNS-сервера, назначенного провайдером. Если он совпадет с IP-адресом, выданным утилитой nslookup.exe, то, значит, мы нашли, что искали и меняем этот адрес на 127.0.0.1. Перезагрузка не требуется. Все! С этого момента DNS-сервер провайдера отдыхает и все запросы идут через наш собственный локальный сервер, проследить за активностью которого можно кликнув левой кнопкой мыши по иконке Small HTTP сервера в системном трее. Откроется консольное окно, в которое сервер валит свой лог.
Что в итоге?
Мы проделали большую работу. Самое время подвести итог: мы установили свой собственный DNS-сервер, не только защищающий нас от хакерских атак, не только ускоряющий web-серфинг, но еще и дающий возможность забыть о глюках DNS-сервера, установленного у нашего провайдера. С другой стороны, мы получили мощное оружие, позволяющее атаковать других, например, в качестве показательных тестов на проникновение. Только вот делать это, естественно, нельзя. Несмотря на то что приватные локальные сети хороши как раз тем, что большинство из них уже находится вне закона и работает без всякой лицензии, по голове ты рискуешь получить в любой ситуации. Лично мыщъх предпочитает атаковать свои собственные виртуальные сети в порядке чистого эксперимента и ожидает того же от читателей.
WARNING
Информация представлена исключительно в целях ознакомления. За применение ее в противозаконных целей ни автор, ни редакция, ни кто-либо, кроме тебя, ответственности не несет! Не чуди!
WWW
* www.xakep.ru/magazine/xa/068/060/1.asp — подробнейшая статья о реализации атаки ARP-spoofing с примерами