В качестве примера рассмотрим 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-binphf HTTP/1.0
Приведенная строка маскирует сигнатуру искомой строки.
Недавно получил распространение способ маскировки данных, поставивший всех в тупик. Он основан на кодировании URL при помощи меняющих друг друга кодировок UTF-8 и Unicode, которые понимают сервера Microsoft IIS и некоторые другие. (UTF-8 – ASCII-совместимый многобайтовый код, применяемый в языке Java. Unicode – 16-битный стандарт кодирования символов, позволяющий представлять алфавиты всех существующих в мире языков). Для представления символов ASCII можно использовать 16-битное кодирование Unicode. Обычно приложения воспринимают эти 16-битные величины как неверные, хотя некоторые могут их обрабатывать.
Хорошим примером, иллюстрирующим возможности перехода к представлению данных на Unicode-коде, является уязвимость, исправленная патчем Microsoft MS00-078. Ранее можно было обмануть информационный сервер Интернет IIS и получить доступ к файлам, размещенным за пределами Web-директории, при помощи обращения к родительской директории. Пример подобного трюка с URL выглядит так
/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, то возможно, что они передаются в другую программу.
Систематичная проверка каждого параметра на возможность его заключения сначала в одинарные (), а затем двойные кавычки ("). Если при заключении параметра в одинарные или двойные кавычки приложение сообщает об ошибке, то это может означать передачу в запрос SQL параметров без всяких изменений. При экспериментах с кавычками (одинарными или двойными) проверяется возможность обработки строк в запросах SQL. Если приложение сообщает об ошибке, следует определить, является ли это реакцией приложения на неверные данные (в кавычках) или на ошибку выполнения запроса SQL (что вполне может быть в случае лишних кавычек).
Определение необходимости и/или полезности каждого параметра. Длинные последовательности строк и чисел, похожие на случайные последовательности, могут быть ключами сессий. Следует несколько раз выполнить ввод одних и тех же данных. Увиденные изменения могут многое сказать о сессии. Насколько сильны изменения? Обратите внимание, изменяется ли длина строки линейно. Некоторые приложения используют идентификатор процесса (PID) в качестве «случайного числа». Возрастающее число, меньшее 65 536, может быть основано на идентификаторе процесса.
Анализ общего состояния Web-сайта и приложения и его использование для предположений об алгоритме работы приложения. Малобюджетные компании, применяющие в своей работе информационный сервер Интернет IIS для Windows NT, вероятнее всего, используют на серверах баз данных Microsoft Access, а крупные корпорации, поддерживающие одновременную работу большого числа пользователей, используют что-то более солидное типа Oracle. Если на сайте используются сценарии интерфейса CGI, загруженные с многочисленных Интернет-ресурсов, то можно предположить, что приложения сайта не писались наспех и полностью адаптированы к потребностям своего сайта. Следует попытаться обнаружить, используется ли на сайте уже известное приложение. И если используется, то попытаться найти его исходный код.
Поиск имени файла. Следует не упустить из виду чего-нибудь, напоминающее имя файла. Имена файлов близки к формату «8.3» (который порожден операционной системой CP/M и был перенят в Microsoft DOS). Признаками имени файла являются строки «.tmp» и строки, состоящие только из букв, чисел, точек и, возможно, символов косой черты (прямой или обратной, в зависимости от используемой платформы). Рассмотрим указатель информационного ресурса URL для машины индексированного поиска в сети Интернет swish-e компании Simple Web Indexing System for Humans, Enhanced:
