Sendmail и электронная почта 6 глава

Рис.8. Спуффинг

В данном случае цель злоумышленника – притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также применяется для других целей – например, при использовании SMTP жертвы для посылки поддельных писем.

Спуффинг обычно используется как первая часть плана по несанкционированному получению прав администратора атакуемого компьютера.

Рассмотрим подробнее стандартный план действий злоумышленника X по получению НСД. Предполагается, что в сети существует некоторый доверительный компьютер, пользователи которого имеют расширенный доступ к атакуемому серверу S.

Этапы спуффинга таковы:

1) злоумышленник определяет IP-адрес доверенного компьютера Т;

2) злоумышленник легальным образом устанавливает связь с S (для этого не нужно быть зарегистрированным пользователем, так как аутентификация происходит позднее и на более высоком уровне) и получает начальный номер последовательности "сервер-злоумышленник" (ISNsl). Этот номер необходим для того, чтобы вычислить начальный номер последовательности "сервер-доверенный компьютер" (ISNs2). Дело в том, что начальный номер последовательности носит не случайный характер, а изменяется по строго определенному закону (правда, сейчас для устранения этой слабости, например, в Windows NT или Linux, от генерации начального номера последовательности неслучайным образом уже отказались). Поэтому, зная начальный номер последовательности одного соединения, можно вычислить начальный номер последовательности другого соединения;

3) злоумышленник временно выводит из строя Т (например, направленным штормом запросов), делая это для того, чтобы не дать Т послать S пакет о том, что соединение не было запрошено, иначе S закроет соединение, установленное злоумышленником;

4) злоумышленник инициирует связь с сервером от имени Т (в заголовке IP-пакетов, в поле отправителя сообщения проставляет адрес доверительного компьютера) и вычисляет начальный номер последовательности "сервер-доверительный компьютер" (ISNs2):

X → S: SYN(ISNx), (обратный адрес: Т);

5) сервер S шлет ответный сигнал компьютеру Т с подтверждением ISNx и своим начальным номером ISNs2:

S → Т: SYN(ISNs2), ACK(ISNx);

6) злоумышленник, вычисливший ISNs2, отвечает вместо Т:

X → S: ACK(ISNs2), (обратный адрес:Т);

7) теперь злоумышленник получил одностороннюю связь с выбранным портом сервера и, в принципе, может дистанционно управлять компьютером-целью. Единственное, что ему остается делать, это посылать подтверждения серверу о непреходящих к нему данных, увеличивая каждый раз на единицу значение ISNs2.

Технически более сложным, но и значительно более эффективным, является вариант спуффинга, когда ПК злоумышленника находится на пути трафика между атакуемым сервером и доверительным компьютером. В этом случае злоумышленник помещает свой ПК вблизи одного из участников диалога и перенаправляет маршрут IP-пакетов так, чтобы они шли через его узел. После этого он производит стандартную процедуру спуффинга. в результате которой получает возможность не только посылать данные серверу, но и принимать ответные пакеты.

Спуффинг относится к достаточно изученным способам НСД в систему Стандартными мерами профилактики спуффинга являются: запрещение сервисов, основанных на аутентификации по IP-адресу источника, и применение пакетных фильтров со следующей настройкой – недопущение в сеть пакетов, посланных извне с ПК, имеющего внутренний сетевой адрес.

В качестве защиты можно порекомендовать и настройку маршрутизаторов, при которых они будут фильтровать ICMP-трафик, превышающий некоторую заданную заранее величину (пакетов/ед. времени). Также можно ограничить доступ к ping.

Спуффинг может иметь место как для IP-пакетов, так и для MAC (Media Access).

Новый тип нападений из Internet, названный Web-spoofing [25], также может стать серьезной угрозой ее безопасности. Этот метод атак состоит в подключении пользователя к ложному Web-серверу с целью подмены данных, запрашиваемых браузером (программой просмотра и поиска) пользователя. Web-spoofing может поставить под угрозу целостность данных владельцев Web-узлов.

