Учебное пособие Ставрополь сф мггу им. М. А. Шолохова 2009
 Скачать 5.26 Mb.
|
|
16.3 Ложный DNS-сервер Как известно, для обращения к хостам в сети Internet используются 32- разрядные IP-адреса, уникально идентифицирующие каждый сетевой компьютер в этой глобальной сети. Однако, для пользователей применение IP-адресов при обращении к хостам является не слишком удобным и далеко не самым наглядным. Использование в Internet породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. Для решения задачи преобразования мнемонически понятных для пользователей имен в IP-адреса была создана система преобразования имен, позволяющая хосту в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера – DNS (Domain Name System)-сервера. Основной задачей, решаемой службой DNS является поиск по имени удаленного хоста его IP-адреса, который и необходим для непосредственной адресации. Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet. - Хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти. - DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней указанного в запросе имени. В случае, если имя найдено, а, следовательно, найден и соответствующий ему IP-адрес, то на запросивший хост DNS-сервер отправляет DNS-ответ, в котором указывает искомый IP-адрес. - В случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов и описанная в этом пункте процедура повторяется, пока имя не будет найдено (или не найдено). Анализируя с точки зрения безопасности уязвимость этой схемы удаленного поиска с помощью протокола DNS, можно сделать вывод о возможности осуществления в сети, использующей протокол DNS, типовой удаленной атаки «Ложный объект РВС». Практические изыскания и 218 критический анализ безопасности службы DNS позволяют предложить три возможных варианта удаленной атаки на эту службу. 16.3.1 Внедрение в сеть Internet ложного DNS-сервера путем перехвата DNS-запроса Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS- запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме «Ложный объект РВС». Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 16.4): - ожидание DNS-запроса; - извлечение из полученного запроса необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера; - в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего имени); - в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер). Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике. Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet. 219 Рис. 16.4 а - Фаза ожидания атакующим DNS-запроса (он находится на ХА1, либо на ХА2) Рис. 16.4 б - Фаза передачи атакующим ложного DNS-ответа Рис. 16.4 в - Фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере Рис. 16.4 - Функциональная схема ложного DNS-сервера 220 16.3.2 Внедрение в сеть Internet ложного сервера путем создания направленного «шторма» ложных DNS-ответов на атакуемый хост Другой вариант осуществления удаленной атаки, направленной на службу DNS, основан на второй разновидности типовой УА «Ложный объект РВС» (при использовании недостатков алгоритмов удаленного поиска). В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса! Другими словами, атакующий создает в сети Internet направленный «шторм» ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Критериями, предъявляемыми сетевой ОС хоста к полученному от DNS- сервера ответу, является: - совпадение IP-адреса отправителя ответа с IP-адресом DNS-сервера; - DNS-ответ должен содержать то же имя, что и в DNS-запросе, - DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос (в данном случае это первая проблема для атакующего), - в DNS-ответе поле идентификатора запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе (а это вторая проблема). В данном случае, так как атакующий не имеет возможности перехватить DNS-запрос, то основную проблему для него представляет номер UDP-порта, с которого был послан запрос. Однако, как было отмечено ранее, номер порта отправителя принимает ограниченный набор значений (≥ 1023), поэтому атакующему достаточно действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый взгляд, второй проблемой может быть двухбайтовый идентификатор DNS- запроса, но, в связи с особенностями функционироания протокола DNS он либо равен единице, либо в случае DNS-запроса от Netscape Navigator (например) имеет значение близкое к нулю (один запрос - ID увеличивается на 1). Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (например, top.secret.com), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер - хост атакующего. Это достигается постоянной передачей (направленным «штормом») атакующим ложных DNS-ответов на атакуемый хост от имени настоящего DNS-сервера на соответствующие UDP-порты. В этих ложных DNS-ответах указывается в качестве IP-адреса хоста top.secret.com IP-адрес атакующего. 221 Рис. 16.5 а - Атакующий создает направленный «шторм» ложных DNS- ответов на Хост 1 Рис. 16.5 б - Хост 1 посылает DNS-запрос и немедленно получает ложный DNS-ответ Рис. 16.5 в - Фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере Рис. 16.5 - Внедрение в Internet ложного сервера путем создания направленного «шторма» ложных DNS-ответов на атакуемый хост Далее атака развивается по следующей схеме. Как только цель атаки (атакуемый хост) обратится по имени к хосту top.secret.com, то от данного 222 хоста в сеть будет передан DNS-запрос, который атакующий никогда не получит, но этого ему и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь атакуемый хост будет передавать все пакеты, предназначенные для top.secret.com, на IP-адрес хоста атакующего, который, в свою очередь, будет переправлять их на top.secret.com, воздействуя на перехваченную информацию по схеме «Ложный объект РВС». Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS: - постоянная передача атакующим ложных DNS-ответов на атакуемый хост на различные UDP-порты и, возможно, с различными ID, от имени (с IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера - хоста атакующего; - в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть ложный сервер ведет работу с сервером от своего имени - со своего IP-адреса); - в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий сервер). Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки сети Internet нарушить маршрутизацию между двумя заданными объектами (хостами)! Данная удаленная атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS. 16.3.3 Внедрение в сеть Internet ложного сервера путем перехвата DNS- запроса или создания направленного «шторма» ложных DNS-ответов на атакуемый DNS-сервер Из рассмотренной схемы удаленного DNS-поиска следует, что в том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache. Итак, в случае, если DNS-сервер не имеет сведений о запрашиваемом хосте, то он сам, пересылая запрос далее, является инициатором удаленного DNS-поиска. Поэтому ничто не мешает атакующему, действуя описанными в предыдущих пунктах методами, перенести свою атаку непосредственно на DNS-сервер. В качестве цели атаки теперь будет выступать не хост, а DNS- 223 сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер. При этом важно учитывать следующую особенность работы DNS- сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера, а именно, если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу в память. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимые сведения уже находятся у него в кэш-таблице. Из анализа только что подробно описанной схемы удаленного DNS- поиска становится очевидно, что в том случае, если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае «шторма» ложных ответов будет вести их постоянную передачу), то в кэш- таблице сервера появится соответствующая запись с ложными сведениями и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме «Ложный объект РВС». И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уровней, а, следовательно, все больше хостов в Internet будут дезинформированы и атакованы! В том случае, если атакующий не может перехватить DNS-запрос от DNS-сервера, то для реализации атаки ему необходим «шторм» ложных DNS-ответов, направленный на DNS-сервер. При этом возникает следующая проблема, отличная от проблемы подбора портов в случае атаки, направленной на хост. Как уже отмечалось ранее, DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Узнать атакующему это текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 2 16 возможных значений ID, достаточно сложно. Зато исчезает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на 53 порт. Следующая проблема, являющаяся условием осуществления этой удаленной атаки на DNS-сервер при направленном «шторме» ложных DNS- ответов, состоит в том, что атака будет иметь успех только в случае, если DNS-сервер пошлет запрос на поиск имени, которое содержится в ложном DNS-ответе. DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос в том и только том случае, когда на него приходит DNS- 224 запрос от какого-либо хоста на поиск данного имени и этого имени не оказывается в кэш-таблице DNS-сервера. В принципе, этот запрос может возникнуть когда угодно, и атакующему придется ждать результатов атаки неопределенное время. Однако, ничто не мешает атакующему, не дожидаясь никого, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать DNS-сервер на поиск указанного в запросе имени. Тогда эта атака с большой вероятностью будет иметь успех практически сразу же после начала ее осуществления. Для примера вспомним скандал (28 октября 1996 года) с одним из московских провайдеров Internet - компанией РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW- серверу попадали, как было сказано в телевизионном репортаже, WWW- сервер «сомнительного» содержания. В связи с абсолютным непониманием случившегося как журналистами (их можно понять - они не специалисты в этом вопросе), так и теми, кто проводил пресс-конференцию (специалистов к общению с прессой, наверное, просто не допустили) информационные сообщения о данном событии были настолько убоги, что понять, что случилось, было толком невозможно. Тем не менее, этот инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS- сервера был занесен IP-адрес хоста www.playboy.com. Рис. 16.6 а - Фаза ожидания атакующим DNS-запроса от DNS-сервера (для ускорения атакующий генерирует необходимый DNS-запрос) Рис. 16.6 б - Фаза передачи атакующим ложного DNS-ответа на DNS-сервер 1 Рис. 16.6 - Внедрение в Internet ложного сервера путем перехвата DNS-запроса от DNS-сервера 225 Рис16.7 а - Атакующий создает направленный «шторм» ложных DNS-ответов от имени одного из корневых DNS-серверов и при этом провоцирует атакуемый DNS-сервер, посылая DNS-запрос Рис16.7 б - DNS-сервер передает DNS-запрос на корневой DNS-сервер и немедленно получает ложный DNS-ответ от атакующего Рис. 16.7 - Внедрение в Internet ложного сервера путем создания направленного «шторма» ложных DNS-ответов на атакуемый DNS-сервер Использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой и так отнюдь не безопасной глобальной сети. 226 16.4 Навязывание хосту ложного маршрута с использованием протокола ICMP с целью создания в сети Internet ложного маршрутизатора В сети Internet используется управляющий протокол ICMP, одной из функций которого является удаленное управление маршрутизацией на хостах внутри сегмента сети. Удаленное управление маршрутизацией необходимо для предотвращения возможной передачи сообщений по неоптимальному маршруту. В сети Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего ICMP- сообщения: Redirect Message. Исследование протокола ICMP показало, что сообщение Redirect бывает двух типов: - Первый тип сообщения носит название Redirect Net и уведомляет хост о необходимости смены адреса маршрутизатора, то есть default- маршрута. - Второй тип - Redirect Host - информирует хост о необходимости создания нового маршрута к указанной в сообщении системе и внесения ее в таблицу маршрутизации. Для этого в сообщении указывается IP-адрес хоста, для которого необходима смена маршрута (адрес будет занесен в поле Destination), и новый IP-адрес маршрутизатора, на который необходимо направлять пакеты, адресованные данному хосту (этот адрес заносится в поле Gateway). Необходимо обратить внимание на важное ограничение, накладываемое на IP-адрес нового маршрутизатора: он должен быть в пределах адресов данной подсети! Что касается управляющего сообщения ICMP Redirect Host, то единственным идентифицирующим его параметром является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации источников сообщений. Таким образом, ICMP-сообщения передаются на хост маршрутизатором однонаправлено, без создания виртуального соединения. Следовательно, ничто не мешает атакующему послать ложное ICMP- сообщение о смене маршрута от имени маршрутизатора. Приведенные выше факты позволяют осуществить типовую удаленную атаку «Внедрение в РВС ложного объекта путем навязывания ложного маршрута”. Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP Redirect Host сообщение, в котором указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного маршрутизатора. Далее это сообщение передается на атакуемый хост от имени маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора. В принципе, можно предложить два варианта данной удаленной атаки. 227 В первом случае атакующий находится в том же сегменте сети, что и цель атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового маршрутизатора может указать либо свой IP-адрес, либо любой из адресов данной подсети. Это даст атакующему возможность изменить маршрут передачи сообщений, направляемых атакованным хостом на определенный IP-адрес, и получить контроль над трафиком между атакуемым хостом и интересующим атакующего сервером. После этого атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от «обманутого» хоста. Рассмотрим функциональную схему осуществления этой удаленной атаки (рис 16.8): - передача на атакуемый хост ложного ICMP Redirect Host сообщения; - отправление ARP-ответа в случае, если пришел ARP-запpос от атакуемого хоста; - перенаправление пакетов от атакуемого хоста на настоящий маршрутизатор; - перенаправление пакетов от маршрутизатора на атакуемый хост; - при приеме пакета возможно воздействие на информацию по схеме «Ложный объект РВС». Рис16.8 а - Фаза передачи ложного ICMP Redirect сообщения от имени маршрутизатора. Рис16.8 б - Фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере Рис. 16.8 -Внутрисегментное навязывание хосту ложного маршрута при использовании протокола ICMP 228 В случае осуществления второго варианта удаленной атаки атакующий находится в другом сегменте относительно цели атаки. Тогда, в случае передачи на атакуемый хост ложного ICMP Redirect сообщения, сам атакующий уже не сможет получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста, поэтому использование данного варианта этой удаленной атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации. Однако, в этом случае атака достигает другой цели: нарушается работоспособность хоста. Атакующий с любого хоста в Internet может послать подобное сообщение на атакуемый хост и в случае, если сетевая ОС на данном хосте не проигнорирует данное сообщение, то связь между данным хостом и указанным в ложном ICMP-сообщении сервером будет нарушена. Это произойдет из-за того, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Схема этой атаки приведена на рис. 16.9. Рис. 16.9 а - Передача атакующим на хост 1 ложного ICMP Redirect сообщения от имени маршрутизатора 1 Рис. 16.9 б - Дезинформация хоста 1. Его таблица маршрутизации содержит информацию о ложном маршруте к хосту top.secret.com Рис. 16.9 - Межсегментное навязывание хосту ложного маршрута при использовании протокола ICMP, приводящее к отказу в обслуживании Оба варианта рассмотренной удаленной атаки удается осуществить (как межсегментно, так и внутрисегментно) на ОС Linux 1.2.8, Windows 95 и Windows NT 4.0. Остальные сетевые ОС (Linux 2.0.0 и защищенный по классу B1 UNIX), игнорировали данное ICMP Redirect сообщение (что, не |