Методы обхода межсетевых экранов для приложений Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.056

МЕТОДЫ ОБХОДА МЕЖСЕТЕВЫХ ЭКРАНОВ ДЛЯ ПРИЛОЖЕНИЙ

Владимир Геннадьевич Мельников

Сибирский государственный университет геосистем и технологий, 630108, Россия, г. Новосибирск, ул. Плахотного, 10, магистрант кафедры наносистем и оптотехники, тел. (952)938-59-98, e-mail: [email protected]

Александр Владимирович Трифанов

Сибирский государственный университет геосистем и технологий, 630108, Россия, г. Новосибирск, ул. Плахотного, 10, аспирант, тел. (923)257-37-48, e-mail: [email protected]

В данной работе рассматривается применение Web Application Firewall (WAF) для защиты веб-приложений от атак. Рассмотрены основные виды и функции WAF и их эффективность. Показано, что несмотря на высокую степень защиты, WAF помогает защититься только от простых атак.

Ключевые слова: межсетевой экран для веб-приложений, обход защиты межсетевых экранов.

WAF BYPASS

Vladimir G. Melnikov

Siberian State University of Geosystems and Technologies, 630108, Russia, Novosibirsk, 10 Plakhotnogo St., undergraduate of the Department of Nanosystems and Optical Engineering, tel. (952)938-59-98, e-mail: [email protected]

Aleksandr V. Trifanov

Siberian State University of Geosystems and Technologies, 630108, Russia, Novosibirsk, 10 Plakhotnogo St., graduate student, tel. (923)257-37-48, e-mail: [email protected]

This paper examies Web Application Firewall (WAF) using to protect web applications from attacks. The effectiveness of WAF basic types and functions are considered. It is shown that the WAF helps to prevent only simple attacks despite the high protection degree.

Key words: Web Application Firewall, WAF bypass.

Для защиты различных сервисов используются - межсетевые экраны, системы обнаружения вторжения, антивирусное ПО и системы управления угрозами. Для веб-приложений существует своя специфика и она предполагает, что за один сеанс работы пользователя с веб-сервером может осуществляться большое количество различных TCP-соединений, которые открываются с различных адресов, но имеют один (возможно динамический) идентификатор сессии. Это приводит к тому, что для эффективной защиты веб-трафика необходима платформа на основе полнофункционального реверс-прокси-серверах[4].

Но разница в технологической платформе - не единственное, что отличает защиту веб-приложений. Это создает целый ряд новых угроз, с которыми традиционные межсетевые экраны не справляются. По оценкам компании Positive

Technologies, в 2014 году 60 % атак на корпоративные сети осуществлялись через веб-приложения, невзирая на наличие традиционных защитных средств [1].

Для предотвращения таких угроз используется Web Application Firewall (WAF), защитный экран для приложений, осуществляющих передачу данных через HTTP и HTTPS. Его предназначение - решение проблем, связанных с угрозами конфиденциальности, целостности и доступности данных сайтов, которые можно получить, произведя эксплуатацию уязвимости, либо иным способом. В любом коде серьезного приложения возможны ошибки. Злоумышленники используют их, чтобы получить несанкционированный доступ к данным владельцев и пользователей сайтов. Необходимо не только своевременно обнаружить и блокировать атаки на приложения, но и устранить возможность эксплуатации уязвимостей. Следующие функции отличают WAF от защитных систем предыдущих поколений:

- автоматическое обучение, поведенческий анализ;

- защита пользователей;

- сканер уязвимостей;

- виртуальный патчинг;

- корреляция, цепочки атак.

Технология WAF достаточно эффективна - отражает до 98 % атак. Но несмотря на свою эффективность, имеются и недостатки. Существует несколько вариантов обхода WAF. Но перед этим нужно сначала разобраться, как же выглядит механизм работы Web Application Firewall [2]. Этапы обработки входящего трафика в большинстве WAF одинаковы и условно выделяют 5 этапов:

- Парсинг HTTP-пакета, который пришел от клиента.

- Выбор правил в зависимости от типа входящего параметра.

- Нормализация данных до вида, пригодного для анализа.

- Применение правила детектирования.

- Вынесение решения о вредоносности пакета. На этом этапе WAF либо обрывает соединение, либо пропускает дальше - на уровень приложения.

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

- регулярные выражения;

- токенайзеры, лексические анализаторы;

- репутация;

- выявление аномалий;

- score builder.

Большинство WAF используют именно механизмы регулярных выражений для поиска атак. На это есть две причины. Во-первых, так исторически сложилось, ведь именно регулярные выражения использовал первый WAF, написанный в 1997 году. Вторая причина также вполне естественна - это простота подхода, используемого регулярными выражениями. Регулярные выражения вы-

полняют поиск подстроки в тексте. Web Application Firewall обладают следующими недостатками:

- Невозможно полностью защитить Web-приложения от всех возможных уязвимостей.

- Обработка возвращаемого трафика клиенту.

- При использовании универсальных фильтров WAF приходится балансировать между эффективностью фильтра и минимизацией ошибок блокировки легитимного трафика [3].

Выделяют следующие типы обхода WAF за счет уязвимости в правилах:

- Модификаторы, числовые квантификаторы и позиционные указатели.

- Ошибки логики.

- Особенности парсеров и опечатки.

- Уязвимые регулярные выражения.

- Использование новых техник эксплуатации уязвимостей в Web (HTTP Parameter Pollution, HTTP Parameter Fragmentation, замена null-byte и т. д.).

