Коллектив авторов - Защита от хакеров корпоративных сетей

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

В качестве примера рассмотрим Web-запрос. Пусть система обнаружения вторжений настроена на подачу сигнала тревоги при появлении любого запроса, содержащего строку /cgi-bin/phf. Предполагается, что в рассматриваемом случае давно известная уязвимость, основанная на вызове программы phf интерфейса CGI, будет оформлена по стандартным правилам протокола HTTP, и поэтому ее будет легко обнаружить. Но опытный злоумышленник, используя тонкие моменты в работе протокола HTTP и атакуемого Web-сервера, может исказить сигнатуру строки /cgi-bin/phf.

GET /%63%67%69%2d%62%69%6e/phf HTTP/1.0

Приведенная строка не соответствует в точности строке /cgi-bin/phf, но Web-сервер перед использованием полученной строки переведет каждый фрагмент %XX в соответствующий ASCII-символ. В запросе может также использоваться нечасто встречаемая форма указания директории самой на себя:

GET /cgi-bin/./phf HTTP/1.0

Включенные в состав запроса символы указания директории самой на себя /./ позволяют изменить сигнатуру уязвимости. Или пусть, для примера, атакуемый Web-сервер – информационный сервер Интернет (IIS) Windows NT (хотя phf – это программа интерфейса CGI системы UNIX). Тогда запрос можно оформить следующим образом:

GET /cgi-bin\phf HTTP/1.0

Приведенная строка маскирует сигнатуру искомой строки.

Недавно получил распространение способ маскировки данных, поставивший всех в тупик. Он основан на кодировании URL при помощи меняющих друг друга кодировок UTF-8 и Unicode, которые понимают сервера Microsoft IIS и некоторые другие. (UTF-8 – ASCII-совместимый многобайтовый код, применяемый в языке Java. Unicode – 16-битный стандарт кодирования символов, позволяющий представлять алфавиты всех существующих в мире языков). Для представления символов ASCII можно использовать 16-битное кодирование Unicode. Обычно приложения воспринимают эти 16-битные величины как неверные, хотя некоторые могут их обрабатывать.

/cgi-bin/../../../../winnt/system32/cmd.exe

В идеальном для злоумышленника случае это позволило бы ему получить доступ к корневой директории, а затем к системной директории WINNT и ее поддиректориям, вызвав программу операционной системы cmd.exe. Позволило бы, если бы информационный сервер Интернет не был достаточно умен, чтобы противостоять злоумышленнику и не позволить ему преодолеть систему безопасности. Меняя некоторые символы на их эквиваленты в Unicode-коде, злоумышленник может обмануть информационный сервер Интернет IIS, заставив его поверить в безопасность URL. После декодирования URL информационный сервер Интернет выполнит программу cmd.exe. Результат замены символов в URL может выглядеть так:

/cgi-bin/..%c0%af..%c0%af..%c0%af..%c0%afwinnt/system32/cmd.exe

В этом примере символ «/» заменен на 16-битный эквивалент в Unicode-коде с представлением в шестнадцатеричном формате «0xC0AF», который затем был перекодирован в URL как «%c0%af». Вместо символа «/» можно было закодировать в Unicode-коде любой другой символ. Символ «/» был использован только в качестве примера.

Будем надеяться, что читатель понял, какую проблему для безопасности представляют не предусмотренные разработчиком приложения данные, введенные пользователем. Следующее, что нужно узнать, – это уязвимо ли ваше приложение. Но как это сделать? Этот раздел посвящен наиболее общим методам, которые используются для определения уязвимости приложения и устранения их.

Тестирование методом «черного ящика»

В Web-приложениях проще всего найти уязвимости, вызванные вводом непредвиденных данных. Объясняется это их многочисленностью и широким распространением. Прежде всего следует исследовать HTML-формы и URL с параметрами (параметры – это значения после знака «?» в URL).

Для тестирования рекомендуется найти Web-приложение, которое поддерживает динамические страницы с большим количеством параметров в URL. Для начала можно использовать придирчивую методику поиска, основанную на замене некоторых значений параметров. Это не так уж и сложно. Для повышения эффективности поиска потенциальных уязвимостей следует придерживаться следующих правил.

Интуитивное понимание принципов работы приложения.Предусмотрена ли в приложении работа с электронными заказами? Если да, то, скорее всего, приложение взаимодействует с какой-нибудь базой данных. Предусмотрена ли возможность обратной связи с приложением после предъявления пользователю HTML-формы? Если да, то, скорее всего, после заполнения HTML-формы будет вызвана внешняя программа или процедура для отсылки электронной почты.

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

Умышленная попытка создания аварийной ситуации.Попытайтесь оставить некоторые поля ввода пустыми или ввести в них столько «плохих» символов, сколько возможно (поместите буквы туда, где должны быть цифры и т. п.). Цель подобных манипуляций – выяснить реакцию приложения на ошибку. Если приложение обнаружит ошибку, то реакция приложения поможет установить алгоритм проверки входных данных. Если приложение выдает диагностические сообщения об ошибке в данных или выводит уже исправленные значения, то следует поэкспериментировать с символами ASCII, чтобы определить, какие данные приложением отбраковываются, а какие – нет. Данные, отбракованные приложением, могут подсказать алгоритм обработки данных. Например, если приложение отсеивает одинарные или двойные кавычки, то данные, вероятнее всего, используются в запросах SQL. Если приложение избавляется от всех метасимволов командного процессора UNIX, то возможно, что они передаются в другую программу.