Zimbra се напаѓа преку е-порака: ранливи се серверите пред 10.1.20

На 30 септември 2026 година Microsoft Threat Intelligence објави докази за активно искористување на CVE-2026-73570 против јавно достапни сервери со Zimbra Collaboration Suite. Специјално подготвена е-порака може да го активира нападот без најавување или дејство од примачот, ако е инсталиран изборниот пакет zimbra-snmp и се вклучени SNMP известувањата. Во истражените упади биле забележани веб-обвивки за далечински пристап, пристап до пошта и собирање податоци за автентикација.

За администраторите одговорот почнува со верзијата и со конфигурацијата на секој сервер што прима пошта. Безбедносната табела на Zimbra ја наведува 10.1.20 како издание во кое е поправена ранливоста во компонентата за SNMP следење. Постара инсталација треба да се надгради; дали опишаната патека е активна на конкретен сервер зависи од двата дополнителни услова. Исклучувањето на веб-поштата само по себе не го запира приемот на злонамерната порака преку SMTP.

Кога постарата инсталација е изложена

Верзија пред поправката, инсталиран zimbra-snmp и вклучени SNMP известувања ја сочинуваат конфигурацијата што овозможува искористување на овој пропуст. Проверка само на бројот на верзијата затоа не кажува дали нападната патека е активна, а проверка само на главниот поштенски сервер може да пропушти друг засегнат јазол. Во поголема инсталација треба да се утврдат улогите и поставките на сите сервери што примаат или обработуваат пошта.

Нападот почнува со специјално подготвено SMTP барање. Податок од него стигнува до обработката на SNMP известувањата; при промена на состојбата на сервис, алатката swatchdog може да го вклучи тој податок во повик кон snmptrap. Така вметната наредба може да се изврши со правата на сервисната сметка zimbra. За тој почетен пристап не е потребна лозинка, ниту корисник што ќе отвори прилог или ќе кликне на врска.

Важна е и мрежната патека до SMTP сервисот. Сервер што прифаќа пошта од интернет може да го прими злонамерното барање и кога неговиот веб-интерфејс е затворен за надворешни посетители. Ако приемот на пошта е ограничен на доверливи посреднички сервери, администраторот треба да провери дали ограничувањето навистина важи за засегнатиот јазол, а не само за адресата што ја користат вработените за веб-пошта.

Поправка и привремени мерки

Надградбата на поправеното издание ја отстранува ранливоста. Додека надградбата се подготвува, отстранувањето на изборниот пакет zimbra-snmp или исклучувањето на SNMP известувањата прекинува еден од неопходните услови за опишаниот напад. Тоа се привремени мерки што бараат проверка на влијанието врз следењето на сервисите; нивното воведување не е замена за ажурирање на софтверот.

Ограничувањето на SMTP и SNMP пристапот на доверливи домаќини може дополнително да ја намали изложеноста, но правилата мора да одговараат на начинот на кој организацијата прима пошта. Блокирањето на веб-пристапот решава друго прашање: може да попречи подоцнежно користење на веб-обвивка, но не го отстранува влезот преку SMTP. Затоа и сервер без јавна веб-пошта заслужува проверка на верзијата, пакетот и известувањата.

Што покажале упадите

Поправката го затвора пропустот за идни напади, но не ги отстранува датотеките или поставките оставени при претходен упад. Во набљудуваните случаи напаѓачите поставувале JSP веб-обвивки во директориуми на апликацијата и создавале дополнителни копии на други поштенски јазли. Некои привремено ги менувале дозволите на директориумите за да ја постават веб-обвивката, а потоа ги враќале. Поради тоа, сегашните дозволи сами по себе не покажуваат дали претходно имало упад.

Напаѓачите користеле и повратни командни врски, задачи што се стартуваат повторно и системски сервиси за траен пристап. Според The Hacker News, во дел од нападите бил искористен постојниот SSH идентитет на Zimbra за пренос на веб-обвивки и други датотеки меѓу доверливи јазли. Тоа ја проширува проверката надвор од првично погодениот сервер: на секој поврзан јазол може да остане посебна патека за пристап.

Забележаната активност опфаќала и читање е-пошта, собирање сервисни лозинки и клучеви за автентикација, како и создавање архиви со податоци од поштенски сандачиња. Во еден истражен случај била подготвена архива од резервни копии на пошта и започната постапка за нејзин пренос кон облачно складиште. Достапните податоци за тој случај не утврдуваат дека преносот успешно завршил. При сопствена проверка, пронајдена архива, излезна врска и потврден пренос се различни наоди што треба одделно да се утврдат.

Редослед за проверка на серверот

1. Утврдете ја верзијата на секој Zimbra јазол и означете ги инсталациите пред поправеното издание за надградба. Ако серверот веќе е ажуриран, зачувајте ја неговата претходна историја на верзии за проверка на периодот кога можел да биде изложен.
2. На постарите инсталации проверете дали е инсталиран zimbra-snmp и дали SNMP известувањата се вклучени. Ако важат двата услова, утврдете кој може да стигне до SMTP сервисот и применете поправка или привремена мерка според можностите на системот.
3. Проверете ги трагите од можен упад на сите поврзани јазли: неочекувани JSP датотеки и создадени сервлетни артефакти, необични процеси поврзани со SNMP, нови системски сервиси и задачи што се стартуваат повторно. Побарајте и архиви од пошта, сомнителни излезни врски и пристап до сервисни податоци за автентикација.

Ако се потврди неовластен пристап, само бришење на пронајдената веб-обвивка не е доволно. Потребно е да се утврди до кои поштенски сандачиња и тајни можело да се пристапи, да се отстранат механизмите за траен пристап на поврзаните јазли и да се заменат засегнатите податоци за автентикација. За организација што сама го одржува Zimbra серверот, исходот од таа проверка одредува дали задачата завршува со надградба или продолжува како одговор на упад.

Прочитајте и:

• Разговорот со AI-лик не е дневник: што да проверите пред да се доверите
• AI-агент пред испраќање е-пошта: паузата мора да ја зачува состојбата
• ВЕЗИЛКА излезе пред јавноста: македонската AI-фабрика бара корисници