TCP-hijacking
Протокол TCP (Transmission Control Protocol) является одним из базовых протоколов транспортного уровня сети Internet. Этот протокол позволяет исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, и является протоколом с установлением логического соединения — виртуального канала. По этому каналу передаются и принимаются пакеты с регистрацией их последовательности, осуществляется управление потоком пакетов, организовывается повторная передача искаженных пакетов, а в конце сеанса канал разрывается. При этом протокол TCP является единственным базовым протоколом из семейства TCP/IP, имеющим дополнительную систему идентификации сообщений и соединения. Именно поэтому протоколы прикладного уровня FTP и TELNET, предоставляющие пользователям удаленный доступ на хосты Internet, реализованы на базе протокола TCP.
Для идентификации TCP-пакета в TCP-заголовке существуют два 32-разрядных идентификатора, которые также играют роль счетчика пакетов. Их названия — Sequence Number и Acknowledgment Number. Также нас будет интересовать поле, называемое Control Bit. Это поле размером 6 бит может содержать следующие командные биты (слева направо):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Далее рассмотрим схему создания TCP-соединения (Рис 1).
Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение:
1. A ->B: SYN, ISSa
Это означает, что в передаваемом A сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).
В отвечает:
2. B ->A: SYN, ACK, ISSb, ACK(ISSa+1)
В ответ на полученный от А запрос В отвечает сообщением, в котором установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В устанавливается свое начальное значение счетчика — ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.
А, завершая рукопожатие (handshake), посылает:
3. A ->B: ACK, ISSa+1, ACK(ISSb+1)
В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Number содержит значение ISSb + 1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake и TCP-соединение между хостами А и В считается установленным.
Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу:
4. A ->B: ACK, ISSa+1, ACK(ISSb+1); DATA
Рис. 1. Схема создания TCP–соединения
Из рассмотренной выше схемы создания TCP-соединения (рис. 1) видно, что единственными идентификаторами TCP-абонентов и TCP-соединения являются два 32-битных параметра Sequence Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему необходимо знать текущие идентификаторы для данного соединения — ISSa и ISSb. Проблема возможной подмены TCP-сообщения становится еще более важной, так как анализ протоколов FTP и TELNET, реализованных на базе протокола TCP, показал, что проблема идентификации FTP и TELNET-пакетов целиком возлагается данными протоколами на транспортный уровень, то есть на TCP. Это означает, что атакующему достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP или TELNET подключение), послать пакет с любого хоста в сети Internet от имени одного из участников данного соединения (например, от имени клиента) и данный пакет будет воспринят как верный! К тому же, так как FTP и TELNET не проверяют IP-адреса отправителей, от которых им приходят сообщения, то, в ответ на полученный ложный пакет, FTP или TELNET-сервер отправит ответ на указанный в ложном пакете настоящий IP-адрес атакующего, то есть атакующий начнет работу с FTP или TELNET сервером со своего IP-адреса, но с правами легально подключившегося пользователя, который, в свою очередь, потеряет связь с сервером из-за рассогласования счетчиков!
Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения. В том случае, когда атакующий находится в одном сегменте с целью атаки или через его сегмент проходит трафик предполагаемого объекта атаки, то задача получения значений ISSa и ISSb является тривиальной и решается путем анализа сетевого трафика. Следовательно, надо четко понимать, что протокол TCP позволяет в принципе защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть в случае нахождения атакующего в других сегментах относительно абонентов TCP-соединения.
Поэтому наибольший интерес для нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах сети. В этом случае задача получения значений ISSa и ISSb не является тривиальной. Далее предлагается следующее решение данной проблемы.
Математическое предсказание начального значения идентификатора TCP-соединения экстраполяцией его предыдущих значений
Первый вопрос, который возникает в данном случае: как сетевая операционная система формирует начальное значение ISSa (так называемый ISN — Initial Sequence Number)? Очевидно, что наилучшим решением с точки зрения безопасности будет генерация этого значения ISN по случайному закону с использованием программного (а лучше аппаратного) генератора псевдослучайных чисел с достаточно большим периодом. В этом случае каждое новое значение ISN не будет зависть от его предыдущего значения, а, следовательно, у атакующего не будет даже теоретической возможности нахождения функционального закона получения ISN.
Однако оказывается, что подобные очевидные правила случайной генерации ISN как для составителей самого описания протокола TCP (RFC 793), так и для разработчиков сетевого ядра различных операционных систем являются далеко не очевидными. Об этом говорят следующие факты. В описании протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32-битного счетчика на 1 каждые 4 микросекунды (?!). А как дело обстоит на практике? Поверьте, плохо! Например, в ранних Berkeley-совместимых ядрах ОС UNIX значение этого счетчика увеличивалось на 128 каждую секунду и на 64 для каждого нового соединения. Анализ исходных текстов ядра ОС Linux 1.2.8. показал, что значение ISN вычисляется данной ОС в зависимости от текущего времени по следующему отнюдь не случайному закону:
(1) ISN = mcsec + sec*1000000, где
mcsec — время в микросекундах;
sec — текущее время в секундах, причем отсчет его идет от 1970 года.
Вы думаете, что в других сетевых ОС лучше? Ошибаетесь! В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду. То есть для Windows NT справедлива следующая формула:
(2) ISN = msec*10, где
msec — время в миллисекундах.
Однако больше всего автора удивил защищенный по классу B1 UNIX, установленный на многопроцессорной миниЭВМ — полнофункциональном файрволе. Эта наиболее защищенная из всех, что встречалась автору, сетевая ОС имеет также простой времязависимый алгоритм генерации начального значения идентификатора TCP — соединения. Как говорится, комментарии здесь излишни. Мало того, что в единственном базовом "защищенном"(?!) протоколе Internet — протоколе TCP, применяется простейший способ идентификации соединения, который в принципе не позволяет гарантировать надежную защиту от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще и сами разработчики сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя простые времязависимые алгоритмы генерации ISN!
Итак, в том случае, если в сетевой операционной системе используется времязависимый алгоритм генерации начального значения идентификатора TCP-соединения, то атакующий получает принципиальную возможность определить с той или иной степенью точности вид функции, описывающей закон получения ISN. Исходя из практических исследований сетевых ОС, а также из общих теоретических соображений можно предложить следующий обобщенный вид функции, описывающий времязависимый закон получения ISN:
(3) ISN = F(mсsec, msec, sec), где
mcsec — время в микросекундах (обычно, в зависимости от аппаратного обеспечения компьютера, минимальной единицей измерения машинного времени является микросекунда — в обычных IBM это так). Этот параметр циклически изменяется за секунду от 0 до 106 — 1
msec — время в миллисекундах. Циклически изменяется за секунду от 0 до 999.
sec — время в секундах. Постоянно увеличивается каждую секунду.
Исходя из формулы (3), а также из того, что микросекунда обычно является минимальной единицей измерения машинного времени в сетевой ОС, можно для удобства аппроксимации свернуть формулу (3) до следующего вида:
(4) ISN = F(mсsec)
Таким образом мы пришли к тому, что в общем случае можно считать, что значение ISN зависит от микросекунд. Данная функция (4) в силу особенностей изменения своих аргументов обычно в сетевых ОС является или кусочнонепрерывной (непрерывной на отдельных интервалах изменения аргумента) или ступенчатой. Например зависимость (1), описывающая закон получения ISN в ОС Linux, в случае приведения ее к виду (4) является кусочнолинейной, а функциональная зависимость (2), справедливая для Windows NT, — дискретной.
Итак, определившись с единицами измерения ISN и обобщенным времязависимым законом его генерации (3)-(4), мы вплотную подошли к проблеме определения вида функциональной зависимости ISN от параметра mcsec для конкретной сетевой ОС. Первый способ получения этой зависимости — анализ исходных текстов ядра операционной системы. Использование данного способа на практике обычно оказывается невозможным из-за отсутствия исходных текстов большинства ОС. Исключение составляют ОС Linux и FreeBSD, поставляемые с исходными текстами ядра.
В связи с этим предлагается другой метод получения закона изменения ISN от параметра mcsec.
В этом случае сетевая ОС рассматривается исследователем как "черный ящик", к которому применяется метод тестирования "запрос-ответ": на исследуемую сетевую ОС передается серия обычных запросов на создание TCP-соединения и принимается соответствующие количество ответов с текущими значениями ISN операционной системы в каждый момент времени. При этом замеряются временные интервалы (в микросекундах) прихода ответов на запросы, то есть за какое время после отправки запроса на него придет ответ и время, прошедшее между запросами. В результате исследователем будет получена следующая таблица дискретных отсчетов ISN и соответствующих им моментов времени в мксек.:
где ISNn — значение ISN, полученное за время tn от начала эксперимента (время начала эксперимента принимается за 0). Аппроксимируя данную таблицу дискретных значений непрерывной функцией одним из известных математических методов (наименьших квадратов, например), получим с погрешностью, сравнимой с погрешностью исходных данных, непрерывную функцию изменения ISN от t, справедливую на данном временном промежутке (от 0 до tn):
(5) ISN(t) = F(t);
Эта формула в общем случае позволяет нам по предыдущему значению ISN, зная функцию изменения ISN от времени, получить следующее значение ISN. Теперь, используя данное равенство (5), атакующий может, получив в ответ на TCP-запрос текущее значение ISN для ОС в данный момент времени, математически предсказать следующее возможное значение ISN через некоторый промежуток времени.
Хотелось бы обратить внимание на следующий важный момент: чем ближе в сети находятся исследователь и тестируемая ОС, тем выше точность получения аппроксимирующей функции, так как в противном случае время за которое запрос дойдет до системы и будет выработан ISN может существенно отличаться из-за задержек в канале связи от времени передачи ответа обратно. При этом погрешность исходных данных будет увеличиваться, а точность экстраполяции — падать.
Заметим, что атакующему вовсе не обязательно проводить подобные исследования с интересующим его удаленным хостом. Достаточно только узнать тип операционной системы на предполагаемой цели атаки и получить в свое распоряжение подобную систему для определения формулы изменения ISN в данной ОС.
Что касается практических результатов, то применение описанной выше методики получения формулы ISN(t) на примере ОС Linux 1.2.8 и Windows NT 4.0 в случае нахождения в одном сегменте с данными ОС позволило определить это 32-битное значение (от 0 до 232) по его предыдущему значению для ОС Windows NT с точностью до 10, а для ОС Linux 1.2.8 с точностью примерно до 100. В следующей таблице приведены снятые в процессе эксперимента с ОС Linux 1.2.8 значения изменения ISN (а не абсолютные значения) за соответствующие промежутки времени.
Рис. 2. Зависимость изменения ISN от времени для Linux 1.2.8
В общем случае определив вид функций для вычисления ISN в операционных системах на сервере и предполагаемом клиенте, атакующий начинает следить за ОС сервера, ожидая подключения предполагаемого клиента. В тот момент времени, когда подключение произошло, атакующий может подсчитать возможный диапазон значений ISN, которыми обменялись при создании TCP-канала данные хосты. Так как атакующий может вычислить значения ISN только приближенно, то ему не избежать подбора. Однако, если не проводить описанный выше анализ, то для перебора всех возможных значений ISSa и ISSb понадобилось бы послать 264 пакетов, что нереально. В случае использования описанного выше анализа в зависимости от полученной степени точности и удаления атакующего от хостов потребуется послать значительно меньшее число пакетов. Например, если удалось вычислить значения ISN на операционных системах с точностью до 100, то атакующему для подмены одного из абонентов TCP-соединения достаточно послать всего 100*100 пакетов.
Далее рассмотрим ставшую уже классической удаленную атаку на r-службу, осуществление которой связано с описанными выше особенностями идентификации TCP-пакетов.
Использование недостатков идентификации абонентов TCP-соединения для атаки на rsh-сервер
В ОС UNIX существует понятие: доверенный хост. Доверенным по отношению к данному хосту называется сетевой компьютер, доступ на который пользователю с данного хоста возможен без его аутентификации и идентификации с помощью r-службы (r — сокращение от англ. "remote" — удаленный). Обычно в ОС UNIX существует файл rhosts, в котором находится список имен и IP-адресов доверенных хостов. Для получения к ним удаленного доступа пользователю необходимо воспользоваться программами, входящими в r-службу (например, rlogin, rsh и.т.д.). В этом случае при использовании r-программ с доверенного хоста пользователю для получения удаленного доступа не требуется проходить стандартную процедуру идентификации и аутентификации, заключающуюся в проверке его логического имени и пароля. Единственной аутентифицирующей пользователя информацией для r-службы является IP-адрес хоста, с которого пользователь осуществляет удаленный r-доступ. Отметим, что все программы из r-службы реализованы на базе протокола TCP. Одной из программ, входящих в r-службу, является rsh, с помощью которой возможно осуществление данной атаки. Программа rsh (remoute shell) позволяет отдавать команды shell удаленному хосту. При этом (что является чрезвычайно важным в данном случае!) для того, чтобы отдать команду, достаточно послать запрос, но необязательно получать на него ответ. При атаке на r-службу вся сложность для атакующего заключается в том, что ему необходимо послать пакет от имени доверенного хоста, то есть в качестве адреса отправителя необходимо указать IP-адрес доверенного хоста. Следовательно, ответный пакет будет отправлен именно на доверенный хост, а не на хост атакующего.
Схема удаленной атаки на rsh-сервер была впервые описана небезызвестным Р.Т. Моррисом-старшим (не младшим!). Она заключается в следующем (схема атаки изображена на Рис. 3.).
Для идентификации TCP-пакета в TCP-заголовке существуют два 32-разрядных идентификатора, которые также играют роль счетчика пакетов. Их названия — Sequence Number и Acknowledgment Number. Также нас будет интересовать поле, называемое Control Bit. Это поле размером 6 бит может содержать следующие командные биты (слева направо):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Далее рассмотрим схему создания TCP-соединения (Рис 1).
Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение:
1. A ->B: SYN, ISSa
Это означает, что в передаваемом A сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).
В отвечает:
2. B ->A: SYN, ACK, ISSb, ACK(ISSa+1)
В ответ на полученный от А запрос В отвечает сообщением, в котором установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В устанавливается свое начальное значение счетчика — ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.
А, завершая рукопожатие (handshake), посылает:
3. A ->B: ACK, ISSa+1, ACK(ISSb+1)
В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Number содержит значение ISSb + 1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake и TCP-соединение между хостами А и В считается установленным.
Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу:
4. A ->B: ACK, ISSa+1, ACK(ISSb+1); DATA
Рис. 1. Схема создания TCP–соединения
Из рассмотренной выше схемы создания TCP-соединения (рис. 1) видно, что единственными идентификаторами TCP-абонентов и TCP-соединения являются два 32-битных параметра Sequence Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему необходимо знать текущие идентификаторы для данного соединения — ISSa и ISSb. Проблема возможной подмены TCP-сообщения становится еще более важной, так как анализ протоколов FTP и TELNET, реализованных на базе протокола TCP, показал, что проблема идентификации FTP и TELNET-пакетов целиком возлагается данными протоколами на транспортный уровень, то есть на TCP. Это означает, что атакующему достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP или TELNET подключение), послать пакет с любого хоста в сети Internet от имени одного из участников данного соединения (например, от имени клиента) и данный пакет будет воспринят как верный! К тому же, так как FTP и TELNET не проверяют IP-адреса отправителей, от которых им приходят сообщения, то, в ответ на полученный ложный пакет, FTP или TELNET-сервер отправит ответ на указанный в ложном пакете настоящий IP-адрес атакующего, то есть атакующий начнет работу с FTP или TELNET сервером со своего IP-адреса, но с правами легально подключившегося пользователя, который, в свою очередь, потеряет связь с сервером из-за рассогласования счетчиков!
Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения. В том случае, когда атакующий находится в одном сегменте с целью атаки или через его сегмент проходит трафик предполагаемого объекта атаки, то задача получения значений ISSa и ISSb является тривиальной и решается путем анализа сетевого трафика. Следовательно, надо четко понимать, что протокол TCP позволяет в принципе защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть в случае нахождения атакующего в других сегментах относительно абонентов TCP-соединения.
Поэтому наибольший интерес для нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах сети. В этом случае задача получения значений ISSa и ISSb не является тривиальной. Далее предлагается следующее решение данной проблемы.
Математическое предсказание начального значения идентификатора TCP-соединения экстраполяцией его предыдущих значений
Первый вопрос, который возникает в данном случае: как сетевая операционная система формирует начальное значение ISSa (так называемый ISN — Initial Sequence Number)? Очевидно, что наилучшим решением с точки зрения безопасности будет генерация этого значения ISN по случайному закону с использованием программного (а лучше аппаратного) генератора псевдослучайных чисел с достаточно большим периодом. В этом случае каждое новое значение ISN не будет зависть от его предыдущего значения, а, следовательно, у атакующего не будет даже теоретической возможности нахождения функционального закона получения ISN.
Однако оказывается, что подобные очевидные правила случайной генерации ISN как для составителей самого описания протокола TCP (RFC 793), так и для разработчиков сетевого ядра различных операционных систем являются далеко не очевидными. Об этом говорят следующие факты. В описании протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32-битного счетчика на 1 каждые 4 микросекунды (?!). А как дело обстоит на практике? Поверьте, плохо! Например, в ранних Berkeley-совместимых ядрах ОС UNIX значение этого счетчика увеличивалось на 128 каждую секунду и на 64 для каждого нового соединения. Анализ исходных текстов ядра ОС Linux 1.2.8. показал, что значение ISN вычисляется данной ОС в зависимости от текущего времени по следующему отнюдь не случайному закону:
(1) ISN = mcsec + sec*1000000, где
mcsec — время в микросекундах;
sec — текущее время в секундах, причем отсчет его идет от 1970 года.
Вы думаете, что в других сетевых ОС лучше? Ошибаетесь! В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду. То есть для Windows NT справедлива следующая формула:
(2) ISN = msec*10, где
msec — время в миллисекундах.
Однако больше всего автора удивил защищенный по классу B1 UNIX, установленный на многопроцессорной миниЭВМ — полнофункциональном файрволе. Эта наиболее защищенная из всех, что встречалась автору, сетевая ОС имеет также простой времязависимый алгоритм генерации начального значения идентификатора TCP — соединения. Как говорится, комментарии здесь излишни. Мало того, что в единственном базовом "защищенном"(?!) протоколе Internet — протоколе TCP, применяется простейший способ идентификации соединения, который в принципе не позволяет гарантировать надежную защиту от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще и сами разработчики сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя простые времязависимые алгоритмы генерации ISN!
Итак, в том случае, если в сетевой операционной системе используется времязависимый алгоритм генерации начального значения идентификатора TCP-соединения, то атакующий получает принципиальную возможность определить с той или иной степенью точности вид функции, описывающей закон получения ISN. Исходя из практических исследований сетевых ОС, а также из общих теоретических соображений можно предложить следующий обобщенный вид функции, описывающий времязависимый закон получения ISN:
(3) ISN = F(mсsec, msec, sec), где
mcsec — время в микросекундах (обычно, в зависимости от аппаратного обеспечения компьютера, минимальной единицей измерения машинного времени является микросекунда — в обычных IBM это так). Этот параметр циклически изменяется за секунду от 0 до 106 — 1
msec — время в миллисекундах. Циклически изменяется за секунду от 0 до 999.
sec — время в секундах. Постоянно увеличивается каждую секунду.
Исходя из формулы (3), а также из того, что микросекунда обычно является минимальной единицей измерения машинного времени в сетевой ОС, можно для удобства аппроксимации свернуть формулу (3) до следующего вида:
(4) ISN = F(mсsec)
Таким образом мы пришли к тому, что в общем случае можно считать, что значение ISN зависит от микросекунд. Данная функция (4) в силу особенностей изменения своих аргументов обычно в сетевых ОС является или кусочнонепрерывной (непрерывной на отдельных интервалах изменения аргумента) или ступенчатой. Например зависимость (1), описывающая закон получения ISN в ОС Linux, в случае приведения ее к виду (4) является кусочнолинейной, а функциональная зависимость (2), справедливая для Windows NT, — дискретной.
Итак, определившись с единицами измерения ISN и обобщенным времязависимым законом его генерации (3)-(4), мы вплотную подошли к проблеме определения вида функциональной зависимости ISN от параметра mcsec для конкретной сетевой ОС. Первый способ получения этой зависимости — анализ исходных текстов ядра операционной системы. Использование данного способа на практике обычно оказывается невозможным из-за отсутствия исходных текстов большинства ОС. Исключение составляют ОС Linux и FreeBSD, поставляемые с исходными текстами ядра.
В связи с этим предлагается другой метод получения закона изменения ISN от параметра mcsec.
В этом случае сетевая ОС рассматривается исследователем как "черный ящик", к которому применяется метод тестирования "запрос-ответ": на исследуемую сетевую ОС передается серия обычных запросов на создание TCP-соединения и принимается соответствующие количество ответов с текущими значениями ISN операционной системы в каждый момент времени. При этом замеряются временные интервалы (в микросекундах) прихода ответов на запросы, то есть за какое время после отправки запроса на него придет ответ и время, прошедшее между запросами. В результате исследователем будет получена следующая таблица дискретных отсчетов ISN и соответствующих им моментов времени в мксек.:
где ISNn — значение ISN, полученное за время tn от начала эксперимента (время начала эксперимента принимается за 0). Аппроксимируя данную таблицу дискретных значений непрерывной функцией одним из известных математических методов (наименьших квадратов, например), получим с погрешностью, сравнимой с погрешностью исходных данных, непрерывную функцию изменения ISN от t, справедливую на данном временном промежутке (от 0 до tn):
(5) ISN(t) = F(t);
Эта формула в общем случае позволяет нам по предыдущему значению ISN, зная функцию изменения ISN от времени, получить следующее значение ISN. Теперь, используя данное равенство (5), атакующий может, получив в ответ на TCP-запрос текущее значение ISN для ОС в данный момент времени, математически предсказать следующее возможное значение ISN через некоторый промежуток времени.
Хотелось бы обратить внимание на следующий важный момент: чем ближе в сети находятся исследователь и тестируемая ОС, тем выше точность получения аппроксимирующей функции, так как в противном случае время за которое запрос дойдет до системы и будет выработан ISN может существенно отличаться из-за задержек в канале связи от времени передачи ответа обратно. При этом погрешность исходных данных будет увеличиваться, а точность экстраполяции — падать.
Заметим, что атакующему вовсе не обязательно проводить подобные исследования с интересующим его удаленным хостом. Достаточно только узнать тип операционной системы на предполагаемой цели атаки и получить в свое распоряжение подобную систему для определения формулы изменения ISN в данной ОС.
Что касается практических результатов, то применение описанной выше методики получения формулы ISN(t) на примере ОС Linux 1.2.8 и Windows NT 4.0 в случае нахождения в одном сегменте с данными ОС позволило определить это 32-битное значение (от 0 до 232) по его предыдущему значению для ОС Windows NT с точностью до 10, а для ОС Linux 1.2.8 с точностью примерно до 100. В следующей таблице приведены снятые в процессе эксперимента с ОС Linux 1.2.8 значения изменения ISN (а не абсолютные значения) за соответствующие промежутки времени.
Следующий график, построенный по значениям из данной таблицы и справедливый для ОС Linux 1.2.8, наглядно показывает линейный характер изменения значения начального идентификатора TCP — соединения ISN на данном временном промежутке (на самом деле зависимость изменения ISN для ОС Linux 1.2.8 носит кусочно-линейный характер) (Рис. 2.)
Рис. 2. Зависимость изменения ISN от времени для Linux 1.2.8
В общем случае определив вид функций для вычисления ISN в операционных системах на сервере и предполагаемом клиенте, атакующий начинает следить за ОС сервера, ожидая подключения предполагаемого клиента. В тот момент времени, когда подключение произошло, атакующий может подсчитать возможный диапазон значений ISN, которыми обменялись при создании TCP-канала данные хосты. Так как атакующий может вычислить значения ISN только приближенно, то ему не избежать подбора. Однако, если не проводить описанный выше анализ, то для перебора всех возможных значений ISSa и ISSb понадобилось бы послать 264 пакетов, что нереально. В случае использования описанного выше анализа в зависимости от полученной степени точности и удаления атакующего от хостов потребуется послать значительно меньшее число пакетов. Например, если удалось вычислить значения ISN на операционных системах с точностью до 100, то атакующему для подмены одного из абонентов TCP-соединения достаточно послать всего 100*100 пакетов.
Далее рассмотрим ставшую уже классической удаленную атаку на r-службу, осуществление которой связано с описанными выше особенностями идентификации TCP-пакетов.
Использование недостатков идентификации абонентов TCP-соединения для атаки на rsh-сервер
В ОС UNIX существует понятие: доверенный хост. Доверенным по отношению к данному хосту называется сетевой компьютер, доступ на который пользователю с данного хоста возможен без его аутентификации и идентификации с помощью r-службы (r — сокращение от англ. "remote" — удаленный). Обычно в ОС UNIX существует файл rhosts, в котором находится список имен и IP-адресов доверенных хостов. Для получения к ним удаленного доступа пользователю необходимо воспользоваться программами, входящими в r-службу (например, rlogin, rsh и.т.д.). В этом случае при использовании r-программ с доверенного хоста пользователю для получения удаленного доступа не требуется проходить стандартную процедуру идентификации и аутентификации, заключающуюся в проверке его логического имени и пароля. Единственной аутентифицирующей пользователя информацией для r-службы является IP-адрес хоста, с которого пользователь осуществляет удаленный r-доступ. Отметим, что все программы из r-службы реализованы на базе протокола TCP. Одной из программ, входящих в r-службу, является rsh, с помощью которой возможно осуществление данной атаки. Программа rsh (remoute shell) позволяет отдавать команды shell удаленному хосту. При этом (что является чрезвычайно важным в данном случае!) для того, чтобы отдать команду, достаточно послать запрос, но необязательно получать на него ответ. При атаке на r-службу вся сложность для атакующего заключается в том, что ему необходимо послать пакет от имени доверенного хоста, то есть в качестве адреса отправителя необходимо указать IP-адрес доверенного хоста. Следовательно, ответный пакет будет отправлен именно на доверенный хост, а не на хост атакующего.
Схема удаленной атаки на rsh-сервер была впервые описана небезызвестным Р.Т. Моррисом-старшим (не младшим!). Она заключается в следующем (схема атаки изображена на Рис. 3.).
Рис. 3. Подмена одного из участников TCP-соединения при атаке на rsh-сервер
Пусть хост А доверяет хосту В. Хост X-Hacker — это станция атакующего.
Вначале атакующий X-Hacker открывает настоящее TCP — соединение с хостом В на любой TCP-порт (mail, echo и.т.д.). В результате X-Hacker получит текущее значение на данный момент времени ISNb. Далее, X-Hacker от имени А посылает на В TCP-запрос на открытие соединения:
1. X-Hacker (A) ->B: SYN, ISSx
Получив этот запрос, В анализирует IP-адрес отправителя и решает, что пакет пришел с хоста А. Следовательно, В в ответ посылает на А новое значение ISNb':
2. B ->A: SYN, ACK, ISNb', ACK(ISSx+1)
X-Hacker никогда не получит это сообщение от В, но, используя предыдущее значение ISNb и схему для получения ISNb' при помощи математического предсказания, может послать на В:
3. X-Hacker (A) ->B: ACK, ISSx+1, ACK (ISNb'+1) Отметим, что для того, чтобы послать этот пакет, возможно потребуется перебрать некоторое количество возможных значений ACK(ISSb' + 1), но не потребуется подбор ISSx + 1, так как этот параметр TCP-соединения был послан с хоста X-Hacker на В в первом пакете.
В случае осуществления данной атаки перед атакующим возникает следующая проблема. Так как X-Hacker посылает пакет (1) на В от имени A, то хост B ответит на A пакетом (2). А, так как хост A не посылал на хост B никакого пакета с запросом, то A, получив ответ от B, перешлет на B пакет с битом RST — закрыть соединение. Атакующего с хоста X-Hacker это естественно не устраивает, поэтому одной из атак, целью которых является нарушение работоспособности системы, X-Hacker должен вывести из строя на некоторое время хост A.
В итоге rsh-сервер на хосте В считает, что к нему подключился пользователь с доверенного хоста А, а на самом деле это атакующий с хоста X-Hacker. И хотя X-Hacker никогда не сможет получить пакеты с хоста В, но он сможет выполнять на нем команды (r-команды).
Илья Медведовский
Сетевые решения. Статья была опубликована в номере 04 за 2001 год в рубрике save ass…
