Helpdesk je jednou z nejdůvěryhodnějších schránek, které organizace provozuje. Zákazníci do něj vkládají údaje o účtech, chybové protokoly, jména a někdy i dokumenty v domnění, že data jsou v bezpečí za platformou. Hlášený řetězec zero-day zranitelností Zammad umožňujících vzdálené spuštění kódu, který byl použit proti Nizozemskému institutu pro odhalování zranitelností (DIVD), je připomínkou, že tato důvěra zcela závisí na softwaru, který tikety spravuje.

Podle zprávy dvě zero-day zranitelnosti Zammad umožňují únos relace, vzdálené spuštění příkazů a potenciální přístup root na podkladovém serveru. Zammad je open-source platforma pro tikety a helpdesk. Podrobnosti ve zdrojovém článku jsou omezené, proto se tento příspěvek drží toho, co bylo hlášeno, a vyhýbá se spekulacím o technických detailech.

Jak byly zero-day zranitelnosti Zammad zřetězeny

Jádrem příběhu je řetězení. Ani jedna z chyb nemusí být sama o sobě zničující, aby kombinace byla vážná. Podle zprávy první slabina umožňuje útočníkovi unést relaci, což znamená převzít přístup autentizovaného uživatele bez znalosti jeho hesla. Druhá umožňuje vzdálené spuštění příkazů, což útočníkovi dovoluje spouštět příkazy na serveru hostujícím Zammad. Odtud je přístup root popsán jako potenciální výsledek, což znamená, že útočník by mohl získat plnou kontrolu nad strojem.

Tento vzorec je běžný u vážných průniků: jedna chyba získá opěrný bod, druhá promění tento opěrný bod v kontrolu. Vysvětluje to také, proč jsou obránci vyzýváni, aby brali zranitelnosti se střední závažností vážně, protože se mohou stát prvním článkem řetězce.

Pro úplný popis útoku, včetně toho, jak se průnik do DIVD odvíjel, si přečtěte naše dřívější články: AI Agent Chains Two Zammad Zero-Days to Breach DIVD a DIVD: AI Agent Exploits Two Zammad Zero-Days in Breach.

Co kompromitovaný helpdesk odhaluje

Server helpdesku uchovává více, než si lidé obvykle uvědomují. V závislosti na tom, jak organizace helpdesk používá, může kompromitovaná instance odhalit:

  • Podpůrné tikety a celou historii konverzace, která je k nim připojena
  • Jména zákazníků, e-mailové adresy a další kontaktní údaje
  • Přílohy, jako jsou snímky obrazovky, protokoly nebo dokumenty, které zákazníci nahráli
  • Interní poznámky, které zaměstnanci napsali o zákaznících nebo incidentech
  • Přihlašovací údaje, API tokeny nebo nastavení integrací uložené na serveru

Přístup root zvyšuje sázky ještě více. Útočník s kontrolou nad hostitelem není omezen na data aplikace. Může dosáhnout na další služby na stejném stroji, číst konfigurační soubory a použít server jako odrazový můstek jinde v síti. Proto se kompromitace helpdesku může stát širším incidentem, nikoli izolovaným.

Případ DIVD je také pozoruhodný, protože DIVD je samo bezpečnostní organizací, která pomáhá s nahlášením a opravou zranitelností. Pokud může být zasažena skupina zaměřená na tuto práci, každá organizace provozující samo-hostované nástroje by měla předpokládat, že je možným cílem. Kontext pokrývá náš článek o the Zammad zero-day chain that enabled the AI-driven breach.

Co by nyní měli administrátoři Zammad udělat

Pokud provozujete Zammad, berte to jako prioritní revizi, nikoli rutinní úkol.

  1. Zkontrolujte oficiální opravy. Sledujte bezpečnostní doporučení projektu Zammad a aplikujte všechny záplaty nebo aktualizace, jakmile budou k dispozici. Nespoléhejte na souhrny třetích stran ohledně podrobností o verzích.
  2. Omezte vystavení. Pokud vaše instance nemusí být dostupná z otevřeného internetu, omezte přístup pomocí VPN, allowlistu IP adres nebo pravidel reverzního proxy, dokud neaplikujete záplatu.
  3. Zneplatněte relace. Vzhledem k tomu, že únos relace je součástí hlášeného řetězce, zvažte po aktualizaci vynucení odhlášení a rotaci tajných klíčů relací.
  4. Rotujte přihlašovací údaje. Změňte administrátorská hesla, API tokeny a všechny tajné klíče uložené na serveru, zejména pokud máte podezření na kompromitaci.
  5. Projděte protokoly. Hledejte neobvyklá administrátorská přihlášení, neočekávané příkazy, nové účty nebo zvláštní odchozí připojení.
  6. Provozujte s nejnižšími oprávněními. Ujistěte se, že aplikace neběží s více systémovými právy, než potřebuje, a udržujte zálohy uložené mimo server.

Co mohou zákazníci udělat pro omezení vystavení

Co to znamená pro vás

Většina lidí nemůže opravit software helpdesku, který organizace používají, ale můžete snížit to, co je v sázce, pokud dojde k jeho kompromitaci.

  • Sdílejte v tiketech méně. Vyhněte se posílání hesel, úplných čísel dokladů, platebních údajů nebo citlivých dokumentů prostřednictvím podpůrného tiketu. Pokud je požadavek skutečně potřebuje, zeptejte se, zda existuje bezpečnější kanál.
  • Před přiložením zredigujte. Rozmažte nebo odstraňte osobní údaje ze snímků obrazovky a protokolů.
  • Používejte jedinečná hesla. Pokud podpůrná platforma někdy uchová přihlašovací údaj, který jste poslali, jedinečné heslo omezí škody.
  • Sledujte oznámení o průnicích. Čtěte e-maily od služeb, které používáte, o bezpečnostních incidentech a buďte opatrní u následných zpráv, které vás žádají o kliknutí na odkazy nebo potvrzení údajů.
  • Očekávejte phishing. Kontaktní údaje a kontext tiketu mohou podvodným zprávám dodat přesvědčivý vzhled. Ověřujte prostřednictvím oficiálních webových stránek organizace.

Závěr

Hlášený řetězec zero-day zranitelností Zammad umožňujících vzdálené spuštění kódu ukazuje, jak se z jediné platformy helpdesku může stát brána k zákaznickým datům a kontrole nad serverem. Administrátoři by měli aplikovat záplaty, omezit přístup a rotovat tajné klíče. Všichni ostatní mohou prostřednictvím tiketů posílat méně citlivých informací a zůstat ostražití vůči oznámením o průnicích. Pro úplný popis toho, jak útok na DIVD probíhal, si přečtěte naše stávající články odkazované výše.