Отказ от значений по умолчанию
Как уже не один раз упоминалось ранее, некоторые системы обнаружения атак исходят из предположения, что порт источника или получателя однозначно идентифицирует протокол, по которому осуществляется взаимодействие между несколькими узлами. Например, порт 80 определяет протокол HTTP, порт 23 — Telnet, порт 31337 — "троянца" Back Orifice и т. д. Однако злоумышленник может использовать стандартные протоколы на нестандартных портах (например, HTTP закрепить за 8081-м портом). Или же изменит значения портов, заданные по умолчанию, на новые, что не позволит некоторым системам обнаружения атак обрабатывать такой "нестандартный" трафик.
Подмена адреса
Очень часто атакующие подменяют свой реальный адрес на сфальсифицированный, что не позволяет своевременно их обнаружить. Например, сканер nmap может вырабатывать пакеты, содержащие помимо реального адреса еще и обманные (decoy), что вызывает "засорение" журнала регистрации системы обнаружения атак. Администратору очень трудно определить, какие из адресов, с которых зафиксированы атаки, являются истинными, а какие — подменены злоумышленником. И хотя задача обнаружения реального адреса источника атаки относится к вопросу реагирования на инциденты, о которой речь пойдет дальше, о такой проблеме не стоит забывать.
Изменение шаблона атаки
Многие системы обнаружения атак работают по принципу сопоставления Участков сетевых пакетов с образцом (шаблоном). Использование баз данных хорошо известных атак позволяет идентифицировать атаки с высокой степенью достоверности. Однако от таких систем можно очень легко уклониться, просто немного изменяя шаблон. Ниже приводится несколько подобных примеров [Коэн1-99].
· Вставка посторонних, ни на что не влияющих символов в команды и Данные атаки, что обычно приводит к невозможности ее обнаружения.
· Замещение пробелов на символы табуляции в командах, реализующих атаку.
· Изменение символа разделителя в системе (например, пробел меняется на %), что приведет к определенным проблемам в выявлении несанкционированной деятельности. Например, URL "/dir/examples attack/attack.asp" может быть заменен на "/dir/examples%20attack/attack.asp".
· Переопределение стандартной последовательности действий при атаке. Например, если атака одинаково осуществляется и при последовательности команд "a;b;c" и при "b;a;c", то большинство систем обнаружения атак распознает первый вариант реализации атаки, но "ослепнет" во втором случае.
· Определение макроподстановки для параметра, используемого при реализации атаки. Например, "$Р" вместо строки "/etc/passwd" или "%SystemRoot%" взамен "c:\winnt".
· Создание сценария, который вберет в себя команды, отдаваемые при атаке. Если тщательно спланировать эту операцию, то система обнаружения атак не сможет "связать вместе" название сценария и команд, что приведет к пропуску атаки.
Проблема с UNICODE
Существует еще одна проблема, которая могла бы быть описана в предыдущем разделе, но т. к. она достаточно важна и нова, я решил посвятить ей отдельный раздел. Эта проблема порождена тем, что сетевые системы обнаружения атак не могут распознавать атаки, использующие UNICODE – формат данных для компьютерного представления символов различных языков. UNICODE поддерживается многими программными средствами и стандартами, в т. ч. Java, LDAP, XML, MS IIS, Apache, MS Office 2000 и т. д. В стандарте UNICODE определено такое понятие, как UTF-8, соответствующее схеме преобразования символов UNICODE в последовательность от одного до четырех байт. В том числе, при помощи UTF-8 обеспечивается совместимость с ASCII. UNICODE позволяет иметь для одного и того же символа несколько представлений. Например, косая черта "\" может быть представлена как следующие шестнадцатеричные значения: 5С (однобайтовая последовательность); С19С (двухбайтовая последовательность) и Е0819С (трехбайтовая последовательность). Для всех приложений, поддерживающих UTF-8, эти три значения идентичны. И хотя недавно консорциум UNICODE отменил множественное представление символов UTF-8 и выпустил изменение к формату UTF-8, названное "UTF-8 Corrigendum" приложения, разработанные еще до опубликования этого документа, поддерживают старый стандарт UTF-8.
Следующая неприятность, связанная с UNICODE, заключается в том, что различные приложения или операционные системы могут различные символы UNICODE (называемые code points) интерпретировать одинаково. Например, в [Hacker1-01] замечено, что Web-сервер MS IIS, функционирующий поверх MS Windows 2000 Advanced Server (English version) интерпретирует различные символы UNICODE U+0041, U+0100, U+0102, U+0104, U+01CD, U+01DE, U+8721, как символ "А". А если учесть, что IIS не делает разницы между строчными и заглавными буквами, то символ "А" может быть описан 30 различными комбинациями UNICODE. Символ "Е" может иметь 34 представления, "I" — 36, "О" — 39, a "U" — 58. Перемножив эти значения, мы получим 83 060 640 различных комбинаций написания строки "AEIOU", воспринимаемых абсолютно одинаково.
Одна из первых описанных проблем [Xforce1-00], связанных с безопасностью (а точнее, с "не безопасностью") UNICODE, относилась именно к MS IIS 4.0 и 5.0. Попытка обращения по URL:
http://www.bank.ru/../../winnt/system32/cmd.exe?/c+format+c:
должна была привести к форматированию диска, т. к. фрагмент ../.. был призван помочь злоумышленнику обойти систему защиты IIS 5.0 и перейти в корневой каталог Web-сервера. Однако прямое обращение по указанному адресу приводило к тому, что IIS удалял фрагмент ../.. и выдавал сообщение об ошибке. Тем не менее, если заменить данный адрес на URL со вставкой UNICODE-фрагмента:
"http://www.bank.ru/..%c1%9c../winnt/system32/cmd.exe?/c+format+c:",
то IIS позволит выполнить несанкционированную команду. Аналогичного результата можно добиться, используя вместо "..%lc%9c.." UNICODE-фрагменты "..%cl%lc..", "..%c0%9v..", "..%c0%af..", "..%c0%qf..", "..%cl%8s..", "..%cl%9c..", "..%cl%pc.." и т. д.
Сложное уклонение
Высококвалифицированные злоумышленники могут применить более сложные методы обхода или уклонения (evasion) от систем обнаружения атак. Они описаны Томасом Птачеком и Тимоти Ньюшэмом в [Ptacek1-98]. Оригинальная версия данного документа доступна по адресу: http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps, а HTML-версия — по адресу: http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.HTML.
Чтобы не пересказывать его содержание, хочу привести один из новых способов обхода системы обнаружения атак. В систему RealSecure Network Sensor встроен уже упоминавшийся механизм Event Propagation, который позволяет уменьшить число событий, отображаемых на консоли и записываемых в базу данных. Этот механизм, предназначенный для повышения стойкости системы к атакам типа "отказ в обслуживании", может быть использован и во вред. Например, если злоумышленник знает, что сетевой сенсор перестает регистрировать события FTP_Put после обнаружения 100 первых, зафиксированных в течение 2-х минут, то он может имитировать 100 обычных событий FTP_Put и только 101-е событие было бы атакой. Сенсор RealSecure Network Sensor после 100 событий FTP_Put перестал бы их фиксировать, и "хитрец" остался бы незамеченным. Этот пример лишний раз иллюстрирует тезис, что не стоит посвящать всех пользователей в особенности и тонкости построения инфраструктуры защиты.