Перейти до вмісту
-Advanced
UA RU
093 442 18 08 Консультація

Post

CVE-2026-73570: уразливість Zimbra вже активно використовують. Як перевірити та захистити поштовий сервер

У Zimbra Collaboration виявлено уразливість CVE-2026-73570, пов’язану з ін’єкцією команд у компоненті SNMP monitoring. CERT Polska повідомила про її активне використання, а CISA додала CVE до каталогу Known Exploited Vulnerabilities.[3][5]

Ризик високий: за певної конфігурації неавторизований атакувальник може надіслати спеціально сформований SMTP-запит і домогтися виконання довільних команд операційної системи від імені користувача zimbra.[3]

Це не означає, що кожен сервер Zimbra автоматично вразливий. Однак адміністраторам не варто обмежуватися лише перевіркою номера версії. Потрібно підтвердити наявність уразливих компонентів і налаштувань, а також перевірити, чи не було використано вразливість до оновлення.

Що сталося

CVE-2026-73570 стосується Zimbra Collaboration до версії 10.1.20 за умови, що встановлено опціональний пакет zimbra-snmp і ввімкнено SNMP notifications.[3] Zimbra описує виправлення як усунення command injection у компоненті SNMP monitoring при ввімкнених SNMP notifications; виправлення включене до релізу 10.1.20.[1][2]

CERT Polska додатково уточнює конфігураційні умови: активний SNMP trap через параметр snmp_notify і запущений swatchdog, який у типовій конфігурації ввімкнений за замовчуванням.[5]

Чому CVE-2026-73570 небезпечна

Для атаки не потрібен обліковий запис Zimbra або попередня авторизація. Успішна експлуатація може призвести до виконання команд із правами системного користувача zimbra.[3]

Поштовий сервер є критичним активом: він обробляє корпоративне листування, вкладення, адресні книги та дані автентифікації. Тому навіть виконання команд не від root, а від сервісного користувача потребує термінової перевірки та контрольованого реагування.

Оцінка NVD для CVE-2026-73570 - 8.9 за CVSS 3.1, рівень High.[3] Але для пріоритезації важлива не лише оцінка: уразливість уже внесена до KEV і має підтвердження активної експлуатації.[3][5]

Які сервери Zimbra в зоні ризику

Сервер потребує першочергової перевірки, якщо одночасно виконуються такі умови:

  1. використовується Zimbra Collaboration версії нижче 10.1.20;
  2. встановлено пакет zimbra-snmp;
  3. увімкнено SNMP notifications / SNMP trap;
  4. працює swatchdog.

Якщо пакет не встановлений або сповіщення SNMP не активовані, описаний шлях експлуатації не відповідає опублікованим умовам CVE. Але це не скасовує необхідність підтримувати Zimbra в актуальному підтримуваному стані та перевірити інші виправлення безпеки релізу.[1][2][3]

Як адміністратору перевірити версію та конфігурацію

Перевірку слід виконувати з адміністративним доступом до власного сервера або за участю відповідального системного адміністратора.

1. Визначте версію Zimbra

У стандартній інсталяції версію можна перевірити від імені користувача zimbra:

sudo -iu zimbra zmcontrol -v

Якщо версія нижча за 10.1.20, сервер потенційно підпадає під опис уразливості, але остаточний висновок залежить від компонентів і конфігурації.[3]

2. Перевірте наявність zimbra-snmp

Перевірте встановлені пакети штатним менеджером пакетів вашої операційної системи. Назва пакета, на яку вказує опис CVE, - zimbra-snmp.[3]

3. Перевірте SNMP notifications і swatchdog

Потрібно встановити фактичне значення snmp_notify та стан swatchdog. Не змінюйте ці параметри без розуміння чинного моніторингу: спочатку зафіксуйте поточну конфігурацію, залежності та доступний план відновлення.

