Log4Shell esiintyy tietomurroissa seuraavan vuosikymmenen aikana
Tämä vuoden 2023 viimeinen kuukausi oli toinen vuosipäivä Log4j/Log4Shell-haavoittuvuuden löytämisestä, joka on haavoittuvuus, joka vaikuttaa edelleen moniin projekteihin ja aiheuttaa turvallisuusriskin.
Ja Log4j on edelleen ensisijainen kyberhyökkäysten kohde Cloudflaren vuosittaisen "Year in Review" -raportin ja myös tietoturvatutkijoiden julkaiseman Log4j Java -kirjaston kriittisten haavoittuvuuksien merkityksellisyyttä koskevan tutkimuksen mukaan. Veracode.
Los Veracode-tutkijat mainitsevat sen tutkittuaan 38.278 XNUMX sovellusta 3.866 XNUMX organisaatiota käyttivät, he havaitsivat sen kaksi viidestä sovelluksesta käyttää edelleen haavoittuvia versioita Apache Log4j -kirjastosta kaksi vuotta sen jälkeen, kun kriittinen haavoittuvuus julkistettiin.
Raportissa korostetaan, että noin kolmasosa sovelluksista käyttää Log4j2 1.2.x -versiota (joka päättyi elokuussa 2015 eikä saa enää korjauspäivityksiä), mikä on 38 %. Suurin syy vanhan koodin käytön jatkamiselle on vanhojen kirjastojen integrointi projekteihin tai vaivalloinen siirtyminen tukemattomista haaroista uusiin, taaksepäin yhteensopiviin haaroihin. Lisäksi 2.8 % sovelluksista käyttää edelleen versioita, jotka ovat alttiina tunnetulle Log4Shell-haavoittuvuudelle.
Sen lisäksi Mainitaan, että pääkategorioita on kolme Veracode-raportin mukaan sovelluksista, jotka käyttävät edelleen Log4j:n haavoittuvia versioita:
- Log4Shell-haavoittuvuus (CVE-2021-44228):
2.8 % sovelluksista käyttää edelleen Log4j-versioita 2.0-beta9 - 2.15.0, jotka sisältävät tunnetun haavoittuvuuden. - RCE (Remote Code Execution) -haavoittuvuus (CVE-2021-44832):
3.8 % sovelluksista käyttää Log4j2 2.17.0 -versiota, joka korjaa Log4Shell-haavoittuvuuden, mutta ei ratkaise koodin etäsuorittamisen (RCE) haavoittuvuutta, joka on tunnistettu nimellä CVE-2021-44832. - Log4j2 1.2.x Branch (tuki valmistui vuonna 2015):
32 % sovelluksista käyttää edelleen Log4j2 1.2.x -haaraa, jonka tuki päättyi vuonna 2015. Tähän haaraan ovat vaikuttaneet kriittiset haavoittuvuudet, kuten CVE-2022-23307, CVE-2022-23305 ja CVE-2022-23302, jotka on tunnistettu 2022, seitsemän vuotta huollon päättymisen jälkeen.
Nämä tiedot korostavat tilanteiden moninaisuutta, joissa sovellukset käyttävät edelleen vanhentuneita ja haavoittuvia Log4j-versioita, mikä herättää tutkijoiden suurta huolta.
Ja huolestuttava tosiasia on, että 3.8 % sovelluksista käyttää Log4j2 2.17.0:aa, joka on korjattu Log4Shellia vastaan, mutta joka sisältää CVE-2021-44832:n, toisen vakavan koodin etäsuorittamisen haavoittuvuuden.
Raportissa korostetaan, että tehdyistä ponnisteluista huolimatta viime vuosina parantamaan tietoturvakäytäntöjä ohjelmistokehityksessä ja avoimen lähdekoodin käytössä, töitä on.
Veracoden tutkimusjohtaja Chris Eng korostaa, että:
Kehittäjillä on ratkaiseva vastuu, ja avoimen lähdekoodin ohjelmistojen tietoturvassa on parantamisen varaa.
Vaikka monet kehittäjät reagoivat alun perin asianmukaisesti Log4j-kriisiin asentamalla version 2.17.0, raportti ehdottaa, että jotkut palasivat aikaisempiin malleihin jättämällä korjaukset käyttöön 2.17.1:n julkaisun jälkeen.
Apache Software Foundation (ASF) on aktiivisesti ilmoittanut loppupään projekteille päivityksen kiireellisyydestä, mutta raportin havainnot osoittavat, että edelleen on sovelluksia, jotka eivät ole toteuttaneet tarvittavia korjauksia.
Veracoden raportti perustui tietoihin, jotka saatiin yli 38,000 90 sovelluksen ohjelmistoskannauksista 15 päivän ajalta 15. elokuuta ja 4. marraskuuta välisenä aikana. Sovellukset käyttivät Log1.1j-versioita 3.0.0 - 1 alpha 3,866 XNUMX XNUMX eri organisaatiossa.
Tutkimuksemme havaitsi myös, että kun kehittäjät saavat ilmoituksen haavoittuvasta kirjastosta tarkistuksen kautta, he korjaavat ne suhteellisen nopeasti: 50 prosenttia haavoittuvuuksista korjataan 89 päivässä, 65 päivässä korkean haavoittuvuuden osalta ja 107 päivässä keskivakavat haavoittuvuudet.
Nämä tulokset ovat yhdenmukaisia aikaisempien varoitusten kanssa, kuten vuoden 2022 Federal Cybersecurity Review Board -raportissa, joka osoitti, että Log4j-kriisin täydellinen ratkaiseminen kestää vuosia.
vihdoin jos olet kiinnostunut tietämään asiasta lisää, Kutsun sinut käymään veracode-blogin alkuperäisessä artikkelissa. Linkki on tämä.