27.02.2012

Сканирование отображения: атаки на TCP без возможности подмены трафика (часть I)

image

В данной статье рассматривается, каким образом поток траффика, взятый из общей очереди пакетов, может быть использован как сторонний канал, через который нарушитель может получить  конфиденциальную информацию.

Автор:Ян Вробель

wrr@mixebit.org

Краткое содержание

В данной статье рассматривается, каким образом поток траффика, взятый из общей очереди пакетов, может быть использован как сторонний канал, через который нарушитель может получить конфиденциальную информацию. Нарушитель отправляет своей жертве последовательность одинаковых сегментов. Жертва отвечает на каждый сегмент последовательности, если сегмент удовлетворяет определенным условиям, которые проверяет нарушитель. Ответы не поступают нарушителю напрямую, вместо этого они вызывают высокую нагрузку на общую для нарушителя и жертвы очередь маршрутизации. Увеличение времени обработки приводит к выполнению тестируемого условия. Основное внимание в работе уделяется TCP, но используемый подход является достаточно общим и может быть применен и для других протоколов, позволяющих создавать request’ы, на которые будет отвечать жертва. Доказательство данной концепции призвано оценить применимость метода в реальной жизни.

1. Введение

Протокол TCP без дополнительного уровня шифрования и аутентификации является уязвимым к атаке «человек посередине». Нарушитель, имеющий возможность перехватывать сетевой траффик между двумя TCP-точками, может с легкостью прочитать и подменить сообщения пользователей. Атаки, в ходе которых нарушитель не может получить доступ к сетевому траффику, гораздо сложнее в реализации. За годы существования TCP было обнаружено несколько подобных уязвимостей, после чего спецификация протокола перерабатывалась, и большинство вендоров внедряли ее, чтобы закрыть найденные уязвимости. TCP-соединение, реализующее последние рекомендации (3, 4, 5), считается достаточно защищенным при атаках без доступа к передаваемому трафику.

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.

2. Связанные работы

Высокая зависимость паттернов распределения трафика у пользователей, использующих общие ресурсы, была продемонстрирована в работе [6]. Авторы осуществляли мониторинг времени ping’а до маршрутизатора, через который пользователь был подключен к интернету, после чего сравнивали результаты с динамикой генерации трафика (активность пользователей). Перехват пакетов в данном случае был пассивным, то есть не отправлялось никаких пакетов, целью которых являлись бы генерация дополнительного трафика и получение дополнительной информации.

Атака, описанная в данной работе, имеет много общих моментов со всем известной техникой, эксплуатирующей слабости в реализации механизма генерации IP ID. Некоторые системы, для предотвращения данной атаки, увеличивают длину поля ID у каждого последующего IP пакета. Это создает сторонний канал, позволяющий определить, отправлен ли с хоста пакет в качестве ответа на входящий трафик. Этот канал может быть использован для сканирования портов или для выполнения атак на установленное TCP соединение [8]. В отличие от техники, описанной в данной работе, для эксплуатации IP ID канала нарушитель должен установить легитимный, двунаправленный канал коммуникации с атакуемым хостом. Современные межсетевые экраны, как правило, запрещают подобные подключения к клиентским машинам. Представленная вам работа сфокусирована на компрометации TCP сессий, но описанная техника может быть также использована для сканирования портов, аналог чего представлен в работе [7].

Рисунок 1. «Высокоуровневая схема атаки. Нарушитель посылает запрос жертве в форме последовательности поддельных сегментов. Если ответ на запрос положительный, жертва отвечает последовательностью сегментов, адресованных ее пиру. В то же время нарушитель пингует его, используя ту же очередь, что и сегменты жертвы. Увеличение времени ответа сигнализирует о позитивном ответе на запросы».

Авторы работы [9] показали, что перегрузка TCP может быть использована нарушителем для повышения эффективности его TCP-подключения за счет других. Применимость данной методики для проведения атаки «отказ в обслуживании» рассмотрена в работе [10]. При попытке проведения авторам удалось существенно снизить пропускную способность при TCP-соединении. В работе, посвященной оценке безопасности TCP [5], объясняется, что данная атака может быть проведена «вслепую» человеком, не имеющим возможность подменять траффик между хостами. Контроль перегрузки TCP поддерживается ACK сегментами, поэтому уровень TCP легко можно обойти с помощью генерации ACK поддельными сегментами с некорректными номерами последовательности.

3. Требования и применимость

Как и в большинстве случаев атак без возможности подмены трафика, нарушитель должен иметь возможность отправлять поддельные IP пакеты на один из хостов установленной сессии. Также необходимо, чтобы нарушитель знал IP адреса и номера портов, используемых при подключении каждым хостом. В данной работе хост, которому отправляются поддельные сегменты, будет именоваться «жертвой», а второй хост – «пир жертвы» (другой компьютер в одноранговой сети).

Помимо этого нарушитель должен иметь возможность отправлять легальный трафик на одну из машин (хост или маршрутизатор) по целевому TCP каналу. В идеале компьютер должен быть проблемным местом при TCP подключении. Но, как описывается в работе [6], хорошим кандидатом на эту роль может быть маршрутизатор, подключающий жертву к интернету. В качестве тестов может использоваться ICMP ping или, например, обмен сегментами внутри легитимного TCP подключения, а, в общем, - все, что позволит обнаружить изменение объема трафика.

На применимость атаки влияют различные факторы:

  • Доступные пропускная способность и время. Чем больше пропускная способность канала между нарушителем и жертвой, тем лучше. Чем меньше пропускная способность между жертвой и ее пиром, тем лучше.
  • Стандартный объем трафика в узком месте. Провести атаку становится сложнее, если через узкое место проходит большой объем трафика, или он имеет меняющиеся характеристики.
  • Топология сети. Провести атаку становится проще, если поддельные сегменты передаются от нарушителя жертве в обход узкого места, то есть не меняют объем трафик, анализируемого нарушителем.
  • Политика очередей узкого места. Высокая изоляция трафика, приходящего от разных пользователей, может усложнить проведение атаки.
  • Измерение трафика и методики анализа. Продвинутые методики могут увеличить вероятность успешного завершения атаки при неблагоприятных сценариях.

Определение практических ограничений исследуемой методики находятся за рамками данной работы. Результаты проведенных экспериментов могут служить ориентирами для анализа применимости атаки при различных сценариях. Подтверждение данной концепции может стать отправной точкой для дальнейших экспериментов. Для проведения рассматриваемой атаки необходимо не так много ресурсов, как для атак «вслепую», но, тем не менее, достаточно, чтобы сделать ее неприменимой во многих случаях.

4. Эксперименты

Все эксперименты были проведены при благоприятных (но при этом реальных) для нарушителя условиях. Нарушитель и жертва использовали один маршрутизатор. Скорости скачивания информации из интернета и ее загрузки обратно равнялись 2500кб/с и 320 кб/с, соответственно. Нарушитель был подключен к жертве по каналу 100мб, но не имел прямой доступ к ее трафику. Были рассмотрены различные сценарии:

· Простаивающее 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.

5. Детали атаки

Предположим, что общий маршрутизатор в качестве политики очередей использует FIFO, и задержка при обработке очереди из N пакетов составляет

В итоге жертва должна сгенерировать ACK сегменты, содержащие около 80 байт (40 байт для заголовков второго уровня, 20 для IP- и 20 для TCP-заголовков). Согласно формуле, задержка при обработке 30 ACK сегментов должна равняться 0.06 секунды. Это в три раза больше, чем ping для простаивающего соединения, поэтому должно легко определяться. 100 ACK сегментов должны вызывать задержку в 2 секунды, что в три раза больше, чем ping при активно используемом соединении (700 мс). Это должно быть легко определяемым при проведении испытаний атаки.

5.1. Одноразовый номер порта.

Согласно разделу «обработка событий» RFC 73, сегменты должны отправляться в ответ на любой сегмент, принадлежащий установленному TCP соединению (сегмент содержит корректный IP адрес и номер порта), но не выходящий за рамки окна (сегмент содержит некорректный номер последовательности). Если хост настроен в соответствии со спецификацией и защищен межсетевым экраном, который отбрасывает сегменты, не принадлежащие известным соединениям, нарушитель может использовать сегменты с некорректным номером последовательности для определения порта, используемого клиентом.

TCP стеки в Windows и Linux построены с учетом рекомендаций RFC и отвечают ACK на любой сегмент с некорректным номером последовательности. Netfilter в Linux использует более строгие правила для проверки отброшенных сегментов, не принадлежащих ни одному из подключений:

  • Сегменты с невыставленным флагом ACK отбрасываются;
  • Число принятия подвергается проверке. Оно принимается только, если оно равно следующему отправляемому октету или меньше max(66000, максимальный размер видимого окна отправителя)

Проверки числа принятия затрудняют поиск номера используемого порта с помощью сегментов с некорректным номером последовательности. Но есть один способ обхода:

  • Сегменты, у которых выставлены флаги SYN и ACK всегда принимаются и передаются на уровень TCP.

На уровне 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.

Ссылки

[1] J. Postel, Transmission control protocol, RFC 793, Internet Engineering Task Force, 1981, http://tools.ietf.org/html/rfc793
[2] G. Van Rooij, Real Stateful TCP Packet Filtering in IP Filter, 2001, www.usenix.org/events/sec01/invitedtalks/rooij.pdf
[3] A. Ramaiah, R. Stewart, M. Dalal, Improving TCP’s Robustness to Blind In-Window Attacks, RFC 5961, 2011, http://tools.ietf.org/html/rfc5961
[4] M. Larsen, F. Gont, Transport Protocol Port Randomization Recommendations, RFC 6056, 2011, http://tools.ietf.org/html/rfc6056
[5] F. Gont, Security Assessment of the Transmission Control Protocol, 2011 http://tools.ietf.org/ html/draft-ietf-tcpm-tcp-security-0
[6] S. Kadloor, Xun Gong, N. Kiyavash, T. Tezcan, N. Borisov. 2010, Low-Cost Side Channel Remote Traffic Analysis Attack in Packets Networks, ICCIEEE, 2010
[7] Antirez, New tcp scan method, 1998, http://seclists.org/bugtraq/1998/Dec/79
[8] klm, Blind TCP/IP hijacking is still alive, 2007, http://www.phrack.org/issues.php?issue=64&id=15
[9] S. Savage, N. Cardwell, D. Wetherall, T. Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communication Review, 29(5), October 1999
[10] A. Kumar, D. Sisalem, TCP based denial of service attacks to edge network: Analysis and detection, 2004, iptel.org/~dor/papers/Kumar1204_TCP.pdf
[11] Fyodor, Remote OS Detection, Nmap Network Scanning. http://nmap.org/book/osdetect.Html
[12] P. Watson, Slipping in the Window: TCP Reset Attacks, CanSecWest 2004 Conference
[13] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, RFC 2581, 1999, http://tools.ietf.org/html/rfc2581
[14] J. Touch, A. Mankin, R. Bonica, The TCP Authentication Option, RFC 5925, 2010, http://tools.ietf.org/html/rfc5925
[15] S. Kadloor, Xun Gong, N. Kiyavash, P. Venkitasubramaniam, Designing Privacy Preserving Router Scheduling Policies, Information Sciences and Systems (CISS), 2011
[16] Reflection Scan Proof of Concept https://github.com/wrr/reflection_scan
или введите имя

CAPTCHA
RU_LIDS
27-02-2012 10:17:57
ИМХО, слишком "лабораторное" исследование. Слишком много если. Само допущение невозможности перехвата трафика, но при этом возможность отправки поддельных пакетов довольно сильно смахивает на коммутируемое соединение между атакующим и жертвой. В этом же случае, проще перевести коммутатор в неразборчивый режим и спокойно перехватывать нужный трафик. Если же коммутатор управляемый и корректно настроен (VLAN, port security, etc), то он и поддельные пакеты сбросит. А чего стоит предположение стабильности "холостого" трафика жертвы в течении определенного времени. Это что за хост такой? На нем, что, не стоит почтовый клиент, антивирус или скайп в конце концов? При этом он медленно, печально и д-о-о-о-лго держит соединение, требуемое для перехвата. Слишком уж идеальная жертва.
0 |
jungle_vnd
27-02-2012 11:27:54
Такого материала мы все видели уже предостаточно. "Лабораторный налет" показывает, что кандидатскую человек защитит успешно. А практика вторична, вернее вообще нереальна (МСЭ/IPS, NAT и т.п. никто не отменял). А про "медленную TCP-атаку" как-то забыли, там и математика посерьезнее.
0 |