Żądanie przychodzi do usługi pocztowej, a do wykonania polecenia dochodzi w podsystemie monitorowania, którego zadaniem jest czytanie dziennika zdarzeń. Napastnik nie potrzebuje do tego konta ani hasła. Tak działa luka w Zimbrze, którą CERT Polska 17 sierpnia opisał jako aktywnie wykorzystywaną, pisząc wtedy o trwającej kampanii. Poprawka wyszła miesiąc wcześniej, 20 lipca. Warto więc zapytać, co przez ten miesiąc działo się po stronie administratorów.
Jak żądanie SMTP trafia do obsługi powiadomień SNMP
W opisie tej podatności występują obok siebie dwa podobne skróty. SMTP to protokół poczty, czyli droga, którą ruch wchodzi na serwer pocztowy. SNMP to protokół monitorowania, którym usługi meldują administratorowi swój stan. Oba biorą tu udział, ale na różnych etapach.
Wejście prowadzi przez usługę pocztową. Amerykańska baza podatności opisuje to jednoznacznie: nieuwierzytelniony napastnik wysyła spreparowane żądania SMTP. Konto, hasło ani kliknięcie ofiary nie są potrzebne. Serwer przyjmuje ruch na tym porcie, bo do tego został postawiony.
Warto zaznaczyć, czego źródła nie mówią. Nie podają, w którym miejscu takiego żądania siedzą dane napastnika. Nie wiadomo więc, czy chodzi o treść listu, czy o pole samego protokołu. Opis wskazuje na żądanie SMTP, a nie na wiadomość leżącą w skrzynce odbiorcy.
Wykonanie następuje gdzie indziej. Zimbra dostarcza narzędzie o nazwie swatchdog, opisane w jej własnym repozytorium jako prosty obserwator dzienników. Obserwuje ono zapisy serwera i na podstawie dopasowanych wpisów generuje powiadomienia SNMP. I właśnie w przetwarzaniu tych powiadomień dane z żądania nie są dostatecznie oczyszczane. Program obsługujący powiadomienie traktuje je jak polecenie i uruchamia w systemie. Prawa są takie, jakie ma sama Zimbra, czyli użytkownik zimbra.
Wynik CVSS wynosi 8,9 w skali dziesięciostopniowej. Jeden składnik tej oceny studzi emocje, więc podajemy go uczciwie. Wektor zakłada wysoką złożoność ataku, czyli konieczność spełnienia określonych warunków. Kampania trwa mimo to, więc ktoś te warunki umie spełnić.
Pakiet SNMP jest opcjonalny, a pilnujący dziennika demon działa domyślnie
Tu leży sedno sprawy i powód, dla którego trudno szybko ustalić, czy problem dotyczy naszego serwera. Warunków jest kilka i muszą wystąpić razem. Podatna jest Zimbra w wersji wcześniejszej niż 10.1.20. Do tego dochodzi zainstalowany pakiet zimbra-snmp, będący składnikiem opcjonalnym.
Opcjonalność ma praktyczny skutek. Pakiet mógł zostać doinstalowany przy wdrożeniu albo później, przy podłączaniu serwera do monitorowania. Jego obecność nie wynika więc z bieżącej konfiguracji poczty i nie widać jej po samym sposobie działania serwera.
Drugi warunek jest mniej oczywisty. CERT Polska podaje, że podatne są instancje z włączoną usługą pułapek SNMP przez parametr snmp_notify oraz z uruchomioną usługą swatchdog. I dodaje o tej drugiej rzecz kluczową: jest ona domyślnie włączona. Administrator, który nigdy świadomie nie konfigurował monitorowania, może więc mieć działający fragment układanki bez własnej decyzji.
Wniosek praktyczny jest prosty. Odpowiedzi na pytanie o własną podatność trzeba szukać na maszynie. Pamięć administratora jest tu złym źródłem, bo liczy się stan faktyczny usług, a nie wspomnienie dawnych wyborów.
Pierwsza Misja AI · Kodożercy
Zagrożenia AI rozumie ten, kto rozumie, jak ona działa
Kurs Pierwsza Misja AI ma osobną lekcję o ciemnej stronie AI: halucynacje, deepfake’i, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.
Poznaj pełny program →
Dlaczego serwer pocztowy pozostaje bez aktualizacji przez miesiąc
Poprawka wyszła 20 lipca w wydaniu 10.1.20. Producent nazwał ją trwałym rozwiązaniem krytycznego problemu SNMP, ujawnionego w ostrzeżeniu z 26 czerwca. Amerykańska agencja CISA dopisała tę pozycję do swojego katalogu 21 sierpnia, z terminem naprawy dla urzędów federalnych wyznaczonym na 24 sierpnia. Polskiej firmy ten termin nie wiąże.
Dlaczego konkretne serwery zostały bez tej aktualizacji, nie mówi żadne dostępne źródło. Dalej idzie więc nasza interpretacja, a nie ustalenie. Jedna rzecz daje się jednak sprawdzić i dotyczy sposobu, w jaki producent opisał poprawkę.
W tabeli ostrzeżeń Zimbry kolumny z wynikiem CVSS i z własną oceną producenta zawierają wartość TBD. Zimbra tłumaczy to zasadą zapisaną wprost: przy poprawkach bezpieczeństwa ogranicza ujawnianie informacji. Słowo o krytyczności padło we wpisie na blogu, ale liczby pozwalającej porównać tę pozycję z innymi zabrakło. Wydanie 10.1.20 zawiera dziewięć poprawek, w tym cztery błędy w klasycznym interfejsie poczty i problem w integracji z Nextcloud. Kto układał kolejność wdrożeń według wyników liczbowych, tej pozycji nie miał jak wyróżnić.
Osobno warto zważyć polską skalę, bo łatwo ją przecenić w obie strony. Zapytania o polskie strony logowania do Zimbry zbierają łącznie około 49 tysięcy wyszukiwań miesięcznie. To miara zainteresowania wyszukiwarkowego, a nie liczba osób, logowań ani instytucji, bo jedna osoba może szukać wielokrotnie. Nie wynika z niej również nic o wersjach tych instalacji ani o obecności pakietu SNMP, a tym bardziej o podatności którejkolwiek instancji. Wystarcza natomiast do jednego wniosku: Zimbra jest w polskim internecie obecna na tyle, że warto sprawdzić własny serwer. Podobną odległość między istnieniem poprawki a jej wdrożeniem opisywaliśmy przy luce w MLflow.
Co CERT Polska każe sprawdzić w dzienniku Zimbry
Polski zespół podał w komunikacie coś cenniejszego niż samo ostrzeżenie, czyli konkretne ślady do wyszukania.
W pliku /var/log/zimbra.log należy szukać wpisów o zmianie stanu usługi. Komunikat CERT Polska podaje wzorzec takiej linii wraz z przejściem ze stanu zatrzymanego na uruchomiony i odwrotnie. Podejrzane jest to, że zamiast nazwy usługi pojawia się w niej inna treść. Ten szczegół dobrze pokazuje naturę problemu, bo dane napastnika lądują w miejscu przeznaczonym na nazwę. Podobny wzorzec, choć w innej technologii, opisywaliśmy przy agencie AI, który wykonał instrukcję ukrytą w logu. Tam treść dziennika czytał model językowy, tutaj zwykłe narzędzie systemowe.
Druga wskazówka dotyczy plików. CERT każe sprawdzić, czy w ciągu ostatnich trzydziestu dni użytkownik zimbra nie utworzył plików w katalogach /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ oraz /tmp/. Dwa pierwsze to katalogi aplikacji internetowych serwera. Zespół zaleca ich kontrolę pod kątem skutków wcześniejszego włamania, czyli tego, co mogło zostać podrzucone, zanim aktualizacja zamknęła samą lukę.
Przy wykryciu takich śladów zespół prosi o kontakt.
Podsumowanie
Luka w Zimbrze jest ciekawa nie skalą, tylko drogą. Napastnik korzysta z wejścia, które serwer pocztowy trzyma otwarte, bo przyjmowanie ruchu pocztowego jest jego zadaniem. Do wykonania polecenia dochodzi natomiast w podsystemie monitorowania, czyli daleko od miejsca, w którym administrator szukałby problemu z pocztą. Warunki muszą wystąpić razem: wersja starsza niż 10.1.20, doinstalowany pakiet zimbra-snmp, włączony parametr snmp_notify i działająca usługa swatchdog. Ta ostatnia jest domyślnie włączona, więc odpowiedzi trzeba szukać na maszynie zamiast we własnej pamięci. Aktualizacja do wydania 10.1.20 zamyka samą podatność. Nie zastępuje jednak kontroli śladów wskazanych przez CERT Polska, bo te dotyczą tego, co mogło się wydarzyć wcześniej. Przy sprzęcie konsumenckim ten sam mechanizm wygląda inaczej, bo tam kod trafia do urządzenia drogą fabrycznej aktualizacji oprogramowania.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
