При появлении громкой уязвимости бывает сложно быстро оценить масштаб угрозы и состояние периметра. Разбираем кейс React2Shell и показываем, как выстроить процесс реагирования — от обнаружения до compromise assessment — и какую роль в этом играет EASM.
Введение
Когда появляется громкая уязвимость уровня Log4Shell или PrivExchange, часто возникают сложности с быстрым и корректным реагированием на нее. Организации не могут оперативно ответить на простые вопросы:
Затронута ли наша инфраструктура?
Если да, какие именно сервисы уязвимы?
Доступны ли эти сервисы злоумышленнику?
Показательным примером стал кейс React2Shell (CVE-2025-55182). При беглом прочтении новостей можно было легко запаниковать: «На React написана львиная доля сайтов в интернете, значит, мы точно под ударом». Ситуацию усложняло и то, что под подозрение попадали не только сами приложения на React, но и фреймворки вроде Next.js. Все это вносило хаос в реагирование и не позволяло спокойно оценить масштабы уязвимости.
Но при изучении деталей оказалось, что реальная ситуация не такая критическая: уязвимость затрагивает не сам React как библиотеку, а серверные компоненты — React Server Components и Server Functions.
В статье разберем полный цикл реагирования на новую уязвимость, состоящий из 6 шагов: от ее обнаружения до проверки, что она действительно устранена. Особое внимание уделим compromise assessment — оценке того, была ли уязвимость использована злоумышленниками. Отдельно расскажем, как external attack surface management (EASM) экономит время и снижает риск слепых зон на внешнем периметре.
Шаг 1. Как узнать о новой уязвимости
Наиболее зрелый подход с точки зрения защиты внешнего периметра предполагает создание техрадара — карты используемых технологий — и автоматизированный мониторинг security-бюллетеней вендоров, NVD и БДУ ФСТЭК. Этот подход дополняется анализом специализированных телеграм-каналов, аккаунтов в X (бывший Twitter) и других социальных сетях, а также отраслевых СМИ. В результате команда может быстрее реагировать на публично раскрытые уязвимости, даже если они еще не попали в бюллетень вендора или публичный каталог уязвимостей.
Например, компания может подписаться на коммерческий фид уязвимостей или получать данные через API из публичных каталогов, использовать RSS для отслеживания обновлений безопасности вендоров и дополнительно анализировать отраслевые издания и каналы. А после этого сопоставлять эту информацию с внутренним инвентарем в CMDB.
Смысл этого шага в том, чтобы как можно раньше узнать о появлении уязвимости и сразу перейти к реагированию. EASM-платформы, такие как BI.ZONE EASM, автоматизируют этот процесс: они отслеживают новые уязвимости, проводят проверки сразу после появления первых сведений об эксплуатации, выявляя наиболее подверженные риску активы на внешнем периметре и помогая приоритизировать устранение уязвимостей на них.
Шаг 2. Первичный анализ: как понять, что это за уязвимость на самом деле
Часто при публикации информации в СМИ возникает ловушка формулировок: то, что указано в заголовке, может не совпадать с реальным описанием уязвимости. В случае React2Shell распространенная формулировка «RCE в React» вводила в заблуждение. В реальности эксплуатация была возможна только при использовании серверных компонентов. Иными словами, если ваши веб-приложения используют React исключительно как фронтенд (а это большая часть сайтов на React), злоумышленники не могут эксплуатировать эту уязвимость.
Грамотный анализ позволяет сузить потенциальный радиус атаки со всех приложений на React до конкретных случаев.
Практически это можно формализовать через набор фильтров:
В каком продукте уязвимость?
В какой она функциональности (сервер, клиент, конкретные модули)?
При каких условиях проявляется (наличие аутентификации, режим работы, наличие определенных прав)?
Какие версии, пакеты или сборки затронуты?
Как осуществляется вход извне?
Что считается исправлением (патч, изменение конфигурации, правило на WAF или межсетевом экране)?
Часть из этих вопросов может не иметь ответов в моменте, но чем быстрее и подробнее вы их сформулируете, тем более точно сможете определить потенциально уязвимые точки в вашей инфраструктуре.
Шаг 3. Как провести инвентаризацию внешнего периметра
После первичного анализа необходимо выяснить, где в вашем периметре есть приложения, которые находятся под угрозой. На практике есть три пути.
Путь 1. Внутренняя CMDB и каталог сервисов
Это самый быстрый путь, если данные в каталоге актуальны. Вы берете готовый список сервисов и сверяете его с условиями уязвимости.
Плюс: это быстро, если каталог точный.
Минус: база данных не всегда соответствует реальности. В ней часто отсутствуют забытые сабдомены, временные лендинги, стейдж-окружения и случайно опубликованные сервисы, которые не попадают в CMDB.
CMDB показывает лишь то, что мы считаем своей инфраструктурой. При этом мы можем не обладать полной информацией или ошибаться, а в условиях 1-day-уязвимости атакующий сканирует реальный внешний периметр. Поэтому ключевым становится не вопрос «что мы думаем, что у нас есть?», а вопрос «что прямо сейчас видит злоумышленник?».
Путь 2. Анализ исходников
Если у вас есть доступ к репозиториям (GitLab, GitHub), можно просканировать код на наличие зависимостей. Например, найти все проекты с React, проверить package.json и lock-файлы.
Плюс: вы ищете уязвимые сервисы максимально близко к источнику — прямо в коде.
Минус: этот подход показывает только разрабатываемые приложения, а не то, что опубликовано. Самый сложный этап — сопоставить репозитории с конкретными адресами на внешнем периметре. Ошибки на этом шаге создают слепые пятна, которые позже не попадут в процесс устранения.
Путь 3. EASM
EASM-платформа подходит к задаче с практической стороны: самостоятельно обнаруживает внешние активы компании — домены, поддомены, веб-приложения, открытые сервисы — путем активного сканирования. Вам остается лишь отфильтровать их по используемому стеку технологий.
Плюс: вы начинаете с того, что реально доступно извне, а не с того, что записано в документах или лежит в репозиториях.
Минус: не все детали стека приложения можно определить путем сканирования.
Как это выглядит для пользователя
В EASM‑платформе (такой как BI.ZONE EASM) это обычно превращается в простую последовательность:
отфильтровать веб‑активы по признакам React / Next.js;
сузить выборку до тех, где вероятно использование React Server Components.
Результат: вместо ручного сбора списка активов в течение дня вы переходите к реагированию в два клика — у вас сразу есть список всех веб-приложений внешнего периметра в формате csv или xlsx, а также отдельный перечень приложений, использующих интересующие вас технологии (в нашем примере — React).
Шаг 4. Как устранить уязвимость и снизить риск ее эксплуатации
Часто патч нельзя применить сразу: он может отсутствовать, требовать технологического окна или дополнительного тестирования. В таких случаях важно заранее определить, какие меры помогут снизить риск эксплуатации уязвимости.
На практике эти действия выполняются параллельно: мы патчим и одновременно снижаем риск, пока обновление раскатывается.
Линия A: закрыть уязвимость
Первым делом необходимо устранить саму причину уязвимости:
Обновить затронутые компоненты до исправленных версий.
Убедиться, что обновление дошло до прода, а не осталось только в репозитории.
Проверить периферийные окружения: стейдж, промо‑домены, региональные сайты.
Линия B: снизить риск на время раскатки обновлений
В окне 1‑day временные меры — нормальная практика. Они не закрывают уязвимость, но затрудняют ее эксплуатацию.
Настроить правила на WAF под конкретную уязвимость.
Если детали неизвестны, поставить правила на WAF под класс уязвимостей.
Ограничить запросы к уязвимым эндпоинтам.
Усилить логирование и настроить алерты на подозрительные запросы, чтобы заметить попытки эксплуатации на ранней стадии.
Устранение уязвимости может занять дни, тогда как эксплуатация начинается в первые часы. Временные меры дают запас времени: даже базовое усиление инфраструктуры может помешать корректной работе эксплоитов атакующих.
Шаг 5. Как подтвердить наличие уязвимости
В случае с 1-day-уязвимостями почти всегда возникает ситуация, когда нет полной уверенности в корректности примененных мер для снижения риска.
Динамика появления рабочего эксплоита почти всегда одинаковая:
Первые сообщения от вендора.
Первые PoC.
Период путаницы — часто неясно, в чем именно заключается PoC, особенно если вы не знакомы с этим классом уязвимостей.
Появление рабочих цепочек уязвимостей, сканеров, публично доступной автоматизации эксплуатации и проверок.
Благодаря развитию ИИ появился интересный феномен: уже в первые часы после публикации громких уязвимостей начинают появляться сгенерированные на основе их описания ИИ-эксплоиты. Они не имеют отношения к реальной эксплуатации, но на первый взгляд выглядят правдоподобно. Также встречаются PoC, которые некорректно интерпретируют саму уязвимость. В частности, о распространении таких PoC автор React2Shell сделал отдельный комментарий на сайте уязвимости, пояснив, что рабочего PoC в паблике на тот момент не было.
Для отслеживания рабочих PoC эффективнее всего мониторить GitHub и X: на первом появляется код эксплоитов, на втором информация о них быстро распространяется в сообществе. При этом важно помнить, что не все PoC работоспособны, и нужно оценивать каждый случай критически.
Это опять возвращает нас к ценности EASM-платформ: мониторингом и анализом PoC занимается выделенная команда, задача которой — как можно раньше получить достоверную информацию об эксплоите.
Шаг 6. Как убедиться, что уязвимость устранена
Сделать бэкап — недостаточно, его нужно проверить. Точно так же просто применить патч — мало. Нужно получить доказательство, что внешний периметр больше не может быть скомпрометирован.
Нормальная валидация — это комбинация двух подходов:
Проверка версий и артефактов деплоя. Недостаточно убедиться, что обновление залито в репозиторий. Надо подтвердить, что оно реально ушло в продакшен.
Повторное сканирование внешних активов на наличие признаков уязвимости. Это становится возможным только после появления надежного PoC или механизма детекта.
EASM-платформа в этой ситуации решает две задачи:
Хранит наиболее полную информацию о внешней поверхности атаки: какие активы имеют внешние интерфейсы и что видит злоумышленник.
Автоматически проверяет PoC на всех доступных из интернета ресурсах.
Compromise assessment: как понять, была ли компрометация
Зачастую во время хаоса, связанного с поиском уязвимых хостов и применением обновлений, организации теряют из виду важный момент. Злоумышленник мог воспользоваться окном возможности для эксплуатации уязвимости, особенно если речь идет о резонансной RCE. При этом последний шаг реагирования — не применение обновлений, а проверка компрометации ранее уязвимых хостов.
Как оценить окно экспозиции
Чтобы понять, были ли попытки успешных атак, нужно определить три момента времени:
T0 — момент, когда вы стали потенциально уязвимы (уязвимый сервис появился или стал доступен извне);
T1 — когда появились публичные эксплоиты;
T2 — когда вы закрыли уязвимость на всех внешних активах (патчем или временными мерами).
Промежуток от T0 до T2 — это ваше окно риска, которое нужно проанализировать. При этом T1 — критическая точка, когда эксплуатация уязвимости становится значительно проще для злоумышленника, и риск достигает максимума.
Что смотреть «снаружи»: признаки попыток эксплуатации на периметре
EASM-платформа помогает быстро сформировать список «подозреваемых» активов — тех, которые соответствуют условиям эксплуатации. Далее проводится анализ логов и телеметрии. В частности, WAF- и access-логи приложений и веб-серверов, где можно увидеть всплески блокировок, аномальные запросы к эндпоинтам с нестандартными телами или заголовками, а также массовые обращения.
На этом этапе важно ответить на вопросы: «Были ли попытки эксплуатации и была ли эксплуатация успешной?». Чем больше известно о механике уязвимости, тем точнее можно интерпретировать события в логах своих приложений.
Что смотреть «внутри»: последствия возможной эксплуатации RCE
Если эксплуатация произошла, следы чаще связаны не с самой уязвимостью, а с постэксплуатацией. Независимо от способа получения RCE злоумышленник, как правило, выполняет схожие действия:
Запускает новые или необычные процессы, контейнеры, задания планировщика.
Инициирует исходящие соединения — C2, настройка туннелей.
Проводит подозрительные изменения в конфигурациях и переменных окружения.
Создает аномальную нагрузку на CPU (свойственно майнингу).
Если атака является частью масштабной кампании, можно использовать данные киберразведки, чтобы определить конкретную группировку и сопоставить ее тактики и поведение на уязвимых серверах. Это повысит эффективность проверки компрометации.
Важно помнить: у любой уязвимости есть окно возможностей для эксплуатации уязвимых хостов. Реагирование не должно заканчиваться установкой патчей. Завершающий этап — оценка компрометации и поиск следов активности на ранее уязвимых системах.
Что дает EASM в реальном реагировании
История React2Shell хорошо показывает, почему вопросы «какие наши сервисы доступны извне и на каком техническом стеке они работают?» — это не инвентаризация ради инвентаризации. Ответы на них влияют на скорость принятия решений в окне 1-day, когда:
уязвимость уже публична;
вокруг нее накапливается шум из противоречивых или недостоверных PoC;
ключевая задача — за считаные часы понять, затронуты ли вы и какие именно активы находятся в зоне риска.
Решения класса external attack surface management позволяют существенно ускорить реагирование на новую уязвимость и повысить точность действий, снижая риск неполного патчинга.
По сути, EASM-платформа выстраивает тот же подход, что и атакующая сторона: сначала обнаружение доступных извне активов, затем проверка условий эксплуатации, и только после этого приоритизация мер, включая патчинг, валидацию и расследование.
