Введение в сетевую инфраструктуру фиктивных объектов (перенаправление маршрутов)
Маршрутом сообщения (пакета) называется последовательность узлов компьютерной сети, по которых данное сообщение (пакет) передается от источника до пункта назначения (приемника), а маршрутизацией – выбор маршрута.
Большие компьютерные сети строятся на совокупности сегментов, связанных между собой через узлы сети, которые называют маршрутизаторами. Маршрутизация сообщения осуществляется узлом сети, который выступает источником сообщения, и узлами (а именно, маршрутизаторами), через которые оно проходит. Источник направляет сообщение непосредственно на узел сети, который является пунктом назначения, если тот расположен в одном сегменте с источником; в другом случае сообщение направляется на один из маршрутизаторов, подключенных к данному сегменту. Маршрутизатор действует аналогичным образом, с той только разницей, что он одновременно подключен к двум или более сегментам, возможности выбора у него, как правило, выше.
В компьютерных сетях с маршрутизацией (многосегментных компьютерных сетях, что то же самое) применяется два уровня адресации: первый уровень – логический (или сетевой, согласно модели OSI; в IP-Сетях – это адресация, которая осуществляется согласно протоколу IP); второй – аппаратный (канальный, согласно модели OSI; обусловленный средой передачи (media specific)). На логическом уровне адресация осуществляется в пределах всей сети (т.е. каждый узел сети должен иметь уникальный сетевой адрес); на аппаратном – в пределах одного сегмента (т.е. на этом уровне достаточно, чтобы только в пределах того или иного сегмента адреса узлов были уникальными). Кроме того, узлы сети могут иметь уникальные имена.
Маршрутизация осуществляется согласно баз данных (в IP-Сетях – таблиц) маршрутизации, которые расположены на каждом узле сети, и в которых должна содержаться информация, необходимая для принятия решения, по какому адресу (логический и аппаратный) нужно непосредственно направлять то или иное сообщение.
Можно выделить три задачи, которые решаются при маршрутизации. Первая состоит в определении числового логического (сетевого, например, IP-) адреса, когда известно только имя пункта назначения (name resolution). Вторая – определение сетевого адреса узла, на который нужно непосредственно направить сообщение (именно эту задачу прежде всего имеют в виду, когда говорят о маршрутизации). Третья – определение аппаратного (канального, например, Ethernet-) адреса узла, на который непосредственно направляется сообщение, когда известен только его логический (сетевой) адрес (address resolution). Возьмем на заметку, что эти задачи решаются именно в такой последовательности, в которой они здесь определены (разве что в решении первой задачи может не быть потребности, если имя пункта назначения не применяется).
Перенаправление маршрутов имеет цель или создание условий для перехвата (прослушивание и, возможно, модификация или подмена) информационного обмена (введение в сетевую инфраструктуру фиктивного объекта), или нарушение трудоспособности системы маршрутизации, которая обслуживает объект атаки. В последнем случае маршруты изменяются таким образом, чтобы сделать невозможным нормальное протекание информационного обмена (т.е., чтобы сообщения просто не доходили к пунктам назначения).
В соответствии с задачами, которые решаются при маршрутизации, можно выделить три метода перенаправления маршрутов:
- нарушение функционирования подсистемы, которая отвечает за преобразование имен в сетевые адреса (например, DNS), таким образом, чтобы сетевые адреса для тех или иных имен определялись неправильно (и, таким образом, сообщения направлялись по фиктивным сетевым адресам);
- искажение баз данных (таблиц), в которых содержится информация о маршрутах передачи сообщений, которые направляются на тот или иной сетевой адрес (т.е. о том, по какому сетевому адресу нужно непосредственно направлять те или иные сообщения);
- нарушение функционирования подсистемы, которая отвечает за преобразование сетевых адресов в канальные (например, ARP) таким образом, чтобы канальные адреса для тех или иных сетевых адресов определялись неправильно (и, таким образом, сообщение направлялись по фиктивным канальным адресам).
В последнем случае контролируемый атакующим сниффер должен быть подключен к тому самому сегменту, что и объект атаки (в первых двух случаях это необязательно).
Перенаправление маршрутов может быть осуществлено с применением разнообразнейших механизмов. Типичными является механизмы, которые можно отнести к одной из трех групп:
- использование полномочий пользователя (администратора) объекта атаки, маршрутизатора или сервера имен (возможно с заблаговременным проникновением в соответствующий узел и завладением этих полномочий);
- передача фиктивных управляющих сообщений (навязывание маршрута) (например, ICMP-Сообщение ‘Redirect Message’ в IP-Сетях);
- передача фиктивных ответов на запросы отдаленного поиска (например, на запросы отдаленного поиска по протоколам DNS или ARP).
Перенаправление маршрутов с помощью передачи фиктивных управляющих сообщений
Навязывание маршрута
В распределенных компьютерных системах применяются протоколы управления маршрутизацией, которые разрешают, среди других, отдаленно изменять базы данных маршрутизации. Например, в IP-Сетях используются протоколы RIP и OSPF, что разрешают маршрутизаторам обмениваться информацией, ICMP, что разрешает сообщать узлам о новом маршруте. Пересылая соответствующие сообщения по этим протоколам, атакующий может изменить маршруты информационного обмена объекта атаки удобным для себя образом. Необходимым условием успеха таких действий является преодоление систем идентификации, аутентификации (если они есть) соответствующего протокола.
В протоколах управления маршрутизацией часто применяются недостаточно стойкие процедуры идентификации и аутентификации. Например, протокол ICMP совсем не предусматривает никакой аутентификации, а в качестве идентификатора источника сообщений применяет значение поля ‘Source Address’ IP-Заголовка.
Перенаправление маршрутов с помощью ICMP-Сообщения ‘Redirect Message’.
Точнее, рассмотрим один из видов этого сообщения, а именно — ‘Redirect Datagrams for the Host’ (“Данные перенаправления для узла”).
Это сообщение служит для информирования узла о том, что нужно изменить маршрут к указанному в сообщении узлу. В сообщении содержится IP-Адрес узла, маршрут к которому нужно изменить, и IP-Адрес маршрутизатора, на который непосредственно нужно направлять сообщения для этого узла. Эти сообщения узлам присылают маршрутизаторы, к которым эти узлы подключены. Получив такое сообщение, узел должен соответствующим образом скорректировать свою таблицу маршрутизации.
Нетрудно заметить, что, прислав на узел, который является объектом атаки, такое сообщение от лица соответствующего маршрутизатора, атакующий может несанкционированно изменить маршрут передачи сообщений, которые объект атаки направляет на тот или иной узел. Чтобы такое сообщение было воспринято узлом как действительное, достаточно в поле ‘Source Address’ IP-Заголовка указать IP-адрес соответствующего маршрутизатора. В качестве IP-Адреса нового маршрутизатора в простейшем случае указывается IP-Адрес контролируемого атакующим узла. Нужно только иметь в виду, что этот адрес должен быть в диапазоне IP-Адресов подсети узла, которому направляется сообщение.
Последнее ограничение предопределяет то, что перехватить с помощью такого приема информационный обмен объекта атаки, атакующий практически может только в том случае, если им контролируется какой-нибудь из узлов подсети, к которой принадлежит объект атаки. Перехват информационного обмена может происходить по следующей схеме. Объект атаки направляет сообщение на контролируемый атакующим узел. Этот узел потом (после, возможно модификации или подмены) направляет сообщение на настоящий маршрутизатор. Если он будет делать это от своего имени, то и сообщение в ответ будут приходить к нему. Сообщения, которые поступают в ответ, узел атакующего (снова таки, после, возможно, модификации или подмены) направляет на объект атаки.
Если атакующий не имеет в подсети, к которой принадлежит объект атаки, контролируемого им узла, он может, указав в сообщении ‘Redirect Datagrams for the Host’ в качестве IP-Адреса нового маршрутизатора IP-Адрес любого узла с этой подсети, кроме настоящего маршрутизатора (например, IP-Адрес несуществующего узла), нарушить трудоспособность объекта атаки. В этом случае атакующему наверное придется передавать сообщение ‘Redirect Datagrams for the Host’ из другого сегмента. Чтобы это сообщение было воспринято объектом атаки, атакующему необходимо знать внутренний IP-Адрес маршрутизатора объекта атаки. Простейший вариант действий атакующего в этом случае заключается в простом переборе возможных IP-Адресов. Поскольку IP-Адрес объекта атаки известен, перебирать в большинстве случаев придется не так уж и много адресов; например, если объект атаки принадлежит к подсети класса C, нужно будет перебрать только 253 IP-Адреса.
На практике возможности по применению данного механизма кое в чем ограниченны. Прежде всего, потому, что не все операционные системы реагируют на сообщение ‘Redirect Datagrams for the Host’ (например, Linux с ядром версии 2.0.0 и выше не реагирует, а Windows 95 и Windows NT реагируют). Кроме того, входные пакеты с обратным адресом, который принадлежит внутреннему диапазону адресов, по обыкновению, отфильтровуются межсетевыми экранами, поэтому применить этот механизм межсегментно во многих случаях не удастся.
Перенаправление маршрутов с помощью передачи фиктивных ответов на запросы отдаленного поиска
Узлы компьютерных сетей по обыкновению не имеют всей необходимой для адресации сообщений информации (т.е. часто не знают нужных им сетевых и/или канальных адресов). Для получения этой информации узлы используют специальные алгоритмы отдаленного поиска, которые состоят в передаче в сеть специальных поисковых запросов и в ожидании ответов на них. Примером сообщений, на которых базируются алгоритмы отдаленного поиска, является DNS- и ARP-Запить в IP-сетях.
Существует два типа поисковых запросов: широковещательные и направленные. Широковещательные запросы получают все узлы сети (но только один из них присылает в ответ нужную информацию). Поэтому, чтобы предотвратить перенагрузку сети, такие запросы применяются практически только внутри одного сегмента (если не хватает информации для адресации на канальном уровне модели OSI). Направленный запрос передается на один (или несколько) специально выделенный для обработки подобных запросов узел сети (например, DNS-Сервер) и применяется для межсегментного поиска в том случае, если не хватает информации для адресации на сетевом уровне модели OSI.
Прислав в ответ на поисковый запрос фиктивную информацию, атакующий может перенаправить маршрут передачи тех или иных сообщений нужным ему образом.
Можно выделить два варианта действий атакующего. Согласно первому варианту, атакующий сначала перехватывает поисковый запрос, а потом присылает фиктивный ответ. Согласно второму варианту, атакующий периодически передает на объект атаки раньше времени подготовленный фиктивный ответ без приема поискового запроса.
Для реализации первого варианта действий у атакующего должна быть возможность перехватить поисковый запрос, т.е., ему нужно иметь доступ к каналу передачи поискового запроса. Для реализации второго варианта в этом нет потребности (хотя при этом могут возникать другие проблемы – например, неопределенность момента реализации атаки, возможность выявления атаки еще до ее реализации).
В обоих случаях атакующий может не ждать, пока объект атаки пошлет поисковый запрос, а спровоцировать его на это (если есть такая возможность).
Перенаправление маршрутов с помощью передачи фиктивных ответов на ARP-Запрос
Протокол ARP применяется в Ethernet-Сегментах IP-сетей и предназначен для определения IP-Адресов узлов, подключенных к тому же сегменту, что и источник сообщения.
Для передачи IP-Пакетов через Ethernet-сегменты, кроме IP-Адреса пункта назначения нужно знать еще или Ethernet-Адрес пункта назначения (если этот пункт назначения находится в том же сегменте), или Ethernet-Адрес маршрутизатора (если пункт назначения находится в другом сегменте).
Узел, который должен передать пакет, может не знать нужного ему Ethernet-Адреса. В этом случае, чтобы найти этот адрес, он передает соответствующий запрос по протоколу ARP (ARP-Запрос). ARP-Запросы являются широковещательными. Прислать на него ответ должен тот узел, IP-Адрес которого указан в запросе (и в этом ответе сообщить свой Ethernet-Адрес). После этого узел, который прислал ARP-Запрос, и узел, который на него ответил, соответствующим образом корректируют свои ARP-Таблицы.
Если атакующий контролирует какой-либо из узлов, которые находятся в том же сегменте, что и объект атаки, то, перехватив ARP-Запрос объекта атаки, он может прислать фиктивный ARP-Ответ, в котором объявить владельцем указанной в ARP-Запросе IP-Адрес контролируемого им узла (т.е. прислать в ответ Ethernet-Адрес контролируемого им узла). В результате все сообщения, которые объект атаки будет присылать на этот IP-Адрес, будут присылаться на контролируемый атакующим узел. Типичной является ситуация, когда атакующий выдает свой узел за маршрутизатор – в этом случае он имеет возможность контролировать весь трафик объекта атаки, который выходит за пределы сегмента.
Обратим внимание, что ARP-Запрос получит и настоящий IP-адрес. Это имеет два неприятные для атакующего следствия. Во-первых, на объект атаки будет прислан еще один ответ, и именно его может воспринять объект атаки, а не ответ атакующего. Во-вторых, в ARP-Таблице этого узла появится запись про Ethernet-Адрес (настоящий) объекта атаки, в результате чего сообщение, которые он будет направлять на объект атаки, в самом деле будут присылаться на объект атаки (перехват информационного обмена объекта атаки будет осуществляться по так называемой петлевой схеме).
Первая “неприятность” одолевается путем учета особенностей реакции операционной системы объекта атаки на ситуации, когда на ARP-Запрос приходит больше одного ответа: некоторые операционные системы настоящим считают тот ответ, который пришел раньше, другие — наоборот.
Для преодоления второй “неприятности” может применяться такой прием: после получения ARP-Запроса от объекта атаки, атакующий может сам прислать такой же запрос, в котором обратный IP-Адрес будет IP-адресом объекта атаки, а обратный Ethernet-Адрес – Ethernet-адресом атакующего; в результате узел, который ответит на запрос, скорректирует свою ARP-Таблицу таким образом, что сообщения, которые он будет направлять объекту атаки (на IP-Адрес объекта атаки), будут присылаться атакующему (на Ethernet-Адрес атакующего). Правда, этот прием во многих случаях не удастся применить тайно, поскольку много операционных систем (например, Windows 95, SunOS 5.3) выдают пользователю предупреждения в случае, когда зафиксируют передачу ARP-Запроса с их IP-Адресом и чужим Ethernet-Адресом.
Очевидно, что атакующему приходится ждать, когда объект атаки пришлет соответствующий ARP-Запрос. В случае, когда объект атаки применяет статическую ARP-Таблицу, он может этого не дождаться. Но на практике чаще всего применяются динамические ARP-Таблицы, и ARP-Запросы передаются довольно часто.
Подчеркнем два преимущества такого механизма перед простым прослушиванием сетевого трафика с помощью сниффера:
- данный механизм без ограничений может быть применен в сегментах с коммутацией;
- атакующий получает возможность осуществлять модификацию и/или подмену информации.
Перенаправление маршрутов с помощью передачи фиктивных ответов на DNS-Запрос
Рассмотрим алгоритм отдаленного поиска по протоколу DNS.
Узел передает на IP-Адрес ближайшего DNS-сервера DNS-Запрос, в котором указывает имя сервера, IP-Адрес которого ему нужно знать.
DNS-Сервер, получив такой запрос, ищет ответ в своей базе данных. Если ответ найден, DNS-Сервер передает на узел DNS-Ответ, в котором сообщает нужный IP-Адрес. Если в базе данных нужной информации не оказалось, DNS-Сервер передает DNS-запрос на один из других DNS-Серверов, и описанная в данном пункте процедура повторяется, пока нужный IP-Адрес не будет установлен (или будет не установлен).
Можно предложить четыре варианта перенаправления маршрутов с использованием недостатков алгоритма отдаленного поиска по протоколу DNS:
- перенаправление маршрутов с помощью перехвата DNS-Запроса узла;
- перенаправление маршрутов с помощью направленного шторма фиктивных DNS-Ответов на узел;
- перенаправление маршрутов с помощью перехвата DNS-Запроса DNS-Сервера;
- перенаправление маршрутов с помощью направленного шторма фиктивных DNS-Ответов на DNS-сервер.
В случае успешной реализации каждого из этих вариантов объект атаки (узел, который прислал DNS-Запрос) будет направлять свои сообщения на фиктивный IP-Адрес (который может быть адресом контролируемого атакующим узла). Атакующий, получая эти сообщения, может перенаправлять их по маршруту назначения. Если он будет это делать от своего имени, ответы на эти сообщения будут поступать к нему.
Каждый из вариантов может быть реализован межсегментно (т.е. контролируемые атакующим узлы, которые принимают участие в атаке, не обязательно должны принадлежать к тому же сегменту, что и объект атаки).
Во всех случаях фиктивный DNS-Ответ должен прийти к объекту атаки раньше, чем настоящий. Для гарантии этого на некоторое время атакующий может попробовать нарушить доступность DNS-Сервера (например, с помощью направленного шторма запросов на установление соединения). Или, если атакующий контролирует какой-либо из маршрутизаторов на пути DNS-Запроса, он может просто не пропустить этот запрос по назначению.
Главным недостатком первого и третьего вариантов является то, что здесь атакующему необходимо иметь доступ к каналу передачи DNS-Запросов.
Второй и четвертый варианты могут быть реализованы практически только в том случае, когда для передачи DNS-Запросов применяется протокол UDP, поскольку только в этом случае фиктивные DNS-Ответы могут быть восприняты как действительные (протокол UDP не предусматривает установления виртуального соединения).
В случае успеха атаки по третьему и четвертому вариантам, фиктивная информация попадет в хеш-таблицу DNS-сервера. В результате чего, во-первых, все дальнейшие обращения объекта атаки к серверу, IP-Адрес которого сфальшивлен, будут осуществляться по фиктивному IP-Адресу, во-вторых, фиктивная информация будет распространяться по сети.
В случае первого и второго вариантов, атака может осуществиться только после того, как объект атаки передаст соответствующий запрос. В случае третьего и четвертого вариантов, атакующий может спровоцировать DNS-Сервер на выдачу нужного запроса, если пришлет ему этот запрос сначала сам.
Твитнуть
Статья очень познавательная, но написана, честно говоря, не на обычного пользователя. Было достаточно сложно прочесть все, думал что безопасность и хакерство это простые вещи =(