Безопасность и Internet - статьи

       

Результаты


Действительно существуют различия в реализации стеков протоколов целевых систем и IDS. Эти различия, прежде всего, основаны на неполном описании межсетевого взаимодействия и ошибках проектирования. Большинство таких различий основывается на разном порядке обработки фрагментированного трафика. Также встречались явные недоработки в IDS, например, IDS Snort и Dragon принимают IP-пакеты с неправильной контрольной суммой, а IDS RealSecure 6.0 и eTrust 1.0 — с неправильной версией протокола IP.

Очень много различий основано на некорректной реализации стеков. Это приводит к тому, что одни и те же ситуации обрабатываются по-разному различными системами. В качестве примера можно привести недостатки в работе IDS Dragon при анализе трафика, направленного ОС Linux RedHat.

  • Прием пакетов, направленных на неправильный Ethernet-адрес.
  • Прием пакетов с неправильной контрольной суммой IP.
  • Прием TCP-сегментов со смещением данных меньше 20 октетов или равным 0.
  • Отсутствие обработки данных, если они пришли в TCP-сегменте, с установленным флагом FIN.
  • Прием данных полностью, если они пришли в пакете с неправильным номером очереди. (Согласно спецификации протокола TCP, место полезной информации, передаваемой конкретным TCP-сегментом, строго определяется его номером очереди; в случае неправильного номера, целевая система "отрезала" лишние данные.)
  • Прием IP-фрагментов, направленных на неверный Ethernet-адрес.
  • Прием IP-фрагментов с неправильной контрольной суммой IP.
  • IDS не обрабатывает поток TCP-фрагментов, в случае посылки в потоке повторяющихся фрагментов. После проведения таких действий, IDS выходит из строя и уже не в состоянии обработать любые TCP-фрагменты.
  • IDS не обрабатывает поток TCP-фрагментов, пришедших в обратном порядке.
  • IDS оставляет новые данные при посылке частично перекрывающихся TCP-фрагментов, тогда как операционная система оставляет старые.
  • Также интересны результаты работы IDS RealSecure 6.0, анализирующей трафик для Windows 2000.

  • RealSecure 6.0 принимает пакеты, направленные на неправильный Ethernet-адрес.
  • IDS принимает пакеты с неправильной версией IP-протокола.
  • IDS принимает данные полностью в случае посылки их в TCP-сегменте с неправильным номером очереди, тогда как операционная система "отрезает" лишние данные.
  • IDS принимает IP-фрагменты, направленные на неправильный Ethernet-адрес.
  • IDS принимает IP-фрагменты с неправильной версией IP-протокола.
  • IDS принимает TCP-фрагменты, направленные на неверный Ethernet-адрес.
  • IDS принимает TCP-фрагменты с неправильной версией IP-протокола.
  • IDS не в состоянии обработать поток TCP-фрагментов в случае посылки их в произвольном порядке.

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

    Это же относится и к обработке потока TCP-фрагментов, например Dragon 5.0 и RealSecure 6.0 были не в состоянии обработать некоторые случаи: Dragon 5.0 просто выходил из строя после получения повторяющихся TCP-фрагментов и не обрабатывал поток TCP-фрагментов, пришедших в обратном порядке; RealSecure 6.0 не смог обработать TCP-фрагменты, пришедшие в произвольном порядке. Получается, что для нарушения работы IDS можно просто послать сигнатуру атаки в различной последовательности TCP-фрагментов. Dragon 5.0 не рассматривал TCP-сегменты с установленным флагом FIN, даже если они несли полезную информацию.

    Особо следует отметить тот факт, что IDS Snort (как для Win32, так и для Linux), не смогла обработать HTTP-запрос, начинающийся с двух символов возврата строки. Целевая система смогла это сделать после правильного подбора номеров очереди (она просто «отрезала» эти символы в начале запроса), что делает Snort также уязвимым к проведению сокрытой атаки методом уклонения. Помимо этого, Snort еще имел восемь несоответствий при работе с Linux и Windows 2000, три из которых связаны с обработкой некорректных заголовков и пять — с различными комбинациями IP- и TCP-фрагментов.

    Итак, тестирование выявило следующее количество различий в работе стеков.

  • Snort 1.8.4 for Linux с RedHat Linux 7.2 - 10 различий: 4 основаны на разной обработке некорректных заголовков, 1 - на обработке неправильного HTTP-запроса и 5 - на обработке фрагментированного трафика.
  • Snort 1.8 for Win32 с Windows 2000: те же различия плюс еще одно при обработке фрагментированного трафика.
  • Dragon 5.0 с Linux Red Hat 7.2 - 10 различий: 5 связаны с фрагментами, 1 - с установленным флагом FIN и 4 - с обработкой некорректных заголовков.
  • eTrust ID 1.0 с Windows 2000 - 8 различий: 5 - фрагментированный трафик, 3 - некорректные заголовки.
  • Real Secure 6.0 с Windows 2000 - 8 различий: 5 - фрагментированный трафик, 3 - некорректные заголовки пакетов.


  • Как показали дальнейшие исследования, все обнаруженные различия можно использовать при проведении сокрытых сигнатурных атак при помощи методов вставки и уклонения.


    Содержание раздела