Для демонстрации обхода за счет уязвимости в модификаторах. числовых квантификаторов и позиционных указателей будет использоваться следующий пример:

if( !preg_match("/A(attackpayload){1,3}$/", $_GET['a']) ) { _exec($cmd . $_GET['a'] . $arg); }

Это выражение, которое защищает функцию _exec(). Регулярное выражение пытается найти паттерн attackpayload в GET-параметре a и, если он найден, предотвратить исполнение вредоносного кода.

В этом коде есть как минимум три проблемы. Первая из них - это регистр. Выражение не учитывает регистр, поэтому, если использовать нагрузку разного регистра, ее удастся обойти: atTacKpAyloAd. Исправить это можно при помощи модификатора (?i), благодаря которому регистр не будет учитываться.

Вторая проблема - это символы начала и конца строки (л$). Выражение ищет вредоносную нагрузку, жестко привязываясь к позиции в строке. В большинстве языков, для которых предназначается вредоносная нагрузка (например, SQL), пробелы в начале и в конце строки не влияют на синтаксис. Таким образом, если добавить пробелы в начале и конце строки, защиту удастся обойти: attackpayioad .Чтобы не допускать подобного обхода, нужно обращать особое внимание на то, как используются явные указатели начала и конца строки.

К последней проблеме относятся квантификаторы. В данном примере это квантификаторы {1,3}. Регулярное выражение ищет количество вхождений от одного до трех.

Соответственно, написав полезную нагрузку четыре или более раз, можно ее обойти: attackpayloadattackpayloadattackpayloadattackpayload...

Исправить это можно, указав неограниченное число вхождений подстроки (+ вместо {1,3} ). Квантификатора {m,n} вообще следует избегать. Например, раньше считалось, что четыре символа - это максимум для корневого домена (к примеру, .info), а сейчас появились TLD типа .university. Как следствие,

регулярные выражения, в которых используется паттерн {2,4}, перестали быть верными, и открылась возможность для обхода.

Ниже представлены примеры обхода, основанные на ошибках логики:

1) (a+)+;

2)a'\s+b;

3) a[\n]*b.

Первое выражение - это пример так называемого ReDoS, отказа в обслуживании при парсинге текста уязвимым регулярным выражением. Проблема в том, что это регулярное выражение будет обрабатываться парсером слишком долго из-за чрезмерного количества вхождений в строку. То есть если мы передадим aaaaaaa....aaaaaaaab, то в некоторых парсерах такой поиск будет выполнять 2An операций сравнивания, что и приведет к отказу в обслуживании запущенной функции.

Второй пример демонстрирует, что здесь был выбран неправильный квантификатор. Знак + в регулярных выражениях означает «1 или более». Соответственно, мы можем передать «а'-пробел-0-раз-Ь», тем самым обойдя регулярное выражение и выполнив вредоносную нагрузку.

В третьем выражении используется черный список. Всегда нужно помнить, что большинству Unicode-символов существуют эквивалентные альтернативы, которые могут быть не учтены в списке регулярных выражений. Использовать черный списки нужно с осторожностью. В данном случае обойти правило можно так: a\rb.

Обходы, осуществляемые за счет особенностей парсеров и опечаток будет демонстрироваться на следующих примерах:

1) [A-z];

2)[digit];

3) a |b,a||b;

4) \11 \e \q.

Первый пример содержит слишком широкий разрешенный диапазон. Кроме желаемых диапазонов символов a-z и a-z, такое выражение разрешает еще и ряд спецсимволов, в числе которых \,,[,] и так далее, что в большинстве случаев может привести к выходу за контекст.

В следующем выражении отсутствует двоеточие до и после класса digit (POSIX character set). В данном случае это просто набор из четырех символов, все остальные разрешены.

Третье выражение предполагает две особенности. В первом случае допущен лишний пробел - такое выражение будет искать не «а или Ь», а «а пробел, или Ь». Во втором случае подразумевался один оператор «или», а написано два. Такое выражение найдет все вхождения а и пустые строки (ведь после | идет пустая строка), но не Ь.

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

обрабатываться по-разному. В этом примере \11 может быть как бэклинком с номером 11, так и символом табуляции (0x09 в восьмеричном коде); \e может интерпретироваться как очень редко описываемый в документации wildcard (символ Esc); \q - просто экранированный символ q. Казалось бы, один и тот же символ, но читается он по-разному в зависимости от условий и конкретного парсера.

Несмотря на то, что WAF отражает большое количество атак, он все же несовершенен. Принципы его работы имеют хорошие перспективы и позволяют отражать несложные и автоматические атаки злоумышленников.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Positiveresearch 2015. Сборник исследований по практической безопасности [Электронный ресурс]. - Режим доступа: https://www.ptsecurity.com/upload/corporate/ru-ru/download/PT_Positive_Research_2015_RU_web.pdf.

2. Приручаем WAF'bi. Как искать байпасы в современных Web Application Firewalls и что с ними делать [Электронный ресурс]. - Режим доступа: https://xakep.ru/2016/12/19/web-application-firewalls-bypasses

3. Евтеев Д. О. Методы обхода Web Application Firewall [Электронный ресурс]. - Режим доступа: https://www.ptsecurity.com/upload/corporate/ru-ru/download/PT-devteev-CC-WAF.pdf.

4. Чем защищают сайты, или зачем нужен WAF? [Электронный ресурс]. - Режим доступа: https://habrahabr.ru/company/pt/blog/269165/.

© В. Г. Мельников, А. В. Трифанов, 2017