Темой нашей сегодняшней статьи будет Virtual Patching.

Virtual Patching — это слой политики безопасности, предназначенный для обнаружения и предотвращения эксплуатации эксплойта для известной уязвимости.

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

Так почему виртуальный патчинг, почему просто не обновить код?

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

Преимущества у виртуального патчинга следующие:

• Быстрое (относительно) решение для закрытия уязвимости пока не будет возможности для полноценного патча.
• Если веб-приложение — ваш продукт, то не нарушает возможные существующие бизнес-процессы, то есть если следующий патч для продукта запланирован, например, через месяц, то не нужно ломать все расписание.
• Возможность закрытия уязвимости членами другой команды, если разработчики этого сделать в данный момент не в состоянии.
• Своевременность — если вы используете готовое ПО, то неизвестно, когда будет выпущен патч для вашего продукта, а оставлять его уязвимым, ясное дело, не хочется.

Недостатки виртуального патчинга:

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

Подготовку к виртуальному патчингу можно разделить на следующие этапы:

1. Подготовка
2. Выявление угрозы
3. Анализ
4. Создание виртуального патча
5. Внедрение и тестирование
6. Восстановление/продолжение работы

Публичная уязвимость

Для примера возьмем SQL-инъекцию и ModSecurity WAF (так как опенсорс).

WordPress Shopping Cart Plugin для WordPress 
/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php 
параметр reqID уязвим к SQL Injection.

WordPress Shopping Cart Plugin для WordPress содержит недочет, который может позволить атакующему исполнить SQL-инъекцию. Проблема кроется в скрипте /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php, в котором некорректно происходит санитизация параметра reqID.

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

Этап подготовки

Как и во многих процессах, подготовка при виртуальном патчинге является важной составляющей. Перед тем, как разбираться с обнаруженной уязвимостью (или того хуже — с атакой в реальном времени), потребуется сделать несколько вещей. Смысл подготовки в том, чтобы во время атаки не судорожно разбираться в том, как работает виртуал патчинг и как можно в текущую инфраструктуру встроить WAF, если его нет, а предпринять определенные и заранее продуманные действия.

Вот несколько критичных моментов, которые должны быть пройдены в стадии подготовки:

• Мониторинг уязвимостей от вендора или из публичных источников — если вы используете стороннее ПО, то убедитесь, что вы подписаны на все экстренные рассылки от вендоров. Это поможет оставаться вам в курсе относительно новых уязвимостей к вашему ПО и соответствующих патчей.
• Заранее подготовьте всю необходимую работу по допуску виртуальных патчей в продакшен — виртуальные патчи должны быть встроены быстро, так что обычный процесс верификации для патчей тут не подойдет. Так как виртуальные патчи не меняют исходный код, они не требуют такого же количества тестирования, как обычные софтверные патчи. Стоит относить виртуальные патчи в ту же категорию, как обновления для антивирусов или сигнатурные обновления для IDS. Это позволит значительно ускорить процесс их выкатывания в продакшен.
• Заранее встройте утилиты для виртуального патчинга — так как основной критерий при виртуальном патчинге — быстрота, то устанавливать новое ПО при необходимости экстренного патча, мягко говоря, плохая идея.
• Увеличьте логирование для ваших систем — стандарт логов, который используют большинство серверов по умолчанию (CLF) не предоставляет достаточное количество данных для корректной реакции на инциденты. У вас должен быть доступ к следующим данным:
  
  ◦ URI запроса (включая QUERY_STRING)
  ◦ Все заголовки запроса (включая куки)
  ◦ Полное тело запроса (включая нагрузку POST`а)
  ◦ Полные заголовки ответа
  ◦ Полное тело ответа

Этап выявления угрозы

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

Проактивный подход

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

• Динамическая оценка приложения — выполняются пентесты или/и автоматические оценочные тесты на работающем веб-приложении для выявлении недостатков.
• Ревью исходного кода — осуществляется ручная или/и автоматическая оценка исходного кода веб-приложении для обнаружения недостатков.

Реактивный подход

Существуют три основных реактивных метода для выявления уязвимостей:

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

Этап анализа

Рекомендуемые шаги для фазы анализа:

• Определить, насколько виртуальный патчинг подходит для вашего случая — он отлично подходит для закрытия недостатков, связанных с вводом (то есть инъекций), но может не предоставлять адекватный уровень защиты для атак других типов или категорий. Должен быть проведен подробный и тщательный анализ исходной проблемы для определения того, будет ли ПО для виртуального патчинга предоставлять адекватный уровень обнаружения и покрытия.
• Задействуйте ваши системы для отслеживания багов/задач — внесите сведения об уязвимости в ваш трекер для дальнейшего отслеживания и изучения.
• Верифицируйте уязвимость — найдите официальное название данной уязвимости, если оно существует. Если же она была обнаружена проактивными методами, то вы должны присвоить ей собственный уникальный номер/название.
• Определите уровень риска — всегда важно понимать насколько критично может быть влияние эксплуатации данной уязвимости для вас. Например будет ли это утечка информации или доступ к БД.
• Определите, какие версии ПО подвержены риску — это важно для понимания, входите ли вы в группу риска или вам ничего не грозит.
• Определите, при каких конфигурациях ПО может возникнуть проблема — некоторые уязвимости могут проявляться только при определенных конфигурациях вашего ПО.
• Составьте список Proof of Concept эксплойтов или полезных нагрузок, использовавшихся во время атаки/теста — многие публикации уязвимостей сопровождается PoC кодом, который демонстрирует уязвимость. Если такие данные доступны, проанализируйте их. Это будет полезно и при дальнейшей разработке и при тестировании виртуального патча.

Этап создания виртуального патча

Процесс создания хорошего виртуального патча завязан на двух аспектах:

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

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

Ручное создание виртуального патча
Позитивный подход (вайтлистинг, составление белого списка) в виртуальном патчинге

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

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

Пример.

В данном случае, параметр reqID должен содержать только целые числа для того, чтобы мы могли применить данный виртуальный патч:

#
# Верифицируем, что мы получили только 1 параметр с названием "reqID"
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
  SecRule &ARGS:/reqID/ "!@eq 1"

#
# Верифицируем, что нагрузка  reqID содержит только целые числа
#
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"

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

Негативный подход (блэклистинг, составление черного списка) в виртуальном патчинге

Данный подход основан на списке правил, которые определяют определенные известные атаки, нежели разрешают только валидный трафик.

Пример создания виртуального патча на основе блэклистинга в ModSecurity

Во пример PoC кода из публичного источника:

http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1

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

SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "@pm '"

Остерегайтесь создания виртуальных патчей для конкретных экслойтов

Конечно, это выглядит привлекательно и экономнее по времени. Например если пентест нашел XSS на вашей странице и использовал следующую нагрузку:

<script>
  alert('XSS Test')
</script>

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

Автоматическое создание виртуальных патчей

Ручное создание патчей может стать неподъемным в связи с ростом количества уязвимостей и автоматизация становится необходимым шагом. Если уязвимости были обнаружены с использованием автоматизированных инструментов (например, сканеров уязвимостей), то может быть возможность конвертировать отчеты данных инструментов в патчи. Самыми популярными средствами автоматизации создания патчей являются прямое импортирование в WAF (естественно, если ваше решение поддерживает такую возможность), OWASP ModSecurity Core Rule Set (CRS) Scripts и ThreadFix Virtual Patching.

Этап внедрения и тестирования

Для корректного тестирования нашего нового виртуального патча нам могут понадобиться следующие инструменты:

• веб-браузер
• веб-утилиты для терминалов (например curl и wget)
• локальный прокси-сервер
• ModSecurity AuditViewer

Шаги:

• Внедрить виртуальные патчи сначала в режиме «только логи», для того чтобы убедиться, что обычный пользовательский трафик не блокируется (ложнопозитивный вариант).
• Если уязвимость была обнаружена с помощью какого конкретного инструменты или команды — запросить повторную проверку.
• Если ретестирование проваливается из-за того, что виртуальный патч можно обойти, нужно вернуться к этапу анализа для определения того, как лучше закрыть проблему.

Этап восстановления/продолжения работы

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