Viime kuussa hyökkääjät käyttivät varastettuja tunnistetietoja hakkeroidakseen kilpailijoiden tiedustelupalvelu SaaS-palveluntarjoajan Kluen. Hyökkäyksen siemenet alkoivat kuitenkin ilmeisesti neljä vuotta aiemmin.
Klue-johtajat sanoi että vuonna 2022 Vancouverissa toimiva yritys myönsi nimeämättömälle kolmannelle osapuolelle valtuutuksen rajoitettua pilottihanketta varten. tutkimus Crowdstrike paljasti myöhemmin, että tunniste on GitHub Personal Access Token (PAT), jonka avulla kehittäjät voivat käyttää ohjelmistokehitysarkistoja.
Pilottivaiheen päätyttyä token pysyi aktiivisena, koska kukaan ei peruuttanut sitä. Se oli jossain näkymättömänä asiakkaille, jotka olivat antaneet Kluelle pääsyn sisimpiin salaisuuksiinsa. Se oli tikittävä aikapommi.
Tutkimuksessa ei selvitetty, miten Icarus (uusi ryhmä, joka on ollut aktiivinen vasta huhtikuusta 2026 lähtien) sai PAT:n, mutta 11. kesäkuuta se käytti tokenia uuden koodin syöttämiseen Kluen integraatiopalvelukerrokseen.
Tältä tasolta Klue hakee dataa asiakkaidensa järjestelmistä, joita ylläpidetään esimerkiksi Salesforce- ja Gong-palveluissa. Se käyttää tätä dataa kilpailija-analyysien tekemiseen asiakkailleen, mikä auttaa heidän myyntihenkilöstöään aloittamaan neuvottelut paremmin valmistautuneena.
Koodipäivitys keräsi OAuth-tokenit (pysyvät istuntotunnukset toistuvaa salasanatonta pääsyä varten), joita Klue säilytti asiakkaidensa tietojen käyttämiseksi kyseisissä järjestelmissä. Hyökkääjät käyttivät sitten näitä tokeneita tietojen keräämiseen kyseisten asiakkaiden Salesforce- ja Gong-instansseista.
OAuth-tokenit laillisuuden pettämisenä
Hyökkäystä ei ollut helppo havaita, koska varastettujen OAuth-tokenien käyttö ei näytä tunkeutumiselta ennen kuin kyseiset tunnukset on peruutettu. Icarus lähetti suoria REST-kutsuja Salesforce- ja Gong-instansseja vastaan aivan kuten mikä tahansa laillinen asiakas tekisi.
Salesforce kertoi Kluelle tapahtuneesta 12. kesäkuuta, minkä seurauksena kilpailutiedusteluyritys alkoi kierrättää OAuth-tokeniaan.
Vahvistettujen uhrien listalla olivat HackerOne, Huntress, Jamf, Recorded Future, Snyk ja LastPass. Se kuulostaa hakemistolta yrityksistä, joiden päivätyö on kertoa muille yrityksille, miten hallita juuri tätä riskiä.
Vaikutuksista uhreihin kirjoitetaan kaikkialla verkossa, sillä heidän oli julkaistava päivityksiä siitä, miten Kluen ongelma oli vaikuttanut heihin. Salesforce vahvisti, että tapaus "rajoittui Kluen sovellusyhteyteen eikä johdu Salesforce-alustan haavoittuvuudesta" – asettaen valvonnan vastuun suoraan integraation valtuuttaneelle asiakkaalle. Se myös... sanoi "Organisaatiot eivät voi muodostaa yhteyttä Salesforceen tämän sovelluksen kautta toistaiseksi". Gong sanoi samaaJa myös tanium esti Kluen.
LastPass esitetty että asiakkaiden nimet, sähköpostiosoitteet, puhelinnumerot, fyysiset osoitteet sekä tukitapausten tiedot ja myyntiin liittyvät tiedot olivat paljastuneet. Yhtiö lopetti kaikkien työntekijöiden pääsyn Klueen.
Huntress teki yksityiskohtaisia päivityksiä, selittäen, että Icarus oli julkaissut datadumpin pimeälle verkkosivustolleen ja uhannut julkaista lisää dataa mainiten yli 200 uhriyrityksen. Se tunnisti tietovuotosivuston isännöidyksi Venäjällä.
Kenelläkään uhreista ei ollut uskottavaa tapaa nähdä, mitä Kluen infrastruktuurissa tapahtui; heidän toimittajariskiohjelmansa olivat oletettavasti hyväksyneet integraation ja siirtyneet eteenpäin. Monille tietoturvatiimeille SaaS-yritysten auditoinnit näyttävät olevan hetkessä tapahtuvia. Kun toimittaja on täyttänyt kyselylomakkeen ja saanut hyväksynnän, auditointi katsotaan tehdyksi.
Miksi tämä tekee ISO 27001 -standardista arvokkaamman
ISO 27001 -standardin toimittaja- ja käyttöoikeuksien hallintamekanismit on suunniteltu suojaamaan Icaruksen hyödyntämiltä vioilta.
Standardi A.5.16 edellyttää organisaatioilta jokaisen identiteetin koko elinkaaren hallintaa sen käyttöönotosta sen poistamiseen, kun taas standardi A.5.18 laajentaa saman vaatimuksen todennustietoihin pakottamalla dokumentoidut rotaatioaikataulut API-avaimille ja -tunnisteille.
Johdonmukaisesti sovellettuna kumpi tahansa näistä olisi nostanut esiin neljä vuotta vanhan PAT:n kauan ennen Ikarosta. Kluen nykyiset vaikeudet ovat oppikirjaesimerkki siitä, mitä näiden periaatteiden soveltamatta jättäminen maksaa loppuvaiheessa.
Mutta se on asia, jonka Klue olisi voinut tehdä sisäisesti, eikä se ole asia, johon sen asiakkaat voivat vaikuttaa. Mitä yritys voi tehdä suojellakseen itseään toimittajan virheiltä?
Kontrollit A.5.19–A.5.23 säätelevät itse toimittajasuhdetta. A.5.22 edellyttää organisaatioilta toimittajapalveluiden säännöllistä seurantaa, tarkastelua ja auditointia.
A.5.21 vie velvoitetta pidemmälle vaatimalla, että turvallisuusvaatimukset siirtyvät alihankkijoille ja että alihankkijan käyttö kirjataan toimitussopimuksiin.
Tietoturvallisuuden hallintajärjestelmä toteuttaa nämä lausekkeet muuttamalla vuosittaisen kyselylomakkeen reaaliaikaiseksi rekisteriksi integraatioista, tunnistetiedoista ja myönnetyistä tokeneista. Se pakottaa keskusteluun käytöstä poistamisesta pilottivaiheen päättyessä. Se antaa myös vaatimustenmukaisuuspäälliköille auditointipolun, joka todistaa, että sekä heidän käyttämänsä toimittajat että heidän alihankkijansa saavat saman jatkuvan valvonnan kuin heidän kanssaan sopimuksen tehneet suorat toimittajat.
Kluen kunniaksi on sanottava, että se on ryhtynyt useisiin toimiin varmistaakseen, ettei näin tapahdu uudelleen, mukaan lukien PAT-tunnisteiden käytön kieltäminen ja siirtyminen eri todennusmekanismeihin. Se on parantanut lokitietojen tallentamista ja ottanut käyttöön tiukemman valvonnan ohjelmistokehitysputkissaan. Parempi myöhään kuin ei milloinkaan.
Tietoturvan hallintajärjestelmä (ISMS) on tapa, jolla vaatimustenmukaisuusvastaavat varmistavat, etteivät heistä tule seuraavia otsikoita, olivatpa he sitten tietomurron suora kohde tai uhrin asiakas.
Laajenna tietosi
Blogi: Miten kiristyshaittaohjelmista tuli yritysten sietokykyongelma
Blogi: Huomioi aukko: Salesforce-tapaus ja pilviriskin kehittyvä luonne