Якщо немає впевненості в архітектурі інсталяції, не виконуйте «швидке» оновлення навмання. Спочатку зберіть версію, перелік вузлів, встановлені пакети, стан сервісів і доступність перевіреної резервної копії.

Чому одного оновлення може бути недостатньо

Оновлення до виправленої версії закриває відомий шлях експлуатації, але не видаляє автоматично наслідки атаки, яка могла відбутися раніше.

Саме тому CERT Polska радить не лише оновити Zimbra, а й перевірити журнали та файли, створені користувачем zimbra у визначених каталогах за останні 30 днів.[5]

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

Що показують практичні розбори скомпрометованих Zimbra-систем

Під час ручних технічних розборів IT Advanced перевіряла журнали, файлову систему, webapps, Jetty work cache, розклад завдань, системні секрети та адміністративні налаштування.

У скомпрометованих середовищах виявляли вебшели, майнер, змінений crontab, механізми закріплення та ознаки доступу до localconfig.xml. Практичний висновок - поява майнера не описує весь інцидент. Це лише видимий індикатор, після якого потрібно окремо перевірити вебшели, скомпільований кеш Jetty, механізми закріплення, системні секрети, активні сесії та зміни на рівні Zimbra.

Ще одна пастка - орієнтація лише на mtime. Часові мітки підозрілих файлів можуть виглядати як легітимні. Для побудови таймлайну потрібно зіставляти ctime, дати скомпільованих класів у Jetty work cache, журнали доступу та інші незалежні джерела.

Працююча пошта також не доводить, що сервер чистий. Шкідливі артефакти та механізми закріплення можуть залишатися непомітними, поки основні функції пошти продовжують працювати.

Джерело цього розділу: узагальнені та обезличені висновки з внутрішніх технічних розборів IT Advanced.

Які ознаки компрометації необхідно перевірити

CERT Polska рекомендує переглянути /var/log/zimbra.log і звернути увагу на неочікувані зміни стану сервісів, зокрема записи:

Service status change: changed from stopped to running
Service status change: changed from running to stopped

Окремо потрібно перевірити файли, створені користувачем zimbra протягом останніх 30 днів у каталогах:[5]

/opt/zimbra/jetty/webapps/
/opt/zimbra/jetty_base/webapps/
/tmp/

Ці записи або файли не завжди означають компрометацію: можливі легітимні адміністративні дії. Їх потрібно зіставляти з часом оновлень, журналами SMTP, системними подіями, історією змін та мережевою активністю.

Не видаляйте підозрілі файли до фіксації доказів. Поспішне очищення може ускладнити визначення масштабу інциденту та відновлення послідовності подій.

Що перевіряє поглиблений аудит

Практичний аудит не обмежується пошуком майнера або одним grep. До нього можуть входити:

  • перевірка фактичного стану виправлення та небезпечної конфігурації;
  • пошук вебшелів за вмістом у webapps, а не лише за назвами файлів;
  • аналіз Jetty work cache, де можуть залишатися скомпільовані сліди вже видалених JSP;
  • зіставлення кодів відповіді та розмірів відповідей у access logs з підозрілими шляхами;
  • перевірка можливого доступу до localconfig.xml та оцінка необхідності ротації системних секретів;
  • persistence sweep: crontab, ключі доступу, системні служби, startup mechanisms і привілейовані облікові записи;
  • перевірка форвардів, нових облікових записів, делегованих і зайвих адміністраторів у Zimbra;
  • перевірка зовнішньої поверхні, TLS, egress policy, резервних копій і можливості відновлення;
  • контрольна перевірка після очищення або відновлення.

Точний склад залежить від версії, архітектури та збережених доказів. Ротацію секретів, очищення cache і перезапуск сервісів потрібно виконувати за погодженим incident-response plan, а не випадковими командами з Інтернету.

Що робити, якщо сервер уразливий або вже зламаний

