Podatności Zammad

W Zammad przed wersją 1.0.4, 1.1.x przed 1.1.3 oraz 1.2.x przed 1.2.1 odkryto problem CSRF. Atakujący może wykorzystać tę podatność, wysyłając żądania międzydomenowe bezpośrednio do API REST dla użytkowników z ważnym ciasteczkiem sesji.

W Zammad przed wersją 7.1.2, gdy włączone jest ustawienie "Automatic account link on initial logon", system wiąże tożsamość zewnętrznego dostawcy SSO z istniejącym kontem lokalnym na podstawie adresu e-mail raportowanego przez dostawcę, bez weryfikacji, że dostawca potwierdził własność tego adresu. Atakujący kontrolujący dowolną tożsamość u skonfigurowanego dostawcy (domyślnie m.in. dowolny tenant Azure AD przez rejestrację aplikacji Microsoft 365 /common) może ustawić e-mail tożsamości na adres ofiary, uwierzytelnić się i zostać zalogowanym jako ofiara, omijając jej lokalne hasło. Problem dotyczy wszystkich istniejących kont, w tym agentów i administratorów.

W Zammad przed wersją 6.3.0 odkryto problem: Zammad Upload Cache używa niebezpiecznych, częściowo przewidywalnych identyfikatorów FormID do identyfikacji treści. Atakujący może próbować je odgadnąć (brute force), aby przesłać złośliwe treści do wersji roboczych artykułów, do których nie ma dostępu.

W Zammad przed wersją 1.0.4, 1.1.x przed 1.1.3 oraz 1.2.x przed 1.2.1 zidentyfikowano problem związany z brakiem mechanizmu ochrony w nagłówkach HTTP Access-Control. Atakujący może wysłać żądania międzydomenowe bezpośrednio do API REST dla użytkowników z ważnym ciasteczkiem sesji i otrzymać wynik.

W Zammad przed wersją 1.0.4, 1.1.x przed 1.1.3 oraz 1.2.x przed 1.2.1 odkryto problem, który pozwala atakującym logować się przy użyciu hasła w postaci skrótu zamiast prawidłowego ciągu hasła.

Zammad to internetowy system helpdesk typu open source. W wersjach przed 7.1.2, podczas sprawdzania podpisu cyfrowego przychodzącego e-maila podpisanego S/MIME, Zammad nie weryfikuje, czy certyfikat podpisujący jest rzeczywiście zaufany — sprawdza jedynie, czy certyfikat o pasującej nazwie jest już przechowywany w systemie. Atakujący może utworzyć własny certyfikat z nazwą prawdziwego, wcześniej zaufanego nadawcy i wysłać sfałszowany e-mail, który zostanie wyświetlony z oznaczeniem „prawidłowo podpisany”. Problem naprawiono w wersji 7.1.2.

Zammad to internetowy system helpdesk typu open source. W wersjach przed 7.1.2 funkcja External Data Source, używana do wyszukiwania rekordów w systemie zewnętrznym, nie weryfikowała odpowiednio, czy użytkownik ma prawo widzieć konkretny ticket, użytkownika, grupę lub organizację, zanim uwzględniła ich szczegóły w żądaniu do systemu zewnętrznego. Uwierzytelniony użytkownik, nawet z podstawowym dostępem klienta, mógł to wykorzystać, odwołując się do identyfikatora innego rekordu, i w ten sposób wyświetlić szczegóły ticketów, kont klientów, zespołów lub organizacji, które do niego nie należały. Problem naprawiono w wersji 7.1.2.

W Zammad przed wersją 7.1.2 użytkownik z prawem edycji bazy wiedzy może osadzić widget wideo ze specjalnie spreparowaną wartością, która nie jest escapowana w kontekście atrybutu HTML. Gdy inny użytkownik z uprawnieniem przełączania sesji otworzy taką odpowiedź, jego przeglądarka wysyła żądanie do endpointu przełączania sesji Zammad z jego własnymi poświadczeniami, co powoduje przełączenie go na konto wybrane przez autora odpowiedzi.

W Zammad przed wersją 7.1.2 krok logowania dwuskładnikowego pozwalał atakującemu na nieograniczone próby zgadywania hasła bez wyzwalania blokady konta ani ograniczania tempa. Odpowiedź ujawniała też, czy zgadywane hasło było poprawne, jeszcze przed sprawdzeniem drugiego składnika.

