Обнаружение сигнатур. 
Программно-аппаратные средства обеспечения информационной безопасности вычислительных сетей

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

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

Совпадение с шаблоном — обнаружение в этом случае базируется на поиске фиксированной последовательности байтов в рассматриваемом элементе данных. Как правило, сопоставляется только в том случае, если подозреваемый пакет ассоциирован с определенной службой. Существуют протоколы, которые не имеют определенных портов. Пример условий сигнатуры: пакет Ipv4 содержит указание на протокол TCP и порт назначения 2222, а полезная нагрузка содержит строку foo — «генерировать тревогу».

Совпадение с шаблонами состояния — по одному пакету устанавливается состояние протокола данных. Появление другого пакета (или пакетов), который соответствует данными состояниями, считается атакой. Достоинства и недостатки данного подхода перечислены в табл выше.

Анализ на основе шаблона используемого протокола — для формирования состояния используется декорированное различных элементов протокола. При декорировании протокола СОВ применяют правила, определенные RFC для нарушений. В некоторых случаях эти нарушения могут находится в определенных полях протокола, что требует более детального анализа.

Эвристический подход — использует логические правила, получения эвристически. Например, для обнаружения сканирования портов можно использовать порог затронутых портов целевой системы. Кроме того, сигнатура может быть ограничена заданием Возможны различные варианты разработки сигнатур, которые определяют соответствующие технологии обнаружении. Для их иллюстрации воспользуемся уязвимости переполнения буфера в Microsoft RPC DCOM (бюллетень MS03−026). Впервые этот бюллетень и соответствующее исправление безопасности были выпущены корпорацией Microsoft 16 июля 2003 г., чтобы уязвимое место в системе безопасности интерфейса DCOM (Distributed Component Object Model) RPC (Remote Procedure Call) системыWindows. Это исправление до сих пор надежно закрывает брешь в системе безопасности. Однако в разделах «Факторы, снижающие опасность» и «Временное решение» первой версии бюллетеня были указаны не все порты, используемые службами RPC, чтобы пользователи, применяющие временные решения проблемы пред установкой исправления, распологали всей необходимой для защиты компьютера информацией. Сетевой протокол DCE/RPC, в частности, определяет вызовы сетевых функций, предоставляемых различными интерфейсами Microsoft, и передачу соответствующих аргументов этим функциям. Протокол RPC используется операционной системой Microsoft. Он обеспечивает взаимодействие между процессами и позволяет программам, запущенными на одном компьютере, беспрепятственно выполнять код на удаленном компьютере. В его основе лежит другой протокол — OSF (Open Software Foundation) RPC. Используемый в Microsoft протокол RPC представляет собой расширенную версию последнего.

Одно из таких расширений, которое отвечает за обменом сообщениями по TCP/IP, является уязвимым метом. Обработка некорректно составленных сообщений может привести к сбою к сбою в работе системы. Это уязвимое место связано с интерфейсом DCOM, который ведет прослушивание портов RPC. Этот интерфейс обрабатывает запрсы на активацию объектов DCOM клиентскими компьютерами серверу (например, запросов путей в стандартном формате записи имен UNC). Злоумышленник, которому удастся, воспользоваться этими уязвимым местом, получит возможность запускать на компьютере пользователя собственной код от имени учетной записи «локальный компьютер». Он сможет выполнять в системе любые действия, в том числе устанавливать программы, просматривать данные, изменять и удалять их, а также создавать новые учетные записи с полными правами. Чтобы восползоватся уязвимостью, злоумышленник должен направить на нужный порт RPC удаленного компьютера специальный запрос.

Были выявлены слабые места в той части службы удаленного вызова процедур Microsoft, которая относится к инструкциям RPC по акциям DCOM. Злонамеренный пользователь, используя эти слабые места, может запустить код с правами на доступ к локальной системе на пораженном компьютере или вызвать прекращение работы службы RPCSS. Затем этот злонамеренный пользователь может выполнить на компьютере любое действие, включая установку программ, просмотр, изменение и удаление данных или создание новых учетных записей с полными правами. Чтобы воспользоваться этими уязвимыми местами, злоумышленник должен создать используемую программу для отправки неправильных сообщений RPC, которые будут направлятся на конечную службу RPCSS уязвимого сервера.

Рассмотрим подробнее схему данной атаки. RPC — сервера представляет различные интерфейса, каждый из которых определяется уникальным идентификаторами IID из 16 байт. Имевшей рассматриваемую уязвимость интерфейс имел следующий IID:

01a0−0000−0000-c000−46.

Каждый интерфейс предоставляет семейство семейство функций, которые определяются значения opnum =4 в вызванном интерфейсе. Запрашиваемая клиентом комбинация interfese/opnum допускает различные множества аргументов для функций. Клиент сначала устанавливает TCP соединение с портом 135/tcp сервера (или портами 139,445,593/tcp, 135/udp) сервера. Схема клиентом атаки на Microsoft RPC DCOM показана на рисунке 4.4.

После установления соединения клиент посылает BIND для присоединения к желаемому интерфейсу. Затем клиент посылает запрос REQUEST для вызова определенной функции opnumв выбранном интерфейсе. Содержимое запроса включает в себя данные, которые интерпретируется сервером как аргументы вызываемой функции.

Что, имя server не будет превышать 32 байт. Если атакующий посылает длинное имя, то благодаря уязвимости в используемой системой библиотеке возникает переполнение буфера, позволяющее атакующему выполнить свой собственный код, вставленный в это длинное имя.

Рассмотрим различные сигнатуры для обнаружения этой атаки.

Сигнатуры эксплойт опираются на характеристики атаки, которые позволяют однозначно идентифицировать атаку. Для рассматриваемого примера однозначно идентифицировать атаку. Для рассмотренного параметрами уязвимости, например, будут: 1) запрошенный уязвимый интерфейс ISystemAction; 2) запрошенная язвимая функция (opnum =4); 3) длинное имя файла; 4) наличие файла машинных команд, реализующих уязвимость.

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

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

• 1) Установление соединения с портом 135/tcp;
• 2) Посылка BIND к уязвимому интерфейсу;
• 3) Наличие параметров в списке аргументов;
• 4) Наличие длинного имен сервера.

В данном случае отличной характеристикой уязвимости является длинное имя сервера. Поэтому сигнатурой может быть контроль длины имени сервера.

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

Для рассматриваемой уязвимости выработка соответствующей сигнатуры не представляется возможной в силу следующих причин:

• 1) Данный протокол не имеет RPC;
• 2) Исходные тексты протокола недопустимы;
• 3) Отсутствие информации о том, как приложение обрабатывает входные данные.

Чтобы проиллюстрировать сигнатуры аномалии протоколов, рассмотрим использование URL для атак в протоколе HTTP. Для этого рассмотрим следующие URL.

Данные URL являются похожими, но первый запрос является законным, а во втором используется атака SQL Ingection.

Сигнатуры политики. Рассмотрим сигнатуру Snort для рассматриваемой уязвимости:

Alert tcp $EXTERNAL_NET any -> $ NOME_NET 135.

(msg: `NETBIOS DCERPC ISystemActivator bind attempt';

Flow: to_server, established;

Content:''5;distance:0; within:1;

Content:''6;distance:1; within:1;

Byte_test: 1,&, 1,0,relative;

Content:'A01000000000000C000000000000046.

; distance:29; within:16;

Reference: cve, CAN-2003;0352; classtype: attempted-admin; sid:2192;).

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

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