Ліст узломвае Zimbra без кліку — патч не выдаляе ўжо ўсталяваны бэкдор

30 верасня 2026 года даследчыкі Microsoft апублікавалі разбор пацверджаных узломаў Zimbra Collaboration Suite праз CVE-2026-73570. Спецыяльна сфармаваны ліст можа запусціць каманды на адкрытым у інтэрнэт паштовым серверы без аўтэнтыфікацыі нападніка і без дзеянняў атрымальніка, калі ўсталяваны zimbra-snmp і ўключаныя SNMP-апавяшчэнні. У расследаваных выпадках нападнікі пакідалі вэб-шэлы, атрымлівалі доступ да пошты і збіралі даныя аўтэнтыфікацыі.

The Hacker News таксама апісвае эксплуатацыю гэтай ужо выпраўленай уразлівасці і размяшчэнне некалькіх вэб-шэлаў у шляхах Jetty і mailboxd. Для адміністратара істотна адрозніць два станы: ці можа сервер прыняць новы шкоднасны запыт і ці застаўся на ім доступ пасля папярэдняга ўзлому. Версія праграмы адказвае на першае пытанне; файлы, працэсы і журналы — на другое.

Ці ўразлівы канкрэтны сервер

Спачатку трэба высветліць, ці ёсць на паштовым вузле дадатковы пакет zimbra-snmp і ці ўключаныя SNMP-апавяшчэнні. Апісаны шлях атакі патрабуе абедзвюх умоў; адна толькі наяўнасць паштовага сервера Zimbra не азначае, што гэты механізм даступны. Праверку варта правесці на кожным вузле, які апрацоўвае ўваходную пошту, бо налады і склад пакетаў у шматвузлавой інсталяцыі могуць адрознівацца.

Затым трэба параўнаць фактычную версію сервера з выпраўленай: бюлетэнь бяспекі Zimbra пазначае выпраўленне CVE-2026-73570 у выпуску 10.1.20. Для гэтай уразлівасці патрэбная версія з гэтым выпраўленнем або пазнейшая падтрымоўваная версія. Калі zimbra-snmp і апавяшчэнні актыўныя, а выпраўлення няма, сервер адпавядае ўмовам апісанай атакі.

Шкоднасны фрагмент трапляе ў сістэму праз SMTP-запыт. Калі змяненне стану службы запускае маніторынг, swatchdog можа ўключыць кантраляванае нападнікам значэнне ў выклік snmptrap праз камандную абалонку. Так каманды выконваюцца з правамі службовага карыстальніка zimbra яшчэ на баку сервера: атрымальніку не трэба адкрываць ліст або пераходзіць па спасылцы.

Чаму патч не завяршае расследаванне

Абнаўленне перакрывае ўразлівы шлях для наступных запытаў, але не прыбірае файлы, якія нападнік паспеў запісаць раней. У расследаваных выпадках пасля выканання каманд ствараліся JSP-вэб-шэлы ў каталогах вэб-прыкладанняў. Да такога файла можна звяртацца праз HTTP, таму для далейшага доступу нападніку ўжо не патрабуецца паўтараць атаку праз SNMP.

Адным файлам справа не заўсёды абмяжоўвалася. Копіі вэб-шэлаў размяшчалі ў шляхах Jetty і mailboxd, у тым ліку на іншых mailbox-вузлах; для пераносу выкарыстоўвалі існыя даверныя SSH-сувязі паміж вузламі і rsync. На некаторых серверах нападнікі часова дазвалялі запіс у агульнадаступны каталог, а пасля размяшчэння файла вярталі ранейшыя правы. Звычайная праверка дазволаў у такім выпадку не пакажа, як файл туды трапіў.

Назіраліся і іншыя спосабы захаваць доступ: зваротныя абалонкі, заданні cron, службы systemd, ключы SSH і лакальныя ўліковыя запісы. Служба zimlog.service у адным з эпізодаў знаходзілася ў /etc/systemd/system/ і запускалася пры старце сістэмы; яе назва нагадвала кампанент журналявання Zimbra. Таму нават пасля выдалення знойдзенага JSP-файла трэба шукаць іншыя механізмы доступу на тым жа вузле і ў астатняй частцы кластара.

Якія сляды звязваюць ліст з узломам

Найбольш выразны след першапачатковай атакі — нечаканая камандная абалонка ў ланцужку працэсаў swatchdog і snmptrap. У падазроным выкліку могуць з’явіцца сімвалы каманднай абалонкі, пасля якіх запускаюцца wget або curl. Побач па часе варта шукаць незвычайныя DNS- і HTTP-звароты, запуск дадатковых працэсаў і злучэнні, падобныя да зваротнай абалонкі. Асобная сеткавая падзея без сувязі з працэсамі яшчэ не вызначае прычыну.

У файлах увагі патрабуюць нечаканыя JSP-файлы ў актыўных каталогах Jetty і mailboxd, а таксама згенераваныя *_jsp.java і скампіляваныя артэфакты ў рабочых каталогах сервлетаў. Іх варта супаставіць з журналамі HTTP-запытаў да адпаведных шляхоў і з падзеямі змены правоў каталогаў. Праверка толькі даты файла можа ўвесці ў зман: пры адным з назіраных спосабаў захавання доступу нападнікі змянялі часовую метку службы systemd, каб яна выглядала старэйшай.

На ўзроўні сістэмы трэба шукаць новыя або змененыя службы systemd, заданні cron, запісы ў authorized_keys і незвычайныя ўліковыя запісы. Для кластара істотныя таксама нетыповыя запускі zmprov, SSH з выкарыстаннем /opt/zimbra/.ssh/zimbra_identity і перанос файлаў праз rsync паміж паштовымі вузламі. Гэтыя дзеянні могуць быць адміністрацыйнымі, таму іх трэба звязваць з часам атакі, паходжаннем працэсаў і змесцівам перанесеных файлаў.

Пра збор сакрэтаў могуць сведчыць нечаканыя выклікі zmlocalconfig -s і LDAP-запыты да zimbraPreAuthKey, zimbraAuthTokenKey і zimbraTwoFactorAuthSecret. У адным расследаваным выпадку нападнік падрыхтаваў архіў паштовай рэзервовай копіі /opt/zimbra/final.tar.gz і запусціў AzCopy для яго перадачы. Наяўныя даныя паказвалі спробу вываду, але не пацвердзілі, што перадача завяршылася; маштаб магчымай страты трэба вызначаць па захаваных журналах і артэфактах.

Што рабіць пасля абнаўлення

Пры выяўленні прыкмет старонняга доступу варта захаваць журналы і іншыя доказы, абмежаваць доступ да закранутых вузлоў і праверыць астатнія mailbox-вузлы. Пасля вызначэння спосабаў замацавання трэба выдаліць усе выяўленыя вэб-шэлы і механізмы паўторнага запуску. Асобнай увагі патрабуюць службовыя ўліковыя даныя і ключы аўтэнтыфікацыі Zimbra, да якіх нападнік мог атрымаць доступ: адна знойдзеная копія вэб-шэла не вызначае поўны маштаб пранікнення.

Калі ўсталяваць выпраўленне адразу немагчыма, выдаленне zimbra-snmp або адключэнне SNMP-апавяшчэнняў прыбірае неабходную ўмову менавіта гэтага шляху атакі. Пасля абнаўлення рашэнне пра аднаўленне звычайнай працы павінна абапірацца на стан усіх закранутых вузлоў і вынікі праверкі захаванага доступу. Інакш сервер можа прымаць ужо выпраўленыя SMTP-запыты, але па-ранейшаму выконваць каманды праз пакінуты вэб-шэл.