Атака на Internet

1. Ожидание DNS-запроса.

2. Извлечение из полученного сообщения необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа от имени (с IP-адреса) настоящего DNS-сервера с указанием в этом ответе IP-адреса ложного DNS-сервера.

3. В случае получения пакета от хоста – изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего имени).

4. В случае получения пакета от сервера – изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).

Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса, а это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в одном сегменте с DNS-сервером. В результате подобная удаленная атака становится трудноосуществимой на практике (попасть в сегмент DNS-сервера, и тем более в межсегментный канал связи, взломщику, скорее всего, не удастся). Однако при выполнении этих условий можно осуществить межсегментную удаленную атаку на сеть Internet.

Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов (см. раздел «Подмена одного из субъектов TCP-соединения в сети Internet»). В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-сервер в поле данных TCP-пакета номера порта и IP-адреса клиентского хоста (особый смысл в этих действиях трудно найти: зачем каждый раз передавать на FTP-сервер IP-адрес клиента?). Если на ложном DNS-сервере не изменить в поле данных IP-адрес и переслать пакет на FTP-сервер по обыкновенной схеме, то следующий пакет будет передан FTP-сервером на хост FTP-клиента, минуя ложный DNS-сервер. Что самое интересное, такой пакет будет воспринят как нормальный, и в дальнейшем ложный DNS-сервер потеряет контроль над трафиком между FTP-сервером и FTP-клиентом. Это связано с тем, что обычный FTP-сервер не предусматривает никакой дополнительной идентификации FTP-клиента, а перекладывает все проблемы идентификации пакетов и соединений на более низкий уровень – уровень TCP (транспортный).

Направленный шторм ложных DNS-ответов на атакуемый хост

Другой вариант осуществления удаленной атаки – внедрение в сеть Internet ложного сервера путем создания направленного шторма ложных DNS-ответов на атакуемый хост – основан на второй разновидности типовой атаки «ложный объект РВС» (при использовании недостатков алгоритмов удаленного поиска). В этом случае кракер осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса. Другими словами, атакующий создает в сети Internet направленный шторм ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Сетевая ОС хоста предъявляет следующие требования к полученному от DNS-сервера ответу: IP-адрес отправителя ответа должен совпадать с IP-адресом DNS-сервера, а имя в DNS-ответе – с именем в DNS-запросе; кроме того, DNS-ответ следует направить на тот же UDP-порт, с которого было послано сообщение (в данном случае это первая проблема для взломщика), и поле идентификатора запроса (ID) в заголовке DNS-ответа должно содержать то же значение, что и в переданном запросе (а это вторая проблема).

Так как атакующий не имеет возможности перехватить DNS-запрос, основную проблему для него представляет номер UDP-порта, с которого этот запрос был послан. Однако, как было отмечено ранее, номер порта отправителя принимает ограниченный набор значений (> 1023), поэтому атакующему достаточно действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый взгляд, второй проблемой может стать двухбайтовый идентификатор DNS-запроса, но он либо равен единице, либо, в случае DNS-запроса, например от Netscape Navigator, имеет значение близкое к нулю (один запрос – ID увеличивается на 1).

Поэтому для осуществления данной удаленной атаки взломщику необходимо выбрать интересующий его объект (например, сервер top.secret.com), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер – хост кракера. Это достигается постоянной передачей (направленным штормом) ложных DNS-ответов на соответствующие UDP-порты атакуемого объекта. В этих ложных DNS-ответах в качестве IP-адреса хоста top.secret.com указывается IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только атакуемый обратится по имени к хосту top.secret.com, то от данного хоста в сеть будет передан DNS-запрос, который атакующий никогда не получит. Однако кракеру этого и не требуется, так как на объект атаки сразу же поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринято ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь жертва будет передавать все пакеты, предназначенные для top.secret.com, на IP-адрес хоста взломщика, который, в свою очередь, будет переправлять их на top.secret.com, воздействуя на перехваченную информацию по схеме «ложный объект РВС».