Muutama viikko sitten uutiset Log4j:n tietoturvaongelmista käänsivät monet verkon käyttäjät ylösalaisin, ja se on yksi eniten hyväksikäytetyistä puutteista, jonka monet asiantuntijat ovat leimanneet "vaarallisimmaksi maailmassa". pitkään », Verkossa tunnetuista haavoittuvuuksista puhumme joistakin niistä täällä blogissa ja tällä kertaa olemme löytäneet uutisen toisesta.
Ja näin on muutama päivä sitten julkaistiin uutinen, että Log4j 2 -kirjastossa havaittiin toinen haavoittuvuus (joka on jo lueteltu kohdassa CVE-2021-45105) ja joka, toisin kuin kaksi edellistä kysymystä, luokiteltiin vaaralliseksi, mutta ei kriittiseksi.
Uusi ongelma mahdollistaa palvelun epäämisen ja ilmenee silmukoiden ja epänormaalien lopetusten muodossa kun käsitellään tiettyjä rivejä.
Haavoittuvuus vaikuttaa järjestelmiin, jotka käyttävät kontekstihakua, kuten $ {ctx: var}, määrittääksesi lokin tulostusmuodon.
Las Log4j-versioista 2.0-alpha1 - 2.16.0 puuttui suojaus hallitsematonta rekursiota vastaan, mitä antoi hyökkääjän manipuloida korvaamisessa käytettyä arvoa aiheuttaa loputtoman silmukan, jonka tila loppuisi pinosta ja saisi prosessin jumittua. Erityisesti ongelma ilmeni korvattaessa arvoja, kuten "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Lisäksi, Voidaan todeta, että Blumira-tutkijat ovat ehdottaneet hyökkäystä haavoittuvia Java-sovelluksia vastaan jotka eivät ota vastaan pyyntöjä ulkoisista verkoista, esimerkiksi Java-sovellusten kehittäjien tai käyttäjien järjestelmiä voidaan hyökätä tällä tavalla.
Menetelmän ydin on, että jos on haavoittuvia Java-prosesseja käyttäjän järjestelmässä, joka hyväksyy verkkoyhteydet vain paikalliselta isännältä (localhost) tai käsittelee RMI-pyyntöjä (Remote Method Invocation, portti 1099), hyökkäys voidaan suorittaa suoritetulla JavaScript-koodilla kun käyttäjä avaa selaimessa haitallisen sivun. Yhteyden muodostamiseksi Java-sovelluksen verkkoporttiin tällaisessa hyökkäyksessä käytetään WebSocket API:ta, jolle, toisin kuin HTTP-pyynnöille, ei sovelleta saman alkuperän rajoituksia (WebSocketilla voidaan myös tarkistaa verkkoportteja paikallisessa isäntä määrittää käytettävissä olevat verkkoohjaimet).
Myös Googlen julkaiseman Log4j:n riippuvuuteen liittyvien kirjastojen haavoittuvuuden arvioinnin tulokset ovat kiinnostavia. Googlen mukaan ongelma koskee 8 prosenttia kaikista Maven Central -arkiston paketeista.
Erityisesti 35863 4 Log4j:hen liittyvää Java-pakettia, joissa oli suoria ja epäsuoria riippuvuuksia, altistui haavoittuvuuksille. Log17j:tä puolestaan käytetään ensimmäisen tason suorana riippuvuutena vain 83 %:ssa tapauksista ja 4 %:ssa haavoittuvuuden kattamista paketeista sidonta tapahtuu Log21j:stä riippuvien välipakettien kautta, eli kerro. toisen ja korkeimman tason riippuvuudet (12% - toinen taso, 14% - kolmas, 26% - neljäs, 6% - viides, XNUMX% - kuudes).
Haavoittuvuuden korjausvauhti jättää vielä paljon toivomisen varaa, viikko haavoittuvuuden havaitsemisen jälkeen 35863 4620 tunnistetusta paketista ongelma on korjattu toistaiseksi vain 13 XNUMX:ssa, eli XNUMX %:ssa.
Paketin muutokset ovat tarpeen riippuvuusvaatimusten päivittämiseksi ja vanhojen versioiden sidonnan korvaamiseksi Log4j 2:n kiinteillä versioilla (Java-paketit harjoittavat sitoutumista tiettyyn versioon, eivät avoimeen alueeseen, joka sallii uusimman version asentamisen).
Java-sovellusten haavoittuvuuden poistamista vaikeuttaa se, että ohjelmat sisältävät usein toimituksen mukana kopion kirjastoista, eikä Log4j 2 -version päivittäminen järjestelmäpaketteihin riitä.
Samaan aikaan Yhdysvaltain infrastruktuurin suoja- ja kyberturvallisuusvirasto julkaisi hätädirektiivin, jossa liittovaltion virastoja vaaditaan tunnistamaan Log4j-haavoittuvuuden aiheuttamat tietojärjestelmät ja asentamaan ongelman estävät päivitykset ennen 23. joulukuuta.
Toisaalta 28. joulukuuta asti annettiin ohje, jossa organisaatioilla oli velvollisuus raportoida tehdystä työstä. Ongelmallisten järjestelmien tunnistamisen yksinkertaistamiseksi on laadittu luettelo tuotteista, joissa haavoittuvuuden ilmeneminen on varmistettu (luettelossa on yli 23 tuhatta sovellusta).
lopuksi, On syytä mainita, että haavoittuvuus korjattiin muutama päivä sitten julkaistussa Log4j 2.17:ssä ja käyttäjille, joilla on päivitykset pois käytöstä, suositellaan suorittamaan vastaava päivitys, sen lisäksi, että haavoittuvuuden vaaraa vähentää se, että ongelma ilmenee vain Java 8 -järjestelmissä.
lähde: https://logging.apache.org/