При Web-spoofing "нападающий" должен сначала заманить пользователя на ложный Web-узел. Это может быть сделано несколькими способами: путем проникновения на существующий узел и подмены URL-адресов (Uniform Resource Locators – универсальных локаторов ресурсов), путем внесения адреса ложного узла в список механизма поиска или путем посылки пользователям по электронной почте приглашения посетить ложный сервер (или на основе атаки "Ложный DNS-сервер", которая будет подробно рассмотрена в разделе 3). Затем адрес ложного узла помещается перед любым URL-адресом, запрашиваемым пользователем, так что адрес http://www.anyurl.com превращается в http://www.spoofserver.com-/http://www.anyurl.com. После этого запрошенная пользователем Web-страница отсылается к нему через ложный сервер, на котором она может быть изменена, а любая информация, которую передает пользователь, может быть перехвачена. В конце концов все другие оперативные ссылки пользователя будут иметь добавленный спереди адрес ложного узла и все URL-запросы будут нарушены. При этом строка состояния внизу экрана и адрес назначения наверху, которые должны были бы подсказать пользователю, что его соединения осуществляются через другой сервер, могут быть изменены с помощью программ на языке Java (Java-апплетов). Даже при непосредственном вводе URL-адреса в строку назначения Java-апплет все равно может вставить в него адрес ложного сервера.

Избавиться от Web-spoofing можно, только пользуясь закладками (Bookmarks) или выбирая опцию Open Location из меню File, так как эти действия вызываются из компонентов браузера, которыми Java-апплет не может манипулировать. Пока полного решения проблемы не существует, поскольку для этого потребовалось бы фундаментально изменить принципы работы WWW и Java-апплетов.

2.4.4.4. Нападения на основе протокола ICMP

Протокол управления сообщениями Internet (Internet Control Message Protocol, ICMP) используется в сетях ТСРЛР как основной метод, при помощи которого посылается важная информация относительно состояния сети. Одной из функций ICMP является удаленное управление таблицей маршрутизации на хостах внутри сегмента интрасети. Динамическое удаленное управление маршрутизацией изначально задумывалось для предотвращения возможной передачи сообщений по неоптимальному маршруту и для повышения отказоустойчивости сети в целом. Предполагалось, что сетевой сегмент может быть подключен к глобальной сети не через один (как это обычно происходит на сегодняшний день), а через несколько маршрутизаторов. В этом случае адресоваться во внешнюю сеть можно через любой из ближайших узлов. Это достаточно удобно, как с точки зрения оптимальности маршрута, так и с точки зрения повышения надежности работы сети (при выходе из строя одного из маршрутизаторов связь с внешним миром возможна через другой маршрутизатор). В обоих случаях (при изменении оптимального маршрута и при выходе из строя маршрутизатора) необходимо изменение таблицы маршрутизации в памяти сетевой ОС. Одно из назначений ICMP состоит именно в динамическом изменении таблицы маршрутизации оконечных сетевых систем.

Основные типы сообщений ICMP - это: эхо-запрос (echo request), "адресат недоступен" (destination unreachable) и пакет переадресации (redirect). Каждое из этих сообщений может быть использовано, чтобы создать хаос в сети.

Эхо-пакет ICMP является основой работы одной из наиболее важных функций ТСРЛР - ping. Администраторы используют его для проверки функционирования некоторого элемента сети. Обычно пакет ping состоит меньше, чем из 100 байт и отправляется через равные промежутки времени и только на очень короткий период. Однако эхо-запрос ICMP может быть сконфигурирован на различную длину - до нескольких тысяч байт. При этом длины посылаемого и возвращаемого пакетов равны.

Имелись многочисленные примеры хостов, "обстреливаемых" очень большими эхо-пакетами ICMP со скоростью в несколько тысяч пакетов в минуту. Это неизбежно засоряло хост-адресат, поскольку сетевой интерфейс вынужден был не только интерпретировать каждый из входящих пакетов, но также формировать соответствующий ответ на него. Это особенно разрушительно для ПК, подключенных к Internet посредством протоколов SLIP (Serial Line Internet Protocol - протокол для телефонной линии связи с последовательно подключенными модемами) или РРР (Point-to-Point Protocol - соединение типа "точка-точка", для передачи данных по выделенным и коммутируемым линиям связи), поскольку приток пакетов не только засоряет их и отнимает системные ресурсы, но буквально начинает заполнять всю доступную им полосу пропускания пакетами ICMP. He имея свободной полосы пропускания для пакетов TCP или UDP (User Datagram Protocol), сетевое соединение обесценивается для пользователя.

Такие атаки называются "Ping flooding". В результате их осуществления атакуемая система тратит вычислительные ресурсы, отвечая на многочисленные эхо-запросы, что приводит к резкому снижению производительности системы и росту загруженности каналов связи.

Неверно сконструированные пакеты переадресации ICMP использовались, чтобы генерировать ложную маршрутизацию между хостами и способствовать перехвату пакетов. ICMP-сообщение о недоступности хоста может использоваться для блокировки соединения хоста со своей сетью или выборочного отключения сессий, подобных Telnet (это пример атаки "отказ в обслуживании") Другие протоколы, типа протокола маршрутизации RIP (Routing Information Protocol), используются для того, чтобы заставить маршрутизаторы и хосты посылать пакеты в неверном направлении.

Сообщение Redirect datagrams for the Network является устаревшим и уже не используется современными сетевыми ОС [18]. Иначе дело обстоит с управляющим сообщением Redirect datagrams for the Host. Здесь нет такого единства в рядах разработчиков различных сетевых ОС. На практике многие из известных ОС игнорируют это сообщение. Например, если в версии Linux 1.2.8 еще была реакция на Redirect datagrams for the Host, то уже в версии Linux 2.0.0 это сообщение игнорировалось. Иначе обстоит дело с ОС Windows 95 и NT. Безответственное отношение разработчиков этих систем к вопросам обеспечения безопасности в данном случае привело к тому же: очевидная опасность Redirect datagrams for the Host была ими проигнорирована и обе системы реагируют на это сообщение, позволяя удаленно изменять таблицу маршрутизации на любом Windows-хосте.

Опасность в реакции сетевой ОС на ICMP-сообшение Redirect datagrams for the Host заключается в несанкционированном изменении маршрутизации на хосте. Анализ механизма идентификации ICMP Redirect-сообщения показывает, что единственным параметром, идентифицирующим это сообщение, является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может и должно передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации источников сообщений. ICMP-сообщения передаются на хост маршрутизатором однонаправленно без создания виртуального соединения (в процессе создания виртуального соединения можно было бы динамически, например, по схеме Диффи-Хелмана, выработать идентифицирующую информацию). А так как изначально ни хост, ни маршрутизатор не имеют заранее определенной статической ключевой информации для идентификации ICMP Redirect-сообщения, то в данном случае у его получателя нет возможности установить подлинность отправителя однонаправленного сообщения ICMP Redirect. Следовательно, ничто не мешает атакующему самому послать ложное ICMP Redirect-сообщение о смене маршрута от имени маршрутизатора.

Это позволяет осуществить ТУА "Внедрение в распределенную сеть ложного объекта путем навязывания ложного маршрута". Для ее осуществления достаточно подготовить ложное ICMP Redirect datagrams for the Host-сообщение, в котором указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного маршрутизатора. Далее это сообщение передается на атакуемый хост от имени маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора.

Имеются два варианта данной УА. В первом случае атакующий находится в том же сегменте интрасети, что и цель атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового маршрутизатора может указать либо свой IP-адрес, либо любой из адресов данной подсети. Это даст атакующему возможность перемаршрутизировать сообщения, направляемые атакованным хостом на определенный IP-адрес, и получить контроль над трафиком между атакуемым хостом и интересующим атакующего сервером. Далее атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от "обманутого" хоста. Рассмотрим функциональную схему осуществления этой УА:

• передача на атакуемый хост ложного сообщения ICMP Redirect datagrams for the Host;

• если пришел ARP-запрос от атакуемого хоста, то посылается ARP-отвег;

• если пришел пакет от атакуемого хоста, то он переправляется на настоящий маршрутизатор:

• если пришел пакет от маршрутизатора, то он переправляется на атакуемый хост:

• при приеме пакета возможно воздействие на информацию по схеме "Ложный объект сети".

В случае осуществления второго варианта УА, атакующий находится в другом сегменте относительно цели атаки. Тогда при передаче на атакуемый хост ложного ICMP Redirect-сообщения сам атакующий уже не сможет получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста. Использование данного варианта УА не позволит атакующему получить доступ к передаваемой по каналу связи информации. Однако в этом случае атака достигает другой цели – нарушения работоспособности хоста. С любого хоста в Internet можно послать подобное сообщение на атакуемый хост и, в случае, если сетевая ОС на данном хосте не проигнорирует данное сообщение, то в дальнейшем нарушится связь между хостом и указанным в ложном ICMP-сообщении сервером. Это произойдет из-за того, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Для того, чтобы провести эту межсегментную атаку необходимо, во-первых, знать внутренний IP-адрес маршрутизатора, к которому подключен хост, во-вторых, выбрать имя сервера, к которому требуется изменить маршругизацию, и, в-третьих, выбрать IP-адрес ложного маршрутизатора из внутренней атакуемой интрасети.

