В данной статье рассматривается, каким образом поток траффика, взятый из общей очереди пакетов, может быть использован как сторонний канал, через который нарушитель может получить конфиденциальную информацию.
TCP-сессия защищена тремя неизвестными нарушителю числами: 16-битным номером порта (новый для каждой сессии) и двумя 32-битными последовательными числами (по одному с каждой стороны коммуникации). Прочие поля, такие как IP адреса конечных точек и порт сервера, легко определить в большинстве случаев. Каждый TCP сегмент, отправленный в рамках установленного подключения, использует все три секретных числа. Для того чтобы сегмент был корректно принят, он должен содержать корректный номер порта, его номер последовательности должен быть в рамках окна получателя, а также число принятия должен быть приемлемым. Согласно действующим рекомендациям, номер порта должен быть случайным числом в диапазоне 1025-65535, а число принятия является подходящим, только если оно равно следующему отправляемому октету или меньше максимального размера окна отправителя. Если данные рекомендации выполняются, нарушителю потребуется
попыток для генерации приемлемого сегмента. Если предположить, что оба окна содержат по 65 кБ, потребуется около 248 попыток. Если конечная точка строго следует правилам проверки RST, когда в RST сегменте номер последовательности должен быть равен следующему ожидаемому номеру последовательности, нарушителю потребуется попыток, чтобы вслепую переустановить соединение, что также подразумевает 248 вариантов. Используемые числа являются достаточно большими, чтобы в большинстве случаев провести атаку «вслепую» неэффективной. Для того чтобы подобрать только один сегмент, нарушителю потребуется 500 часов при скорости 100Гб в секунду. И даже если сегмент будет принят, вероятность того, что он совпадет с началом окна, равняется . Таким образом, успешная атака «вслепую» может скомпрометировать подключение, но шансов на успех достаточно мало.Риск принятия поддельного TCP сегмента в качестве действительного имеет место, и его изучают. Выполняя определенные рекомендации можно не учитывать риск ответа на поддельные сегменты. Уровень TCP может либо сбросить данный сегмент, либо принять его (с ACK или RST). Данное действие различается в зависимости от реализации протокола. Впервые оно было упомянуто в разделе «обработка событий» RFC 793 [1], но используемые на сегодняшний день системы (а особенно межсетевые экраны) не следуют RFC полностью. Вместо этого в них реализуются функции фильтрации, как в примере, описанном в [2]. Эти новые правила созданы для того, чтобы сохранять совместимость между различными реализациями протокола.
В каждой конкретной реализации TCP перспектива ответа на отклоненный сегмент зависит от одного из закрытых значений сегмента. Если нарушитель узнает его и получит ответ на поддельный сегмент, TCP сессия может быть скомпрометирована. Нарушитель может определить, удовлетворяет ли закрытое значение определенным критериям (порт был выбран верно, число последовательности – в рамках окна, число принятия было подходящим). Неизвестные нарушителю значение могут быть найдены в несколько шагов, ни один из которых не требует больших ресурсов.
Перегрузка общей для нарушителя и целевого TCP потока очереди является, по сути, сторонним каналом, через который нарушитель может определить, был ли ответ на поддельный сегмент. Определение нагрузки, вызываемой одним пакетом, на практике может оказаться довольно сложной задачей, но нарушитель может отправить последовательность сегментов. Если будут получены ответы на все сегменты, будет зафиксировано резкое увеличение трафика (в худшем варианте – переполнение очереди). Данная методика представлена на рисунке 1.
Атака, описанная в данной работе, имеет много общих моментов со всем известной техникой, эксплуатирующей слабости в реализации механизма генерации IP ID. Некоторые системы, для предотвращения данной атаки, увеличивают длину поля ID у каждого последующего IP пакета. Это создает сторонний канал, позволяющий определить, отправлен ли с хоста пакет в качестве ответа на входящий трафик. Этот канал может быть использован для сканирования портов или для выполнения атак на установленное TCP соединение [8]. В отличие от техники, описанной в данной работе, для эксплуатации IP ID канала нарушитель должен установить легитимный, двунаправленный канал коммуникации с атакуемым хостом. Современные межсетевые экраны, как правило, запрещают подобные подключения к клиентским машинам. Представленная вам работа сфокусирована на компрометации TCP сессий, но описанная техника может быть также использована для сканирования портов, аналог чего представлен в работе [7].
Рисунок 1. «Высокоуровневая схема атаки. Нарушитель посылает запрос жертве в форме последовательности поддельных сегментов. Если ответ на запрос положительный, жертва отвечает последовательностью сегментов, адресованных ее пиру. В то же время нарушитель пингует его, используя ту же очередь, что и сегменты жертвы. Увеличение времени ответа сигнализирует о позитивном ответе на запросы».
Авторы работы [9] показали, что перегрузка TCP может быть использована нарушителем для повышения эффективности его TCP-подключения за счет других. Применимость данной методики для проведения атаки «отказ в обслуживании» рассмотрена в работе [10]. При попытке проведения авторам удалось существенно снизить пропускную способность при TCP-соединении. В работе, посвященной оценке безопасности TCP [5], объясняется, что данная атака может быть проведена «вслепую» человеком, не имеющим возможность подменять траффик между хостами. Контроль перегрузки TCP поддерживается ACK сегментами, поэтому уровень TCP легко можно обойти с помощью генерации ACK поддельными сегментами с некорректными номерами последовательности.
Помимо этого нарушитель должен иметь возможность отправлять легальный трафик на одну из машин (хост или маршрутизатор) по целевому TCP каналу. В идеале компьютер должен быть проблемным местом при TCP подключении. Но, как описывается в работе [6], хорошим кандидатом на эту роль может быть маршрутизатор, подключающий жертву к интернету. В качестве тестов может использоваться ICMP ping или, например, обмен сегментами внутри легитимного TCP подключения, а, в общем, - все, что позволит обнаружить изменение объема трафика.
На применимость атаки влияют различные факторы:
Определение практических ограничений исследуемой методики находятся за рамками данной работы. Результаты проведенных экспериментов могут служить ориентирами для анализа применимости атаки при различных сценариях. Подтверждение данной концепции может стать отправной точкой для дальнейших экспериментов. Для проведения рассматриваемой атаки необходимо не так много ресурсов, как для атак «вслепую», но, тем не менее, достаточно, чтобы сделать ее неприменимой во многих случаях.
· Простаивающее TCP соединение с незначительным объемом трафика, проходящего через узкое место. Самый благоприятный сценарий, в ходе которого ответы за запросы занимали большую часть трафика, проходящего через узкое место.
Нарушитель отправляет ping на маршрутизатор, находящийся в одном хопе от граничного маршрутизатора. Это позволяет быть уверенным, что ping-пакеты и сегменты, отправляемые жертвой в ответ на поддельный трафик, используют одну очередь исходящих сообщений на граничном маршрутизаторе. Когда соединение с внешней сетью не использовалось, время на передачу и подтверждение (RTT) ping’а было порядка 20 мс, когда же соединение было нагружено, RTT возросло до 700 мс.
Был проведен анализ двух систем: Windows XP SP3 со включенным межсетевым экраном и Linux 3.0.0 с Netfilter, включенным следующей командой:
iptables -A INPUT -m state \
--state ESTABLISHED -j ACCEPT;
iptables -A INPUT -j DROP;
Это общепринятая конфигурация для клиентской машины. Весь входящий трафик, не предназначенный для подключений, инициированных данной машиной, отбрасывается.
На исследуемых системах использовались разные правила для обработки TCP-сегментов. Для определения того, как защищенный межсетевым экраном хост отвечает на входящие сегменты, необходимо проанализировать два шага. Первый – отбросит ли межсетевой экран подобный сегмент, и второй – как сегмент будет обработан на уровне TCP. Различия рассматриваемых систем видны уже на первом шаге: Netfilter использует более строгие правила фильтрации трафика [2]. Второй шаг в обеих системах одинаков (по крайней мере, правила обработки, на которые проводилась атака) и максимально соответствует RFC 793. Правила обработки, используемые при атаке, будут освещены далее.
Доказательство концепции, использованной для получения результатов экспериментов, можно найти в работе [16]. В работе не рассматриваются низкоуровневые детали реализации, заинтересованным читателям следует обратиться к документации.
Важно отметить, что атаки не выявили багов в реализации TCP.
В итоге жертва должна сгенерировать ACK сегменты, содержащие около 80 байт (40 байт для заголовков второго уровня, 20 для IP- и 20 для TCP-заголовков). Согласно формуле, задержка при обработке 30 ACK сегментов должна равняться 0.06 секунды. Это в три раза больше, чем ping для простаивающего соединения, поэтому должно легко определяться. 100 ACK сегментов должны вызывать задержку в 2 секунды, что в три раза больше, чем ping при активно используемом соединении (700 мс). Это должно быть легко определяемым при проведении испытаний атаки.
TCP стеки в Windows и Linux построены с учетом рекомендаций RFC и отвечают ACK на любой сегмент с некорректным номером последовательности. Netfilter в Linux использует более строгие правила для проверки отброшенных сегментов, не принадлежащих ни одному из подключений:
Проверки числа принятия затрудняют поиск номера используемого порта с помощью сегментов с некорректным номером последовательности. Но есть один способ обхода:
На уровне TCP ACK-ответ на подобные сегменты происходит, если их номер последовательности находится вне окна. Это позволяет определить номер порта хоста, защищенного Netfilter. Единственным недостатком является тот факт, что, если номер последовательности SYN-ACK сегмента случайно окажется в рамках окна, Linux закроет соединение. Вероятность подобной ситуации равна (размер окна/232).
На рисунке 2 представлена динамика RTT при последовательности поддельных сегментов, направленных на верный порт. Скачок значения RTT происходит как и прогнозировалось, но зачастую он не является единственным. Далее повторяются все запросы, которые вызвали скачок, до тех пор, пока не останется только один. Данный алгоритм позволяет определить номер порта (максимальное значение среди успешных попыток)
а) соединение простаивает, 5 запросов ping на порт, 30 поддельных сегментов на порт
б) соединение используется (загрузка данных), 10 запросов ping на порт, 1000 поддельных сегментов на порт
Рисунок 2. Изменение динамики «потерянных» ping-запросов позволяет определить используемый порт (11235). Ping считается потерянным, если ответ не пришел три раза подряд с одного и того же порта.
Наименьшее время запроса равняется времени одного ping’а. Даже при минимальном времени в 20 мс сканирование 64 тысяч портов займет около 21 минуты. Если пропускная способность канала между нарушителем и жертвой является довольно большой, нарушителем может быть проверено большая часть портов в каждой последовательности поддельных сегментов. Данная последовательность может быть интерпретирована как запрос «при подключении используется порт в интервале [X;Y]?». Если часть последовательности отражается, то ответ «да», после чего можно продолжить поиск точного номера порта в данном интервале. Во время экспериментов данные запросы были довольно эффективны и позволяли снизить время поиска (см. рисунок 3). В таблице 1 приведены результаты попыток атаки. Результаты оказались схожими для обеих систем. Можно повысить эффективность, если при подключении будет использоваться порт из меньшего диапазона.
Рисунок 3. Сканирование при простаивающем соединении. Поддельные сегменты покрыли 200 множеств портов. 5 ping’ов и 6000 поддельных сегментов (30 на каждый порт) отправлены на каждое множество. Анализ RTT и «пиков» потерь ping’ов позволили определить, что номер используемого порта лежит на интервале 11200-11400.