Проблема непрерывной защиты веб-приложений – взгляд со стороны исследователей и эксплуатантов

Взгляд со стороны исследователей

Опираясь на нашу экспертизу в области Application Security, как offensive (анализ защищанности, пентесты и т.п.), так и defensive (построение SDLC, разработка SolidWall WAF), полагаем, что рассуждения о SOC, непрерывном мониторинге и WAF’ах скоро будут неотделимы от рассуждений о непрерывной разработке и особенностях этого процесса для того или иного приложения/сервиса.

Начнем с очевидной тенденции к сокращению длительности релизного цикла. Интересные факты:

• тенденция на уменьшение релизного цикла ПО именно как новый тренд отмечалась еще в 2001 году в статье Microsoft Research (визионеры?);
• статья о Continuous delivery в «Википедии» появилась в декабре 2011 года;
• в 2014 году появилась Continuous Delivery Conference ;
• в последние 5 лет появляются статьи по изучению наблюдаемых феноменов (например, “Continuous Software Engineering and Beyond: Trends and Challenges”) с анализом собственного опыта (например, “Continuous delivery? easy! just change everything (well, maybe it is not that easy)”) и т.п.

Короткие релизные циклы переформатируют перечень причин и мотивов, которые делали целесообразным использование традиционных мероприятий – привлечения внешних консультантов для поиска недостатков (неважно, каким методом – «белым» или «черным» ящиком), ручного тестирование собственной QA- или security-командой. Действительно, схема «проверил код релиза и живи полгода спокойно до следующего» больше не работает. В разработке с короткими релизными циклами перечисленные «традиционные» мероприятия рассматриваются уже более зрело: как источник обратной связи на процессы и их обеспечение всем необходимым – инструментами, людьми, методиками.

Наши консультации по SDLC часто начинаются на начальном этапе проекта, когда есть только идея. Целевые показатели по защищенности разрабатываемого приложения/сервиса мы прорабатываем и утверждаем с заказчиком на этапе инициализации проекта. В зависимости от них определяется и утверждается некий «паспорт» по достижению (и контролю) этих показателей: набор соглашений по точкам встраивания процедур обеспечения защищенности в процесс разработки, по применяемым инструментам, по зонам ответственности, по периодичности (или событиям-триггерам) запуска процедур и т.п.

Отметим, что непрерывность процессов (особенно в части тестирования и развертывания) подразумевает переход к высокой степени автоматизации рутинных задач. Автоматизация отлично помогает снизить частоту попадания в продукт типичных (=понятных) недостатков:

• недостатков, под которые написали тесты;
• недостатков, под которые написали правила для статического/динамического анализатора;
• недостатков, которые являются следствием человеческого фактора (автоматическая подготовка окружения; конфигурация и развертывание).

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

• Нетипичные недостатки уровня логики в отдельных модулях.
• Недостатки, появляющиеся на стыке ответственности различных групп (например, разработчиков различных сервисов в микросервисной архитектуре, возникающие в отсутствие явных контрактов, или администраторов и devops’ов).
• Недостатки, связанные с использованием 3rd-party библиотек/платформ/фреймворков с опубликованными уязвимостями. Рассуждения касаются в том числе и бинарных библиотек, врапперы над которыми использует приложение, и утилит, которые запускаются как отдельные процессы (ярким примером будут уязвимости в ImageMagic – CVE-2016-3714, CVE-2016-3715, CVE-2016-3716, CVE-2016-3717, CVE-2016-3718). Важность своевременной защиты от атак на недостатки в 3rd-party-компонентах трудно переоценить. В 2017 году практическая реализуемость массовых автоматизированных атак в масштабах всего Интернета не вызывает вопросов. Примерами служат недавние набеги на Joomla (например, CVE-2016-8870 + CVE-2016-8869) или Apache Struts (CVE-2017-5638).

От недостатков первых двух типов можно избавляться через whateverbox-анализ от сторонней организации, проводимый с определенной периодичностью, или через массовое народное непрерывное тестирование aka Bug Bounty. Недостатки третьего типа на этапе сборки можно устранять, реализовав анализ внешних зависимостей (см. Vulners, WhiteSource, OWASP dependency-check), а на этапе эксплуатации – выполнением тех же проверок теми же инструментами, но в виде отдельного задания и с большей частотой. И наконец, еще один вариант – защищаться от атак через непрерывный мониторинг и реагирование.

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

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

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

Что же такое правильный мониторинг? Отдельно поговорим сначала об инструментах, а потом о процессах.

Не секрет, что основным инструментом мониторинга злонамеренной активности в отношении веб-приложений являются средства класса WAF. Интернет знает достаточно попыток описать, из чего может/должен состоять хороший WAF. К числу наиболее удачных можно отнести:

• Web Application Firewall Evaluation Criteria
• https://www.anti-malware.ru/analytics/Technology_Analysis/Web_Application_Firewall

 

Мы же предлагаем свой рейтинг фич, который, по нашему опыту, решает, подходит ли данный инструмент для защиты конкретного приложения. Постановка задачи именно такая – сравнить инструменты мониторинга не вообще, а для конкретного приложения на конкретном стеке технологий.

WAF должен уметь понимать прикладной протокол защищаемого приложения

Здесь действует простое правило: если WAF не сможет разобрать, каким образом передаются значения параметров, он не сможет обнаружить и манипуляции с этими значениями (injection/tampering).

Под прикладным протоколом приложения мы понимаем:

1. Способ адресации функций/ресурсов приложения. В самых простых приложениях это часть PATH в URL. Иногда встречаются приложения, где URL-путь всегда одинаковый (например, /do), функции адресуются значением параметра типа “action”, а ресурсы – параметром типа “page” или “res”. В общем же случае функция/ресурс может адресоваться произвольным набором атрибутов HTTP-запроса.
2. Способ передачи входных параметров, которые параметризуют функции приложения. Отметим, что спецификация протокола HTTP никак не ограничивает фантазию веб-разработчиков в выборе способа транспорта необходимых данных через структуру HTTP-запроса.

 

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

В качестве примера интересных протоколов передачи параметров можно привести следующие:

• 3D-Secure. На одном из шагов протокола инкпасуляция выглядит следующим образом: на сервер приходит POST-запрос с типом контента application/x-www-form-urlencoded, в теле запроса есть параметр PaReq. Параметр PaReq является XML-документом, сжатым при помощи алгоритма DEFLATE, затем закодированного в Base64 и URL-кодированного. Соответственно, реальные параметры приложения передаются в тегах и атрибутах этого XML-документа. Если WAF не может раскрыть такую «матрешку» и применить политики анализа к параметрам внутри XML (и/или валидировать его структуру), значит WAF по сути работает в режиме Fail Open. Другие примеры из этой же серии – это многочисленные XML в JSON и наоборот, конечно, не без помощи упаковки в BASE64.
• Google Web Toolkit и другие протоколы, использующие собственную сериализацию (не JSON/XML/YAML/...). Вместо тысячи слов – один пример запроса:


Соответственно, если WAF не может получить из запроса конечные значения параметров, с которыми оперирует защищаемое приложение, то WAF не работает. Отметим, что существует приличное количество способов сериализации бинарных объектов (а еще можно запилить свой собственный!).
• Oracle Application Express (APEX).  URL приложения в APEX выглядят примерно так:  http://apex.app:8090/apex/f?p=30:180:3426793174520701::::P180_ARTICLE_ID:5024 . POST-запросы в URL-части – аналогично, а параметры передаются в теле (x-www-urlencoded), но названия вне зависимости от вызываемой операции – одинаковые: x01=val1&x02=val2… и т.п. Вот пример запроса:
• 

Если в первых двух примерах разбор протокола требовался для определения значений входных параметров, то в приложениях такого типа WAF дополнительно должен понять, какая запрашивается операция или ресурс. Заметим, что никто не мешает разработчикам приложений на APEX в параметрах x01, x02 и т.д. передавать, например, XML/JSON, закодированный в base64, или, как на последнем снимке, сериализованные X-WWW-URLENCODED параметры.

WAF должен иметь гранулярность уровня операций защищаемого приложения

Приложения на APEX отлично иллюстрируют следующий тезис: WAF должен применять свои механизмы/политики/правила не с гранулярностью сущностей HTTP-протокола (секции URL, заголовки и их значения, имена параметров и их значения), а с гранулярностью функций приложения и их входных параметров.

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

• инкапсуляция значений этих параметров может быть разной (см. значения x01 на снимках экрана выше);
• как следствие, типы, области значений и семантика этих параметров будут отличаться!

Получается, что от механизмов WAF мы хотим следующего:

• Подсистема построения и применения позитивных моделей должна строить не одну общую позитивную модель на основе всех наблюдаемых значений параметра x01, а N моделей по числу функций приложения, принимающих этот параметр.
• Подсистема сигнатурного анализа должна применять к параметру x01 не один и тот же набор сигнатур, а K наборов (К £ N) в зависимости от пожеланий оператора по покрытию сигнатурами значений x01 для действий или их групп.
• Если же оператор захочет настроить для параметра x01 какое-то дополнительное правило (например, подавление ложного срабатывания), то он должен иметь возможность выбирать scope работы этого правила не в терминах протокола HTTP (регулярное выражение над URL, к примеру), а опять же в терминах функций приложения, принимающих x01.

Авторы данной статьи встречались с ситуацией, когда на WAF одного крупного вендора не работал User Tracking (Механизм User Tracking позволяет связать запросы, отправляемые пользователями приложения после аутентификации, с их логинами. Для конфигурации этого механизма инструменты обычно требуют ввести критерии успешного логина, неуспешного логина и критерии инвалидации сессии (тайм-аут по бездействию при наличии, новый вход под тем же пользователем, отправка logout запроса по заданному URL и т.п.)) на APEX-приложении как раз из-за того, что правила для разделения успешного login-действия, неуспешного login-действия, logout-действия и остальных действий невозможно было задать предоставляемыми выразительными средствами, это были регулярные выражения над полями HTTP-запроса.

Приведенные рассуждения справедливы, конечно, не только для APEX-приложений, но и для различных приложений со сложной маршрутизацией не на основе URL: XML-RPC, JSON-RPC, SOAP и т.п.

Взгляд со стороны SOC

Но является ли установка WAF панацеей и настоящей «серебряной пулей»? И что делать безопаснику, который столкнулся с этим решением, как выжать из технологии все соки и максимум возможностей: обеспечить не только администрирование, но и эффективное выявление и реагирование на атаки?

Мир enterprise-клиентов, особенно интернет-компаний, уверенно стремится от цикла быстрых релизов (раз в месяц/два) к динамике практически непрерывной разработки (3-4 релиза в неделю). В этом случае даже возможности по автоматизированной защите и обучению приложений, предоставляемые текущими вендорами WAF, сталкиваются со сложностями. Мы бы хотели рассказать об этом, опираясь на опыт деятельности коммерческого центра мониторинга и реагирования на кибератаки Solar JSOC

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

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

Эти особенности одновременно являются основными причинами для передачи эксплуатации данного решения на аутсорсинг. Ниже хотелось бы рассмотреть особенности, связанные с проактивной эксплуатацией Web Application Firewall в современных реалиях.

Эксплуатация WAF

1. Обновление – отслеживание патчей, в том числе закрывающих ошибки.
2. Написание частных сигнатур:

• отслеживание новых критичных сигнатур, совместные с заказчиком тестирование и подготовка контрмер на период, пока не выпущены официальные обновления.
• написание сигнатур в качестве компенсационных мер по закрытию уязвимостей исходного кода приложений:
• уязвимости известные разработчикам, закрытие которых требует масштабных доработок исходного кода;
• уязвимости, выявленные в результате анализа исходного кода приложений, например, с помощью сканера Solar InCode.

3. Профилирование запросов, обращений к URL.
4. Validation – проверка и анализ параметров запросов, ответов на защищаемый ресурс, приложение.

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

Думаю, не вызывает сомнений то, что вариант «пришел-настроил-включил-работает» в 99% случаев не жизнеспособен.

Режим работы WAF

Первый вариант: только блокирование – по сигнатурам и профилю. Здесь надо учитывать два момента: 1) есть риск заблокировать легитимные запросы; 2) необходимо анализировать атаки. Иногда случается, что 99% запросов заблокировано, а 1% прошел. По факту анализа этого 1 % пишутся и добавляются в блок новые кастомные сигнатуры.

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

Однако чаще всего используется третий вариант – гибридный.

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

Кастомные сигнатуры

Одним из важных моментов в эксплуатации Web Application Firewall является написание кастомных сигнатур. Требуется это в нескольких случаях: появление новой уязвимости, регистрация аномалий, требующих дополнительного анализа, и сбор долговременной статистики аутентификации в приложении.

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

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

Работа с динамический контентом

Правильный цикл работы с постоянно изменяющимся контентом, с нашей точки зрения, должен выглядеть следующим образом:

