Как понять, затрагивает ли уязвимость вашу CMS

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

Почему заголовок бюллетеня ещё ничего не значит

Новость об уязвимости пишется так, чтобы её открыли. «Критическая дыра в WordPress», «миллионы сайтов под угрозой» — а внутри выясняется, что речь о плагине, который стоит у малой доли сайтов, и только в конфигурации с включённой регистрацией пользователей. Мы в АйТи-Фреш, когда занимаемся информационной безопасностью сайтов клиентов, первым делом отделяем шум от факта: какой именно компонент, какие версии, при каких условиях. Пока этих трёх ответов нет, паниковать рано, а успокаиваться — тем более.

Типовая ошибка — две крайности. Первая: «у нас же не WordPress, а Битрикс, нас не касается» — при том что уязвим не движок, а библиотека, которую тянут оба. Вторая: срочно обновлять всё подряд в пятницу вечером, без резервной копии и без проверки совместимости. Неудачное обновление тоже может положить сайт. Уязвимость и проверку совместимости лучше разбирать по отдельности. Правильный подход скучнее, зато работает: триаж. Это короткая процедура, после которой у вас на руках одно из трёх решений — «не применимо, закрываем», «применимо, ставим исправление в плановое окно» или «применимо и эксплуатируется, действуем сегодня». Дальше я разберу, откуда брать факты и как не обмануть самого себя.

Где искать первичный источник и чему верить

Первичный источник — это то, что опубликовал сам разработчик компонента: страница security advisory проекта, раздел безопасности в репозитории, примечания к выпуску с пометкой об исправлении уязвимости. У WordPress это страница безопасности и анонсы релизов, у Joomla — Security Centre, у Битрикса — информация в обновлениях модулей и сообщения вендора, у OpenCart — репозиторий и примечания к версиям. Дополнительная опора — запись CVE и карточка NVD: в них есть описание, ссылки и, если данные внесены, затронутые конфигурации. Запись CVE не заменяет бюллетень разработчика: сведения об условиях и версиях могут уточняться.

При расхождении сначала читаю бюллетень разработчика и проверяю, к какому именно выпуску относится его диапазон; затем сопоставляю его с записью CVE и NVD. Данные в базах могут быть неполными или обновляться позже. CVSS показывает серьёзность уязвимости по заданным метрикам, но не риск именно вашего сайта. Для оценки на месте отдельно выясняю, нужна ли учётная запись, какая роль требуется и доступна ли уязвимая функция. Высокий балл — повод разобраться быстро, но не доказательство, что сайт уже под угрозой.

• Бюллетень или примечания к выпуску от разработчика компонента
• CVE-запись на cve.org со ссылками на исходные материалы
• Карточка в NVD: затронутые конфигурации и оценка
• Каталог активно эксплуатируемых уязвимостей CISA KEV
• Банк данных угроз ФСТЭК для российского контура

Как точно узнать версию CMS, плагинов и библиотек

Вторая половина проверки — фактический состав сайта. Админка может показывать не то, что лежит на диске после ручной замены файлов. Поэтому сверяю версию на сервере и сохраняю вывод проверки. В WordPress для этого подходят команды WP-CLI: список плагинов содержит их версии и статус, в том числе статус inactive. Неактивный плагин тоже нужно проверить: выключенное расширение не вызывается обычным образом, но отдельные доступные файлы могут вести себя иначе. Не объявляю его уязвимым автоматически — проверяю конкретный обработчик и при ненадобности удаляю расширение.

wp core version
wp plugin list --fields=name,version,status
wp theme list --fields=name,version,status

В Joomla проверьте манифест administrator/manifests/files/joomla.xml и версии расширений в менеджере расширений. В 1С-Битрикс константа SM_VERSION содержит версию главного модуля, а SM_VERSION_DATE — дату его выпуска; версии остальных модулей смотрите отдельно в их карточках или штатном разделе обновлений. Не делайте вывод по одному файлу, если поставщик описывает затронутые версии иначе. Самое коварное — библиотеки. Уязвимость бывает не в CMS, а в компоненте, который плагин принёс с собой: в PHP-библиотеке из vendor, в JavaScript-пакете, в редакторе форматированного текста. Тут помогает composer.lock, если он есть, и поиск по имени библиотеки в каталоге плагинов. Если бюллетень говорит об уязвимой библиотеке, а вы не знаете, кто её у вас использует, — ищите по файлам, а не по памяти. В WP-CLI сохраняю список установленного ядра, плагинов и тем с версиями и статусами; это даёт исходную точку для сравнения с бюллетенем. Если в составе есть неактивный плагин, отдельно проверяю, не используется ли его код напрямую.

Условия эксплуатации: когда уязвимость есть, а риска нет

Совпадение версии — ещё не приговор. В описании любой приличной уязвимости есть условия: нужна ли авторизация и с какой ролью, должна ли быть включена определённая функция, доступен ли уязвимый адрес из интернета. Я выписываю эти условия отдельным списком и против каждого ставлю факт по нашему сайту. Регистрация посетителей выключена? Уязвимость для роли «подписчик» сразу теряет остроту. Форма загрузки файлов не используется? Смотрим, можно ли до неё достучаться напрямую, минуя интерфейс. Пока факт не проверен, не записываю условие как отсутствующее: помечаю его неизвестным и сохраняю осторожную оценку до проверки.

Дальше — сетевая доступность. Ограничение доступа к административному адресу по списку доверенных адресов уменьшает доступность этой точки снаружи, если правило действительно применяется ко всем путям. Но нестандартный URL сам по себе не ограничивает доступ. Ограничение по доверенным адресам и дополнительная проверка входа снижают риск, но не отменяют остальные условия уязвимости. И последнее условие — есть ли подтверждения эксплуатации. Запись в каталоге CISA KEV означает, что уязвимость отмечена как эксплуатируемая; это основание поднять приоритет, но всё равно сверить применимость к своему сайту. Публичный код эксплойта сам по себе не доказывает массовую атаку. При отсутствии признаков эксплуатации можно спланировать проверку и обновление, учитывая бюллетень разработчика, доступность функции и последствия простоя.

• Требуется ли авторизация и с какой ролью
• Включена ли уязвимая функция на вашем сайте
• Доступен ли уязвимый адрес из интернета
• Есть ли публичный эксплойт или признаки атак
• Какие данные или права получает атакующий

Условный пример: старый плагин формы

Представим сайт-каталог на WordPress с формой заявки. Администратор получает рассылку о критической уязвимости плагина форм и спрашивает, нужно ли выключить сайт. Я не делаю вывод по заголовку: сначала открываю бюллетень, выписываю затронутый диапазон и проверяю состав установленного ПО. Тут важна точность, а не скорость ради красивого отчёта. Пусть первая проверка показывает уязвимую версию активного плагина. Это ещё не ответ: в описании уязвимости может быть обязательное условие — например, конкретный обработчик или включённая опция. Я сверяю это условие с настройками формы и проверяю файлы на сервере. Условный пример нужен ровно для этого: показать ход проверки, а не выдавать выдуманный инцидент за реальный клиентский кейс.

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

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

Что делать до выхода или установки патча

Бывает, что исправления ещё нет или его нельзя поставить сразу: сайт на старой ветке PHP, плагин доработан под заказ, разработчик обновит только завтра. Это не повод ждать сложа руки. Первая мера — убрать уязвимую функцию из доступа: отключить и удалить ненужный плагин, закрыть конкретный адрес на уровне веб-сервера, временно отключить регистрацию или загрузку файлов. Вторая — сузить круг тех, кто достаёт до админки: доступ по списку адресов, двухфакторная аутентификация, ревизия учёток с правами администратора. До установки обновления копирую файлы и базу данных: без обеих частей восстановление может оказаться неполным.

Третья мера — подходящее правило WAF, если оно доступно и проверено на вашем сценарии. Это временное ограничение части запросов, а не исправление кода; после установки патча правило нужно пересмотреть. Четвёртая — наблюдение: включите подробное журналирование обращений к уязвимому адресу и посмотрите журнал назад, насколько хватит хранения. Если атака уже была, вы хотите узнать об этом от себя, а не от клиентов. До обновления сохраняю и файлы сайта, и базу данных, затем проверяю, что копию можно восстановить. Восстановление на отдельной тестовой среде показывает, что откат существует не только в отчёте. Подробнее — в материале «Резервное копирование WordPress с иммутабельностью». Обновление плагина на живом сайте без отката заканчивается тем, что вы чините уже не уязвимость, а белый экран.

Как превратить разовую панику в регламент

Один раз сверить версии несложно; повторять проверку для каждого бюллетеня без учёта компонентов — уже рутина, которую быстро забросят. Поэтому у клиентов мы заводим реестр компонентов сайта: CMS и её ветка, каждый плагин и тема с версией, ключевые библиотеки, версия PHP и веб-сервера. Реестр обновляется после каждого обновления сайта, а не раз в год. С ним триаж нового бюллетеня занимает минуты: открыл таблицу, сравнил версию, перешёл к условиям. Без реестра каждый бюллетень начинается с раскопок на сервере, и через месяц их просто перестают делать.

Второй элемент — подписка на первичные источники, а не на новостные каналы. Почти у всех CMS и крупных плагинов есть рассылки или ленты с объявлениями о безопасности. Третий — внутренние сроки реакции по категориям. Их задают с учётом доступности уязвимой функции, подтверждений эксплуатации и последствий обновления. Для KEV или подтверждённой атаки назначаю срочную оценку и план устранения; для применимой уязвимости без таких признаков — ближайшее безопасное окно. Неприменимое решение записываю с обоснованием и условием пересмотра. Обоснование важно: через полгода никто не вспомнит, почему решили не обновлять. И последнее — регулярная уборка. Каждый неиспользуемый плагин — это код, который надо проверять при каждом бюллетене. Самый дешёвый патч — тот, который не нужен, потому что компонента нет. На этом серия «Безопасность CMS» закончена: проверенные копии, обновления по графику, триаж по первичным источникам — три привычки, которые закрывают большую часть того, о чём пишут в тревожных рассылках.

• Реестр компонентов с версиями после каждого обновления
• Подписка на бюллетени разработчиков используемых компонентов
• Сроки реакции по трём категориям риска
• Журнал решений с обоснованием «не применимо»
• Регулярное удаление неиспользуемых плагинов и тем

Частые вопросы