DNS под прицелом
Ложный DNS - сервер в
сети Internet
Илья
Медведовский
[email protected]
В последнее время в компьютерной прессе все
больше внимания уделяется проблеме нарушения
информационной безопасности в сети Internet. При
этом освещение самой проблемы обычно
преподносится либо в жанре детективного романа
(⌠Хакеры взломали сервер компании ...■) либо -
рекламного проспекта (⌠Firewall - абсолютная защита
Internet■). Очевидно, что в данном случае пропущено
промежуточное звено - достоверная информация о
том, а собственно почему удалось осуществить
этот взлом, то есть какие уязвимости системы
использовал атакующий? Поэтому после
ознакомления с литературой подобного рода
многочисленные пользователи Сети, которые в
подавляющем большинстве своем не являются
специалистами в области информационной
безопасности, начинают справедливо полагать, что
сеть Internet далеко небезопасна (и это
действительно так!) и что оттуда им постоянна
угрожает некая ⌠неведомая■ опасность в лице
⌠всемогущих■ хакеров. Почему неведомая
опасность, спросит читатель? Все дело в том, что в
печати (в отличие от электронной) практически
полностью отсутствуют статьи с описанием
механизмов реализации тех самых ⌠неведомых■
удаленных атак в сети Internet. Именно поэтому с
целью повышения уровня информированности
пользователей Сети об исходящих из нее угрозах и
была задумана данная статья.
Заранее отметая возможные упреки в пропаганде
⌠хакерства■, автор хотел бы заметить, что для
всех уже, видимо, настала пора перестать прятать
голову в песок, как бы не замечая всех угроз,
которые несет в себе Internet, и начать
руководствоваться основным лейтмотивом, который
и подтолкнул автора на статьи и книги: ⌠Кто
предупрежден - тот вооружен■.
Немного о DNS
Как известно для обращения к хостам в сети Internet
используются 32 - разрядные IP - адреса, уникально
идентифицирующие каждый сетевой компьютер в
этой глобальной сети. Однако, для пользователей
использование IP - адресов при обращении к хостам
является не слишком удобным и далеко не самым
наглядным. Поэтому, в самом начале зарождения Internet
для удобства пользователей было принято решение
присвоить всем компьютерам в сети имена.
Использование имен позволяет пользователю лучше
ориентироваться в киберпространстве сети Internet -
куда проще, понятней и наглядней для
пользователя запомнить, например, имя www.ferrari.it, чем
четырехразрядную цепочку IP - адреса.
Использование в Internet мнемонически понятных для
пользователей имен породило проблему
преобразования имен в IP - адреса. Такое
преобразование необходимо, так как на сетевом
уровне адресация пакетов идет не по именам, а по IP
- адресам, следовательно, для непосредственной
адресации сообщений в Internet имена не годятся. На
этапе раннего развития Internet, когда в сеть
было объединено небольшое количество
компьютеров, NIC (Network Information Center) для решения
проблемы преобразования имен в адреса создал
специальный файл (hosts file), в который вносились
имена и соответствующие им IP - адреса всех хостов
в сети. Данный файл регулярно обновлялся и
распространялся по всей сети. Но, по мере
развития Internet число хостов, объединенных в
сеть увеличивалось, и данная схема становилась
все менее и менее работоспособной. Поэтому, была
создана новая система преобразования имен,
позволяющая пользователю в случае отсутствия у
него информации о соответствии имен и IP - адресов
получить необходимые сведения от ближайшего
информационно-поискового сервера (DNS - сервера).
Эта система получила название доменной системы
имен - DNS (Domain Name System).
Для реализации системы DNS был создан
специальный сетевой протокол DNS, а также, в сети
создавались специальные выделенные
информационно-поисковые серверы - DNS-серверы.
Поясним основную задачу, решаемую службой DNS. В
современной сети Internet хост при обращении к
удаленному серверу обычно имеет информацию
только о его имени и не знает его IP - адреса,
который и необходим для непосредственной
адресации. Следовательно, перед хостом возникает
стандартная проблема удаленного поиска: по имени
удаленного хоста найти его IP - адрес. Решением
этой проблемы и занимается служба DNS на базе
протокола DNS.
Рассмотрим DNS - алгоритм удаленного поиска IP -
адреса по имени в сети Internet:
- хост посылает на IP - адрес ближайшего DNS - сервера
(он устанавливается при инсталляции сетевой ОС)
DNS - запрос, в котором указывает имя сервера, IP -
адрес которого необходимо найти;
- DNS - сервер, получив запрос, просматривает свою
базу имен на наличие в ней указанного в запросе
имени. В случае, если имя найдено, а,
следовательно, найден и соответствующий ему IP -
адрес, то на запросивший хост DNS - сервер
отправляет DNS - ответ, в котором указывает искомый
IP - адрес. В случае, если указанное в запросе имя DNS
- сервер не обнаружил в своей базе имен, то DNS -
запрос отсылается DNS - сервером на один из
корневых DNS - серверов, адреса которых содержатся
в файле настроек DNS - сервера root.cache, и описанная в
этом пункте процедура повторяется пока имя не
будет найдено (или не найдено).
Анализируя с точки зрения безопасности
уязвимость этой схемы удаленного поиска с
помощью протокола DNS, можно сделать вывод о
возможности осуществления в сети, использующий
протокол DNS, типовой удаленной атаки "Ложный
объект распределенной ВС" (см. книгу ⌠Атака
через Internet■). Практические изыскания и
критический анализ безопасности службы DNS
позволяют предложить три возможных варианта
удаленной атаки на эту службу.
1. Внедрение в сеть Internet ложного DNS -
сервера путем перехвата DNS - запроса
В данном случае это удаленная атака на базе
стандартной типовой УА, связанной с ожиданием
поискового DNS - запроса. Перед тем, как
рассмотреть алгоритм атаки на службу DNS
необходимо обратить внимание на следующие
тонкости в работе этой службы. Во-первых, по
умолчанию служба DNS функционирует на базе
протокола UDP (хотя возможно и использование
протокола TCP) что, естественно, делает ее менее
защищенной, так как протокол UDP в отличии от TCP
вообще не предусматривает средств идентификации
сообщений. Для того, чтобы перейти от UDP к TCP
администратору DNS - сервера прийдется очень
серьезно изучить документацию (в стандартной
документации на демон named в ОС Linux нет никакого
упоминания о возможном выборе протокола (UDP или
TCP) на котором будет работать DNS - сервер). Кроме
того этот переход несколько замедлит систему,
так как, во-первых, при использовании TCP требуется
создание виртуального соединения и, во-вторых,
конечные сетевые ОС вначале посылают DNS - запрос с
использованием протокола UDP и в том случае, если
им в придет специальный ответ от DNS - сервера, то
тогда сетевая ОС пошлет DNS - запрос с
использованием TCP. Во-вторых, следующая тонкость,
на которую требуется обратить внимание, состоит
в том, что значение поля "порт отправителя" в
UDP - пакете вначале принимает значение ? 1023 и,
затем увеличивается с каждым переданным DNS -
запросом. В-третьих, значение идентификатора (ID)
DNS - запроса ведет себя следующим образом. В
случае передачи DNS - запроса с хоста его значение
зависит от конкретного сетевого приложения,
вырабатывающего DNS - запрос. Эксперименты автора
показали, что в случае передачи запроса из
оболочки командного интерпретатора (SHELL)
операционных систем Linux и Windows '95 (например, ftp
nic.funet.fi) это значение всегда равняется единице. В
том случае, если DNS - запрос передается из Netscape
Navigator, то с каждым новым запросом сам броузер
увеличивает это значение на единицу. В том
случае, если запрос передается непосредственно
DNS - сервером, то сервер увеличивает это значение
идентификатора на единицу с каждым вновь
передаваемым запросом. Все эти тонкости имеют
значение в случае атаки без перехвата DNS -запроса
(п. 2. и 3.).
Для реализации атаки путем перехвата DNS -
запроса атакующему необходимо перехватить DNS -
запрос, извлечь из него номер UDP - порта
отправителя запроса, двухбайтовое значение ID
идентификатора DNS - запроса и искомое имя и, затем,
послать ложный DNS - ответ на извлеченный из DNS -
запроса UDP - порт, в котором указать в качестве
искомого IP - адреса настоящий IP - адрес ложного DNS -
сервера. Это позволит в дальнейшем полностью
перехватить и активно воздействовать по схеме
"Ложный объект РВС" на трафик между
⌠обманутым■ хостом и сервером.
Рассмотрим обобщенную схему работы ложного DNS -
сервера (Рис. 1):
- ожидание DNS - запроса;
- получив DNS - запрос, извлечение из него
необходимых сведений и передача по сети на
запросивший хост ложного DNS - ответа, от имени (с IP
- адреса) настоящего DNS - сервера, в котором
указывается IP - адрес ложного DNS - сервера;
- в случае получения пакета от хоста, изменение в
IP - заголовке пакета его IP - адреса на IP - адрес
ложного DNS - сервера и передача пакета на сервер
(то есть, ложный DNS - сервер ведет работу с
сервером от своего имени);
- в случае получения пакета от сервера, изменение
в IP - заголовке пакета его IP - адреса на IP - адрес
ложного DNS - сервера и передача пакета на хост (для
хоста ложный DNS - сервер и есть настоящий сервер).
Необходимым условием осуществления данного
варианта атаки является перехват DNS - запроса. Это
возможно только в том случае, если атакующий
находится либо на пути основного трафика либо в
сегменте настоящего DNS - сервера. Выполнение
одного из этих условий местонахождения
атакующего в сети делает подобную удаленную
атаку трудно осуществимой на практике (попасть в
сегмент DNS - сервера и тем более в межсегментный
канал связи атакующему скорее всего не удастся).
Однако в случае выполнения этих условий возможно
осуществить межсегментную удаленную атаку
на сеть Internet.
Отметим, что практическая реализация данной
удаленной атаки выявила ряд интересных
особенностей в работе протокола FTP и в механизме
идентификации TCP - пакетов. В случае, если FTP -
клиент на хосте подключился к удаленному FTP -
серверу через ложный DNS - сервер, то оказывалось,
что каждый раз после выдачи пользователем
прикладной команды FTP (например, ls, get, put и т. д.) FTP -
клиент вырабатывал команду PORT, которая состояла
в передаче на FTP - сервер в поле данных TCP - пакета
номера порта и IP - адреса клиентского хоста
(особый смысл в этих действиях трудно найти -
зачем каждый раз передавать на FTP - сервер IP -
адрес клиента)! Это приводило к тому, что если на
ложном DNS - сервере не изменить передаваемый IP -
адрес в поле данных TCP - пакета и передать этот
пакет на FTP - сервер по обыкновенной схеме, то
следующий пакет будет передан FTP - сервером на
хост FTP - клиента, минуя ложный DNS - сервер и, что
самое интересное, этот пакет будет воспринят как
нормальный пакет, и, в дальнейшем, ложный DNS -
сервер потеряет контроль над трафиком между FTP -
сервером и FTP - клиентом! Это связано с тем, что
обычный FTP - сервер не предусматривает никакой
дополнительной идентификации FTP - клиента, а
перекладывает все проблемы идентификации
пакетов и соединения на более низкий уровень -
уровень TCP (транспортный).
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 - запроса от Netscape Navigator (например) имеет
значение близкое к нулю (один запрос - ID
увеличивается на 1).
Поэтому для осуществления данной удаленной
атаки атакующему необходимо выбрать
интересующий его хост (например, TOP.SECRET.COM),
маршрут к которому требуется изменить так, чтобы
он проходил через ложный сервер - хост
атакующего. Это достигается постоянной
передачей (направленным "штормом")
атакующим ложных DNS - ответов на атакуемый хост от
имени настоящего DNS - сервера на соответствующие
UDP - порты. В этих ложных DNS - ответах указывается в
качестве IP - адреса хоста TOP.SECRET.COM IP - адрес
атакующего. Далее атака развивается по следующей
схеме. Как только цель атаки (атакуемый хост)
обратиться по имени к хосту TOP.SECRET.COM, то от
данного хоста в сеть будет передан DNS - запрос,
который атакующий никогда не получит, но этого
ему и не требуется, так как на хост сразу же
поступит постоянно передаваемый ложный DNS -
ответ, который и будет воспринят ОС атакуемого
хоста как настоящий ответ от DNS - сервера. Все!
Атака состоялась и теперь атакуемый хост будет
передавать все пакеты, предназначенные для TOP.SECRET.COM,
на IP - адрес хоста атакующего, который, в свою
очередь, будет переправлять их на TOP.SECRET.COM,
воздействуя на перехваченную информацию по
схеме "Ложный объект распределенной ВС".
Рассмотрим функциональную схему предложенной
удаленной атаки на службу DNS (рис. 2):
постоянная передача атакующим ложных DNS -
ответов на атакуемый хост на различные UDP - порты
и, возможно, с различными ID, от имени (с IP - адреса)
настоящего DNS - сервера с указанием имени
интересующего хоста и его ложного IP - адреса,
которым будет являться IP - адрес ложного сервера -
хоста атакующего;
в случае получения пакета от хоста, изменение в
IP - заголовке пакета его IP - адреса на IP - адрес
атакующего и передача пакета на сервер (то есть,
ложный сервер ведет работу с сервером от своего
имени - со своего IP - адреса);
в случае получения пакета от сервера, изменение
в IP - заголовке пакета его IP - адреса на IP - адрес
ложного сервера и передача пакета на хост (для
хоста ложный сервер и есть настоящий сервер).
Таким образом, реализация данной удаленной
атаки, использующей пробелы в безопасности
службы DNS, позволяет из любой точки сети Internet
нарушить маршрутизацию между двумя заданными
объектами (хостами)! То есть данная удаленная
атака осуществляется межсегментно по отношению
к цели атаки и угрожает безопасности любого
хоста Internet, использующего обычную службу DNS.
3. Внедрение в сеть Internet ложного
сервера путем перехвата DNS - запроса или создания
направленного "шторма" ложных DNS - ответов на
атакуемый DNS - сервер
Из рассмотренной ранее схемы удаленного DNS -
поиска следует, что в том случае, если указанное в
запросе имя DNS - сервер не обнаружил в своей базе
имен, то запрос отсылается сервером на один из
корневых DNS - серверов, адреса которых содержатся
в файле настроек сервера root.cache. То есть, в том
случае, если DNS - сервер не имеет сведений о
запрашиваемом хосте, то он пересылает запрос
далее - а значит, теперь сам DNS - сервер является
инициатором удаленного DNS - поиска. Поэтому ничто
не мешает атакующему, действуя описанными в
предыдущих пунктах методами, перенести свой
удар непосредственно на DNS - сервер. То есть, в
качестве цели атаки теперь будет выступать не
хост, а DNS - сервер и ложные 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 - запроса не представляется возможным. Поэтому,
ничего кроме перебора 216
возможных значений ID предложить что-либо
достаточно сложно. Зато исчезает проблема
перебора портов, так как все DNS - запросы
передаются DNS - сервером на 53 порт.
Следующая проблема, являющаяся условием
осуществления этой удаленной атаки на DNS - сервер
при направленном "шторме" ложных DNS - ответов
состоит в том, что атака будет иметь успех, только
в том случае, если DNS - сервер пошлет запрос на
поиск определенного имени (которое содержится в
ложном DNS - ответе). DNS - сервер посылает этот столь
необходимый и желанный для атакующего запрос в
том случае, если на него прийдет DNS - запрос от
какого-либо хоста на поиск данного имени и этого
имени ни окажется в кэш-таблице DNS - сервера. В
принципе этот запрос может прийти когда угодно и
атакующему может быть прийдется ждать
результатов атаки сколь угодно долго. Однако, ни
что не мешает атакующему, не дожидаясь никого,
самому послать на атакуемый DNS - сервер подобный
DNS - запрос и спровоцировать DNS - сервер на
поиск указанного в запросе имени! Тогда эта атака
с большой вероятностью будет иметь успех
практически сразу же после начала ее
осуществления!
Для примера вспомним недавний скандал (28
октября 1996 года) с одним из московских
провайдеров Internet - компании РОСНЕТ, когда
пользователи данного провайдера при обращении к
обычному информационному WWW - серверу попадали
на, как было сказано в телевизионном репортаже, WWW
- сервер "сомнительного" содержания
(наверное, www.playboy.com).
В связи с абсолютным непониманием случившегося
как журналистами (их можно понять - они не
специалисты в этом вопросе), так и теми, кто
проводил пресс-конференцию (специалистов к
общению с прессой наверное просто не допустили)
информационные сообщения о данном событии были
настолько убоги, что понять что случилось было
толком невозможно. Однако, возможно, то, что
произошло в Москве вполне укладывается в только
что описанную схему удаленной атаки на DNS -
сервер. С одним исключением: вместо адреса хоста
атакующего в кэш-таблицу DNS - сервера был занесен
IP - адрес хоста www.playboy.com.
Однако, видимо, большинство российских
кракеров еще не доросли до столь утонченных
методов сетевого взлома, как атака на DNS. После
того, как был написан предыдущий абзац автору
довелось ознакомится с интервью, которое якобы
дал кракер, осуществивший этот взлом. Из него
следовало, что атака использовала одну из
известных "дыр" в WWW - сервере РОСНЕТа. Это и
позволило атакующему подменить одну ссылку на
другую. Осуществление атак такого типа является
по сути тривиальным и не требует от взломщика
практически никакой квалификации (подчеркиваю -
именно осуществление; совершенно другое дело -
это нахождение этой "дыры"). Высокая
квалификация необходима именно для поиска той
самой уязвимости, используя которую можно
взломать систему. Но, по глубокому убеждению
автора, лица, обнаружившее уязвимость и
осуществившее на ее базе взлом, скорее всего
будут не совпадать, так как именно высокая
квалификация специалиста, обнаружившего
"дыру", не позволит ему причинить ущерб
простым пользователям (Р. Т. Моррис не был
исключением. Просто его червь из-за ошибки в коде
вышел из-под контроля и поэтому пользователям
сети был нанесен определенный ущерб).
В завершение автор хотел бы снова вернуться к
службе DNS и сказать, что, как следует из
предыдущих пунктов, использование в сети Internet
службы удаленного поиска DNS, позволяет
атакующему организовать в Internet удаленную атаку
на любой хост, пользующийся услугами данной
службы, и может пробить серьезную брешь в
безопасности этой и так отнюдь не безопасной
глобальной сети. Напомню, что как указывал S.M.
Bellovin в ставшей почти классической работе
&"Security Problems in the TCP/IP Protocol Suite": "A combined attack
on the domain system and the routing mechanisms can be catastrophic"
(комбинация атаки на доменную систему и
механизмы маршрутизации может привести к
катастрофе).
В заключении автор хотел бы добавить, что с
подробным описанием механизмов реализации
основных видов атак в сети Internet вы сможете
ознакомиться в написанной мной в содружестве с П.
Семьяновым новой книге "Атака через Internet".
Copyright (C) by Илья Медведовский -
эксперт-аналитик
по информационной безопасности
Санкт-Петербургского
Специализированного Центра Защиты
Информации.
