Поиск уязвимостей в современных системах IDS

Евгений Жульков
07.08.2003
Открытые системы, #07-08/2003

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

Сетевые системы обнаружения атак (IDS — Intrusion Detection System), построенные по классической архитектуре, могут быть легко скомпрометированы, хотя ранее считалось, что их использование позволяет остановить многие сетевые атаки [1].

Среди множества сетевых атак можно выделить класс сигнатурных атак, в процессе которых передается неизменяемый блок данных заданного уровня сетевого взаимодействия. Большинство современных инструментов IDS используют сигнатурный метод поиска вторжений; он прост в использовании и при корректной реализации механизмов поиска сигнатур позволяет достичь высоких результатов обнаружения. Следует подчеркнуть: методы сокрытия атак, предложенные Томасом Птачеком и Тимоти Ньюшемом [1], позволяют скрыть от IDS факт проведения только сигнатурных атак.

Успешное использование методов сокрытия основано на предположении о том, что стеки протоколов, реализованные в IDS и в атакуемой (целевой) системе, различаются. Подобные различия могут быть вызваны несколькими причинами:

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

Передаваемая по сети информация может быть по-разному обработана IDS и целевой системой, а из-за различий в стеках протоколов появляется возможность создать последовательность пакетов, которая будет принята IDS, но отвергнута целевой системой. В таком случае IDS не знает, что целевая система не приняла пакет, и атакующий может воспользоваться этим для сокрытия факта проведения атаки, посылая специально созданные пакеты. Создавая ситуацию, когда целевая система отбрасывает пакеты, а система обнаружения атак их принимает, нарушитель как бы «вставляет» данные в анализатор событий IDS (рис. 1).

Рис. 1. Метод вставки

В общем случае можно сказать, что метод вставки применим, когда стек протоколов в IDS реализован менее строго, чем в целевой системе. Естественное решение данной проблемы — создать стек протоколов настолько строгим, насколько возможно. Однако в этом случае появляется возможность использовать другой метод сокрытия — метод уклонения, при котором целевая система примет, а сетевая система обнаружения вторжений отбросит пакеты (рис. 2).

Рис. 2. Метод уклонения

Метод поиска различий

Итак, для успешного использования методов сокрытия необходимо найти различия в реализации стеков TCP/IP. Для этого используются специально подготовленные тестирующие сетевые пакеты, позволяющие анализировать реакцию IDS и целевых систем.

Чтобы понять, каким образом необходимо подготавливать тестирующую последовательность сетевых пакетов, следует более подробно рассмотреть использование методов сокрытия атак. Так, для проведения метода вставки надо подобрать такую последовательность тестирующих пакетов, чтобы целевая система ее не восприняла. Причины, по которым целевая система не обработает последовательность, могут быть различными — либо стек протоколов целевой системы решит, что последовательность не корректна, либо произойдет перезапись передаваемого блока данных, например, после обработки перекрывающихся IP- или TCP-фрагментов [2, 3].

После обнаружения последовательностей сетевых пакетов, которые не воспринимает целевая система, переходят ко второй фазе тестирования — исследование реакции IDS на прием этих последовательностей. Какие последовательности сетевых пакетов будут восприняты как правильные и обработаны? В случае, если найдена одна или несколько таких последовательностей, можно считать, что данная комбинация целевой системы и IDS имеет уязвимость, позволяющую использовать метод вставки. С методом уклонения все наоборот: требуется найти последовательности пакетов, которые целевая система воспримет, а IDS не станет обрабатывать.

Для метода поиска различий, прежде всего, были выделены уровни сетевого взаимодействия, на которых проводится поиск. При проведении исследований рассматривались средства IDS, работающие в сетях TCP/IP. Для данного стека протоколов принята четырехуровневая модель: канальный, сетевой, транспортный и прикладной. Для создания полной картины существующих различий методика поиска затрагивала все 4 уровня. Кроме того, необходимо выявить признаки сетевых пакетов, по которым система принимает решение, что пришедший пакет некорректный и его следует отбросить.

TCP-фрагментом будем называть TCP-сегмент, являющийся частью одного сеанса. (Спецификация протокола TCP не оперирует этим понятием; нам же оно необходимо для описания нашей методики.) Пример TCP-фрагмента: в процессе работы через telnet-соединение в рамках одного сеанса передается множество TCP-сегментов, содержащих всего один символ, введенный пользователем. В нашей методике поиска уязвимостей возможные различия искались в следующих аспектах реализации стека протоколов;

