Sokat beszéltek a neten a sebezhetőségről Log4J, amely lehetővé teszi a támadók számára, hogy tetszőleges kódfuttatást indítsanak el távolról ha képes adatokat küldeni egy olyan alkalmazásnak, amely a log4j könyvtárat használja az esemény naplózására.
Ez a támadás hitelesítés nélkül is megtehetőPéldául a hitelesítési hibákat naplózó hitelesítési oldal kihasználásával.
Ez a hiba arra késztette a kiberbiztonságra szakosodott cégeket, hogy dolgozzanak az eseményen, és azt jelzi, hogy egyre növekszik az ezt a hibát kihasználó támadások száma.
A tagok Az Apache Software Foundation kifejlesztett egy javítást a sérülékenység kijavítása érdekében és a 2.15.0-s verzió, amellett, hogy a kockázatok csökkentésére lehetséges megoldásokat is ismertettek.
Mi az Apache Log4j? Mennyire súlyos a hiba?
Azok számára, akik még mindig nem tudják, mennyire súlyos a probléma, elmondhatom December 9-én sérülékenységet fedeztek fel az lrögzíteni a könyvtárat log4j Apache.
Ez a könyvtár széles körben használják alkalmazásfejlesztési projektekben Java / J2EE, valamint szabványos Java / J2EE alapú szoftvermegoldás szolgáltatók.
log4j tartalmaz egy keresési mechanizmust, amely lekérdezésre használható speciális szintaxison keresztül egy formátum karakterláncban. Például különféle paraméterek kérésére használható, például a Java környezet verziója a $ {java: version} segítségével stb.
Ezután a jndi kulcs megadása a karakterláncban, a keresési mechanizmus használja a JNDI API-t. Alapértelmezés szerint minden kérés a java előtaggal történik: comp / env / *; a szerzők azonban megvalósították az egyéni előtag használatának lehetőségét kettőspont használatával a kulcsban.
Itt rejlik a sebezhetőség: sijndi: ldap: // kulcsként kerül felhasználásra, a kérés a megadott LDAP szerverhez érkezik. Más kommunikációs protokollok, például LDAPS, DNS és RMI is használhatók.
Ezért a támadó által irányított távoli kiszolgáló visszaküldhet egy objektumot a sebezhető kiszolgálónak, ami tetszőleges kódfuttatáshoz vagy bizalmas adatok kiszivárgásához vezethet.
A támadónak csak egy speciális karakterláncot kell küldenie Azon a mechanizmuson keresztül, amely ezt a karakterláncot egy naplófájlba írja, és ezért a Log4j könyvtár kezeli.
Ez megtehető egyszerű HTTP-kérésekkel, például webes űrlapokon, adatmezőkön stb. küldöttekkel, vagy bármilyen más típusú interakcióval szerveroldali regisztrációval.
Tenable a sebezhetőséget "az elmúlt évtized legfontosabb és legkritikusabb sebezhetőségeként" jellemezte.
A koncepció bizonyítékát már közzétették. Ezt a sérülékenységet jelenleg aktívan kihasználják.
A sebezhetőség súlyossága az Legfeljebb 10 a CVSS skálán.
Íme az érintett rendszerek listája:
- Apache Log4j 2.0–2.14.1 verziók
- Az Apache Log4j 1.x verziói (elavult verziók) speciális konfigurációtól függően.
- Az Apache Log4j sebezhető verzióját használó termékek – Az európai nemzeti CERT-ek teljes listát vezetnek a termékekről és azok sebezhetőségi állapotáról
A CERT-FR a hálózati naplók alapos elemzését javasolja. A következő okok alapján azonosítható a sérülékenység kihasználására irányuló kísérlet, amikor URL-ekben vagy bizonyos HTTP-fejlécekben felhasználói ügynökként használják
Végül érdemes megemlíteni erősen ajánlott a log2.15.0j 4 verzió mielőbbi használata.
Ha azonban nehézségekbe ütközik az erre a verzióra való átállás, átmenetileg a következő megoldások alkalmazhatók:
A log2.7.0j könyvtár 4-s és újabb verzióit használó alkalmazásoknál lehetőség van a támadások elleni védelemre az események formátumának módosításával, amelyek a % m {nolookups} szintaxissal lesznek naplózva a felhasználó által megadott adatokhoz. .
Ez a módosítás megköveteli a log4j konfigurációs fájl módosítását az alkalmazás új verziójának létrehozásához. Ezért az új verzió üzembe helyezése előtt meg kell ismételni a műszaki és funkcionális ellenőrzési lépéseket.
A log2.10.0j könyvtár 4-s és újabb verzióit használó alkalmazások esetén a log4j2.formatMsgNoLo konfigurációs paraméter módosításával is védekezhet a támadások ellen