Как проверить CVE-2022-27926 в Zimbra и выбрать обновление

CVE-2022-27926 — отражённая XSS в Zimbra 9.0, исправленная в патче P24. Версию я проверяю командой zmcontrol -v от пользователя zimbra. Но в 2026 году остановиться на P24 нельзя: поддержка ветки 9.0 уже завершилась. Ниже — проверка риска, подготовка копии и порядок обновления с проверяемым результатом.

Что позволяет CVE-2022-27926 и где заканчивается её риск

В карточке NVD указана отражённая XSS в компоненте /public/launchNewWindow.jsp Zimbra Collaboration 9.0: параметры запроса позволяют внедрить веб-скрипт или HTML. Злоумышленнику не нужна собственная учётная запись, но для описанной атаки требуется действие пользователя, например открытие подготовленной ссылки. При проверке безопасности корпоративной почты я разделяю эти условия: доступный веб-компонент, уязвимая сборка и действия человека. Наличие старой версии само по себе ещё не доказывает состоявшийся взлом.

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

В примечаниях к P24 производитель относит эту ошибку к Medium. Это основание точно описать последствия, а не отложить работу со словами «всего лишь браузер». Я проверяю, опубликован ли веб-интерфейс, кто им пользуется и есть ли подтверждённое исправление. Отсутствие жалоб пользователей в этот список доказательств не входит. Тихий сервер — прекрасный собеседник, но плохой аудитор.

Формулировка NVD относится к ветке 9.0. Я не превращаю её в утверждение, будто уязвимость обусловлена исключительно новой архитектурой, а вся ветка 8.x заведомо защищена. Для другой версии, сторонней сборки или изменённого веб-компонента нужно отдельное подтверждение поставщика. Разбор ниже касается официальной Zimbra 9.0 и конкретного исправления. Общий вывод о состоянии всей почты по одному номеру CVE я не выдаю.

Как проверить версию Zimbra и установленный патч

Я начинаю с командной строки сервера. Из оболочки root переключаюсь в пользователя zimbra и запрашиваю версию, затем отдельно состояние служб. Если вход уже выполнен под пользователем zimbra, первая строка не нужна. Это проверка без изменения конфигурации и без перезапуска: её можно выполнить до согласования окна работ. Команды из руководства администратора Zimbra 9 выглядят так:

su - zimbra
zmcontrol -v
zmcontrol status

У команд разные задачи. Ключ -v выводит версию продукта, а status показывает состояние компонентов. Запись Running рядом со службой не сообщает, какой патч исправляет XSS. Я сохраняю полный вывод, дату проверки и роль узла, затем сопоставляю результат с примечаниями к выпуску. Обрезанная запись «9.0.0» без сведений о патче недостаточна для заключения. Название основного пакета тоже не заменяет проверку пакетов исправления.

Для официальной ветки 9.0 граница исправления этой ошибки — P24. Если подтверждён более ранний патч, исправление нужно запланировать; если патч неизвестен, я оставляю статус «не подтверждено». P24 или последующий официальный патч означает наличие исправления именно этой CVE при штатной установке. Это ещё не оценка других ошибок, доступа к администрированию и состояния резервных копий. Зелёная строка в отчёте не умеет защищать соседние строки.

В системе с несколькими узлами я повторяю инвентаризацию на каждом сервере и отмечаю, где работают веб-компоненты и почтовые хранилища. Иначе легко проверить один узел, а объявить обновлённой всю установку. Если поставщик сборки отличается от разработчика продукта, уточняю его обозначения патчей и наличие перенесённого исправления. Версию ОС также записываю, но свежая ОС не исправляет старый код приложения. В итоговой таблице должны быть отдельные поля для продукта, патча, ОС и источника пакетов.

• Сохранить полный вывод `zmcontrol -v` от пользователя zimbra.
• Проверить службы через `zmcontrol status` отдельно от версии.
• Сверить патч и сборку с документацией их поставщика.
• Повторить проверку на остальных узлах установки.

Что я проверяю до обновления: копия, восстановление, окно

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

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

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

Время работ я оцениваю по размеру данных, скорости хранилища, исходной версии и результатам репетиции. Число сотрудников не отвечает ни на один из этих вопросов. Проверку восстановления выношу в самостоятельный пункт приёмки; подробный порядок разобран в материале про восстановление Zimbra из копии. Результат подготовки — доступная копия, проверенная последовательность возврата и согласованное окно, а не письмо «резервирование вроде включено».

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

P24 — историческая граница исправления CVE-2022-27926, а не актуальная цель обновления. В действующей таблице жизненного цикла Zimbra для ветки 9.0 указано завершение General Support и Technical Guidance 30 июня 2025 года. В базе знаний сохранилась более ранняя дата окончания поддержки; я сверил её с актуальной таблицей производителя, где видно продление. На дату этой проверки, 25 октября 2026 года, план для старого сервера должен включать переход на поддерживаемую ветку или другую подходящую почтовую систему.

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

В примечаниях к P24 есть отдельные инструкции для Ubuntu и Red Hat, а внутри — шаги для разных ролей узлов. Поэтому я не предлагаю одну общую команду обновления всей ОС как рецепт исправления почты. Для рабочего сервера беру перечень пакетов, порядок установки и перезапуска из документации целевого выпуска. Перед подтверждением операции смотрю, что менеджер пакетов собирается установить, заменить или удалить. Неожиданное удаление компонента почты — повод разобрать зависимости, а не быстрее нажать согласие.

После установки выполняю предусмотренный инструкцией перезапуск. Команда zmcontrol restart от пользователя zimbra перезапускает службы на текущем узле; это не перезагрузка операционной системы. Необходимость перезагрузки ОС оценивают отдельно по составу обновлений. На одном сервере остановка служб влияет на доступность почты, поэтому обещание нулевого простоя заранее я убираю. Для общего маршрута есть план перехода с Zimbra 9; здесь критерий уже: подтвердить исправление конкретной XSS и не оставить сервер на завершившей поддержку ветке.

• Выбрать поддерживаемый целевой выпуск и проверить допустимый маршрут.
• Повторить нужные шаги на изолированной копии.
• Установить пакеты по инструкции целевого выпуска в согласованное окно.
• Выполнить предписанный перезапуск и перейти к проверке почты.

Условный разбор: бюро «Правовой формат», 46 рабочих мест

Возьму условное московское юридическое бюро «Правовой формат» из задания: 46 рабочих мест. Это учебный сценарий, а не рассказ о реальном клиенте. Исходное условие — Zimbra 9.0.0 GA без подтверждённого уровня патча, открытый веб-интерфейс и непроверенное восстановление. По такой записи я не объявляю сервер взломанным. Я фиксирую пробелы: требуется установить точную сборку, проверить наличие исправления и понять, можно ли восстановить переписку.

Для сценария я закладываю два отдельных этапа: подготовку с репетицией и согласованное окно изменения рабочей системы. На подготовке сохраняю вывод версии, выясняю роли узлов, проверяю копию и измеряю восстановление. Допустим, уточнение инвентаризации подтвердило официальный патч ниже P24. Тогда отсутствие исправления этой XSS становится установленным фактом, а не догадкой по надписи GA. Если проверить патч не удалось, задача остаётся открытой с конкретным ответственным.

На репетиции проверяю маршрут до выбранного поддерживаемого выпуска и сохраняю результаты каждой контрольной операции. В рабочем окне повторяю проверенные шаги, затем проверяю вход, приём и отправку писем, вложения, календарь и доступ с используемых почтовых клиентов. Для 46 рабочих мест нельзя автоматически обещать ни 46 ящиков, ни короткую процедуру: общие адреса и объём переписки считаются отдельно. Красивое равенство в смете не обязано совпадать с устройством почты.

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

Как подтвердить результат и не пропустить следующий патч

После работ я снова запрашиваю zmcontrol -v и zmcontrol status, сверяю результат с целевым выпуском и сохраняю протокол установки пакетов. Затем выполняю функциональные проверки из согласованного списка. Одного открывшегося окна входа мало: пользователь должен прочитать старую переписку, отправить тестовое письмо и получить ответ. Изменение номера версии и работоспособность почты — отдельные условия приёмки. Для нескольких узлов проверка повторяется по их ролям.

Из базы знаний я беру полезное уточнение: основной журнал приложения mailboxd по умолчанию — /opt/zimbra/log/mailbox.log. Системный /var/log/zimbra.log собирает сообщения компонентов через системное журналирование. Я смотрю оба источника за период изменения, соотношу новые ошибки со временем установки и проверяю завершение операций менеджера пакетов. Чистый журнал не доказывает отсутствия XSS в прошлом, зато помогает обнаружить сломанный запуск или работу почтового компонента после обновления.

Если есть подозрительные письма, необычные входы или изменения правил пересылки, я открываю отдельную проверку инцидента. Исправление ошибки не отменяет действий, которые могли произойти до установки патча. Сохраняю доступные журналы и подозрительные сообщения, проверяю учётные записи, активные сеансы и правила обработки почты. О том, как читать события без гадания по одной строке, рассказываю в разборе журналов и признаков атаки. Сам по себе старый патч не является доказательством утечки.

Для дальнейшего контроля назначаю ответственного и подключаю официальные уведомления. В базе есть два конкретных адреса: https://wiki.zimbra.com/security-advisory-feed.php для уведомлений безопасности и https://blog.zimbra.com/feed/ для подробностей о патчах и других новостях. Я проверил их назначение по публикации разработчика. До обновления можно временно ограничить доступ к веб-интерфейсу по требованиям организации, но такое ограничение не исправляет код. В журнале задач остаются выбранный выпуск, срок работ и подтверждение приёмки. Подписка сама пакеты не устанавливает — у неё пока нет такой должности.

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