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

Активные атаки на уровне TCP. При данном типе атак крэкер взаимодействует с получателем информации, отправителем иили промежуточными системами, возможно, модифицируя иили фильтруя содержимое TCPIP-пакетов.

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

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

Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется. Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак. 2.4.Предсказание TCP sequence number Данная атака была описана еще Робертом Моррисом Robert T. Morris в A Weakness in the 4.2BSD Unix TCPIP Software Англоязычный термин IP spoofing.

В данном случае цель крэкера - притвориться другой системой, которой, например, доверяет система-жертва в случае использования протокола rloginrsh для беспарольного входа. Метод также используется для других целей например, для использовании SMTP жертвы для посылки поддельных писем. Вспомним, что установка TCP-соединения происходит в три стадии 3-way handshake клиент выбирает и передает серверу sequence number назовем его C-SYN, в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение C-ACK и собственный sequence number сервера S-SYN. Теперь уже клиент должен выслать подтверждение S-ACK. Схематично это можно представить так После этого соединение считается установленным и начинается обмен данными.

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

Это возможно сделать на основе знаний о конкретной реализации TCPIP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет возможно, с нескольких попыткок и с поправкой на скорость соединенияпредсказать sequence number для следующего соединения. Если реализация TCPIP использует специальный алгоритм для определения 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 или отправки etcpasswd крэкеру по электронной почте. Представим это в виде схемы 1 Естественно, 100 срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные крэкером.

Для корректной обработки этих ситуаций программа должна быть усложнена. 2.5.