• обработка некорректных заголовков кадров канального уровня (Ethernet);
• обработка некорректных пакетов сетевого уровня (IP);
• обработка некорректных заголовков сегментов транспортного уровня (TCP);
• обработка IP-фрагментов;
• обработка TCP-фрагментов;
• обработка различных комбинаций TCP-флагов;
• обработка пакетов с неправильными порядковыми номерами протокола TCP;
• обработка некорректного HTTP-сеанса.

Перечисленные аспекты реализации могут существенно различаться в разных системах. Особенный интерес представляют вопросы, связанные с обработкой фрагментированного трафика: в стандартах вообще нет рекомендаций, которых должны придерживаться разработчики при обработке аномального фрагментированного трафика (частично или полностью перекрывающиеся фрагменты), поэтому именно на этой детали реализации стеков необходимо акцентировать внимание.

Для поиска различий были разработаны специальные последовательности тестирующих пакетов.

1. Обработка заголовков. Назначение данных тестов - определить, каким образом происходит обработка заголовков сетевых пакетов, и какие заголовки система считает некорректными. Тестирование проводится в четыре этапа:
   • обработка некорректных пакетов канального уровня;
   • обработка некорректного IP-заголовка;
   • обработка некорректного TCP-заголовка;
   • посылка TCP-сегмента с неправильным номером очереди.
2. Обработка фрагментов. Данный класс тестов предназначен для определения той стороны реализации стека, которая связана с обработкой TCP- и IP-фрагментов. Проведение тестов проходило в четыре этапа:
   • посылка IP-фрагментов с некорректным заголовком канального и сетевого уровней;
   • посылка TCP-фрагментов с некорректным заголовком канального, сетевого и транспортного уровней;
   • посылка IP- и TCP-фрагментов в различной последовательности (произвольный порядок, обратный порядок, посылка повторяющихся пакетов);
   • посылка частично и полностью перекрывающихся IP- и TCP-пакетов.
3. Обработка флагов TCP. Эти тесты предназначены для определения того, как система обработает различные комбинации флагов TCP-сегмента при передаче потока данных. Рассматривались восемь комбинаций флагов ACK, SYN, FIN. Интересовало новое состояние TCP-соединения, реакция целевой системы (какие TCP-сегменты система пошлет в ответ) и поведение системы обнаружения вторжений.
4. Обработка HTTP-сеанса. При проведении этого теста проверялась обработка некорректного HTTP-запроса, начинающегося с двух символов начала строки (0x0D, 0x0A, 0x0D, 0x0A). По спецификации данными символами должен заканчиваться запрос к Web-серверу. Проведение теста тесно связано с логикой обработки TCP-сегментов с неправильными номерами очередей, результаты по которым были получены ранее.

Проведение тестирования

Тестирование реализации стеков операционной системы и IDS проводилось на макете, состоящем из двух компьютеров, объединенных сетью Ethernet. Хост, с которого проводилось тестирование, назывался «атакующей системой», а тестируемый хост — «целевой системой» (рис. 3). На хосте имелся файл с названием PHF. Доступ к данному файлу моделировал доступ к уязвимому сценарию phf (www.infosecurity.com/archive/1). В случае HTTP-запроса с атакующей системы к этому файлу Web-сервер передавал его содержимое атакующему, что говорило об успехе атаки. Совсем необязательно выполнять сам сценарий на Web-сервере: если Web-сервер выдал содержимое файла, можно считать, что атака состоялась. Атакующий мог видеть результат атаки на экране с помощью запущенного сетевого анализатора Snort. В случае успеха Snort перехватывал содержимое файла PHF. Обращение к файлу PHF выбрано не случайно. Во-первых, в [1] рассматривали также обращение к PHF. Во-вторых, данная уязвимость была обнаружена в 1996 году и все рассмотренные IDS имели правила для поиска такой сигнатуры.

Рис. 3. Тестовый макет

Создание тестирующей последовательности пакетов проводилось при помощи специально разработанной программы NetStuff, которая является расширенным генератором пакетов, позволяющим выполнять следующие действия.

1. Установка связи. Программу можно использовать для установления TCP-соединения с удаленным сервером. В качестве параметров трехэтапного квитирования пользователь может выбрать IP-адреса отправителя и получателя, номера портов отправителя и получателя, а также задать начальный номер ISN.
2. Разрыв связи. Для разрыва ранее установленного соединения предусмотрена специальная функция. Пользователю предоставляется возможность определить IP-адреса и номера портов отправителя и получателя, а также текущий номер последовательности.
3. Посылка пакетов. Основная функция программы - посылка данных в пакетах TCP/IP. Программа имеет возможность посылки данных как в одном пакете, так и в нескольких TCP- или IP-фрагментах. При посылке пакетов имеется возможность настроить все известные поля протоколов канального, сетевого и транспортного уровней. Автоматически высчитывается контрольная сумма TCP-сегментов и IP-пакетов.

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

