Log4j:n haavoittuvuudet jäädäkseen – oletko valmis?

Laajalle levinnyt haavoittuvuus, joka ilmestyi ensimmäisen kerran Apache Log4j:ssä vuonna 2021 käytetään jatkossakin, mahdollisesti jopa huonommilla tavoilla kuin tähän mennessä olemme nähneet. Näiden uhkien huolestuttavampi puoli on, että on hyvä mahdollisuus, että niitä käytetään edelleen kuukausia tai vuosia tulevaisuudessa.

Kotimaan turvallisuusministeriön kyberturvallisuusarviointilautakunta debytoi vuonna 2021, ja vuonna 2022 julkaistiin ensimmäinen turvallisuusraportti (PDF). Siinä hallitus kutsui Log4j:tä "endeeemiseksi haavoittuvuudeksi", pääasiassa siksi, että Log4j:lle ei ole kattavaa "asiakasluetteloa", joten haavoittuvuuksien pysyminen on lähes mahdotonta. Eräs liittovaltion kabinetin osasto käytti jopa 33,000 4 tuntia LogXNUMXj-vastaukseensa.

Ja monet markkinoilla olevat organisaatiot ja tietoturvaratkaisut eivät tunnista eroa hyödynnettävyyden ja haavoittuvuuden välillä, mikä jättää hyökkääjille mahdollisuuden harjoittaa haitallista toimintaa.

Hyödynnettävyys vs. haavoittuvuus

Yksi kyberturvallisuuden avainkysymyksistä nykyään on haavoittuvuuksien ja niiden vakavuuden välisen eron ymmärtäminen. Mitä tulee hyödynnettävyyden ja haavoittuvuuden mittaamiseen, on suuri ero sen välillä, onko tietoturvauhka hyödynnettävissä yrityksesi sisällä vai onko se vain "haavoittuva" eikä se voi estää liiketoimintaa tai saavuttaa kriittistä omaisuutta. Tietoturvatiimit viettävät liian paljon aikaa ymmärtämättä näiden kahden välistä eroa ja korjaavat jokaisen haavoittuvuuden sitä mukaa kuin ne asettavat etusijalle hyödynnettävät.

Jokaisella yrityksellä on tuhansia yhteisiä haavoittuvuuksia ja altistuksia (CVE), joista monet saavat korkeat pisteet Common Vulnerability Scoring Systemissä (CVSS), joten niitä kaikkia on mahdotonta korjata. Tämän torjumiseksi toivon, että riskipohjaiset haavoittuvuuden hallintatyökalut (RBVM) toimivat helpottaa priorisointia selventämällä, mikä on hyödynnettävissä.

Turvallisuuspriorisointimenetelmät, jotka yhdistävät CVSS-pisteet RBVM-uhkatietoihin, eivät kuitenkaan tarjoa optimaalisia tuloksia. Jopa suodatuksen ja luonnossa hyödynnettävien asioiden tarkastelun jälkeen turvatiimeillä on vielä liikaa käsiteltävää, koska luettelo on pitkä ja hallitsematon. Ja se, että CVE:llä ei ole hyväksikäyttöä tänään, ei tarkoita, etteikö sillä olisi sitä ensi viikolla.

Vastauksena yritykset ovat lisänneet ennakoivaa riskiälyä, joka voi auttaa käyttäjiä ymmärtämään, voidaanko CVE:tä hyödyntää tulevaisuudessa. Tämä ei vieläkään riitä ja aiheuttaa liikaa korjattavia ongelmia. Tuhansilla haavoittuvuuksilla näyttää edelleen olevan hyväksikäyttöä, mutta monilla on muita ehtoja, jotka on täytettävä, jotta ongelmaa voidaan todella hyödyntää.

Esimerkiksi Log4j:llä seuraavat parametrit on tunnistettava:

• Onko haavoittuvaa Log4j-kirjastoa olemassa?
• Onko se ladattu käynnissä olevalla Java-sovelluksella?
• Onko JNDI-haku käytössä?
• Kuunteleeko Java etäyhteyksiä ja onko olemassa yhteys muille koneille?

Jos ehdot ja parametrit eivät täyty, haavoittuvuus ei ole kriittinen eikä sitä pidä priorisoida. Ja vaikka haavoittuvuutta voitaisiin hyödyntää koneessa, niin mitä sitten? Onko kone äärimmäisen kriittinen, tai ehkä sitä ei ole liitetty mihinkään kriittiseen tai arkaluonteiseen omaisuuteen?

On myös mahdollista, että kone ei ole tärkeä, mutta sen avulla hyökkääjä voi jatkaa kohti kriittistä omaisuutta salakavammalla tavalla. Toisin sanoen konteksti on avainasemassa – onko tämä haavoittuvuus mahdollisella hyökkäyksellä kriittiseen omaisuuteen? Riittääkö haavoittuvuuden katkaiseminen kuristuspisteessä (useiden hyökkäyspolkujen risteys), jotta hyökkäyspolku ei pääse saavuttamaan kriittistä omaisuutta?

Tietoturvatiimit vihaavat haavoittuvuusprosesseja ja niiden ratkaisuja, koska haavoittuvuuksia tulee jatkuvasti lisää – kukaan ei voi koskaan pyyhkiä täysin puhtaaksi. Mutta jos he voivat keskittyä siihen, mitä voi luoda vahinko kriittiseen omaisuuteen, he voivat ymmärtää paremmin, mistä aloittaa.

Log4j-haavoittuvuuksien torjunta

Hyvä uutinen on, että haavoittuvuuksien asianmukainen hallinta voi auttaa vähentämään ja korjaamaan Log4j-keskeisille hyökkäyksille altistumista tunnistamalla, missä mahdollisen hyväksikäytön riski on olemassa.

Haavoittuvuuden hallinta on tärkeä osa kyberturvallisuutta, ja se on välttämätöntä järjestelmien ja tietojen turvallisuuden ja eheyden varmistamiseksi. Se ei kuitenkaan ole täydellinen prosessi, ja järjestelmissä voi silti olla haavoittuvuuksia huolimatta parhaimmista yrityksistä tunnistaa ja lieventää niitä. On tärkeää tarkistaa ja päivittää säännöllisesti haavoittuvuuksien hallintaprosessit ja strategiat sen varmistamiseksi, että ne ovat tehokkaita ja että haavoittuvuuksia korjataan ajoissa.

Haavoittuvuuksien hallinnassa ei tulisi keskittyä pelkästään haavoittuvuuksiin itseensä, vaan myös mahdolliseen hyväksikäyttöön. On tärkeää tunnistaa kohdat, joissa hyökkääjä on saattanut päästä verkkoon, sekä reitit, joita he voivat käyttää vaarantaakseen kriittisen omaisuuden. Tehokkain ja kustannustehokkain tapa pienentää tietyn haavoittuvuuden riskejä on tunnistaa haavoittuvuuksien, virheellisten määritysten ja käyttäjien käyttäytymisen väliset yhteydet, joita hyökkääjä voi hyödyntää, ja käsitellä näitä ongelmia ennakoivasti ennen haavoittuvuuden hyödyntämistä. Tämä voi auttaa keskeyttämään hyökkäyksen ja estämään järjestelmän vahingoittumisen.

Sinun tulee myös toimia seuraavasti:

• Laastari: Tunnista kaikki tuotteesi, jotka ovat haavoittuvia Log4j:lle. Tämä voidaan tehdä manuaalisesti tai käyttämällä avoimen lähdekoodin skannereita. Jos jollekin haavoittuvalle tuotteellesi on julkaistu asiaankuuluva korjaustiedosto, korjaa järjestelmä mahdollisimman pian.
• Ratkaisu: Aseta Log4j-versioissa 2.10.0 ja uudemmissa Java CMD -riville seuraava: log4j2.formatMsgNoLookups=true
• Lohko: Jos mahdollista, lisää verkkosovelluksesi palomuuriin sääntö, joka estää: "jndi:"

Täydellinen turvallisuus on saavuttamaton saavutus, joten on turha tehdä täydellistä hyvän vihollista. Keskity sen sijaan mahdollisten hyökkäyspolkujen priorisointiin ja lukitsemiseen, mikä parantaa jatkuvasti turva-asentoa. Tunnistaminen ja realistisuus sen suhteen, mikä todella on haavoittuvaa ja mikä on hyödynnettävissä, voi auttaa tässä, koska se mahdollistaa kyvyn ohjata resursseja strategisesti tärkeimpiin kriittisiin alueisiin.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• Platoblockchain. Web3 Metaverse Intelligence. Tietoa laajennettu. Pääsy tästä.
• Lähde: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-