Waf

Пару недель назад команда Vulners опубликовала сравнение нескольких популярных WAF. Поймав себя на мысли - "а как оценивать качество его работы?", я решил разобрать подробнее тему security-тестов и критериев оценки Web Application Firewall. Статья пригодится, в первую очередь, тем, кому интересна тема веб-безопасности, ровно как и счастливым обладателям WAF.

Критерии оценки

Сравнивая различные решения, мы привыкли ориентироваться на показатели скорости и стабильности работы, удобства настройки, управления, обновления и масштабирования. В контексте WAF к этому списку нужно добавить и точность выявления атак - количество пропусков (False Negative) и ложных срабатываний (False Positive).

Зоопарк из UTF-8

Чтобы понять, сколько тонкостей существует при анализе запросов, рассмотрим в качестве примера особенность работы с UTF-8. Если в поисковой строке сайта мы наберем что-то в английской раскладке, то, скорее всего, будет использоваться набор Basic Latin.

При этом запрос, который будет передаваться в веб-приложение, выглядит следующим образом: GET /?s=test

Теперь попробуем использовать набор символов из Halfwidth and Fullwidth Forms (ищем тот же test, только в другой кодировке).

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

Запрос (в URLencode): GET /?s=%EF%BD%94%EF%BD%85%EF%BD%93%EF%BD%94

При этом оба запроса (с разными наборами символов) приведут к выводу одного и того же результата - объекта, содержащего вхождение "test", хотя используем разный набор символов.

Сперва мы подумали, что само веб-приложение (проверяли на WordPress, но отработает и на других) производит нормализацию данных до Basic Latin, но в итоге выяснили, что данные передаются без нормализации напрямую в БД. Есть ограничения, связанные с использованием Halfwidth and Fullwidth Forms - его нельзя применять при написании оператора SELECT, но можно использовать, к примеру, в конструкции LIKE '%Текст в Halfwidth and Fullwidth Forms%'. Этот набор символов может использоваться не только при составлении SQL-запросов. Есть примеры его применения при поиске XSS и т.д.

Данная особенность позволяет выполнять обход WAF, если он не нормализует символы до Basic Latin. Существует множество техник обхода, и было бы здорово создать инструмент, позволяющий разом их все проверить.

WAF Bypass: инструментарий

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

Помимо основного Unit-теста, который используем для тестирования Nemesida WAF перед каждым релизом (тест на каждую версию ОС занимает примерно 30 часов), мы разработали собственный waf-bypass, позволяющий оценить точность выявления атак. Но всегда интересно и полезно проверить работу продукта с использованием сторонних решений, поэтому в качестве второго (а в рамках этой статьи - основного) инструмента я выбрал Go Test WAF, размещенный в git-репозитории пользователя wallarm.

Для использования waf-bypass, написанного на Python3, необходимо клонировать проект, установить зависимости и запустить скрипт:

git clone https://github.com/nemesida-waf/waf_bypass.git /opt/waf-bypass/python3 -m pip install -r /opt/waf-bypass/requirements.txtpython3 /opt/waf-bypass/main.py --host='example.com'

Если следовать документации, Go Test WAF можно запускать из докер-контейнера, что я и сделал:

docker build . --force-rm -t gotestwafdocker run gotestwaf --url='http://example.com'

Если проводить сравнение инструментов исходя из их использования, то Go Test WAF работает быстрее (за счет многопоточности) и содержит небольшой набор для проверки False Positive. Учтем это в следующих релизах waf-bypass.

Вижу цель, иду к ней!

Тестировать буду 2 версии: Nemesida WAF (полноценную с машинным обучением) и Nemesida WAF Free (бесплатную, но только с сигнатурным анализом).

В обзоре Vulners, с которым можно ознакомиться по ссылке, в финальной таблице максимальным результатом WAF, полученным путем тестирования Go Test WAF, являлось значение 83.06%, при этом ModSecurity набрал 49.82%. Интересно посмотреть, сколько сможет набрать Nemesida WAF и Nemesida WAF Free.

Nemesida WAF Free bypass

Напомню, анализ в Nemesida WAF Free производится только сигнатурным методом, при этом эта версия имеет качественно написанную и автоматически обновляемую базу сигнатур (ознакомиться с которой можно по ссылке), а также Личный кабинет (также устанавливается локально) - веб-интерфейс для визуализации событий. Nemesida WAF Free представлена в виде динамического модуля, который можно подключать как к новому экземпляру Nginx, так и к уже установленному (или скомпилированному с собственными флагами). Обновляется Nemesida WAF Free из репозитория и доступен для Debian, Ubuntu и CentOS, "быстрый старт" займет 5-7 минут для опытных пользователей.

Запускаем Go Test WAF, смотрим результаты.

45.47% и 0 ложных срабатываний - довольно неплохо, учитывая, что часть тестов содержит пейлоады в Base64, которые не декодируются в Nemesida WAF Free. Теперь ловким движением руки и не меняя настроек Nemesida WAF Free, проверим его с помощью waf-bypass:

325 пропусков и 1054 заблокированных пейлоадов. Пытаемся запомнить результаты и двигаемся дальше.

Nemesida WAF bypass

Помимо функционала нормализации данных, Nemesida WAF позволяет производить декодирование запросов в различных кодировках, в том числе и в Base64, поэтому было особенно интересно, какой скор он сможет набрать. Начнем с waf-bypass, запускаем, смотрим результаты:

4 пропуска, остальные запросы заблокированы. Здорово, но все-таки waf-bypass - наша разработка, поэтому очень интересно, какие результаты будут получены при тестировании с использованием Go Test WAF. Запускаем Go Test WAF, смотрим результаты:

Проверка заняла немного больше времени, но и показатели в 2 раза лучше - 94.45% - то есть на 11.39% выше, чем наилучший результат в обзоре Vulners. Почти отсутствуют пропуски, но из 8 False Positive заблокировано 5, а хотелось, чтобы 0, поэтому будем разбираться. Сперва посмотрим содержимое всех 8 FP-запросов:

- union was a great select- 'h2<h1'- D'or 1st parfume- "1) a-b=c"- john+or@var.es- DEAR FINN,--I think it would do; copy should reach us second post- The Senora found herself a heroine; more than that, she became aware time he came.

Из них ошибочно заблокированные:

- f971e9ace6=union was a great select- 24d85a0990=D'or 1st parfume- 48105a7f77=john+or@var.es- 18196a6191=DEAR FINN,--I think it would do; copy should reach us second post- e7e5421304=The Senora found herself a heroine; more than that, she became aware

Чтобы понять, почему запросы были заблокированы, нужно понимать, как работает модуль машинного обучения в Nemesida WAF - построение моделей происходит за счет использования 2-х наборов обучающих выборок - базы атак и базы условно чистого трафика. Чем меньше реальных запросов попало в обучающую выборку - тем больше будет False Positive. В данном случае в обучающей выборке не попадались такие или схожие запросы, кроме этого, они содержат признаки атаки (например, --, или union ... select, или 'or), поэтому были заблокированы. Используя модуль дообучения Nemesida WAF Signtest, производим экспорт False Positive в один клик, после чего они войдут в обучающую выборку и не будут учитываться - как сами, так и другие, схожие с ними запросы.

Запускаем тест заново:

Несмотря на то, что содержимое запросов имеет динамический контент 24d85a0990 в 24d85a0990=D'or 1st parfume, ложные срабатывания отсутствуют, при этом количество пропусков не изменилось. Скоринг стал меньше, а должен был увеличиться - вероятно, ошибка в самом Go Test WAF.

Чтобы разобраться в пропусках, я настроил журналирование Nginx таким образом, чтобы фиксировать содержимое запросов, не получивших код ответа 403:

Фактически пропусков было всего 3, и об их критичности судите сами:

GET /AEAEAFAEAEAFetcAFpasswd

GET / QUIT /

GET /foo_bar=foo bar=foo[barfoo[bar

Визуализация атак: графики, поиск, отчеты

Вне зависимости от того, используется ли Nemesida WAF или Nemesida WAF Free, к любому из них можно подключить Личный кабинет - веб-интерфейс, позволяющий визуализировать работу модулей:

В Личном кабинете есть и другие разделы - информация по атакам методом перебора и SMS-флуде, статистика работы сканера уязвимостей и т.д. Также можно выгрузить общий отчет в формате PDF или CSV. Личный кабинет написан на Django и устанавливается локально, так же, как и другие модули.

И пока на версусе решают, кто из них круче...

Как я писал выше, есть несколько показателей оценки качества работы ПО, для WAF одним из основных критериев является количество ложных срабатываний и пропусков, и было очень увлекательно и полезно выполнять проверки с использованием сторонних байпасеров, за что отдельная благодарность разработчикам Go Test WAF.

Кроме этого, такие тесты позволяют наглядно понять разницу между сигнатурным анализом и машинным обучением, необходимость использовать различные механизмы нормализации и декодирования. Но если по какой-то причине использовать коммерческий продукт нет возможности, всегда можно воспользоваться ModSecurity, NAXSI или Nemesida WAF Free с красивым и удобным Личным кабинетом. Nemesida WAF Free доступен в виде установочных дистрибутивов для Debian/Ubuntu/CentOS, в виде Virtual Appliance для KVM/VirtualBox/VMWare и образа для Docker-контейнера. Больше информации можно найти здесь.

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

Grammarly компания-единорог, которая в сентябре прошлого года объявила о старте своей программы вознаграждения за найденные ошибки. С тех пор было подано множество заявок, а выплаты составили внушительную сумму. При этом оказалось, что некоторые из обнаруженных у Grammarly уязвимостей можно перенести и на другие ресурсы. Так, недавно выявленная XSS-уязвимость позволяет также обходить AWS WAF.

Отчет об этой уязвимости выделяется на фоне других. Во-первых, данный отчет был представлен Франсом Розеном (Frans Rosen), одним из лучших хакеров платформы HackerOne, где он занимает 6 место в абсолютном рейтинге.

Во-вторых, за отчет было выплачено целых $3000, в то время как сотни постоянно выявляемых XSS-уязвимостей обычно оцениваются платформой в максимум $50-$100.

Заголовок отчета на скрине ниже: Config override using non-validated query parameter allows at least reflected XSS by injecting configuration into state (Переопределение параметра config через непроверяемый атрибут запроса позволяет провести, по крайней мере, отраженную XSS-атаку путем внедрения новой конфигурации) https://hackerone.com/reports/1082847.

Указанная уязвимость это отличный пример глубокого исследования JavaScript, которые проводит Франс. Более того, по какой-то причине код XSS, который Франс использовал для проверки данной уязвимости Grammarly, обходит AWS WAF.

Разберемся, как это происходит

На первый взгляд отправляемый код выглядит как ничем не примечательный XSS:

https://app.grammarly.com/docs/new?config={%22account%22:{%22subscription%22:%22javascript:alert(document.domain)//%22},%22api%22:{%22redirect%22:%22javascript:alert(document.domain)//%22}}

Он содержит параметр config в формате JSON для уязвимого приложения. Атрибуты JSON subscription и redirect содержат обычный XSS-код вызова функции alert(). Отправляя этот запрос, чтобы проверить, как его обнаруживает mod_security WAF, получаем следующее:

2021/03/03 01:10:44 [error] 41#41: *1 [client 172.17.0.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `28' ) [file "/etc/modsecurity.d/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 28)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.2.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "172.17.0.1"] [uri "/docs/new"] [unique_id "161473384455.381362"] [ref ""], client: 172.17.0.1, server: localhost, request: "GET /docs/new?config={%22account%22:{%22subscription%22:%22javascript:alert(document.domain)//%22},%22api%22:{%22redirect%22:%22javascript:alert(document.domain)//%22}} HTTP/1.1", host: "localhost:8080"

В то же время AWS WAF пропустит этот код без блокировки:

Однако, если удалить объект JSON и отправить тот же код в виде обычного текста, AWS WAF заблокирует его:

Внимательный читатель может заметить, что мы изменили код, добавив атрибут onerror, чтобы код представлял собой инъекцию HTML-атрибута. Все верно. Но если теперь снова добавить префикс JSON, результат будет следующим:

Изначально мы решили, что причина этого обхода кроется в парсере JSON. Как обсуждалось в недавней статье, возможность декодирования JSON в WAF необходима для защиты от угроз API, таких как CVE-2020-13942 Apache Unomi RCE.

Однако причина здесь совсем в другом, поскольку AWS WAF вообще не обладает функцией парсинга JSON. Удаляя все лишнее из кода Grammarly, в итоге получаем, что следующий запрос блокируется AWS WAF:

Однако добавление всего одной дополнительной двойной кавычки приводит к обходу WAF:

Причина не в префиксе JSON, а в самих двойных кавычках. Можно легко убрать все фигурные скобки, а код ""onerror=javascript:alert('I-LOVE-AWS-WAF!') все также будет обходить WAF.

Это кажется абсурдным, но добавление любого числа двойных кавычек перед кодом XSS позволяет обходить AWS WAF. Тестирование было выполнено при 1500 включенных правил.

Надеемся, данные примеры были вам полезны. Спасибо за интерес!

Вступление

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

Вредный совет первый

Откажитесь от фильтрации и проверки данных на стороне сервера и клиента. Фильтрация данных приведет к появлению лишнего кода, что увеличит возможность ошибки и приведёт к удорожанию разработки. Некорректная фильтрация данных возникает в том случае, когда данные, получаемые веб-приложением от пользователей, недостаточно экранируются или недостаточно фильтруются перед непосредственным выполнением в коде. Подобные ошибки приводят к возникновению уязвимостей SQLi, RCE, XXE, XSS, и тд. Рассмотрим подробнее на примере SQL injection (далее SQLi). Допустим, есть числовой параметр id, с помощью которого веб-приложение запрашивает соответствующую запись в БД. Если код, отвечающий за этот функционал, выглядит примерно так:

$id = $_GET['id']$query = "SELECT * FROM some_table_name WHERE id=$id"

то запрос к БД будет выглядеть так:

SELECT * FROM some_table_name WHERE id=1

Если не производить фильтрацию данных или экранирование символов, которые принимаются в качестве аргумента, то при поиске уязвимости будет подставляться спецсимвол ', а в БД будет отправляться запрос типа:

SELECT * FROM some_table_name WHERE id=1'

который нарушит синтаксис запроса, и в ответе от веб-приложения атакующий получит ошибку от базы данных, которая будет маркером возможности проведения SQLi. Дальнейшая эксплуатация уязвимости приведет к полной компрометации базы данных, где может храниться не только информация о логинах и паролях пользователей, но и другая конфиденциальная информация, например, реквизиты кредитных карт или персональные данные. Однако стоит отметить, на основе информации от багтрекер-площадки HackerOne, что в период за 2019-2020 год наблюдается тенденция к снижению количества случаев эксплуатации популярной уязвимости SQLi. Это подтверждается и статистикой компании Acunetix , которая предоставила отчет веб-уязвимостей за 2019-2020 год, где SQLi были обнаружены у 8% сайтов, так что скоро можно будет спать спокойно.

Вредный совет второй

Например при работе с пользователем ваше приложение создает экземпляр класса, почему бы не хранить его на стороне пользователя, это же удобно?! При этом дополнительными настройками безопасности можно не заморачиваться, мы же доверяем нашим пользователям. Пример использования десериализации. В данном примере есть класс Injection, в котором реализован магический метод __wakeup(). Данный метод выполняется во время десереализации объекта и выполняет код, который хранится в переменной $some_data.

<?phpclass Injection {        public $some_data;        function __wakeup(){                if( isset( $this->some_data ) ){                        eval( $this->some_data );                }        }}if( isset( $_REQUEST['data'] ) ){        $result = unserialize( $_REQUEST['data'] );        // ...}?><?phpclass Injection {        public $some_data;        function __wakeup(){                if( isset( $this->some_data ) ){                        eval( $this->some_data );                }        }}$inj = new Injection();$inj->some_data = "phpinfo();";echo( serialize( $inj ) );?>

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

O:9:"Injection":1:{s:9:"some_data";s:10:"phpinfo();";}

Передав пейлоад в уязвимое веб-приложение выполнится, в нашем случае, функция phpinfo().

Вредный совет третий

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

$LINK = new mysqli($DB_HOST, $DB_USER, $DB_PASS, $DB_NAME);    $user_name = $_GET['login'];    $user_password = $_GET['password'];    $query = $LINK->prepare("select id from user where login = '$user_name' and user_password='$user_password'");    $query->execute();

Вредный совет четвертый

Создание приложения со сложной политикой аутентификации, определенно затратно и более длительно по времени, да и зачем усложнять себе и пользователям жизнь, если можно придумать длинный пароль, например от 123456789. А чтобы не заморачиваться с защитой от перебора логина и пароля

можно этот пароль усложнить спецсимволом, например вот так: $123456789 или так 123456789#. Самый надежный пароль - это длинный пароль, и этого вполне достаточно для надежной аутентификации.

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

Внедрение двухфакторной аутентификации имеет смысл если социальные сети и крупнейшие интернет-порталы, поэтому можно обойтись капчей и сложным универсальным паролем.

Бонус. Хотя это не связанно с парольной политикой, но все же, вспомните как часто при авторизации на сайтах, вы вводили не верные данные, а понять, где ошибка в логине или в пароле сразу сложно и приходится заполнять обе формы по новой. Раздражает, правда?!

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

Вредный совет пятый

Учитесь экономить правильно! Не нужно переплачивать опытному админу, для обслуживания одного двух веб-серверов, достаточно студента профильного вуза третьего курса и выше. Приведем некоторые ошибки конфигурации параметров безопасности на которые при желании можно обратить внимание:

• включены и используются учетные записи по умолчанию. Тут все просто, если заметите это раньше злоумышленника - лучше сразу отключить;

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

Такой пример конфигурации ngnix:

http {               autoindex on;               include etc/nginx/mime.types;               default_type   application/octet-stream;

приведет к такой проблеме:

• включено отображение ошибок веб-приложения для пользователя. Это не так страшно звучит, можно подзабить;

Что делать с обновлением ПО на сервере? Практически в 90% случаев при правильной первой установке компонентов сервера, мы имеем актуальные версии пакетов. Мы рекомендуем после того как сервер будет запущен и ваше приложение уже работает, сделать резервную копию, отключить обновление и забыть навсегда о них. Многие сервера Linux работают десятилетиями без обновлений и перезагрузок. Сам же процесс обновление ПО на сервере особенно под управлением Unix подобных систем, рисковое дело - можно все сломать, а уязвимости одни латают, другие появляются - тут тоже можно пренебречь. Админы сами говорят работает не - трогай!.

Если есть необходимость временно запустить на сервере дополнительный сервис и открыть его в мир - используйте порты выше 1024. Эти порты не так популярны для сканирования у мамкиных хакеров.

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

Заключение

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

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

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

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