Рассмотрим возможные сложности реализации и способы построения препятствий на пути осуществления данной атаки.

Первая проблема – внутренний IP-адрес маршрутизатора. Узнать его можно только путем простого перебора – получить этот адрес из внешней сети не представляется возможным (утилита traceroute даст только IP-адрес маршрутизатора во внешней сети). Поэтому исходя из того, что большинство хостов в интрасети находятся в подсетях класса С, то для осуществления этой атаки достаточно будет послать 256 ICMP Redirect-сообщений с различными IP-адресами отправителя. Например, пусть хост имеет IP-адрес 194.85.96.197. Тогда исходя из предположения, что он находится в подсети класса С, IP-адрес маршрутизатора, к которому он подключен, будет иметь те же первые три байта: 194.85.96. Хакеру достаточно будет перебрать только последний байт (послать 256 пакетов).

Вторая проблема – выбор имени (или IP-адреса) сервера, к которому будет изменена маршрутизация. Очевидно, что узнать к какому серверу наиболее часто обращается пользователь данного хоста не представляется возможным. Однако ничто не мешает, посылая неограниченное число ICMP Redirect-сообщений, последовательно изменять маршрутизацию к наиболее известным или наиболее часто используемым серверам Internet (поисковые серверы, серверы известных фирм, и т.д.). Дело может сильно упроститься в том случае, если злоумышленник обладает некоторой информацией об атакуемом объекте (например, он является бывшим сотрудником данной фирмы).

Решение третьей проблемы – выбор IP-адреса ложного маршрутизатора из внутренней атакуемой сети – не представляет труда. Используя утилиту ping, атакующий находит любой активный в настоящий момент хост во внутренней интрасети и использует его IP-адрес в качестве адреса ложного маршрутизатора. Но нельзя использовать в качестве адреса ложного маршрутизатора адрес любого хоста во внутренней интрасети. Дело в том, что использовав без предварительной проверки активности любой адрес из внутренней интрасети, можно попасть на неактивный в данный момент хост. Тогда при первом же обращении с атакованного хоста на этот ложный маршрутизатор на него будет передан ARP-запрос и, не получив на него ответа (хост не активен, например, выключен из сети), ОС через небольшой интервал времени (несколько секунд) пошлет вновь данный запрос, но уже на поиск адреса старого маршрутизатора и, получив на него ответ, тут же "вычистит" из таблицы маршрутизации ложный маршрут. Таким образом, задержка в связи будет минимальна и, соответственно, атака нанесет минимальный ущерб.

В том случае, если атакующий в качестве ложного маршрутизатора выберет активный хост, то с ARP-ответом от него проблем не возникнет и связь будет нарушена на значительно более долгий промежуток времени. Время нарушения работоспособности для каждой сетевой ОС свое: для Windows NT 4.0 это время составляет около 10 мин.

Защититься от этой атаки можно только фильтрацией (при помощи МЭ) проходящих ICMP Redirect-сообщений. Другой способ защиты состоит в изменении исходных текстов сетевого ядра ОС с дальнейшей его перекомпиляцией с целью запретить реакцию на ICMP Redirect-сообщение. Но это возможно только в случае свободного распространения исходных текстов ОС (как в случае с ОС Linux или ОС FreeBSD).

Вообще, подобные типы нападения довольно редки, но почти любым типом пакета, существующим в интрасети, можно воспользоваться для атаки.

2.4.4.5. ARP-spoofing или ложный ARP-cepвep

В Internet для нахождения адреса сетевого адаптера используется протокол ARP (Address Resolution Protocol), который позволяет получить взаимно однозначное соответствие IP- и Ethernet-адресов для хостов, находящихся внутри одного сегмента [18]. Это достигается следующим образом: при первом обращении к сетевым ресурсам хост отправляет широковещательный ARP-запрос на Etliernet-адрес FFFFFFFFFFFFh, в котором указывает IP-адрес маршрутизатора и просит сообщить его свой Ethernet-адрес (IP-адрес маршрутизатора – обязательный параметр, который всегда устанавливается вручную при настройке любой сетевой ОС в Internet). Этот широковещательный запрос получат все станции в данном сегменте интрасети, в том числе, и маршрутизатор. Получив данный запрос, маршрутизатор внесет запись о запросившем хосте в свою ARP-таблицу, а, затем, отправит на запросивший хост ARP-ответ, в котором сообщит свой Ethernet-адрес. Полученный в ARP-ответе Ethernet-адрес будет занесен в ARP-таблицу, находящуюся в памяти ОС на запросившем хосте и содержащую записи соответствия 1Р-и Ethernet-адресов для хостов внутри одного сегмента. В случае адресации к хосту, расположенному в той же подсети, также используется ARP-протокол и рассмотренная схема полностью повторяется.