W Zammad przed wersją 7.1.2 każdy uwierzytelniony użytkownik może wywołać endpoint REST pobierania listy tagów i otrzymać nazwy tagów dla dowolnego zgłoszenia, niezależnie od posiadanych uprawnień. Ponieważ identyfikatory zgłoszeń są kolejnymi liczbami, możliwe jest masowe wyliczanie danych.

W Zammad przed wersją 7.1.2 nieoczyszczone etykiety opcji są renderowane w oknach konfiguracji agentów AI w panelu administracyjnym. Etykieta opcji jest wstawiana jako surowy HTML bez escapowania, co pozwala atakującemu kontrolującemu etykietę wstrzyknąć dowolny HTML i JavaScript.

W Zammad przed wersją 7.1.2, gdy żądanie Microsoft Graph kończy się błędem, system zapisuje w logach błąd wraz z tokenem uwierzytelniającym. Maskowanie tokenu jest niekompletne — dla formatu JWT ukrywana jest tylko pierwsza część, a pozostałe pozostają czytelne w postaci jawnej.

W Zammad w wersjach 7.0.3 i 7.1.1 uwierzytelniony administrator może uzyskać zapisane poświadczenia integracji w postaci jawnej przez API administracji integracjami. Niektóre odpowiedzi nie maskują spójnie pól wrażliwych, więc skonfigurowane sekrety mogą być zwracane jawnie zamiast jako zamaskowany placeholder.

W Zammad przed wersją 7.1.2 sanitizer HTML blokujący zdalne obrazy w artykułach i widokach e-mail można obejść, używając skróconego formatu URL bez podwójnego ukośnika po schemacie. Nowoczesne przeglądarki traktują oba formaty jako równoważne, więc spreparowany e-mail lub zgłoszenie może spowodować ciche załadowanie obrazu z zewnętrznego serwera.

W Zammad przed wersją 7.1.2 podczas tworzenia lub aktualizacji podpisu e-mail system przetwarza obrazy inline wskazane w treści podpisu. Jeśli treść zawiera znacznik img wskazujący na istniejący załącznik, system kopiuje go do nowego rekordu należącego do podpisu bez sprawdzenia uprawnień użytkownika do oryginalnego załącznika.

W systemie Zammad przed wersją 7.1.2 uwierzytelniony użytkownik z uprawnieniami agenta może podać dowolny identyfikator uruchomienia analizy AI do punktu końcowego podsumowania zgłoszenia i otrzymać komunikat błędu dostawcy AI zapisany dla tego uruchomienia, nawet jeśli uruchomienie należy do zgłoszenia, do którego agent nie ma dostępu. Ujawnienie ogranicza się do ciągu błędu dostawcy; treść zgłoszenia nie jest ujawniana. Problem naprawiono w wersji 7.1.2.

W Zammad przed wersją 7.1.2 kontrolowany przez atakującego HTML w przychodzących e-mailach lub zgłoszeniach może obejść sanitizer adresów URL obrazów za pomocą sekwencji przejścia ścieżki. Gdy uwierzytelniony agent wyświetla treść, przeglądarka rozwiązuje URL do chronionego endpointu API i wysyła żądanie z ciasteczkiem sesji agenta.

W Zammad w wersjach 7.0.3 i 7.1.1 w pewnych warunkach weryfikacja przychodzącej poczty podpisanej PGP może oznaczyć wiadomość jako mającą ważny podpis („Good”) od zarejestrowanego klucza nadawcy, mimo że wyświetlana treść nie jest objęta tym podpisem. Artykuł może zostać zapisany ze statusem poprawnego podpisu, który nie odzwierciedla autentyczności treści.

W Zammad przed wersją 7.1.2 filtr zabezpieczający konfigurację Agenta AI może zostać ominięty przez wprowadzenie specjalnie spreparowanego tekstu w jednym z pól Agenta AI. Administrator z uprawnieniami do tworzenia lub edycji Agentów AI może wykorzystać to do wykonania dowolnych poleceń na serwerze hostującym Zammad, potencjalnie odczytując, modyfikując lub niszcząc wszystkie dane na tym serwerze. Nie jest wymagana interakcja innych użytkowników; złośliwy kod uruchamia się automatycznie przy następnym przetwarzaniu zgłoszenia przez dotkniętego Agenta AI. Problem naprawiono w wersji 7.1.2.

