Puutteellinen valtuutus -haavoittuvuus Atlassian Confluencessa

Miksi tämä haavoittuvuutta hyödyntävä hyökkäys oli niin vaarallinen

Tiistaina 31. lokakuuta ensimmäisen kerran havaitusta tapauksesta CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server oli tuolloin saatavilla hyvin vähän tietoa. Kyseessä oli vakava ongelma, որի vakavuusluokitus oli 9,1 (mutta sen todettiin mahdollistavan vain tuhoamista). Paras tapa pienentää riskiä oli varmistaa toimiva varmuuskopiointistrategia ja poistaa instanssi internetistä, jos sitä ei voinut päivittää heti saatavilla olevaan korjattuun versioon.

Oletamme, että sisäinen keskustelu oli tässä vaiheessa samankaltaista kuin meillä Eficodella. Ajattelimme, että kyse voisi olla esimerkiksi SQL-komentojen injektoinnista tietokannan poistamiseksi. Joka tapauksessa asensimme korjauksen huomaamattomasti, ilmoitimme asiakkaillemme ja siirryimme eteenpäin.

Atlassianin vakuuttelu siitä, että koodin suorittaminen ja tietojen ulosvienti olivat mahdottomia, vaikutti todennäköisesti osaltaan vaaran syntymiseen. Ei kuitenkaan tiedetä, ymmärsikö Atlassian, miten haavoittuvuus kehittyisi.

Alkuperäinen viestintä ja riskinhallintasuunnitelmat olivat harhaanjohtavia

Nopea toiminta osoittautui Eficoden pelastukseksi. Toimittajat jakavat tietoa yleensä kahdella tavalla. Ne joko kertovat asiasta ensin kumppaneilleen, jolloin korjauksia voidaan asentaa rauhassa ennen kuin haavoittuvuuden yksityiskohdat tulevat julki, tai ne julkaisevat tiedot kaikille varmistaakseen, että ne ovat heti saatavilla.

Jälkimmäisessä tapauksessa syntyy kilpajuoksu: tietoturvatiimit pyrkivät asentamaan korjaukset, kun taas uhkatoimijat yrittävät hyödyntää haavoittuvuutta. Tässä tapauksessa alhainen vakavuusluokitus antoi kuitenkin lisäaikaa. Haavoittuvuus oli tuhoava, ei hyväksikäyttöön soveltuva.

Viikon loppuun mennessä haavoittuvuuden vakavuusluokitus oli kuitenkin nostettu 10,0:aan, ja Remote Code Executionista oli kehitetty proof of concept -toteutuksia. Tätä kirjoitettaessa aseistetut exploitit ovat helposti saatavilla GitHubissa.

Muutama päivä ensimmäisten PoC-toteutusten ilmestymisen jälkeen saimme tietoa Ransomware-hyökkäyksistä.

Kun nämä asiat tapahtuivat, Eficoden instanssit oli jo korjattu.

Perustason tietoturvatoimien puute

Ransomware on luonnollisesti vahvasti riippuvainen siitä, ettei yrityksellä ole tehokkaita tietoturvatoimia. Tässä tapauksessa kyse oli varmuuskopioista. Vankka varmuuskopiointiratkaisu on avain Ransomware-hyökkäysten nopeaan ja tehokkaaseen ratkaisemiseen.

Kyberturvallisuudessa puhutaan kyberturvallisuusväsymyksestä. Sillä tarkoitetaan työntekijöiden väsymistä turvallisen alustan edellyttämiin toimenpiteisiin. Juuri tämä ilmiö johtaa tilanteisiin, joissa varmuuskopioita ei ole, palomuureja ei oteta käyttöön ja arkaluonteiset resurssit ovat julkisesti saatavilla.

Kun tietoturvauhat ja niihin vastaaminen lisääntyvät, myös väsymys kasvaa. Tämä näkyy selvästi DevOpsissa, jossa tiimit koostuvat usein tilapäisesti kootuista kehittäjistä ja infrastruktuuriasiantuntijoista ilman selkeästi määriteltyjä tietoturvakäytäntöjä.

Palautumaton tietojen menetys on yhä nopein tie yrityksen maksukyvyttömyyteen. Yhä useammat yritykset yrittävät kiertää tosiasioita eivätkä myönnä, että ne ovat nykyään muun toimintansa ohella myös IT-yrityksiä.

Yksi ratkaisu on hyödyntää Eficoden kaltaista Managed Service -palveluntarjoajaa, joka ylläpitää näitä alustoja sadoille yrityksille. Palveluihin kuuluvat esimerkiksi Jira, Confluence, Bitbucket, GitLab, GitHub, Jenkins ja muut hostatut DevOps-sovellukset.

Miten instanssit löydetään

Yksi tämän haavoittuvuuden alkuperäisistä riskinhallintatoimista oli yksinkertainen: poista se julkisesta internetistä. Tämä on aina hyvä tapa pienentää hyökkäyspintaa, mutta se edellyttää, että voit luottaa kaikkiin yrityksesi työntekijöihin.

Sisäisten hyökkäysten mahdollisuuden ja yritysprofiilien vuoksi on helppo ajatella, että tällaiset hyökkäykset ovat kohdennettuja. Useimmiten näin ei kuitenkaan ole. Ne ovat yksinkertaisia, tilaisuuteen perustuvia hyökkäyksiä. Shodan.io:n kaltaiset työkalut toimivat hakukoneina – eivät tiedolle, vaan internetiin yhdistetyille laitteille.

Haku:

Confluence "country:fi"

paljastaa pelkästään Suomessa useita satoja julkiseen internetiin avoimia Confluence-instansseja. Ilman suodatinta tuloksia saadaan kymmeniä tuhansia.

Miten haavoittuvuutta hyödynnetään

Haavoittuvuuden hyödyntäminen osoittautui erittäin yksinkertaiseksi: seuraavaan päätepisteeseen lähetetään yksi HTTP POST -pyyntö:

/json/setup-restore.action

ja määritetään seuraava otsake:

"X-Atlassian-Token": "no-check",

Confluence-ylläpitäjät käyttävät tätä päätepistettä sivuston palauttamiseen pakatusta varmuuskopiosta, joka ladataan pyynnön datana. Yleensä ylläpidollinen päätepiste on suojattu jonkinlaisella tunnistautumisella. Haavoittuvissa versioissa tällaista tietoturvatoimea ei kuitenkaan ole.

Hyökkäys onnistuu yksinkertaisesti palauttamalla vaarantunut Confluence-varmuuskopio, joka sisältää haitallisia lisäosia, kuten tässä hyökkäyksessä yleisesti nähtävän Web Shell Pluginin.

Miten riskiä voi pienentää

Riskiä voi pienentää usealla tavalla. Varmin keino on päivittää uuteen versioon. Jos se ei ole mahdollista, instanssin poistaminen julkisesta internetistä vähentää hyökkäyspintaa, vaikkei se poistaisikaan riskiä kokonaan.

Seuraavien URL-osoitteiden estäminen verkkotasolla pysäyttää myös exploitin nykytiedon perusteella

/json/setup-restore.action/json/setup-restore-local.action/json/setup-restore-progress.action

Turvallisinta on kuitenkin päivittää uusimpaan korjattuun versioon.

Mitä käyttäjän kannattaa tehdä seuraavaksi?

Jos olet päivittänyt korjattuun versioon, Confluence-instanssisi pitäisi olla turvassa. Pysy ajan tasalla seuraamalla Atlassianin tietoturvailmoituksia. Vastaavia syötteitä löytyy useimmista DevOps-työkaluista.

Jos tiimisi kuitenkin kärsivät kyberturvallisuusväsymyksestä, voit harkita myös Managed Services -toimittajaa. Se hoitaa nämä asiat puolestasi, jotta kehittäjäsi voivat keskittyä siihen, minkä he osaavat parhaiten: loistavien asioiden koodaamiseen.

Mitä seuraavaksi tietoturvassa?

Tämä haavoittuvuus paljastaa kyberturvallisuuden ongelman, joka kiteytyy yhteen helppoon kysymykseen: mitä yhteistä tällä exploitilla ja Log4Shellillä on?

Molempien vakavuusaste on 10,0.

Log4Shell kuitenkin pysäytti internetin käytännössä viikoiksi, kun taas tämä exploiti on suhteellisen hyvin hallinnassa. Mistä ero johtuu?

Käy ilmi, että yleisin kyberturvallisuuden mittari tapausten arviointiin, CVSS (Common Vulnerability Scoring System), mittaa vain yhtä asiaa: vaikutusta yksittäiseen järjestelmään.

Meillä ei ole keinoa mitata, kuinka laajalle hyökkäys leviää. Kun ainoa merkittävä mittarimme kertoo, kuinka vakava exploiti voi olla järjestelmässä aktiivisena, päädymme hämmentäviin tilanteisiin, kuten tähän: vakavuusaste 10,0 koskee joitakin Confluence-asennuksia tuhansissa järjestelmissä, kun taas Log4j oli asennettuna miljooniin järjestelmiin.

Kyberturvallisuudessa tulisi kehittää kattavuutta ja vaikutusta mittaavia mittareita CVSS-pisteen rinnalle, jotta nämä tapaukset ja niiden vaikutukset olisivat selkeämpiä.

Atlassian Data Centerin tietoturva Eficode ROOTilla

Lopuksi on hyvä mainita, miten Eficode ROOT voi helpottaa arkeasi näinä haastavina kyberturvallisuuden aikoina. Ajattele sitä omistautuneena tiiminä, joka seuraa jatkuvasti esimerkiksi CVE-2023-22518 -korjauksen kaltaisia asioita. Tiimi hoitaa tietoturvapäivitykset sujuvasti ja nopeasti osana päivittäistä työtään. Voit keskittyä ydintyöhösi luottaen siihen, että tietoturva-asiat ovat hoidossa ilman ylimääräistä stressiä tai vaivaa.