Вот теперь, отрекомендовавшись у Сервера, Клиент может преспокойно отсылать свои пакеты данных, не забывая при этом менять поля ACK, ISSкл+1, ACK(ISSсер+1) и DATA. Разбор полета.
Из предыдущего раздела мы видим, что на этапе установки соединения (когда хосты здороваются) опознавание пакетов осуществляется только по Sequence Number и Acknowledgment Number. Тут сразу становится ясно, что для формирования ложного TCP-пакета нам достаточно знать текущие значения идентификаторов для данного соединения - ISSкл и ISSсер. Усугубляет картину еще и то, что FTP и TELNET вовсе не проверяют подлинность пакетов, полагая, что это сделает за них транспортный уровень. Отсюда вывод: внедрившись в процесс передачи данных на транспортном уровне можно послать пакет с любого хоста в сети Internet не зависимо от потокола (TELNET или FTP) от имени одного из участников данного соединения (например, от имени клиента), и данный пакет будет воспринят как верный! К тому же, постольку поскольку FTP и TELNET не проверяют IP адрес отправителя, то ответ на ложный пакет придет по указанному в нем адресу. Бедный же хозяин пакетов (Клиент) попросту отвалится из-за рассогласования счетчиков (сервер нас уже посчитал).
Дядь, дай десять копеек.
Ну что ж осталось дело за малым. Надо рассчитать ISSкл и ISSсер, а также предсказать динамику их изменения. Это самая сложная задача, но мы трудностей не боимся. (Он сказал "Поехали!" и взмахнул рукой).
Случай 1 (простой).
Предположим, что мы находимся в том же сегменте сети, что и атакуемый хост. Дело за малым. Ставим сниффер, направляем весь трафик через свой хост и смотрим за клиентами, подключающимися к серверу. Конечно же нас интересуют только пакеты со значениями ISSкл и ISSсер (можно даже не интересоваться содержанием поля DATA, т.е. анализировать только заголовки). Итак. Собираем информацию, ищем зависимость, составляем формулу и в путь.
Случай второй (сложный).
Предположим, мы находимся в другом сегменте сети и проанализировать трафик нам не удастся.
Для начала нам надо определить ISN - Initial Sequence Number, т.е. как ОС формирует начальное значение. По документации протокола TCP (RFC 793) рекомендуется увеличивать значение этого 32-битного счетчика на 1 каждые 4 микросекунды, но на практике это далеко не так. Например, в Linux 1.2.8 это значение вычисляется по такому закону:
ISN=mcsec + 1000000 sec, где mcsec - время в микросекундах;
sec - текущее время в секундах, причем отсчет его идет от 1970 года.
в Windows NT 4.0:
ISN=10 msec, где msec - текущее время в миллисекундах.
ОК, На этом и сговоримся. Закон вычисления ISN зависит от времени и представляет функцию
ISN=F(mсsec)
Вид же самой функции F можно получить проанализировав исходный код ядра. Тут Вы сразу закричите: "Да ты гонишь, где же достать исходники Windows?!" Да, трудновато. Придется импровизировать.
Представим ОС "черным яциком" и проведем серию тестов запрос-ответ, причем фиксируя время между запросом и ответом на него, а также время между запросами. (Проще говоря, прикинемся обезьяной с часами, и будем просить соединения у сервера, записывая изменения ISN во времени).
В результате получится такая таблица значений