Якщо ознак компрометації не виявлено

  1. Зафіксуйте поточну версію та конфігурацію.
  2. Перевірте стан резервного копіювання і можливість відновлення.
  3. Підготуйте сумісне оновлення до актуальної виправленої версії.
  4. Виконайте оновлення у контрольоване вікно.
  5. Перевірте запуск сервісів, доставку пошти, вебклієнт, черги та журнали.
  6. Повторіть контрольну перевірку конфігурації та індикаторів.

Якщо є підозрілі ознаки

  1. Не обмежуйтеся звичайним оновленням.
  2. Зафіксуйте журнали, часові мітки, підозрілі файли та стан системи.
  3. Обмежте зовнішній доступ настільки, наскільки це можливо без знищення доказів і неконтрольованої зупинки критичних процесів.
  4. Визначте, які облікові записи, ключі, токени й поштові дані могли бути доступні.
  5. Після збереження доказів виконайте очищення або відновлення з довіреного стану.
  6. Змініть потенційно скомпрометовані секрети та перевірте суміжні системи.
  7. Після відновлення проведіть повторну перевірку та посилення конфігурації.

Порядок дій залежить від архітектури Zimbra, наявності резервних копій і критичності поштового сервісу. Для підтвердженого інциденту потрібен окремий план реагування, а не лише стандартний patch management.

Як IT Advanced може допомогти

IT Advanced проводить первинну оцінку версії та конфігурації, перевіряє умови CVE-2026-73570 і шукає ознаки компрометації не лише в активних файлах, а й у журналах, Jetty work cache, механізмах закріплення та налаштуваннях Zimbra. Якщо є ознаки доступу до системних секретів, окремо визначається обсяг ротації, відновлення і контрольної перевірки. Подальші роботи погоджуються після оцінки фактичного стану сервера; однаковий результат для всіх інсталяцій не обіцяється.

Перевіримо ваш сервер Zimbra на вразливість CVE-2026-73570 та ознаки компрометації. За потреби виконаємо резервне копіювання, безпечне оновлення до актуальної версії та контрольну перевірку після робіт.

Перевірити сервер Zimbra
Для первинної оцінки достатньо повідомити версію Zimbra. Паролі та доступи на цьому етапі не потрібні.

Детальніше про порядок робіт: оновлення та аудит безпеки Zimbra. Додатковий контекст: аудит кібербезпеки та обслуговування серверів.

FAQ

Чи всі сервери Zimbra до 10.1.20 уразливі?

Ні. Опублікований опис CVE вказує на додаткові умови: встановлений zimbra-snmp, увімкнені SNMP notifications і відповідна робота компонента моніторингу.[3][5] Перевіряти потрібно і версію, і конфігурацію.

Чи можна експлуатувати CVE-2026-73570 без авторизації?

Так. За описом NVD, неавторизований атакувальник може через спеціально сформований SMTP-запит домогтися виконання команд від користувача zimbra.[3]

Яка версія містить виправлення?

Виправлення включене до Zimbra 10.1.20.[1][2] Перед оновленням потрібно перевірити сумісність, резервні копії та план відновлення.

Чи достатньо просто оновити Zimbra?

Для закриття відомої вразливості оновлення необхідне, але після можливої атаки його недостатньо. Потрібно окремо перевірити журнали, підозрілі файли та інші ознаки компрометації.[5]

Які дані потрібні для первинної оцінки?

Спочатку достатньо повідомити точну версію Zimbra, тип інсталяції та наявність zimbra-snmp/SNMP notifications. Паролі й віддалений доступ на цьому етапі не потрібні.

Що робити, якщо знайдено підозрілий файл?

Не видаляйте його одразу. Зафіксуйте шлях, власника, часові мітки та пов’язані журнали, після чого організуйте контрольований incident triage. Видалення без фіксації може знищити важливі докази.

Чи означає відсутність відомих індикаторів, що сервер чистий?

Ні. Опубліковані індикатори допомагають первинній перевірці, але їх відсутність не є повною гарантією. Глибина аналізу має відповідати ризику та фактичному стану системи.

Sources