Néhány héttel ezelőtt a Log4j biztonsági problémáiról szóló hír sok felhasználót felforgatott a hálózaton, és ez az egyik legtöbbet kihasznált hiba, amelyet sok szakértő a "legveszélyesebbnek" minősített. hosszú ideje », A hálózaton ismertté vált sebezhetőségek közül néhányról beszélünk itt a blogon és ezúttal egy másik hírét találtuk.
És ez van néhány napja megjelent a hír, miszerint a Log4j 2 könyvtárában újabb biztonsági rést azonosítottak (amely már szerepel a CVE-2021-45105 alatt), és amely az előző két kérdéssel ellentétben veszélyesnek, de nem kritikusnak minősült.
Az új probléma lehetővé teszi a szolgáltatás megtagadását, és hurkok és rendellenes lezárások formájában nyilvánul meg bizonyos sorok feldolgozásakor.
Sebezhetőség olyan rendszereket érint, amelyek környezetkeresést használnak, például $ {ctx: var}, a naplókimeneti formátum meghatározásához.
az A Log4j 2.0-alpha1 és 2.16.0 közötti verziói nem tartalmaztak védelmet az ellenőrizetlen rekurzióval szemben, mit lehetővé tette a támadó számára, hogy manipulálja a helyettesítéshez használt értéket végtelen hurok létrejöttéhez, amelyből kifogyna a hely a veremen, és a folyamat lefagyna. A probléma különösen akkor fordult elő, amikor olyan értékeket helyettesítettek, mint például "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Ezen túlmenően, Megjegyzendő, hogy a Blumira kutatói támadást javasoltak a sebezhető Java alkalmazások ellen amelyek nem fogadják el a külső hálózatoktól érkező kéréseket, például a Java alkalmazások fejlesztőinek vagy felhasználóinak rendszereit támadhatják meg ilyen módon.
A módszer lényege, hogy ha vannak sebezhető Java folyamatok a felhasználó rendszerén, amely csak a helyi gazdagéptől fogad hálózati kapcsolatokat (localhost), vagy RMI-kéréseket dolgoz fel (Remote Method Invocation, 1099-es port), a támadás végrehajtható JavaScript kóddal amikor a felhasználó rosszindulatú oldalt nyit meg a böngészőben. Egy ilyen támadás során a Java-alkalmazás hálózati portjával való kapcsolat létrehozásához a WebSocket API-t használják, amelyre a HTTP kérésekkel ellentétben nem vonatkoznak azonos eredetű korlátozások (a WebSocket a helyi hálózati portok vizsgálatára is használható gazdagép az elérhető hálózati illesztőprogramok meghatározásához).
Szintén érdekesek a Google által közzétett Log4j-vel kapcsolatos függőségekhez kapcsolódó könyvtárak sebezhetőségének értékelésének eredményei is. A Google szerint a probléma a Maven Central adattárában található összes csomag 8%-át érinti.
Különösen 35863 4 Log4j-hez kapcsolódó, közvetlen és közvetett függőségű Java-csomag volt kitéve a sebezhetőségnek. A Log17j viszont csak az esetek 83%-ában kerül felhasználásra az első szint közvetlen függőségeként, a sérülékenységgel érintett csomagok 4%-ában pedig a Log21j-től függő köztes csomagokon keresztül történik az összerendelés, azaz tell. a második és legmagasabb szintű függőségek (12% - a második szint, 14% - a harmadik, 26% - a negyedik, 6% - az ötödik, XNUMX% - a hatodik).
A sebezhetőség javítási üteme továbbra is hagy kívánnivalót maga után, egy héttel a sérülékenység azonosítása után a 35863 4620 azonosított csomagból eddig csak 13-ban, azaz XNUMX%-nál sikerült megoldani a hibát.
Csomagmódosításokra van szükség a függőségi követelmények frissítéséhez és a régi verzió-összerendelések Log4j 2 rögzített verzióira való lecseréléséhez (a Java-csomagok egy adott verzióhoz kötődnek, nem pedig egy nyílt tartományhoz, amely lehetővé teszi a legújabb verzió telepítését).
A Java alkalmazások sérülékenységének kiküszöbölését nehezíti, hogy a programok gyakran tartalmazzák a könyvtárak másolatát a szállításban, és nem elegendő a Log4j 2 verzió frissítése a rendszercsomagokban.
Eközben az Egyesült Államok Infrastruktúra-védelmi és Kiberbiztonsági Ügynöksége vészhelyzeti irányelvet adott ki, amely előírja a szövetségi ügynökségeknek, hogy azonosítsák a Log4j sebezhetősége által érintett információs rendszereket, és telepítsenek frissítéseket, amelyek megakadályozzák a problémát.
Ezzel szemben december 28-ig iránymutatást adtak, amelyben a szervezeteknek beszámolási kötelezettségük volt az elvégzett munkáról. A problémás rendszerek azonosításának egyszerűsítése érdekében elkészült azon termékek listája, amelyekben igazolódott a sebezhetőség megnyilvánulása (több mint 23 ezer alkalmazás található a listán).
Végül, Érdemes megemlíteni, hogy a sérülékenységet a néhány napja publikált Log4j 2.17-ben javították a frissítéseket letiltott felhasználóknak pedig javasolt a megfelelő frissítés elvégzése, amellett, hogy a sebezhetőség veszélyét mérsékli, hogy a probléma csak Java 8-as rendszereken jelentkezik.
forrás: https://logging.apache.org/