Szerző: Dömös Zsuzsanna

2023. december 18. 09:42

Az appok 38 százaléka sebezhető még a Log4J-n keresztül

Már több mint két éve elérhető a Log4Shell javítása, de a rengeteg figyelmeztetés és hír ellenére a szervezetek jelentős része használja még mindig a sebezhető verziókat.

Az Apache Log4j naplózójában felfedezett kritikus biztonsági rés, a Log4Shell javítása a számok szerint még mindig nem triviális feladat a fejlesztők számára, hiába érkezett meg a szoftveres javítás 2021 végén az év, ha nem az évtized egyik legsúlyosabb biztonsági sebezhetőségére. A Java hibaüzenetek naplózására használt Apache Log4j könyvtárat érintő, Log4Shell néven becézett, CVE-2021-44228 számú sérülékenység hitelesítés nélküli, tetszőleges, távoli kódfuttatást tesz lehetővé a támadók számára, melynek sikeres kihasználása estén teljes, rendszerszíntű hozzáférést tesz lehetővé. 

A biztonsági rés a nagy számú potenciálisan érintett szerver és kliens mellett a viszonylag egyszerű támadási mód miatt számít különösen veszélyesnek. Nem kell különösebb gyakorlat a rendszerek feltöréséhez, elég ha az adott applikáció egyetlen elemet bejegyez a naplóba, azt könnyűszerrel ki tudják cserélni a hackerek a saját kódjukra. Erre védelmet a legalább 2.15.0-ás verzió telepítése jelentene.

Aggasztó, hogy az Apache Log4j könyvtárat használó alkalmazások nagyjából 38%-a még mindig a biztonsági rést tartalmazó veszélyeztetett verziók valamelyikét használja, tehát a 2.0-beta9 - 2.15.0 közti kiadásokat – mutat rá a Veracode alkalmazásbiztonsági cég augusztus 15. és november 15. között gyűjtött adatokon alapuló jelentése.

log4j-sonatype

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak

Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

A Veracode 90 napon keresztül gyűjtött adatokat 3866 szervezettől, több mint 38278 olyan alkalmazást vizsgálva,amelyek a Log4j 1.1 és 3.0.0-alpha1 közötti verziókat használják. Ezen alkalmazások 2,8%-a használja a Log4J 2.0-beta9 és 2.15.0 közötti változatait, amelyek sérülékenynek számítanak. További 3,8% a Log4j 2.17.0-t használja, amely bár nem érintett a Log4Shell hibában, de érzékeny a CVE-2021-44832 távoli kódvégrehajtási hibára, amit a keretrendszer 2.17.1-es verziójában sikerült javítani.

Az alkalmazások 32%-a a Log4j 1.2.x verzióját használja, ami már 2015 augusztusban elérte a támogatás végét. Ezek a verziók több, 2022-ig felfedezett súlyos sebezhetőséget tartalmaznak, köztük a CVE-2022-23307, CVE-2022-23305 és CVE -2022-23302 hibákat.

Összességében tehát az alkalmazások körülbelül 38%-a valamilyen nem biztonságos Log4j verziót használ. Ez az arány közel áll a Sonatype szoftver-ellátási lánc menedzsment Log4j dashboardja alapján becsült számhoz, mely szerint az elmúlt héten a könyvtár letöltéseinek 25%-a még a sebezhető verziókra érkezett.

Az elavult könyvtárverziók használata egy régóta fennálló problémát jelez, a Veracode szerint részben a fejlesztők kényelmességét. A fejlesztők 79%-a soha nem frissíti a harmadik féltől származó könyvtárakat, miután azokat bevezette egy projektbe, elkerülendő a funkcionalitásban esetleg fellépő hibákat. Szintén a jelentés világít rá, hogy a projektek 50%-ának 65 napnál hosszabb időre van szükség a súlyos hibák kijavításához.

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról