Введение (моя любимая часть)
Хакер не раз рассказывал о протоколе ТСР,
так что повторятся и растекаться по древу я
особенно не буду. Напомню основные
положения: Transmission Control Protocol описывается в RFC
№793 и преимуществом его является
надежность передачи данных от одного хоста
к другому по сети. Это означает, что ТСР
гарантирует надежность передачи данных и
автоматически определит пропущенные или
поврежденные пакеты. Что для нас важно из
его конструкции?
В общем виде заголовок ТСР пакета
выглядит так:
(Более
подробно читай в наших статьях "Протокол TCP")
Программа передает по сети некий буфер
данных, ТСР разбивает данные на сегменты
и дальше упаковывает сегменты в датаграмы.
Из датаграм формируются пакеты и уже
передаются по сети. У получателя происходит
обратный процесс: из пакетов извлекаются
датаграмы, сегменты их датаграм, сегменты
передаются в ТСР стек и там проверяются,
потом собираются и передаются программе.
Sequence numbers
Данные разбиваются на сегменты, которые
отдельными пакетами направляются по сети
получателю. Возможна ситуация, когда пакеты
прибудут в точку назначения не по порядку.
Это поле - 32-битный номер, определяющий
номер сегмента в последовательности, он с
каждым пакетом увеличивается и позволяет
собрать данные в правильном порядке. В
общем смысле значение определяет принадлежит
ли пакет активной сессии или нет.
Window
TCP так же предоставляет хостам механизм
сказать друг другу сколько данных они хотят
получить. Это и есть поле Window, 16 битное число
в ТСР заголовке. Будучи однажды заданным,
оно говорит хосту, что приниматься будет
строго ограниченный объем данных, а
остальные пойдут лесом. Если очередь приема
будет полна, хост может выставить значение
в 0 и таким образом сказать партнеру что
типа мол хорош.
Контрольные биты
SYN, ACK, PSH, URG, RST и FIN, про них уже не раз
говорили, так что повторяться не буду.
Атака TCP reset
Главная идея - сфальсифицировать пакет и
прекратить или скомпрометировать установленное ТСР соединение.
Давай представим, что существует
соединение от хоста А к хосту В. Третий хост
С подделывает пакет в котором указывает
исходный порт и IP адрес хоста А, порт
назначения и адрес хоста В, и текущий sequence
number активного ТСР соединения между А и В.
Хост С устанавливает RTS бит на пакете, так
что когда В получит пакет, он немедленно
прекратит соединение. Это приведет к отказу
от обслуживания до тех пор, пока соединение
не будет восстановлено. На уровне
приложения конечно трудно сказать что
будет, это скорее зависит от самой
программы.
В такой ситуации конечно наиболее уязвимы
приложения и протоколы поддерживающие
продолжительные соединения. Например BGP
(Border Gateway Protocol) от Cisco (см. RFC
1771), так как он основывается на постоянной
ТСР сессии между компьютерами. Сбой в
работе протокола может привести к
“колебанию маршрута” (route flapping),
довольно неприятному событию для
маршрутизатора.
Уязвимость
Paul Watson, обнаруживший уязвимость,
объясняет, что на самом деле такую атаку не
так трудно организовать как казалось ранее.
По предыдущим подсчетам выяснили, что
брутфорс атака на sequence number потребует
перебора всех чисел от 1 до 4.294.967.295. Однако
это вовсе не так. Например, если ТСР стек на
хосте А ограничен window в 16К, стек должен
получать все пакеты в пределах этого "окна"
и атакующему не обязательно посылать
пакеты с установленным RTS во всей
последовательности SN, а ограничится только
каждым возможным окном, так как ТСР примет
любой Sequence number в пределах некоторого
диапазона, заданного величиной окна. Таким образом
нападающему надо перебрать 4.294.967.295 / 16.384 = 262.143
что бы попасть во все доступные окна.
Вероятно и 262 тысячи может показаться
большим числом, однако это не так. Во-первых,
при хорошем коннекте атакующий способен
генерить десятки тысяч пакетов в секунду.
Во-вторых, атаку можно распределить по
нескольким хостам. Например на стандартной
DSL линии можно производить 250 пакетов в
секунду, что исчерпает все варианты за 17
минут, на Т1 это уже 4.730 пакетов и всего лишь
60 секунд.
В примере рассмотрен пример окна в 16К,
однако по RFC это поле 16 битное, что дает до 64К.
Еесли используется полный его размер, то
атакующему достается всего 65.537 пакетов, 4 и
15 секунд соответственно. Причем имейте
ввиду, что это максимальное время, в среднем
оно будет наполовину меньшим (на практике
это 3 минуты и 8 секунд). Что касается
описанных в уязвимости 4 пакетов, то она
возникает только при использовании window scaling,
ТСР расширении (см. RFC
1323) где размер "окна" увеличен с 16 до
30 бит (реализовано, например, и в описанном
выше BGP). В случае максимального размера
атакующему действительно придется послать
только 4 пакета что бы реализовать TCP Reset.
Source Port
Все приведенные выше примеры опираются на
то, что атакующий знает порт назначения и IP
адрес, порт исходный и исходный адрес.
Первые два параметра доступны и известны, IP
адрес получателя так же не составляет труда
узнать - это адрес клиента которого спуфим.
Единственный вопрос - исходный порт.
Например если ОС случайным образом выдает
порт из пула от 1025 до 49.152 (так как например
делает OpenBSD), это увеличит количество
попыток ровно в 48.127 раз, так как надо
будет попробовать подловить номер SN с
каждым номером порта. Хорошая новость в том,
что большинство ОС, включая Linux и Windows, не
используют такой механизм, что сводит на
нет вероятность такой защиты.
SYN атака
Reset атака может быть выполнена и без RST
бита. Вместо него можно установить SYN бит
выполнив точно такую же атаку что была
описана выше. На большинстве реализаций TCP
стека в случае получения повторного SYN
будет выслан RST с sequence number. Если SYN входит в
"окно" текущей сессии, то вместо с RST
ответом сессия будет прекращена, а система
вероятно даже перезагружена.
Blind data injection
Ну и третий вариант развития событий.
Делается все так же как и в предыдущих
случаях - брутфорсом подбираем sequence number,
только вместо посылки пустых SYN или RST
пакетов лепим нормальный пакет с данными.
Соединение в таком случае не прервется, а
вот что у пользователя соберется на
компьютере - совершенно непонятный вопрос.
Передаваемые данные будут катастрофически
повреждены.