Особое внимание уделялось выбору систем для тестирования: необходимо было рассмотреть как коммерческие, так и свободно распространяемые средства IDS.

В качестве исследуемых систем IDS были выбраны Snort 1.8.4. beta for Linux [4], Snort 1.8. for Win32 [4], eTrust Intrusion Detection 1.0 от Computer Associates [5], Dragon 5.0 от Enterasys Networks [6], RealSecure 6.0 от Internet Security Systems. Первые две системы распространяются свободно, для работы остальных понадобился демо-ключ, не ограничивающий функциональные возможности. Операционные системы, защищенные IDS: Windows 98 SE v4.10.2222; Windows 2000 SP2 v5.00.2195; Windows NT 4.0 SP3; Linux Red Hat 7.2 на ядре 2.4.7-10.

Поиск уязвимостей проходил по следующему сценарию.

1. Исследовалась реализация стека протоколов сетевого взаимодействия целевой системы. Для этого использовался генератор пакетов NetStuff и ранее подготовленные тестирующие последовательности сетевых пакетов. Инициировался запрос к файлу PHF, хранящемуся на Web-сервере целевой системы. В случае, если Web-сервер обработал запрос и выдавал содержимое файла, можно говорить о том, что конкретная реализация стека целевой системы восприняла текущую тестирующую последовательность, в противном случае, - что стек целевой системы не смог обработать запрос.
2. Аналогично проводилось тестирование IDS. Если IDS смогла обнаружить сигнатуру атаки "phf" и выдала сообщение об атаке, то можно говорить о том, что IDS восприняла тестирующую последовательность.
3. После изучения особенностей реализации стеков рассматривались полученные результаты и искались различия в работе стеков систем. Так, если конкретная целевая система оставляет новые данные при обработке перекрывающихся IP-фрагментов, а IDS оставляет старые, можно говорить о том, что найдено различие.
4. Последний этап поиска - попытка проведения скрытой атаки методом вставки или сокрытия. Для этого использовались результаты, полученные в предыдущем пункте. В том случае, если удавалось незаметно для IDS получить содержимое файла PHF, можно говорить о том, что найдена новая уязвимость.

Результаты

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

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

1. Прием пакетов, направленных на неправильный Ethernet-адрес.
2. Прием пакетов с неправильной контрольной суммой IP.
3. Прием TCP-сегментов со смещением данных меньше 20 октетов или равным 0.
4. Отсутствие обработки данных, если они пришли в TCP-сегменте, с установленным флагом FIN.
5. Прием данных полностью, если они пришли в пакете с неправильным номером очереди. (Согласно спецификации протокола TCP, место полезной информации, передаваемой конкретным TCP-сегментом, строго определяется его номером очереди; в случае неправильного номера, целевая система "отрезала" лишние данные.)
6. Прием IP-фрагментов, направленных на неверный Ethernet-адрес.
7. Прием IP-фрагментов с неправильной контрольной суммой IP.
8. IDS не обрабатывает поток TCP-фрагментов, в случае посылки в потоке повторяющихся фрагментов. После проведения таких действий, IDS выходит из строя и уже не в состоянии обработать любые TCP-фрагменты.
9. IDS не обрабатывает поток TCP-фрагментов, пришедших в обратном порядке.
10. IDS оставляет новые данные при посылке частично перекрывающихся TCP-фрагментов, тогда как операционная система оставляет старые.

Также интересны результаты работы IDS RealSecure 6.0, анализирующей трафик для Windows 2000.

1. RealSecure 6.0 принимает пакеты, направленные на неправильный Ethernet-адрес.
2. IDS принимает пакеты с неправильной версией IP-протокола.
3. IDS принимает данные полностью в случае посылки их в TCP-сегменте с неправильным номером очереди, тогда как операционная система "отрезает" лишние данные.
4. IDS принимает IP-фрагменты, направленные на неправильный Ethernet-адрес.
5. IDS принимает IP-фрагменты с неправильной версией IP-протокола.
6. IDS принимает TCP-фрагменты, направленные на неверный Ethernet-адрес.
7. IDS принимает TCP-фрагменты с неправильной версией IP-протокола.
8. 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-фрагментов.

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

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

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

Поиск уязвимостей

Поиск уязвимостей IDS был проведен посредством посылки запросов целевой системе с работающей IDS. Запрос формировался с учетом обнаруженных ранее различий. Успешное сокрытие атаки позволяло говорить о том, что найдена уязвимость. Описание некоторых методов сокрытия сигнатурных атак, использующих найденные уязвимости в зависимости от операционной системы целевой системы, типа атаки и используемой системы обнаружения, представлены в таблицах 1-5. Методы, которые можно использовать для сокрытия атак через Internet, отнесены к классу межсегментных. Если же метод подходит только для атак внутри одной сети, он отнесен к внутрисегментному классу.

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

Если для проведения атак используются различия в работе IDS и операционной системы, то в зависимости от того, какую операционную систему защищает IDS, могут появляться новые уязвимости. Например, мы рассмотрели только связку RealSecure 6.0/Windows 2000. А что, если RealSecure 6.0 защищает Web-сервер на платформе Linux Red Hat? Понятно, что некоторые ранее найденные уязвимости будут неактуальны. Однако, используя особенности реализации стека Linux Red Hat, полученного на первом этапе тестирования, можно обнаружить новые уязвимости.

Используя результаты, полученные после поиска различий, нарушитель может разработать методы сокрытия для любых комбинаций IDS и ОС. Для этого ему необходимо выяснить, какая IDS защищает конкретный сегмент сети. Это основная проблема — особенно, если нарушитель находится вне сегмента. Если же нарушитель находится в том же сегменте сети, то появляется возможность определить тип IDS по служебной информации, которой IDS обменивается со своими агентами и сенсорами (если имеется распределенная архитектура IDS). После этого, используя генератор пакетов и проведя несколько тестирующих легальных запросов на целевую систему, нарушитель определяет особенности ее работы. Скажем, он может проанализировать, как обрабатывается фрагментированный трафик. Далее, используя базу данных с особенностями работы конкретной IDS и результатами тестирования, нарушитель сможет найти различия и сгенерировать такую последовательность пакетов, которая позволит незаметно провести сигнатурную атаку.

Выводы

В качестве исследуемых IDS выбирались наиболее популярные системы. Факт наличия в них уязвимостей позволяет говорить о том, что и в остальных доступных инструментах ситуация будет не лучше.

С точки зрения возможности применения методов вставки и уклонения, самыми уязвимыми оказались Dragon 5.0 и eTrust 1.0. Поэтому, если нарушитель знает, что сегмент сети защищен системой обнаружения вторжений Dragon 5.0, то он имеет возможность провести сигнатурную атаку, скрыв ее, например, при помощи модификации потока TCP-фрагментов.

eTrust 1.0 оказалась лучше Dragon 5.0 с точки зрения уязвимостей, позволяющих скрыть атаку, но и здесь имеется семь различных способов скрыть факт проведения сигнатурной атаки (таблица 4). В том случае, если нарушитель не знает, как работает целевая система, он может провести межсегментную атаку, скрыв ее при помощи посылки частично перекрывающихся IP-фрагментов.

Среди коммерческих систем RealSecure 6.0 оказалась наиболее стойкой к методу сокрытия, однако у нарушителя все же имеется пять различных способов скрыть атаку, один из которых позволяет провести межсегментную атаку (таблица 5).

Несмотря на то, что система Snort является бесплатной, она показала достойные результаты. Нет недоработок, связанных, например, с обработкой фрагментированного трафика.

Осталось непонятным, зачем разработчики изменили порядок обработки одинаковых TCP-фрагментов при переходе на платформу Win32. Операционные системы этого класса обрабатывают перекрывающиеся пакеты не так, как Linux, однако, в новой версии Snort, работающей и на платформе Win32, и для Linux имеется уязвимость, связанная с обработкой таких фрагментов.

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

Литература

1. Ptacek T., Newsham T. Insertion, evasion, and denial of service: eluding network intrusion detection. Secure Networks, 1998.
2. RFC 791 - IP.
3. RFC 793 - TCP.
4. Snort. The Open Source Network Intrusion Detection System. http://www.snort.org.
5. eTrust Intrusion Detection, http://www3.ca.com/Solutions/Overview.asp?ID=163.
6. Dragon IDS. Intrusion Detection Solutions, http://www.enterasys.com/ids/dragonids.html.

Евгений Жульков (ezhulkov@openwaygroup.com) — магистр кафедры «Информационная безопасность компьютерных систем» Санкт-Петербургского государственного политехнического университета.

---

Таблица 1. Методы сокрытия. Snort 1.8.3 for Linux

Таблица 2. Методы сокрытия. Snort 1.8 for Win32

Таблица 3. Методы сокрытия. Dragon 5.0

Таблица 4. Методы сокрытия. eTrust ID 1.0

Таблица 5. Методы сокрытия. RealSecure 6.0