На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Эффект альтернативного кодирования для систем IDS

Существуют сотни различных способов закодировать конкретную атаку, и каждый из них оформлен по-своему в виде набора сетевых пакетов, хотя все они приводят к одному и тому же результату. Это явление называют конвергенцией входных данных в конкретное состояние программы. Отмечается большое разнообразие наборов входных данных, которые приводят атакуемую программу в одинаковое конечное состояние. Другими словами, нет четкой зависимости между конкретным набором входных данных и конечным состоянием программы (для большинства программ). Например, есть миллионы различных пакетов, которые могут быть доставлены в систему и которые будут проигнорированы. Важнее, что существуют тысячи пакетов, доставка которых приведет к получению одинакового ответа от атакуемой программы.
Различные наборы входных данных
Для корректной работы сетевая система обнаружения вторжений должна обладать полным набором сведений как о кодировании, так и о любом другом преобразовании входных данных, которое может привести к успешной атаке (для каждой конкретной сигнатуры). Реализовать такой метод весьма сложно. В качестве простого примера, только поверхностно зная некоторые правила, злоумышленник способен так изменить стандартные атаки, что загрузит работой систему IDS на долгое время, пока он будет попивать текилу на Бермудах.
На 1 мы проиллюстрировали пример атаки с помощью десинхронизации, которая получила широкую огласку в конце 1990-х годов. GET-запрос сегментирован на несколько пакетов. Оба запроса, обозначенные А и В, отправляются атакуемому хосту. В нижней строке указывается порядковый номер пакета, согласно которому поступают данные. Однако мы видим, что отправленные символы немного от­личаются. Запрос А искажен, а запрос В является легитимным GET-запросом данных каталога cgi-bin.

Сравним запросы А и В. Обратите внимание, что здесь есть перекрывающиеся пакеты. Например, в пакете 1 содержатся символы "GT" и "G", а в пакете 2 — символы "ЕТ" и "Е". Когда эти пакеты поступают на атакуемый компьютер, он должен принять решение о том, как поступить с перекрывающимися символами. Существует несколько возможных вариантов. Строки, обозначенные на рисунке символами С, D и Е, являются возможными вариантами восстановления окончательной строки данных. Обход системы обнаружения вторжений происходит при восстановлении этой системой искаженной или некорректной строки, в то время как сервер реконструирует действительный запрос.
Проблема усложняется в геометрической прогрессии для каждого уровня протокола, где возможно наложение символов. С помощью фрагментации пакетов на уровне протокола IP можно организовать затирание символов. Сегментация используется для этой же цели на уровне протокола TCP. Для некоторых протоколов уровня приложений возможны даже более серьезные наложения. Если злоумышленник при атаке скомбинирует несколько уровней наложения, то вероятность нужного ему восстановления данных значительно увеличивается.
Любая система обнаружения вторжений, которая старается проверить каждый пакет из набора на предмет содержащегося в нем запроса, оказывается в затруднительном положении. В некоторых системах предусмотрена возможность моделирования поведения каждой возможной цели атаки при восстановлении пакетов, что позволяет провести более точный анализ поступающих данных. Предполагается, что используется точная модель работы атакуемого компьютера, что уже весьма сложно. При этом также предполагается, что даже при работающей модели атакуемого компьютера, система обнаружения вторжений позволяет правильно восстановить отправленные данные на линии с гигабитовой скоростью передачи информации. В реальной жизни системы обнаружения вторжения просто помечают подобные замаскированные запросы как "подозрительные", но практически никогда не восстанавливают цельного содержимого отправленных данных. В центре этой проблемы лежит вопрос точности работы протокола согласно заданным спецификациям. Разбор структуры пакета на уровне приложений является достаточно сложной задачей. Однако спецификации TCP/IP определены достаточно четко, поэтому система обнаружения вторжений в общем случае может восстанавливать фрагменты пакетов на достаточно высоких скоростях (часто с помощью аппаратных средств). Грамотно написанные системы обнаружения вторжений также хорошо работают с простыми протоколами наподобие HTTP. Однако восстановление отправленных данных на уровне приложений выполнить очень сложно и остается вне зоны внимания для большинства систем обнаружения вторжений.
Исследование по частям
Сложные системы программного обеспечения могут рассматриваться как наборы подсистем. Можно даже Internet расценивать как единую (хотя и особо крупную) систему программного обеспечения. С этой точки зрения каждый компьютер, подключенный к Internet, может считаться подсистемой. Эти компьютеры, конечно, в свою очередь можно разделить на подсистемы. Процесс разделения крупной систе­мы на мелкие подсистемы называют разделением на части (partitioning). Обычнуюсистему можно рассматривать как единое целое, состоящее из набора составляющих на различных уровнях детализации.
Очевидно, что мы не можем ограничить систему какими-то конечными рамками, поэтому мы всегда исследуем программное обеспечение как часть большей системы, которая поддается описанию. Это вполне приемлемо, поскольку вся Вселенная является (ограниченным) набором систем, которые обмениваются информацией4. Теоретически нет предела уязвимым приложениям, на которые можно провести атаку. Одним из наиболее удачных способов является исследование искусственно взятых частей системы, которые можно успешно "измерить". Проще всего начать с исполняющегося процесса — образа приложения, когда оно запущено на конкретном компьютере. Ис­пользуя описанные в этой книге средства, можно провести исследование процесса запущенного приложения и определить загруженные модули программного кода. Подобным образом можно исследовать входные данные и другой трафик, чтобы определить правила взаимодействия между модулями, операционной системой и сетью. Также можно узнать о внешних взаимодействиях программы с файловой системой, внешними базами данных и об исходящих соединениях по сети. Все вышеперечисленное составит достаточно большой объем информации для исследования.
Однако даже этот процесс можно разбить на подпроцессы. Например, мы можем расценивать каждую библиотеку DLL как отдельный элемент и анализировать ее отдельно. Затем мы можем проанализировать входные и выходные данные небольшого фрагмента кода, исследуя различные вызовы функций API.
В следующем примере мы покажем, как отслеживать вызовы функций API на платформе Windows.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика