Сетевые атаки

Перехват пакетов на маршрутизаторе

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

Навязывание хосту ложного маршрута с помощью протокола ICMP

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

WinNuke

Hаpяду с обычными данными пеpесылаемыми по TCP соединению cтандаpт пpедустатpивает также пеpедачу сpочных (Out Of Band) данных. Hа уpовне фоpматов пакетов TCP это выpажается в ненулевом urgent pointer. У большинства PC с установленным Windows пpисутствует сетевой пpотокол NetBIOS, котоpый использует для своих нужд 3 IP поpта: 137, 138, 139. Как выяснилось, если соединиться с Windows машиной в 139 поpт и послать туда несколько байт OutOfBand данных, то pеализация NetBIOS-а не зная что делать с этими данными попpосту подвешивает или пеpезагpужает машину. Для Windows 95 это обычно выглядит как синий текстовый экpан, сообщающий об ошибке в дpайвеpе TCP/IP и невозможность pаботы с сетью до пеpезагpузки ОC. NT 4.0 без сеpвис паков пеpезагpужается, NT 4.0 со втоpым сеpвис паком выпадает в синий экpан.

Аналогичная посылка данных в 135 и некоторые другие порты  приводит к значительной загрузке процессора RPCSS.EXE. На NTWS это приводит к существенному  замедлению работы, NTS практически замораживается.

Ложный ARP сервер

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

Предсказание TCP sequence number (IP-spoofing)

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

Установка TCP-соединения происходит в три стадии: клиент выбирает и  передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.

Предположим, что злоумышленник  может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, злоумышленник получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения. Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.

Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A" и оказаться на A, не вводя пароля. Предположим, что злоумышленник расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.

Первая задача злоумышленника - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. После этого злоумышленник может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный). Злоумышленник высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера. Злоумышленник высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B. Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и злоумышленник. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B. Злоумышленник подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK (заметим, что если системы располагаются в одном сегменте, злоумышленнику для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если злоумышленнику повезло и sequence number сервера был угадан верно, соединение считается установленным. Теперь злоумышленник может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd злоумышленнику по электронной почте.

Противодействие: простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети. В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые в находятся в недоступном состоянии. Впрочем, что мешает злоумышленнику имитировать работу системы B ответом на ICMP-пакеты? Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм). Если сеть использует firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC (злоумышленник может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.). Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы). Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству.

Локальная буря

Сделаем небольшое отступление  в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы  поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ  на полученный пакет отправителю  выслается строка знакогенератора) и других (date etc).

В данном случае злоумышленник  может послать единственный UDP-пакет, где в качестве исходного порта  будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й  порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует  ее и вновь отсылает на 19.. и так  до бесконечности.

Бесконечный цикл съедает  ресурсы машин и добавляет  на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться.

Противодействие: в качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресами, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов.

IP Hijacking

Метод является комбинацией 'подслушивания' и IP-spoofing'а.

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

Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.

Существует возможность  ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge 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...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.

ACK-буря

Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ. И так до бесконечности.

К счастью современные  сети строятся по технологиям, когда  допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает".

Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше.

Детектирование  и защита

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

Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью.

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

Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP.

Следует заметить, что метод  также не срабатывает на некоторых  конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.

Обнаружение атак и защита от них