При использовании в распределенной сети алгоритмов удаленного поиска имеется возможность осуществления ТУА, связанной с внесением в систему ложного объекта. Перехватив на атакующем хосте внутри данного сегмента интрасети широковещательный ARP-запрос, можно послать ложный ARP-ответ, в котором объявить себя искомым хостом, (например, маршрутизатором), и, в дальнейшем, активно контролировать и воздействовать на сетевой трафик "обманутого" хоста по схеме "Ложный объект распределенной сети". Необходимо обратить внимание, что данная УА возможна только в сети с широковещательной средой передачи (типа Ethernet) и является внутрисегментной. (Стать ложным ARP-сервером довольно просто. Например, и в ОС Solaris, и в Linux имеется команда агр, которая, кроме всего прочего, как раз и предназначена для этой цели.)

Рассмотрим обобщенную функциональную схему ложного ARP-сервера:

• ожидание ARP-запроса;

• при получении ARP-запроса передача по сети на запросивший хост ложного ARP-ответа, в котором указывается адрес сетевого адаптера атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес, на котором будет принимать пакеты ложный ARP-сервер;

• прием, анализ, воздействие и передача пакетов обмена между взаимодействующими хостами.

Проблемы здесь, в первую очередь, связаны с тем, что даже очень квалифицированные сетевые администраторы и программисты не знают либо не понимают тонкостей работы протокола ARP. При обычной настройке сетевой ОС, поддерживающей протоколы TCP/IP, не требуется настройка модуля ARP. Поэтому протокол ARP остается, как бы скрытым для администраторов. Обратим также внимание на тот факт, что у маршрутизатора тоже имеется ARP-таблица, в которой содержится информация о IP- и соответствующих им Ethernet-адресах всех хостов из сегмента интрасети, подключенного к маршрутизатору. Информация в эту ARP-таблицу на маршрутизаторе обычно заносится не "вручную", а при помощи протокола ARP. Поэтому так легко в одном сегменте IP-сети присвоить чужой IP-адрес: выдать команду сетевой ОС на установку нового IP-адреса, потом обратиться в сеть, а, значит, сразу же будет послан широковещательный ARP-запрос и маршрутизатор, получив этот запрос, автоматически обновит запись в своей ARP-таблице (поставит в соответствии с чужим IP-адресом Ehternet-адрес сетевой карты) – а в результате обладатель данного IP-адреса потеряет связь с внешним миром (все пакеты, адресуемые на его бывший IP-адрес и приходящие на маршрутизатор, будут направляться маршрутизатором на Ethernet-адрес атакующего). Правда, некоторые ОС анализируют все передаваемые по сети широковещательные ARP-запросы. Например, ОС Solaris при получении ARP-запроса с указанным в нем IP-адресом, совпадающим с IP-адресом данной системы, выдает предупреждающее сообщение о том, что хост с таким-то Ethernet-адресом пытается присвоить себе данный IP-адрес.

Теперь вернемся к схеме атаки "ложный ARP-сервер". Из анализа механизмов адресации становится ясно, что, так как поисковый ARP-запрос кроме атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись о IP- и Ethernet-адресе атакуемого хоста. Поэтому, когда на маршрутизатор придет пакет, направленный на IP-адрес атакуемого хоста, то он будет передан не на ложным ARP-сервер, а непосредственно на хост. То есть схема передачи пакетов в этом случае будет следующая:

• атакованный хост передает пакеты на ложный ARP-сервер;

• ложный ARP-сервер передает принятый от атакованного хоста пакет на маршрутизатор;

• маршрутизатор, в случае получения ответа на переданный запрос, передает его непосредственно на атакованный хост, минуя ложный ARP-сервер.

