Среди базовых служебных сервисов поддержки локальных сетей Ethernet существенную роль играет поддержка ARP-функций. Address Resolution Protocol (ARP) [1] служит для физического разрешения IP-ссылок.
В сетях Ethernet параметрами настройки рабочих станций (РС) служат, помимо прочих сведений, указания на основные узлы сети: гейт в Интернет, DNS-сервер, почтовые сервера (в настройках почтовых программ) и собственный адрес настраиваемой РС. Все эти настройки исполняются в IP-адресах, условных логических адресах локальной сети. Между тем, реальный обмен Ethernet-пакетами обязан быть осуществлен с указанием технологических (hardware) адресов сетевых адаптеров, или MAC-адресов. Таким образом, перед началом установления каждого соединения каждая РС обязана знать MAC-адрес объекта, с которым необходимо связаться. Получение MAC-адреса интересуемого объекта по известному IP-адресу исполняется с помощью ARP-процедур.
В общем случае, перед началом использования любого соединения РС посылает в сеть ARP-запрос (Request), в котором указывается собственный IP-адрес и интересуемый IP-адрес. Сетевые драйверы автоматически проставляют в блоке Layer формируемого пакета также собственный технологический MAC-адрес запрашивающей станции. В качестве MAC-адреса назначения в этом случае всегда указывается FF...FFh, т.е. формируемый запрос адресован сразу всем объектам локальной сети (broadcasting). На этот запрос отзывается РС, IP которой запрашивается, и формирует ответ в виде ARP-Reply-пакета, в котором содержатся IP-адрес и MAC-адрес запрашивающей ПК, собственные IP- и MAC-адреса (рис. 17).
Однако, стандарт ARP-протокола в этом месте содержит, представляется, некоторую избыточность: в ARP-Reply-пакете собственный MAC-адрес (Hardware Source Address) присутствует дважды, один раз в составе информационной части пакета (Sender Address в Dada Fields), второй раз в виде технологического адреса отправки в оболочке дейтаграммы пакета. Такой дуализм, представляется, теоретически открывает неприятную возможность манипуляций.
Рис. 17. Структура полей ARP-ответа в IPv4-сетях
В самом деле, при построении реализующих алгоритмов установления связи предполагалось, что каждая процедура ARP-запроса будет проводиться после включения ПК единственный раз, а результаты ее – сохраняться в буферном пуле ARP-запросов. В то же время, реальные исследования потоков с помощью разработанных автором средств сплошного круглосуточного аудита [2] показывают, что на практике операционные среды Windows 95/98/Me/NT/2000/XP сбрасывают данные буферного пула ARP чаще, чем необходимо. Более того, ряд стандартных программ (PowerShute, средства дистанционного управления ПК, локальная почта) принудительно формируют ARP-запросы сверх необходимых каждый раз при установлении очередного сеанса связи. Реально буферный пул ARP-запросов использует только механизм доступа в Интернет через Internet Explorer. Вследствие этого, непрерывные ARP-запросы уже известных узлов многократно повторяются, предваряя каждое соединение.
Представим, что в описанных условиях существует сетевой объект S, действующий следующим образом. Получая в качестве обычного члена локальной сети все ARP-запросы от всех РС, он для некоторого ПК A, фиксированного по IP-адресу, имитирует ARP-ответы некоторого ПК B, подставляя несуществующий MAC-адреса в содержательной части ARP-запроса и оставляя собственный MAC-адрес в технологическом заголовке ARP-Reply-пакета. Разумеется, любые дальнейшие попытки компьютера A связаться с компьютером B будут обречены на неудачу, если пакеты от S будут опережать ответы от B: получив от S недействительный MAC-адрес компьютера B, приложения будут адресовать свои запросы несуществующему компьютеру и не смогут установить сеанс связи.
Самое страшное в том, что такое поведение предложенного сетевого объекта S не является формальным нарушением правил работы в сети, поскольку соответствует протоколу, однако открывает возможность произвольно блокировать исполнение нужных сетевых работ на любом избранном ПК ЛВС, что создает потенциальную угрозу хакерских атак на любой ПК этой сети. Интересно отметить, что наличие коммутаторов типа Cisco Catalyst с введенным Secure-режимом не сможет помешать злоумышленнику, использующему атаку указанного типа: корректный MAC-адрес отправителя в Layer-поле позволит скоммутировать фальшивый пакет и направить его точно в цель.
Для успешного проведения описанного варианта атаки следует обеспечить посылку ARP-Reply раньше, чем аналогичный Reply будет выдан сетевым объектом B, которому на самом деле адресован запрос. В этой связи следует отметить, что ARP-функции являются третьим уровнем обобщенной модели ISO-OSI [3]. Хакерская же программа, исполняющая этот род атаки, вовсе не обязана содержать все реализующие компоненты по всем уровням ISO-OSI и, таким образом, ее ответ будет сформирован значительно быстрее, что, собственно, и обеспечит приоритет фальшивого ответа перед истинным.
Обращаясь к возможным конкретным ситуациям, следует особо отметить случай, когда искомый компьютер B является внутренним DNS-сервером. Использование описанной технологии в этом случае может не только отключить атакуемый компьютер A от всех серверов, но и перенаправить его к фальшивому, заранее подготовленному сайту (например, банковскому). В средних и крупных локальных сетях, и в том числе в корпоративной сети ЦЭМИ, DNS-сервер установлен за одним или более маршрутизаторами или коммутаторами, поэтому если хакер на компьютере S находится ближе в коннективном смысле, вероятность успеха много выше: за время коммутации пакетов компьютер S уже успеет послать ответ.
Особо опасным в этом плане представляется то, что большинство существующих
средств системных администраторов (например, команды arp серверов и
рабочих станций) не позволят обнаружить злоумышленника: они покажут только
кортеж
Исследования, проведенные в ЛВС ЦЭМИ РАН, показали, что фальсифицированные указанным образом ARP-пакеты действительно с легкостью проникают через коммутатор, не вызывая своей некорректностью каких-либо мер или регистрации на коммутаторах или иных сетевых устройствах.
(X) Работа выполнена при финансовой поддержке РФФИ, проект N 04-07-90260в