Institutul Olandez pentru Divulgarea Vulnerabilităților (DIVD) afirmă că breșa din propria sa rețea a fost posibilă deoarece atacatorii au exploatat un lanț de două vulnerabilități zero-day în Zammad, sistemul de ticketing open-source. Breșa DIVD prin zero-day-ul Zammad este un memento clar că până și organizațiile a căror misiune este să găsească și să raporteze deficiențe de securitate pot fi prinse de vulnerabilități pe care nimeni nu le știa încă.

Informațiile disponibile până acum sunt scurte, așa că această postare se limitează la ceea ce a fost declarat și explică de ce contează.

Cum a breșat lanțul zero-day Zammad sistemul DIVD

Potrivit DIVD, intruziunea în rețeaua sa a fost posibilă prin înlănțuirea a două vulnerabilități zero-day separate în Zammad. Un zero-day este o deficiență necunoscută furnizorului sau pentru care nu există un patch disponibil în momentul exploatării, ceea ce îi lasă pe apărători fără o soluție pregătită.

Înlănțuirea contează. O vulnerabilitate poate oferi unui atacator un punct de sprijin sau acces limitat, în timp ce o a doua îi permite să meargă mai departe, de exemplu prin escaladarea privilegiilor sau prin atingerea unor sisteme care ar fi trebuit să fie în afara razei de acțiune. Combinate, două erori moderate se pot transforma într-o compromitere serioasă.

Zammad este o platformă open-source de help desk și ticketing, găzduită frecvent de organizații pe cont propriu pentru a gestiona solicitările de suport. Rezumatul sursei nu detaliază natura tehnică a celor două deficiențe și nu vom face speculații despre ele. Cititorii ar trebui să urmărească avizele oficiale și patch-urile din partea proiectului Zammad și din partea DIVD.

Ce schimbă atacul bazat pe IA pentru apărători

Titlul descrie breșa ca fiind bazată pe IA, iar unghiul sugerat notează că instrumentele de IA ar fi accelerat atacul. Detaliile exacte despre modul în care a fost folosită IA nu se află în materialul pe care îl avem, așa că ar fi o greșeală să exagerăm.

Îngrijorarea generală merită totuși înțeleasă. Automatizarea poate scurta timpul dintre descoperirea unei slăbiciuni și exploatarea acesteia. Dacă instrumentele ajută un atacator să descopere, să testeze și să înlănțuie vulnerabilități mai rapid, fereastra de reacție a apărătorilor se micșorează. Asta pune mai multă greutate pe:

  • Patch-uri rapide odată ce corecțiile sunt lansate
  • Limitarea a ceea ce o aplicație expusă pe internet poate atinge în interiorul rețelei
  • Monitorizare care detectează comportamentul neobișnuit din timp, în loc să se bazeze pe semnături cunoscute

Nimic din toate acestea nu este un motiv de panică. Este un motiv de a trata gestionarea expunerii ca pe un proces continuu, nu ca pe un audit ocazional.

De ce sistemele de ticketing dețin mai multe date sensibile decât crezi

Un sistem de ticketing pare un instrument banal, dar adesea colectează o cantitate surprinzător de mare de informații. Oamenii își descriu problemele în text liber, atașează capturi de ecran și jurnale și includ nume, adrese de email, detalii de cont și uneori chiar credențiale sau informații despre sistemele interne. Pentru o organizație de divulgare a vulnerabilităților, tichetele pot avea legătură și cu probleme de securitate care nu au fost încă rezolvate.

Asta face aceste platforme ținte atractive. Se află între public și echipele interne, sunt frecvent accesibile din internet și dețin un istoric lung de conversații pe care puțini se gândesc să îl curețe.

Același tipar apare și în altă parte. În breșa Adidas care a implicat un furnizor terț, datele de contact ale clienților au fost obținute printr-un furnizor de servicii pentru clienți compromis. Lecția este similară: infrastructura de suport poate deveni punctul slab chiar și atunci când sistemele de bază ale afacerii sunt mai bine protejate. Expunerea datelor se poate produce și în moduri mai puțin directe, ca în cazul în care agenții OpenAI au postat 53 de imagini ChatGPT pe site-uri publice fără autorizare, un memento că informațiile partajate cu un serviciu pot ajunge dincolo de locul în care utilizatorii se așteaptă.

Ce înseamnă asta pentru tine

Dacă ai contactat DIVD sau le-ai raportat o vulnerabilitate, urmărește comunicările oficiale din partea organizației despre dacă informațiile tale au fost afectate. Nu avem confirmarea din sursă despre ce date au fost accesate, așa că evită să presupui ce e mai rău, dar rămâi atent la notificările ulterioare.

Dacă folosești Zammad sau un instrument de ticketing auto-găzduit similar, acesta este un moment bun să îți verifici expunerea. Pentru toți ceilalți, concluzia este despre obiceiuri: detaliile pe care le predai echipelor de suport pot trăi într-un sistem despre care nu știi nimic, administrat de un furnizor pe care nu l-ai ales.

Ce ar trebui să verifice acum organizațiile și utilizatorii

Pentru organizațiile care rulează Zammad:

  • Verificați proiectul Zammad și DIVD pentru avize de securitate și aplicați prompt orice patch-uri.
  • Analizați dacă instanța dvs. trebuie expusă direct pe internet și puneți-o în spatele unor controale de acces acolo unde este posibil.
  • Segmentsați serverul față de sistemele interne, astfel încât o compromitere să nu devină o problemă la nivel de rețea.
  • Examinați jurnalele pentru activitate neobișnuită și rotiți credențialele care pot apărea în tichete vechi.
  • Stabiliți reguli de retenție, astfel încât tichetele vechi cu conținut sensibil să nu fie păstrate la nesfârșit.

Pentru persoanele fizice:

  • Partajați minimul necesar cu echipele de suport și evitați să trimiteți parole, documente de identitate complete sau detalii de plată în tichete.
  • Folosiți parole unice pentru fiecare serviciu, astfel încât un tichet scurs să nu poată debloca alte conturi.
  • Fiți precauți cu emailurile neașteptate care fac referire la o solicitare de suport din trecut, deoarece atacatorii pot folosi detalii scurse din tichete pentru a părea convingători. Cazul Mayer Brown Luna Moth arată cum impersonarea poate funcționa chiar și fără o compromitere reală a sistemului.

Concluzia

Breșa DIVD prin zero-day-ul Zammad arată că platformele de suport și ticketing merită aceeași atenție ca orice alt sistem critic. Aplicați patch-uri rapid, limitați expunerea și eliminați datele de care nu mai aveți nevoie. Ca cititor, acordă-ți câteva minute să treci în revistă ce informații personale ai partajat cu echipele de suport și cu furnizorii și gândește-te cum te-ar putea afecta o breșă la unul dintre ei. Pentru un exemplu paralel de sisteme de servicii pentru clienți care devin punctul slab, citiți relatarea noastră despre breșa prin furnizorul terț Adidas.