1. Сформированная политика выгружается с боевого сервера в тестовую среду.
2. В процессе тестирования обновленного контента одновременно тестируется совместимость с текущей политикой WAF, в случае необходимости производится ее корректировка.
3. В идеальной схеме обновление приложения или сервиса тестируется на пилотной группе (регионе). На этом этапе политика WAF переводится в блокирующий режим и тестируется в боевых условиях. Так же осуществляется тюнинг и тонкая настройка конфигурации политики.
4. Далее обновление и политика применяется глобально ко всем клиентам заказчика и становится эталонной до следующего обновления.

В идеальном мире есть тестовая среда, функциональные и нагрузочные тесты длительностью примерно в 2 недели. Но жизнь иногда расставляет все по-другому. Примерно в 30% случаев нам приходится работать с сокращенным режимом разработки приложений и веб-сайтов у заказчиков, когда обновление сразу «накатывается» на продуктивные серверы. В этом случае необходимо оперативно подстроить политику WAF под новые условия работы. Для этого профилирование запускается на короткий промежуток времени – полдня-день. Из-за большого объема трафика этого зачастую достаточно для обучения. Спустя указанное время «допрофилированная» обновленная политика переводится в блокирующий режим.

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

Вот два ярких примера цикла разработки у наших клиентов:

Первый случай – заказчик выпускает один релиз в неделю. При этом взаимодействие между заказчиком и подрядчиком не предусматривает детального release notes, по которому можно понять, нужна ли корректировка политики. Единственный вариант – работа «на горячую» с коротким и оперативным циклом тюнинга политики WAF:

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

Дополнительная корреляция для анализа инцидентов

Если компания использует собственный или аутсорсинговый Security Operations Center, подключение WAF к SIEM-системе позволит наладить оперативное уведомление и разбор по всем типам инцидентов, в том числе и веб-атакам, из одной точки – SIEM-системы. Специалисты первой линии мониторинга могут фиксировать корреляционные срабатывания, настроенные по различным сценариям:

1. Аномальное количество различных сработавщих на WAF сигнатур с внешнего хоста – потенциальное сканирование на уязвимости.
2. Срабатывание сигнатур в течение нескольких дней подряд с одного внешнего хоста – медленное сканирование.
3. Срабатывание порогового значения сигнатур за короткий промежуток времени с разных хостов – распределенное сканирование/DDoS уровня приложения.

После того как специалисты первой линии оповестят службу эксплуатации WAF, последние имеют возможность подключиться уже к интерфейсу СЗИ и в режиме реального времени «тюнить» политики для противодействия атаке.

одключение к SIEM-системе позволяет не только наладить оперативное оповещение о сработках WAF, но и обогащать информацию об атаках сведениями из других систем, а также производить сложную корреляцию по цепочкам событий. Например, для понимания успешности атаки информацию с Web Application Firewall можно коррелировать с успешными запросами в SQL-базах данных или локальными логами веб-сервера.

Наш подход к обработке инцидентов:

Но и это далеко не все подводные камни. Самыми сложными в детектировании являются атаки на логику приложения (хотя их отражение, возможно, не задача WAF).

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

Заказчику необходимо контролировать подозрительные операции – слишком большое количество списанных бонусов или транзакций с бонусами за определенное время. В качестве инструмента для сбора сводной статистики используется отдельная таблица (Active List в ArcSight). Ежедневная выгрузка из этого листа отправляется аналитику для изучения аномалий, не попадающих в текущие корреляционные срабатывания.

В одной из таких выгрузок была обнаружена запись:
«modify_order_bonus  ":"{\"bonusAvailable\":18.0,\"bonus\":-20000}" reason: success»

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

Но и это еще не все: при дальнейшей обработке заказа в специализированных системах, куда передавалась информация с веб-сайта, значение требуемых к списанию бонусов бралось по модулю! Так клиент успешно получил скидку в 20 тысяч рублей при наличии на счету 18 баллов.

Web Application Firewall не увидел ничего аномального, так как структура запроса была правильной, и количество запросов не было подозрительным. Лишь последующий сбор статистики и просмотр событий глазами живого аналитика позволил выявить успешную попытку мошенничества в ключевом бизнес-приложении клиента.

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

Защита окружения приложений

Далеко не все хакеры атакуют приложение «в лоб». В части случаев значительно проще проникнуть в инфраструктуру компании и атаковать приложение или его базу изнутри, чтобы вносить изменения напрямую. Помимо этого, существуют внутренние злоумышленники, в том числе имеющие доступ к приложению, и за ними необходим не меньший контроль.

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