Перехват сессии

admin — Mon, 06 Oct 2008 07:25:21 +0000

После того, как злоумышленник научился обходить аутентификацию, основанную на сетевом адресе (путем подмены этого адреса в пакетах), вопрос обеспечения доверия к сеансу работы хоста с хостом переместился на более высокий уровень. Хост-сервер, например, может производить предварительную идентификацию и аутентификацию хоста-клиента, устанавливающего сеанс работы, и далее учитывать установленную сессию как доверенную.
В стандартном наборе протоколов TCP/IP функцию сессионного протокола выполняет TCP, обеспечивая контроль (идентификацию) сессии путем последовательной нумерации каждого нового пакета уникальными номерами (sequence number и acknowledge number), увеличивающимися на длину переданной информации от пакета к пакету, при этом начальное значение каждого из этих двух номеров генерируется случайно на этапе установления соединения. Если сервер не предпринимает дополнительных мер по идентификации пакетов, то злоумышленнику достаточно знания о текущих номерах сессии, чтобы сформировать свой пакет, в котором адрес отправителя будет адресом клиента, а оба номера пакета будут соответствовать тем, которые он узнал. Доверенному клиенту будет послан пакет разрыва сессии — таким образом злоумышленник сможет продолжать работу в сессии от имени доверенного хоста (перехватить сессию).
Если злоумышленник имеет возможность установить свой хост или свое программное обеспечение на компьютере, расположенном в том же сегменте, что и клиент или сервер, либо на канале передачи данных между ними, то, используя средства пассивного прослушивания сети (сниффер), он может получить информацию о номерах из перехваченных пакетов. Если же такой возможности у него нет, то он может попытаться предугадать эти номера. Дело в том, что ряд реализаций сервисов TCP в операционных системах имеет такие алгоритмы генерации начального случайного числа, что оно может быть предсказано на основе предварительных знаний об уже сформированных пакетах других сессий (которые обычно инициируются самим злоумышленником с этой единственной целью).
Данный пример обычно приводится в литературе в ситуации, когда злоумышленник не имеет возможность непосредственно перехватывать поток сообщений между хостами А и Б. В этом случае злоумышленник инициирует соединение от имени хоста А, выполняет атаку “отказ в обслуживании” на хост А (чтобы тот не смог оповестить хост Б, что на адрес А пришли пакеты о начале сессии), и, предугадывая порядковые номера пакетов, продолжает соединение (точнее, односторонний поток, так как ответные пакеты от Б не вернутся к злоумышленнику) с хостом Б. В нашем случае схема упрощена (злоумышленник может перехватывать пакеты сессии А-Б), но интересна тем, что атака может начаться после того, как пользователь хоста А был аутентифицирован и авторизован на хосте Б, т. е. получил некие расширенные права.
1. Злоумышленник “слушает” трафик А-Б, ожидая авторизации пользователя А на хосте Б.
2. Злоумышленник посылает на хост Б следующий по очереди пакет как продолжение нормальной сессии А-Б. На хост А он посылает сигнал о разрыве соединения, хотя это больше формальность, поскольку хост А далее выводится из работы любой из доступных атак класса Deny of Service (Отказ в обслуживании), например, атакой SYN-FLOOD.
3. Продолжая сессию от имени А, злоумышленник обычно поддерживает хост А в состоянии отказа от обслуживания.
Учитывая то, что даже некоторые межсетевые экраны (из тех, которые вполне могут находиться на службе), уделяя внимание аутентификации клиента при установлении соединения, не контролируют далее аутентичность пакетов, описанная атака — перехват авторизованной сессии, вполне может быть использована.
Злонамеренные воздействия могут быть применены на любом участке информационного потока, и ко всем им следует быть готовым.

Информационная безопасность » Перехват сессии

Перехват сессии