Фаззинг веб-приложений, защищенных модулем Apache mod_rewrite Текст научной статьи по специальности «Компьютерные и информационные науки»

bridge, Massachusetts, USA. 2005. - Режим доступа: http://groups.csail.mit. edu/infolab/publications/TREC2005.pdf.

5. AQUA [Электронный ресурс]. - Режим доступа: www.aktors.org/ technologies/aqua.

6. Vargas-Vera M., Motto E., Domingue J. An Ontology-Driven Questinon Answering System (AQUA) [Электронный ресурс] / Knowledge Media Institute (KMi), The Open University, Walton Hall, Milton Keynes, UK 2003. - Режим доступа: http://www.aktors.org/technologies/aqua/SS803MVargas-Vera.pdf.

7. TrueKnowledge - technology [Электронный ресурс]. - Режим доступа: http://corporate.trueknowledge.com/technology.

8. TrueKnowledge - architecture [Электронный ресурс]. - Режим доступа: http://corporate.trueknowledge.com/architecture/

9. Answer.com [Электронный ресурс]. - Режим доступа: http://wiki.an-swers.com/about.

10. WolframAlpha [Электронный ресурс]. - Режим доступа: www.wolf-ramalpha.com/about.html.

11. WolframAlpha FAQ [Электронный ресурс]. - Режим доступа: www.wolf-ramalpha.com/faqs.html.

ФАЗЗИНГ ВЕБ-ПРИЛОЖЕНИЙ, ЗАЩИЩЕННЫХ МОДУЛЕМ APACHE MOD_REWRITE

© Полухин П.В.*

Воронежский государственный университет, г. Воронеж

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

В современных условиях в сети Интернет все чаще можно встретить сайты, которые скрывают передаваемые параметры приложений посредством модуля Apache - mod_rewrite. Это зачастую создает у web-разработчиков иллюзию возможности защитить web-приложения от атак с использованием уязвимостей SQL Injection, Cross-Site Scripting и прочих. Однако мы считаем, что это является распространенным заблуждением, подобно тому, что сокрытие fingerprint (отпечатков) сервисов увеличивает безопасность этих сервисов. Безусловно, использование mod_rewrite для сокрытия передаваемых параметров к приложению, также как и сокрытие отпе-

* Аспирант кафедры Математических методов исследования операций.

чатков является некоторой преградой для атакующего. Но, как говорится, «нет такой преграды, которую нельзя было бы обойти».

Целью исследования является анализ фаззинга веб-приложений, защищенных mod_rewrite для анализа наличия в них уязвимостей.

Исследовав отечественные и зарубежные труды известных ученых-программистов, мы пришли к мнению, что mod_rewrite - достаточно мощный инструмент для URL-преобразований «на лету». Этот модуль web-сервера Apache предоставляет широкие возможности для поисковой оптимизации (SEO); защиты от прямых загрузок, путем сокрытия реального местоположения файла; сокрытия иерархии поступающих параметров, каталогов и сценариев web-приложения путем их централизованного динамического преобразования; разграничения доступа; mod_rewrite может проверять значения HTTP-заголовков, в том числе значение COOKIE на соответствие правилам и по результатам проверок проводить (не проводить) перенаправление.

Чаще всего в практической деятельности, настроенный модуль mod_re-write затрудняет возможности поиска и эксплуатации уязвимостей web-приложений. Мы считаем, что основными причинами вышеперечисленных проблем выступают следующие аспекты.

Во-первых, трудно распознать реальное предназначение элемента URL. Например, если есть ссылка, имеющая следующий вид http://www.example. com/ search/stroka_poiska, то невозможно понять, какой из элементов URL является относительным путем от корневого каталога web-сервера, что является названием сценария, а что является параметром этого сценария. Это сильно затрудняет анализ структуры web-приложения. Например, следующие правила позволят одной и той же ссылке соответствовать различным реальным представлениям структуры web-приложения: RewriteRule Asearch/(.+)$ search.php?search=$1

При таком правиле ссылка http://www.example.com/search/stroka_ poiska соответствует сценарию search.php, который располагается в папке /main/ относительно корневого каталога web-сервера, вызванному с параметром search=stroka_poiska.

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

Например, данные правила:

RewriteRuleA(.+)/(.+)$script1.php?value1=$2&value2=$3 RewriteRuleA(.+)/(.+)/(.+)$ script2.php?value1=$2&value2=$3 отправят 2 схожих запроса разным сценариям: http://www.example.com/stroka1/stroka2 http://www.example.com/stroka1/stroka2/stroka3

Во-вторых, трудно определить язык программирования, на котором написано приложение. За ссылкой http://www.example.com/main/articles/

statya.html может находиться как серверный сценарий на языке PHP или ASP или Perl, так и статическая страница на языке HTML.

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

В четвертых, при автоматизации поиска уязвимостей необходимо заменять некоторые символы (например, слеш - / на %2F (hexadecimal encoding) или %252F (double encoding)) по причине их обработки еще на стадии «разбора» URL-адреса mod_rewrite-ом.

В связи с этим, многие разработчики и администраторы предпочитают «маскировать» наличие уязвимостей с помощью mod_rewrite, а не обнаруживать и исправлять проблемы. Но такой подход, как и любой метод, основанный на подходе «Security Through Obscurity» имеют существенные недостатки в работе.

В связи, с чем нами раскроем методику работы веб-приложений, защищенных посредством модуля Apache - mod_rewrite.

Основная идея поиска уязвимостей при включенном mod_rewrite - это перебор (brute-force), позволяющий определить реальные имена реальных параметров серверных сценариев, в которые подставляются значения из правил перезаписи (rewrite rules) mod_rewrite. Основные особенности перебора:

- использование в одном запросе множества параметров (количество параметров ограничивается максимальной длиной URL - (по умолчанию для web-сервера Apache 2.x - 8192 символа, для IIS -16 384 символа);

- применение метода бинарного поиска (дихотомии) [4] для обнаружения необходимых параметров;

- словарный перебор (использование популярных названий параметров и префиксов) - id, count, и т.д. в сочетании с полным перебором названий параметров (комбинированные атаки);

- различные варианты анализа результатов;

- возможность рекурсивного поиска параметров (для поиска всего множества параметров одного сценария).

Рассмотрим сущность алгоритма поиска уязвимостей в web-приложе-нии при включенном mod_rewrite.

Первый этап - определение реального имени серверного сценария. Используются стандартные и популярные названия сценариев, такие как index.php, main.php. Необходимо определить, существует ли данный сценарий или нет (например, по наличию ошибки «404 - Not Found»).

Второй этап предполагает определение параметров поступающих в приложение. Наиболее часто разработчиками web-приложений используются названия параметров, такие как id, file и т.д. Учитывая это, необходимо проверить:

- самые популярные названия переменных (id, path, page, debug, cat и проч.) - словарь популярных названий;

- короткие названия переменных (1-5 символов) в алфавите [a-z0-9-_] -полный перебор;

- «гибридные» названия - по формулам: «префикс» + «популярное название параметра» и «популярное название параметра» + «постфикс»;

- «полный перебор» + «разделитель (_,-)» + «популярное название параметра»;

- «популярное название параметра» + «разделитель (_,-)» «полный перебор».

Так же можно использовать: массивы GLOBALS (http://example.com/ index.php?GLOBALS[var]=value); стандартные переменные _SERVER (в определенных случаях можно перезаписать и их); переменные в сочетании с их zend_hash_key (для обхода уязвимых функций unset()).

Следующий этап состоит в определении значений параметров. Считаем, что для решения этой задачи важно использовать различные варианты параметров. Ведь, если, например, везде подставлять в значение =1, то велика вероятность, что оно совпадет со значением «по умолчанию» переменной и сервер вернет тот же ответ. Также различные параметры - это различные ошибки. А если проводить поиск по значению параметра в ответе (потенциальные XSS, Local File Including, Path Traversal), то для каждого параметра потребуется генерировать уникальное значение.

Оценка возможных вариантов, их предназначение, плюсы и минусы.

Числовое значение: 0,1,2,... Самый простой вариант. Можно обойтись 3 вариантами - 0,1 и больше 1. Из плюсов - минимальная длина строки запроса, что минимально сказывается на производительности работы.

Ошибочное значение: «../», «a%00» и т.д. - различные наборы символов, которые могут привести к потенциальным ошибкам, по сигнатурам которых можно определить присутствие параметра.

Фиксированное значение параметра. Например, если существует URL http://example.com search/stroka_poiska, то, зафиксировав ответ сценария на значение stroka_poiska и подставив это значение во все параметры, то по ответу, совпадающему с эталонным значением, можно будет найти параметр, отвечающий за конкретную позицию в URL-адресе.

Случайное число. Генерируя достаточно длинные случайные числа (59 символов), можно искать совпадение с этими числами в ответах сценариев. Случайные числа дают большую вероятность отсутствия ошибки второго рода (False Positive).

Четвертый этап - составление запроса и подбор данных. Составить запрос следующего вида, где ограничение на длину URL запроса составляет 8192 символа (для конкретного сервера Apache) http://example.com/ scriptphp?param1=value&param2=value&...&abc=value. Это означает, что

все параметры из алфавита [a-z0-9] длины до 4 символов переберутся примерно за 5880 запросов. При хорошей скорости интернета, это потребует 3-5 минут.

И наконец, на заключительном этапе проводится анализ ответов и определение наличия параметра.

Считаем, что эта часть работы алгоритма самая значимая, поскольку именно она определяет эффективность работы. Проведем сравнительную оценку различных походов.

Определение по длине ответа - самый быстрый и простой способ. Необходимо лишь узнать длину эталонного запроса и сравнивать ее с длиной запросов с параметрами, но неприменим в ситуациях, когда каждый раз сценарий генерирует ответ с уникальным содержимым.

Определение по сигнатурам случайных значений переменных позволяет уменьшить число ложных срабатываний, однако приводит к уменьшению скорости уз-за увеличения длины значений параметров (с 1-2 символов до 5-7 символов, что увеличивает время перебора почти в два раза).

Определение по сигнатурам ошибок - почти полное отсутствие ошибок второго рода (False Positive - ложное срабатывание), что исключает идентификацию наличия параметра в запросе, когда на самом деле его в нем нет, однако требуется использовать базу сигнатур ошибок.

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

Таким образом, результаты проведенного исследования позволяют считать, что приведенный метод подходит не только для оценки защищенности web-приложений, использующих mod_rewrite, но и для поиска переменных, которые могут быть перезаписаны при включенном параметре register_globals, а также для поиска недокументированных возможностей, таких как различные отладочные режимы и др. Это существенно повышает универсальность метода и его практическую ценность для конкретных хозяйствующих субъектов и иных структур.

Список литературы:

1. Теория и практика обеспечения информационной безопасности / Под ред. П.Д. Зегжда. - М.: Яхтсмен, 1996. - 292 с.

2. Игер Б. Работа в Internet / Б. Игер, А. Тихонова. - М.: БИНОМ, 1998. -313 с.

3. Саттон М. Fuzzing: исследование уязвимостей методом грубой силы / М. Саттон, А. Грин, П. Амини. - М.: Символ-Плюс, 2009. - 560 с.