W systemie Zammad przed wersją 7.1.2 akcja destroy_form w AttachmentsController usuwa rekordy UploadCache Store wyłącznie na podstawie dostarczonego przez użytkownika form_id, bez weryfikacji, czy użytkownik jest właścicielem tych rekordów. Uwierzytelniony atakujący, który pozna UUID oczekującego przesyłania innego użytkownika, może po cichu usunąć tymczasowe pliki przed ich przesłaniem przez ofiarę. Problem naprawiono w wersji 7.1.2.

W Zammad w wersjach 7.0.2 i 7.1.0 zarządzanie sesjami dla połączeń websocket i long-polling jest podatne na atak typu path traversal. Identyfikatory sesji dostarczane przez klienta są niewystarczająco walidowane przed użyciem do konstruowania wewnętrznych ścieżek plików. Gdy aktywny jest magazyn sesji oparty na plikach (domyślna konfiguracja), uwierzytelniony atakujący może manipulować identyfikatorem sesji, aby odnosił się do lokalizacji poza zamierzonym katalogiem, prowadząc do usunięcia dowolnych plików i katalogów na serwerze. Wymaga to tylko sesji uwierzytelnionej o niskich uprawnieniach i jednego spreparowanego żądania. Instancje skonfigurowane z magazynem sesji opartym na Redis nie są dotknięte. Problem naprawiono w wersjach 7.0.3 i 7.1.1.

Zammad to internetowy system helpdesk/obsługi klienta o otwartym kodzie źródłowym. W wersjach przed 7.0.2 i 7.1.0 sanitizer HTML Zammad (HtmlSanitizer::Strict) blokuje zewnętrzne adresy URL w celu zapobiegania ładowaniu zdalnych treści, ale atrybut srcset, również dozwolony, nie podlega tej samej kontroli. To niedopatrzenie pozwala atakującemu na osadzenie dowolnych zewnętrznych adresów URL w atrybucie srcset po prostu wysyłając e-mail, skutecznie omijając ochronę przed zewnętrznymi treściami. Gdy agent wyświetla zgłoszenie zawierające złośliwy srcset, przeglądarka po cichu ładuje adres URL kontrolowany przez atakującego, co prowadzi do wycieku adresu IP agenta, User-Agent, Referer i dokładnego czasu wyświetlenia zgłoszenia. HtmlSanitizer::Strict został rozszerzony o blokowanie zewnętrznych adresów URL w atrybucie srcset tagów. Zrobiono to, aby zapobiec śledzeniu pikseli i ładowaniu zewnętrznych treści, co mogłoby naruszyć prywatność użytkownika. Problem został naprawiony w wersjach 7.0.2 i 7.1.0.

Zammad to internetowy system helpdesk/obsługi klienta o otwartym kodzie źródłowym. W wersjach przed 7.0.2, podczas uwierzytelniania federacyjnego (OAuth/OIDC/SAML), adres URL obrazu profilu od zewnętrznego dostawcy tożsamości jest pobierany bez weryfikacji adresu docelowego. Podmiot kontrolujący swój profil u podłączonego dostawcy może spowodować, że serwer połączy się z wewnętrznymi lokalizacjami sieciowymi. Różnice w czasie odpowiedzi i wzorcach błędów między osiągalnymi i nieosiągalnymi celami pozwalają na sondowanie usług wewnętrznych. Procesy robocze mogą być blokowane na kilka sekund na żądanie. Wymaga skonfigurowanego zewnętrznego dostawcy uwierzytelniania, u którego podmiot może modyfikować adres URL obrazu profilu. Problem został naprawiony w wersji 7.0.2.

W Zammad przed wersjami 7.0.2 i 7.1.0 występuje brak walidacji w kaskadzie autoryzacji. W określonych warunkach ograniczenia klucza dostępu są nadpisywane przez ukryte uprawnienia konta nadrzędnego, co niweluje separację obszarów funkcjonalnych i prowadzi do niekontrolowanej ekspansji uprawnień administracyjnych. Atakujący może tworzyć nowe konta administratorów pomimo ograniczeń tokenów, uzyskując pełny dostęp do wszystkich danych systemu (zgłoszenia, klienci, konfiguracja) i całkowitą kontrolę nad instancją Zammad. Problem naprawiono w wersjach 7.0.2 i 7.1.0.

