Tukipalvelu on yksi organisaation luotetuimmista sähköpostilaatikoista. Asiakkaat liittävät sinne tilinsä tietoja, virhelokeja, nimiä ja joskus asiakirjoja olettaen, että tiedot ovat turvassa alustan takana. Raportoitu Zammad zero-day -etäkoodin suoritusketju, jota käytettiin Dutch Institute for Vulnerability Disclosurea (DIVD) vastaan, muistuttaa, että tämä luottamus riippuu täysin ohjelmistosta, joka säilyttää tikettejä.
Raportin mukaan kaksi Zammad zero-day -haavoittuvuutta mahdollistavat istunnon kaappauksen, etäkomentojen suorittamisen ja mahdollisen root-käyttöoikeuden taustalla olevalle palvelimelle. Zammad on avoimen lähdekoodin tiketti- ja tukipalvelualusta. Lähdeartikkelin yksityiskohdat ovat rajallisia, joten tämä kirjoitus pitäytyy siinä, mitä on raportoitu, ja välttää teknisten yksityiskohtien arvailua.
Miten Zammad zero-dayt ketjutettiin
Ydin tarina on ketjuttamisesta. Kummankaan virheen ei tarvitse olla yksinään tuhoisa, jotta yhdistelmä olisi vakava. Raporttien perusteella ensimmäinen heikkous mahdollistaa hyökkääjän kaapata istunnon, mikä tarkoittaa todentuneen käyttäjän käyttöoikeuksien haltuunottoa tietämättä heidän salasanaansa. Toinen mahdollistaa etäkomentojen suorittamisen, jolloin hyökkääjä voi suorittaa komentoja Zammadia isännöivällä palvelimella. Tästä eteenpäin root-käyttöoikeus kuvataan mahdollisena lopputuloksena, mikä tarkoittaa, että hyökkääjä voisi saada täyden hallinnan koneeseen.
Tämä malli on yleinen vakavissa tunkeutumisissa: yksi virhe antaa jalansijan, toinen muuttaa sen hallinnaksi. Se selittää myös, miksi puolustajia kehotetaan suhtautumaan vakavuudeltaan keskitasoisiin ongelmiin vakavasti, sillä niistä voi tulla ketjun ensimmäinen lenkki.
Koko hyökkäyskertomusta, mukaan lukien miten DIVD:n tietomurto eteni, katso aiemmasta kattauksestamme: AI-agentti ketjuttaa kaksi Zammad zero-daytä murtautuakseen DIVD:hen ja DIVD: AI-agentti hyödyntää kahta Zammad zero-daytä tietomurrossa.
Mitä vaarantunut tukipalvelu paljastaa
Tukipalvelimen palvelin sisältää enemmän kuin ihmiset yleensä ymmärtävät. Riippuen siitä, miten organisaatio käyttää sitä, vaarantunut instanssi voisi paljastaa:
- Tukitiketit ja niihin liittyvän täydellisen keskusteluhistorian
- Asiakkaiden nimet, sähköpostiosoitteet ja muut yhteystiedot
- Liitteet, kuten näyttökuvat, lokit tai asiakkaiden lataamat asiakirjat
- Sisäiset muistiinpanot, jotka henkilökunta kirjoitti asiakkaista tai tapauksista
- Palvelimelle tallennetut tunnistetiedot, API-tokenit tai integraatioasetukset
Root-käyttöoikeus nostaa panoksia edelleen. Hyökkääjä, jolla on isännän hallinta, ei rajoitu sovelluksen tietoihin. Hän voi päästä käsiksi muihin samalla koneella oleviin palveluihin, lukea konfiguraatiotiedostoja ja käyttää palvelinta astinlautana muualla verkossa. Siksi tukipalvelun vaarantuminen voi muuttua laajemmaksi tapaukseksi kuin rajoitetuksi.
DIVD-tapaus on myös merkittävä, koska DIVD on itse tietoturvaorganisaatio, joka auttaa raportoimaan ja korjaamaan haavoittuvuuksia. Jos tähän työhön keskittynyt ryhmä voi joutua kohteeksi, minkä tahansa organisaation, joka käyttää itse isännöityjä työkaluja, tulisi olettaa olevansa mahdollinen kohde. Kappaleemme Zammad zero-day-ketjusta, joka mahdollisti AI-vetoisen tietomurron käsittelee tätä kontekstia.
Mitä Zammad-ylläpitäjien tulisi tehdä nyt
Jos ylläpidät Zammadia, käsittele tätä ensisijaisena tarkasteluna rutiinitehtävän sijaan.
- Tarkista viralliset korjaukset. Seuraa Zammad-projektin tietoturvatiedotteita ja käytä korjauksia tai päivityksiä heti, kun ne ovat saatavilla. Älä luota kolmannen osapuolen yhteenvetoihin versiotietojen osalta.
- Rajoita altistumista. Jos instanssiasi ei tarvitse olla saavutettavissa avoimesta internetistä, rajoita pääsyä VPN:llä, IP-sallintaluettelolla tai käänteisen välityspalvelimen säännöillä, kunnes olet korjannut sen.
- Mitätöi istunnot. Koska istunnon kaappaus on osa raportoitua ketjua, harkitse pakotettuja uloskirjautumisia ja istuntosalaisuuksien vaihtamista päivityksen jälkeen.
- Vaihda tunnistetiedot. Vaihda järjestelmänvalvojan salasanat, API-tokenit ja kaikki palvelimelle tallennetut salaisuudet, erityisesti jos epäilet vaarantumista.
- Tarkista lokit. Etsi epätavallisia järjestelmänvalvojan kirjautumisia, odottamattomia komentoja, uusia tilejä tai outoja lähteviä yhteyksiä.
- Aja vähimmän oikeuden periaatteella. Varmista, että sovellus ei aja useammilla järjestelmäoikeuksilla kuin se tarvitsee, ja pidä varmuuskopiot tallessa erillään palvelimesta.
Mitä asiakkaat voivat tehdä rajoittaakseen altistumista
Mitä tämä tarkoittaa sinulle
Useimmat ihmiset eivät voi korjata organisaatioiden käyttämää tukipalveluohjelmistoa, mutta voit vähentää sitä, mikä on vaakalaudalla, jos sellainen murretaan.
- Jaa vähemmän tiketeissä. Vältä salasanojen, täydellisten henkilötunnusten, maksutietojen tai arkaluontoisten asiakirjojen lähettämistä tukitiketin kautta. Jos pyyntö todella tarvitsee niitä, kysy, onko olemassa turvallisempaa kanavaa.
- Poista tiedot ennen liittämistä. Sumea tai poista henkilötiedot näyttökuvista ja lokeista.
- Käytä ainutlaatuisia salasanoja. Jos tukialusta koskaan sisältää lähettämäsi tunnistetiedon, ainutlaatuinen salasana rajoittaa vahinkoja.
- Seuraa tietomurtoilmoituksia. Lue käyttämiesi palveluiden sähköpostit tietoturvatapauksista ja ole varovainen seurantaviesteistä, jotka pyytävät sinua klikkaamaan linkkejä tai vahvistamaan tietoja.
- Odota tietojenkalastelua. Yhteystiedot ja tikettikonteksti voivat saada huijausviestit näyttämään vakuuttavilta. Vahvista organisaation viralliselta verkkosivustolta.
Lopputulos
Raportoitu Zammad zero-day -etäkoodin suoritusketju osoittaa, miten yksittäinen tukipalvelualusta voi muuttua portiksi asiakastietoihin ja palvelimen hallintaan. Ylläpitäjien tulisi korjata, rajoittaa pääsyä ja vaihtaa salaisuudet. Kaikki muut voivat lähettää vähemmän arkaluontoista tietoa tikettien kautta ja pysyä valppaana tietomurtoilmoitusten varalta. Saadaksesi täydellisen selvityksen siitä, miten DIVD-hyökkäys eteni, lue aiempi kattauksemme yllä olevista linkeistä.",