В этом случае, очевидно, что последняя фаза, связанная с "приемом, анализом, воздействием и передачей пакетов обмена" между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте) будет проходить уже не в режиме полного перехвата пакетов ложным сервером, а режиме "полуперехвата" (петлевая схема). В режиме полного перехвата маршрут всех пакетов, отправляемых как в одну, так и в другую стороны, обязательно проходит через ложный сервер; а в режиме "полуперехвата" маршрут пакетов образует петлю.

Несложно придумать несколько способов, позволяющих функционировать ложному ARP-серверу по мостовой схеме перехвата (полный перехват). Например, можно, получив ARP-запрос, самому послать такой же запрос и присвоить себе данный IP-адрес (правда, в этом случае ложному ARP-серверу не удастся остаться незамеченным, так некоторые ОС, перехватив этот, запрос, выдадут предупреждение об использовании их IP-адреса). Другой, значительно более предпочтительный способ: послать ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес, и в дальнейшем вести работу с данного IP-адреса как с маршрутизатором, так и с "обманутыми" хостами.

Различные сетевые ОС по разному используют этот протокол для изменения информации в своих ARP-таблицах. В ОС Linux 1.2.8 при адресации к хосту, находящемуся в одной подсети с данным хостом, в случае отсутствия в ARP-таблице соответствующей записи о Ethernet-адресе, передается ARP-запрос и в дальнейшем при последующих обращениях к данному хосту, посылки ARP-запроса не происходит, В ОС Solaris при каждом новом обращении к хосту происходит передама ARP-запроса и, следовательно, ARP-таблица динамически обновляется. Windows 95 при обращении к хостам с точки зрения использования протокола ARP ведет себя так же, как и Linux, за исключением того, что эта ОС периодически (каждую минуту) посылает ARP-запрос о Ethernet-адресе маршрутизатора. В результате в течение нескольких минут вся интрасеть с Windows 95 с легкостью поражается с помощью ложного ARP-сервера. Что касается NT 4.0, то эксперименты показали – здесь также используется динамически изменяемая ARP-таблица и ARP-запросы о Ethernet-адресе маршрутизатора передаются с периодичностью 5 мин., следовательно, интрасеть поражается чуть дольше.

Причина успеха данной УА кроется не столько в недостатках организации Internet, сколько в широковещательной среде Ethernet. Кроме этого, очевидно, что УА является внутрисегментной и поэтому представляет угрозу для пользователя только в случае нахождения атакующего внутри сегмента интрасети.

2.4.4.6. IP Hijacking

При этой атаке злоумышленник перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP-spoofing.

Необходимые условия атаки – злоумышленник должен иметь доступ к ПК, находящемуся на пути сетевого потока, и обладать достаточными правами на нем для генерации и перехвата IP-пакетов.

Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером Sequence Number и АСК не будут совпадать с ожидаемым значением клиента, и наоборот. В данном случае злоумышленник, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы.

Этот метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку злоумышленник начинает работу уже после того, как произойдет авторизация пользователя.

Есть два способа рассинхронизировать соединение.

1). Ранняя десинхронизацт. Соединение десинхронизируется на стадии его установки:

• злоумышленник прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии;

• дождавшись пакета S-SYN от сервера, он высылает серверу пакет типа RST (сброс), конечно, с корректным Sequence Number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента;

• сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым Sequence Number, после чего посылает клиенту новый S-SYN-пакет;

• клиент игнорирует S-SYN-пакет, однако злоумышленник, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента;

• итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована.

Естественно, 100 % срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные злоумышленником. Для корректной обработки этих ситуаций программа должна быть усложнена.

2). Десинхронизация нулевыми данными. В данном случае злоумышленник прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.

Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии, вызывает так называемую АСК-бурю. Например, пакет выслан сервером, и для клиента он является неприемлемым, поэтому тот отвечает АСК-пакетом. Реакцией на этот неприемлемый уже для сервера пакет становится получение клиентом очередного ответа... И так до бесконечности. Современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку АСК-пакеты не несут данных, повторных передач не происходит и "буря стихает".

Есть несколько способов детектирования данной атаки. Например, можно реализовать TCP/IP-стек, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией Sequence Number/АСК. Однако в данному случае нет страховки от злоумышленника, меняющего и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих АСК-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью.

Если злоумышленник не поддерживает десинхронизированное соединение до его закрытия или не фильтрует вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откроют новую сессию, не обращаясь к администратору.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: