Zimbra взламывают письмом без входа — обновление 10.1.20 закрывает брешь

В техническом отчёте Microsoft от 30 сентября 2026 года описаны атаки на доступные из интернета почтовые серверы Zimbra через специально подготовленное письмо. Уязвимость CVE-2026-73570 позволяет выполнить команду без учётной записи и участия получателя, если на сервере установлен дополнительный пакет zimbra-snmp и включены уведомления SNMP. На скомпрометированных узлах исследователи наблюдали веб-оболочки, доступ к почте и сбор ключей аутентификации.

Бюллетень безопасности Zimbra относит исправление внедрения команд в компоненте мониторинга SNMP к версии 10.1.20. Администратору нужно проверить не только текущую версию, но и конфигурацию до обновления: исправление закрывает уязвимый путь, однако уже созданные средства удалённого доступа и раскрытые секреты остаются отдельной проблемой.

Когда письмо приводит к выполнению команды

Письмо доставляется по почтовому протоколу SMTP. Содержащееся в нём подготовленное значение попадает в обработку уведомлений о состоянии служб; при срабатывании мониторинга оно включается в командный вызов отправки уведомления SNMP. Если значение обработано без достаточной очистки, встроенная команда выполняется с правами служебной учётной записи Zimbra. Вход в веб-почту или открытие письма адресатом для этого пути атаки не требуются.

Риск возникает при сочетании двух условий: дополнительный пакет zimbra-snmp установлен, а уведомления SNMP включены. Если одного условия нет, описанный механизм не срабатывает. В публикации Ars Technica от 30 сентября также указаны оба условия и отсутствие необходимости в пароле. Полученные при эксплуатации права служебной учётной записи дают возможность записывать файлы приложения; в наблюдавшихся атаках злоумышленники затем добивались более широкого доступа к системе.

Какие узлы считать затронутыми

Первое решение зависит от версии каждого почтового узла и его прежних настроек. Версия 10.1.20 содержит исправление этой бреши; на более ранней версии доступный извне сервер с работающими уведомлениями SNMP и пакетом zimbra-snmp был уязвим. Текущая исправленная версия сама по себе не показывает, успели ли выполнить команду до обновления. Поэтому полезны журналы установки пакетов, изменения настроек и даты развёртывания исправления.

1. Проверьте фактическую версию Zimbra на каждом узле, принимающем почту из интернета. Сверьте её с историей обновлений, чтобы установить, работал ли узел на уязвимой версии в период возможной атаки.
2. Для прежней уязвимой версии выясните, были ли одновременно установлены zimbra-snmp и включены уведомления SNMP. При отсутствии любого из этих условий именно описанный путь через письмо не работал. Если историю настроек восстановить нельзя, не делайте вывод о безопасности по их нынешнему состоянию.
3. На узлах с уязвимым сочетанием установите исправленную версию или более новую. Если обновление приходится отложить, отключение уведомлений и удаление дополнительного пакета перекрывают необходимые условия атаки; возможность ограничить доступ к почтовому и управляющему протоколам зависит от схемы доставки почты.

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

Какие следы остаются после проникновения

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

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

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

Что остаётся сделать после установки исправления

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

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

Читайте также:

• Check Point взламывают без входа — нужны два разных исправления
• Обновление установлено не всегда: как проверить исправления Windows
• Вакансия стала входом для Lazarus — Windows спасает только после обновления