Det nederlandske instituttet for sårbarhetsavsløring (DIVD) sier at bruddet på deres eget nettverk var mulig fordi angripere utnyttet en kjede av to null-dag-sårbarheter i Zammad, det åpen kildekode-baserte tikettsystemet. Zammad-null-dagen og DIVD-bruddet er en tydelig påminnelse om at selv organisasjoner hvis jobb er å finne og rapportere sikkerhetssårbarheter, kan bli rammet av feil ingen visste om ennå.

Rapporteringen som er tilgjengelig så langt er kortfattet, så dette innlegget holder seg til det som er blitt uttalt, og forklarer hvorfor det er viktig.

Hvordan Zammad-null-dag-kjeden brøt seg inn hos DIVD

Ifølge DIVD ble inntrengningen i nettverket deres muliggjort ved å kjede sammen to separate null-dag-sårbarheter i Zammad. En null-dag er en feil som er ukjent for leverandøren eller som ikke har noen tilgjengelig retting når den utnyttes, noe som etterlater forsvarere uten en klar løsning.

Kjeding er viktig. Én sårbarhet kan gi en angriper fotfeste eller begrenset tilgang, mens en andre lar dem gå lenger, for eksempel ved å heve privilegier eller nå systemer som burde vært utenfor rekkevidde. Kombinert kan to moderate feil utgjøre et alvorlig kompromiss.

Zammad er en åpen kildekode-basert helpdesk- og tikettplattform, vanligvis selvhostet av organisasjoner for å håndtere støtteforespørsler. Kildeoppsummeringen beskriver ikke den tekniske naturen til de to feilene, og vi kommer ikke til å gjette oss til dem. Lesere bør følge med på offisielle råd og oppdateringer fra Zammad-prosjektet og fra DIVD.

Hva det AI-drevne angrepet endrer for forsvarere

Overskriften beskriver bruddet som AI-drevet, og den foreslåtte vinklingen bemerker at AI-verktøy angivelig fremskyndet angrepet. Detaljene om nøyaktig hvordan AI ble brukt, finnes ikke i materialet vi har, så det ville være en feil å overdrive det.

Den generelle bekymringen er likevel verdt å forstå. Automatisering kan forkorte tiden mellom å finne en svakhet og utnytte den. Hvis verktøy hjelper en angriper med å oppdage, teste og sette sammen sårbarheter raskere, blir vinduet forsvarere har til å reagere, mindre. Det legger mer vekt på:

  • Rask lapping så snart rettinger er utgitt
  • Begrense hva en internett-eksponert applikasjon kan nå inne i nettverket
  • Overvåking som fanger opp uvanlig atferd tidlig, i stedet for å stole på kjente signaturer

Ingenting av dette er grunn til panikk. Det er en grunn til å behandle eksponeringshåndtering som en pågående prosess snarere enn en sporadisk revisjon.

Hvorfor tikettsystemer inneholder mer sensitive data enn du tror

Et tikettsystem ser ut som et hverdagslig verktøy, men det samler ofte en overraskende mengde informasjon. Folk beskriver problemene sine i fritekst, legger ved skjermbilder og logger, og inkluderer navn, e-postadresser, kontodetaljer, og noen ganger påloggingsinformasjon eller intern systeminformasjon. For en organisasjon som jobber med sårbarhetsavsløring, kan saker også gjelde sikkerhetsproblemer som ennå ikke er rettet.

Det gjør disse plattformene til attraktive mål. De sitter mellom offentligheten og interne team, de er ofte tilgjengelige fra internett, og de inneholder en lang historie med samtaler som få tenker på å rydde opp i.

Det samme mønsteret dukker opp andre steder. I Adidas-bruddet som involverte en tredjepartsleverandør ble kundekontaktdata anskaffet gjennom en kompromittert kundeserviceleverandør. Lærdommen er liknende: støtteinfrastruktur kan bli svakhetspunktet selv når kjerneforretningssystemene er bedre beskyttet. Dataeksponering kan også skje på mindre direkte måter, som i tilfellet der OpenAI-agenter publiserte 53 ChatGPT-bilder på offentlige nettsteder uten autorisasjon, en påminnelse om at informasjon som deles med en tjeneste, kan reise lenger enn brukere forventer.

Hva dette betyr for deg

Hvis du har kontaktet DIVD eller rapportert en sårbarhet til dem, følg med på offisiell kommunikasjon fra organisasjonen om hvorvidt informasjonen din ble påvirket. Vi har ikke bekreftelse fra kilden på hvilke data som ble aksessert, så unngå å anta det verste, men vær oppmerksom på oppfølgingsvarsler.

Hvis du bruker Zammad eller et liknende selvhostet tikettverktøy, er dette et godt øyeblikk til å sjekke eksponeringen din. For alle andre handler takeaway om vaner: detaljene du overlater til støtteskranker, kan leve i et system du ikke vet noe om, drevet av en leverandør du ikke valgte.

Hva organisasjoner og brukere bør sjekke nå

For organisasjoner som kjører Zammad:

  • Sjekk Zammad-prosjektet og DIVD for sikkerhetsråd og bruk eventuelle oppdateringer umiddelbart.
  • Vurder om instansen din trenger å være direkte eksponert mot internett, og sett den bak tilgangskontroller der det er mulig.
  • Segmenter serveren fra interne systemer slik at et kompromiss ikke blir et nettverksomfattende problem.
  • Gå gjennom logger for uvanlig aktivitet og roter påloggingsinformasjon som kan forekomme i gamle saker.
  • Sett oppbevaringsregler slik at gamle saker med sensitivt innhold ikke beholdes på ubestemt tid.

For enkeltpersoner:

  • Del minimumet som er nødvendig med støtteteam, og unngå å sende passord, fullstendige ID-dokumenter eller betalingsdetaljer i saker.
  • Bruk unike passord for hver tjeneste slik at en lekket sak ikke kan låse opp andre kontoer.
  • Vær forsiktig med uventede e-poster som refererer til en tidligere støtteforespørsel, siden angripere kan bruke lekkede saksdetaljer for å fremstå overbevisende. Mayer Brown Luna Moth-saken viser hvordan identitetsetterligning kan fungere selv uten et genuint systemkompromiss.

Takeaway

Zammad-null-dagen og DIVD-bruddet viser at støtte- og tikettplattformer fortjener samme gransking som ethvert annet kritisk system. Lapp raskt, begrens eksponering, og rydd ut data du ikke lenger trenger. Som leser: bruk noen minutter på å gå gjennom hvilken personlig informasjon du har delt med støtteskranker og leverandører, og vurder hvordan et brudd hos en av dem kan påvirke deg. For et parallelt eksempel på kundeservicesystemer som blir svakhetspunktet, les vår dekning av Adidas-bruddet via tredjepartsleverandør.