Активные атаки на уровне TCP

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

Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии.

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

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

3.2.6.1 Предсказание TCP sequence number - IP-спуфинг

Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software. Англоязычный термин - IP spoofing.

Спуфинг - это вид атаки, при которой хакер внутри организации или за ее пределами выдает себя за санкционированного пользователя. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей - например, для использовании SMTP жертвы для посылки поддельных писем. Для этого всего существуют различные способы. Например, хакер может воспользоваться IP-адресом, находящимся в пределах диапазона санкционированных к применению в рамках Сети данной организации IP-адресов, или авторизованным внешним адресом, в случае если ему разрешен доступ к определенным сетевым ресурсам. Кстати, IP-спуфинг часто используется как составная часть более сложной, комплексной атаки. Типичный пример - атака DDoS, для осуществления которой хакер обычно размещает соответствующую программу на чужом IP-адресе, чтобы скрыть свою истинную личность. Однако чаще всего IP-спуфинг используется для выведения из строя системы при помощи ложных команд, а также для воровства конкретных файлов или, наоборот, внедрения в базы данных ложной информации.

Описание

Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number[3] (назовем его 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 случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм).

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

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

Неплохо также на всякий случай заблаговременно пресечь попытки спуфинга чужих сетей пользователями вашей сети - эта мера может позволить избежать целого ряда неприятностей, если внутри организации объявится злоумышленник или просто компьютерный хулиган. Для этого нужно использовать любой исходящий трафик, если его исходный адрес не относится ко внутреннему диапазону IP-адресов организации. При необходимости данную процедуру может выполнять и провайдер услуг Интернет. Этот тип фильтрации известен под названием "RFC 2827". Опять-таки, как и в случае со сниффингом пакетов, самой лучшей защитой будет сделать атаку абсолютно неэффективной. IP-спуфинг может быть реализован только при условии, что аутентификация пользователей происходит на базе IP-адресов. Поэтому криптошифрование аутентификации делает этот вид атак бесполезными. Впрочем, вместо криптошифрования с тем же успехом можно использовать случайным образом генерируемые одноразовые пароли.

Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы).

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

IP Hijacking

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

Описание

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

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

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

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

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

Ранняя десинхронизация

Соединение десинхронизируется на стадии его установки.

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

· Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента.

· Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN -пакет.

· Клиент игнорирует S-SYN -пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK -пакет от имени клиента.

· Итак, клиент и сервер находятся в состоянии ESTABLISHED (установленный), однако сессия десинхронизирована.

Представим это в виде схемы:

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