Zammad to internetowy system helpdesk/obsługi klienta o otwartym kodzie źródłowym. W wersjach przed 7.0.2 podatność w sanityzacji HTML Zammad pozwala na wstrzyknięcie określonych elementów HTML do treści zgłoszeń. Gdy inny użytkownik wyświetla spreparowane zgłoszenie, wstrzyknięty element może wywołać żądanie wylogowania, kończąc sesję przeglądającego. Podatność została naprawiona w wersji 7.0.2.

W Zammad przed wersją 7.0.1 uwierzytelniony użytkownik o niskich uprawnieniach może wstrzyknąć dowolny kod HTML, w tym procedury obsługi zdarzeń JavaScript, do tytułu zgłoszenia podczas standardowego procesu tworzenia zgłoszenia. Tytuł jest zapisywany bez sanityzacji. Problem naprawiono w wersji 7.0.1.

W systemie Zammad przed wersją 7.0.2 stwierdzono podatność polegającą na obejściu autoryzacji, która pozwala uwierzytelnionemu agentowi odczytać treść odpowiedzi z bazy wiedzy, do której nie powinien mieć dostępu. Podatna mutacja GraphQL sprawdza tylko uprawnienie ticket.agent, a nie autoryzację do samej odpowiedzi. Problem naprawiono w wersji 7.0.2.

W Zammad przed wersją 7.0.2 występuje błąd kontroli dostępu w API GraphQL. Uwierzytelniony użytkownik może odczytać dane elementu paska zadań (taskbar) należącego do innego użytkownika, podając jego identyfikator, co może ujawnić m.in. automatycznie zapisane szkice zgłoszeń.

W Zammad przed wersją 7.0.2 w przychodzącym przetwarzaniu e-maili PGP wartość zwracana przez weryfikację gpg była po cichu ignorowana. Niezależnie od tego, czy gpg zgłosił poprawny, niepoprawny czy brakujący podpis, procedura bezwarunkowo zapisywała sign: { success: true, comment: "Good signature" } w preferencjach bezpieczeństwa artykułu. Każdy nadawca mógł manipulować treścią podpisanego e-maila PGP lub stworzyć wiadomość z całkowicie sfałszowanym lub niepasującym podpisem, a Zammad wyświetlał ją jako kryptograficznie zweryfikowaną z etykietą "Good signature". Użytkownicy i agenci polegający na wskaźniku podpisu w celu potwierdzenia autentyczności i integralności wiadomości mogli zostać wprowadzeni w błąd, ufając zmodyfikowanym lub sfałszowanym treściom. Podatność dotyczy wszystkich przychodzących e-maili podpisanych PGP przetwarzanych przy włączonej integracji PGP. Problem naprawiono w wersji 7.0.2.

W Zammad przed wersją 7.0.2 dowolny uwierzytelniony agent może przeglądać tytuły, statusy, etykiety i adresy URL zgłoszeń GitHub/GitLab powiązanych z dowolnym zgłoszeniem w systemie, podając kolejne identyfikatory zgłoszeń. Narusza to granice izolacji zgłoszeń między agentami.

W Zammad przed wersją 7.0.2 nieuwierzytelnione żądanie do POST /api/v1/import/otrs/import_check blokuje pracownika żądań Zammad na około dwie minuty. Akcje import_check i import_status nie mają zabezpieczenia setup_done_response, które mają inne akcje w tym samym kontrolerze, więc wykonują się na w pełni skonfigurowanych instancjach produkcyjnych. Akcja wchodzi w pętlę ponowień wobec pustego punktu końcowego OTRS, śpiąc 30 s + 45 s między próbami. Nieuwierzytelniony zdalny atakujący może odmówić usługi produkcyjnej instancji Zammad. Każde żądanie kosztuje prawie nic i wymusza ~115 sekund blokowania po stronie serwera. Kilka żądań na sekundę nasyca pulę pracowników Puma. Problem naprawiono w wersji 7.0.2.

Zammad przed wersją 7.0.2 zawiera podatność, która pozwala użytkownikowi z uprawnieniami edytora w jednej kategorii bazy wiedzy na zobaczenie tytułów odpowiedzi i znaczników czasu aktualizacji z kategorii, do których nie ma dostępu, poprzez globalne szybkie wyszukiwanie. Nazwy kategorii nie są ujawniane, ale tytuły mogą zawierać wrażliwe informacje.

W Zammad przed wersją 7.0.2 występuje problem z kontrolą uprawnień w obszarze zarządzania bazą wiedzy. W pewnych warunkach walidacja danych dla powiązanych elementów nie była w pełni egzekwowana, co mogło pozwolić użytkownikom z ograniczonymi uprawnieniami odczytu na interakcję z elementami poza ich zakresem dostępu.

W Zammad przed wersją 7.0.2 klient mogący wyświetlić zgłoszenie nie widzi wewnętrznych artykułów przez API listy artykułów, ale może bezpośrednio pobrać załącznik należący do wewnętrznego artykułu przez endpoint pobierania załączników. Endpoint ten sprawdza tylko nadrzędne zgłoszenie, a nie artykuł, co omija autoryzację na poziomie artykułu.

Zammad 7.1.0 zawiera uwierzytelnioną podatność na nieprawidłową autoryzację w punkcie końcowym klonowania załączników artykułów biletów.

Zammad przed wersją 7.0.1 zawiera błąd autoryzacji w punkcie końcowym REST POST /api/v1/ai_assistance/text_tools/:id. Dane kontekstowe (np. grupa lub organizacja) dostarczone do użycia w promptcie AI nie były sprawdzane pod kątem dostępności dla bieżącego użytkownika, co prowadzi do użycia nieautoryzowanych danych w promptcie.

W Zammad, webowym systemie helpdesk, przed wersjami 7.0.1 i 6.5.4, endpoint REST POST /api/v1/ai_assistance/text_tools/:id nie sprawdzał, czy użytkownik ma uprawnienia do korzystania z narzędzia tekstowego. Umożliwiało to użycie go w każdej sytuacji, bez odpowiedniej autoryzacji.

Zammad przed wersją 7.0.1 zawiera podatność na iniekcję szablonów po stronie serwera (SSTI), która prowadzi do zdalnego wykonania kodu (RCE) przez agenta AI. Wpływ jest ograniczony do środowisk, gdzie atakujący może kontrolować type_enrichment_data (zwykle konfiguracja administracyjna wysokiego poziomu).

Zammad przed wersjami 7.0.1 i 6.5.4 umożliwia nieuwierzytelnionym atakującym dostęp do punktu końcowego 'getting started', który ujawnia wrażliwe dane wewnętrzne, nawet po zakończeniu konfiguracji systemu.

W Zammad, webowym systemie helpdesk, przed wersjami 7.0.1 i 6.5.4, endpoint używany do tworzenia zgłoszeń (ticket creation) nie sprawdzał autoryzacji, gdy używany był parametr do dodawania linków. Umożliwiało to nieautoryzowane tworzenie zgłoszeń z linkami.

Podatność CSRF w Zammad przed wersjami 7.0.1 i 6.5.4. Punkty końcowe OAuth dla Microsoft, Google i Facebook nie walidują parametru stanu CSRF.

Podatność w mechanizmie SSO w Zammad przed wersjami 7.0.1 i 6.5.4. System nie weryfikował, czy nagłówek pochodzi z zaufanego proxy/gateway SSO przed podjęciem działań.

Zammad, webowy system helpdesk/customer support, przed wersjami 7.0.1 i 6.5.4, zawierał podatność w modelu webhooka polegającą na braku walidacji adresów loopback lub link-local. Sprawdzany był tylko schemat URL (HTTP/HTTPS) i nazwa hosta, co mogło prowadzić do ujawnienia poufnych metadanych dostawców chmury/hostingu. Poprawka rozszerza walidację zarówno przy konfiguracji webhooków, jak i przy wyzwalaniu zadań webhooka.

Zammad to webowy system helpdesk/obsługi klienta. Przed wersjami 7.0.1 i 6.5.4, sanitizer HTML dla artykułów zgłoszeń nieprawidłowo oczyszczał schematy URI data:, co pozwalało na przechowywanie złośliwej treści w bazie danych. GUI Zammad renderuje tę treść, ale dzięki regułom CSP kliknięcie w link nie powoduje szkód. Luka jest naprawiona w wersjach 7.0.1 i 6.5.4.

System Zammad przed wersją 7.0.1 umożliwia klientom w organizacjach współdzielonych (widzącym wzajemnie swoje zgłoszenia) podgląd pól nieprzeznaczonych dla klientów, w tym pól wewnętrznych (np. priorytet, atrybuty niestandardowe). Dzieje się tak, gdy klient otwiera zgłoszenie innego użytkownika z tej samej organizacji. Klienci nie mogą modyfikować tych pól.