[et_pb_section fb_built=“1″ fullwidth=“on“ _builder_version=“4.2.2″][et_pb_fullwidth_image src=“https:\/\/www.kippdata.de\/wp-content\/uploads\/2021\/12\/domino.png“ _builder_version=“4.2.2″][\/et_pb_fullwidth_image][\/et_pb_section][et_pb_section fb_built=“1″ _builder_version=“3.22″][et_pb_row _builder_version=“3.25″ background_size=“initial“ background_position=“top_left“ background_repeat=“repeat“][et_pb_column type=“4_4″ _builder_version=“3.25″ custom_padding=“|||“ custom_padding__hover=“|||“][et_pb_text _builder_version=“4.2.2″ background_size=“initial“ background_position=“top_left“ background_repeat=“repeat“ hover_enabled=“0″]<\/p>\n
Zuletzt aktualisiert mit Hinweisen zu Log4J2 Version 2.13.1 und 2.3.1 f\u00fcr Java 7 und Java 6 am 22.12.2021, 11:25. Davor aktualisiert mit Hinweisen zu CVE-2021-45105 und Absicherung mittels mod_security am 20.12.2021, 11:55.<\/p>\n
Die Apache Software Foundation hat am 10.12.2021 ein kritisches Sicherheits-Problem in der Logging-Bibliothek Log4j ver\u00f6ffentlicht. Das zugeh\u00f6rige Problem hat den Namen „Log4Shell“ (mancherorts auch „Log4jShell“) und tr\u00e4gt die offizielle CVE-Nummer CVE-2021-44228. Weitere Untersuchungen an denen auch kippdata beteiligt war, resultierten in der Aufdeckung und Bekanntgabe der zus\u00e4tzlichen Probleme CVE-2021-45046 und CVE-2021-45105.<\/p>\n
Die offizielle Erl\u00e4uterungsseite des Log4j-Projektes findet sich unter https:\/\/logging.apache.org\/log4j\/2.x\/security.html<\/a>. Die entsprechenden CVE-Seiten sind https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2021-44228<\/a>, https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2021-45046<\/a> und https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2021-45046<\/a>.<\/p>\n Die Auswirkungen der Probleme sind:<\/p>\n Auch wenn RCE automatisch DoS und ID zur Folge hat, werden diese hier erw\u00e4hnt, weil einige Gegenma\u00dfnahmen zwar RCE unterbinden, jedoch nicht auch den DoS- oder ID-Angriff.<\/p>\n Das Problem hat zu Recht den h\u00f6chsten CVSS Score 10.0.<\/p>\n <\/p>\n Jede Anwendung, die Log4j in einer Version vor 2.17.0 beinhaltet – das ist die Version, die am 18.12.2021 ver\u00f6ffentlicht wurde – mit Java 7 eine Version vor 2.13.3, muss als angreifbar gelten. Allerdings ist die vorherige Version 2.16.0 bereits gut gegen RCE gesch\u00fctzt und auch Angriffe vom Typ DoS und ID sind nur m\u00f6glich, wenn die Log-Konfiguration bestimmte Eigenschaften hat. Au\u00dferdem wurden f\u00fcr den Einsatz mit Java 7 Version 2.12.2 und 2.12.3 ver\u00f6fentlicht und f\u00fcr den Einsatz mit Java 6 Version 2.3.1. Versionen 2.12.3 und 2.3.1 sind so wie 2.17.0 vollst\u00e4ndig gesch\u00fctzt, Version 2.12.2 so wie 2.16.0 nur eingeschr\u00e4nkt.<\/p>\n Eine weitergehende Pr\u00fcfung, ob ein konkreter Einsatz einer anf\u00e4lligen Version angreifbar ist, ist nur durch ein aufwendiges professionelles und dennoch nicht eindeutiges Penetration Testing m\u00f6glich – oder alternativ durch ein extrem aufwendiges Source Code Review, das jede Log-Nachricht im Source Code der Anwendung und aller Hilfsbibliotheken untersucht.<\/p>\n Die Log4j-Bibliothek ist in der Programmiersprache Java geschrieben und wird in sehr vielen Java-Anwendungen verwendet. Auch Anwendungen in anderen Sprachen, die in einer Java Virtual Machine laufen, wie etwa Groovy, Scala, Kotlin oder Clojure k\u00f6nnen diese Bibliothek verwenden.<\/p>\n Das Problem hat auch deshalb den CVSS Score 10.0, weil die Voraussetzungen f\u00fcr einen effektiven Angriff grunds\u00e4tzlich nicht hoch sind.<\/p>\n Die Bibliothek Log4j gibt es in 2 Versionen:<\/p>\n <\/p>\n Nach aktuellem Stand sind die g\u00e4ngigen Logging-Fassaden und -Implementierungen SLF4J, Logback und java.util.logging nicht betroffen.<\/p>\n <\/p>\n Das schwerwiegendste Problem ist die Remote Code Execution in Versionen vor 2.16.0. Eine Pr\u00fcfung kann grunds\u00e4tzlich folgende Ans\u00e4tze verwenden:<\/p>\n Nach unserer Einsch\u00e4tzung muss deshalb bei jeder Anwendung, die Log4J verwendet von einer Angreifbarkeit ausgegangen werden, au\u00dfer der Hersteller eine Anwendung schliesst dies f\u00fcr diese offiziell aus.<\/p>\n Das weitere DoS- und ID-Problem in Version 2.16.0 kann nur ausgenutzt werden, wenn eine verwundbare Log-Konfiguration verwendet wird. Bekannte Angriffsvektoren nutzen einen Eintrag der Form ${ctx:mykey} oder $${ctx:mykey} in einem PatternLayout in der Konfiguration. Diese k\u00f6nnen – sofern ein Angreifer Daten in den MDC (Mapped Diagnostic Context) einschleusen kann – zu einer unterminierten Rekursion und damit einem Denial of Service f\u00fchren. Indirekt kann dieser DoS dann f\u00fcr ein Information Disclosure genutzt werden, indem ein Angreifer mit bestimmten Werten durchprobiert, wann ein DoS ausgel\u00f6st wird. Die alleinige Verwendung eines MDC, etwa via %X, %mdc oder %MDC, stellt jedoch kein Problem dar.<\/p>\n <\/p>\n Eine umfangreiche inoffizielle Liste findet sich unter https:\/\/gist.github.com\/SwitHak\/b66db3a06c2955a9cb71a8718970c592<\/a>.<\/p>\n Das „Nationaal Cyber Security Centrum“ aus den Niederlanden pflegt aktuell eine Liste betroffener Software unter\u00a0https:\/\/github.com\/NCSC-NL\/log4shell\/<\/a>. Dort gibt es verschiedene Kategorien, unter anderem die wichtige Liste\u00a0https:\/\/github.com\/NCSC-NL\/log4shell\/tree\/main\/software<\/a>.<\/p>\n Die Apache Software Foundation (ASF) hat eine aktuelle Liste der von der ASF bereitgestellten Software mit Status unter https:\/\/blogs.apache.org\/security\/entry\/cve-2021-44228<\/a>\u00a0ver\u00f6ffentlicht.<\/p>\n Bitte beachten Sie, dass in den Listen als Beispiel h\u00e4ufig steht, dass Apache Tomcat nicht betroffen ist. Das ist grunds\u00e4tzlich korrekt, weil Tomcat nicht zwingend mit Log4J2 f\u00fcr das Logging kommt. Viele Distributionen – wie etwa unsere – f\u00fcgen jedoch Log4j 2 wegen seiner f\u00fcr professionelle produktive Umgebungen wichtigen F\u00e4higkeiten hinzu, wodurch Tomcat angreifbar wird. \u00c4hnliches mag auch f\u00fcr andere Software in den Listen gelten.<\/p>\n <\/p>\n Leider gibt es mittlerweile Hinweise, dass die ersten Versuche, die L\u00fccke auszunutzen, etwa am 01.12.2021 geschahen. Das Problem wurde dem Log4j-Projekt aber erst etwa eine Woche vor Ver\u00f6ffentlichung der ersten korrigierten Version und der Problembeschreibung gemeldet. Das Projekt hat also sehr z\u00fcgig reagiert, aber insgesamt war das Problem schon einige Tage fr\u00fcher in Hackerkreisen bekannt.<\/p>\n <\/p>\n Das ist leider nicht robust m\u00f6glich. Hinweise k\u00f6nnen zwar Zeichenketten wie etwa „jndi:“ in Log-Dateien sein. Aus dem Fehlen dieser l\u00e4sst sich aber nicht schlie\u00dfen, dass es keinen Angriff gab.<\/p>\n <\/p>\n Eine Remote Code Execution l\u00e4sst nat\u00fcrlich auch eine Korruption des betroffenen Systems bis hin zum Einbau von Hintert\u00fcren zu. Der Code des Angreifers l\u00e4uft zwar „nur“ unter dem Benutzer, unter dem der Java-Prozess der betroffenen Anwendung ausgef\u00fchrt wurde, kann jedoch durch Kombination mit ggf. anderen vorhandenen Sicherheitsl\u00fccken m\u00f6glicherweise auch zu erweiterten Privilegien des Angreifers f\u00fchren.<\/p>\n Eine Korruption eines Systems l\u00e4sst sich also leider nicht ausschlie\u00dfen. Sofern daf\u00fcr vorher Vorkehrungen getroffen wurden, kann eine Korruption durch Abgleich mit vorhandenen Fingerprints oder Einspielung \u00e4lterer Sicherungen ausgeschlossen werden.<\/p>\n <\/p>\n Nein.<\/p>\n Viele bekannten Angriffsszenarien nutzen zwar initial einen Aufruf zu einem Netzwerkdienst, der eine vom Angreifer kontrollierte Antwort liefert. Einen solchen Dienst zu starten ist beispielsweise mit einer Java-Klasse von wenigen Bytes Gr\u00f6\u00dfe m\u00f6glich. Der Dienst ben\u00f6tigt keinen privilegierten Port oder besondere Nutzer-Rechte. Auch wenn der anzugreifende Java-Prozess keine Netzkommunikation ins Internet \u00f6ffnen kann, ist denkbar, dass ein Angreifer zun\u00e4chst auf einem weniger gut abgesicherten internen System den notwendigen Dienst startet und diesen aufruft.<\/p>\n Dar\u00fcber hinaus gibt es jedoch weitere Szenarien, die \u00fcblicherweise offene Kommunikationskan\u00e4le nutzen, wie etwa die Namensaufl\u00f6sung via DNS. Dort kann ein Information Disclosure – also die Offenlegung vertraulicher Informationen – stattfinden, etwa indem ein Passwort in der Form MYSECRET.attacker.com in einen Servernamen eingebaut wird. Schon der Versuch der Kommunikation mit diesem Server f\u00fchrt zun\u00e4chst zu einer DNS-Anfrage der internen DNS-Server an den DNS-Server der Domain attacker.com bei der MYSECRET dorthin \u00fcbertragen wird.<\/p>\n Es ist zu erwarten, dass weitere Szenarien auftauchen, die den externen Dienst nicht mehr voraussetzen. Die Einschr\u00e4nkung der Kommunikation auf Kommunikationspartner (Systeme und Ports), die f\u00fcr die Funktion einer Anwendung zwingend notwendig sind, ist dennoch auf jeden Fall sinnvoll. Sie alleine gen\u00fcgt jedoch nicht zur Absicherung gegen das aktuelle Problem.<\/p>\n <\/p>\n Aktuelle Java Patchversionen unterbinden das Nachladen von Klassen aus unsicheren Quellen. Die originalen Angriffsszenarien nutzten ein solches Nachladen, weshalb zun\u00e4chst der Eindruck entstand, dass Java Patchupdates ausreichen. Dies hat sich jedoch schon nach kurzer Zeit als unzureichend herausgestellt.<\/p>\n Dennoch ist es wichtig regelm\u00e4ssige Java-Patchupdates durchzuf\u00fchren. Auch in diesem Falle hat dies die Angriffsfl\u00e4che verringert, die Absicherung ist aber nicht vollst\u00e4ndig.<\/p>\n <\/p>\n Das Apache Logging-Projekt hat am Montag, dem 13.12.2021, die neue Version 2.16.0 bereit gestellt, welches das Remote Code Execution-Problem behebt. Das verbliebe DoS- und ID-Problem wird erst mit Version 2.17.0 vom 18.12.2021 behoben. Ein Update der Log4j 2 Bibliothek auf diese Version ist die beste Behebung. Wir empfehlen deshalb dringend mit Prio 1 ein schnelles Update auf 2.17.0.<\/p>\n Allerdings setzt Log4j 2.17.0 minimal Java 8 voraus. F\u00fcr alte Anwendungen, die noch Java 7 verwenden, hat das Projekt am 14.12.2021 Version 2.12.2 ver\u00f6ffentlicht, die ebenfalls nicht mehr mit Remote Code Execution angreifbar ist. Seit 22.12.2021 steht die vollst\u00e4ndig gesch\u00fctzte Version 2.12.3 zur Verf\u00fcgung. Diese sollte f\u00fcr alle Anwendungen verwendet werden, die Java 7 ben\u00f6tigen. F\u00fcr den Einsatz mit Java 6 steht ebenfalls seit 22.12.2021 Version 2.3.1 zur Verf\u00fcgung, die die gleichen Probleme beseitigt.<\/p>\n Sollte ein Update nicht m\u00f6glich sein, empfehlen wir folgende H\u00e4rtungen gegen Remote Code Execution:<\/p>\n Falls Sie die Log4j2-Jar-Datei log4j-core.jar oder log4j-core-[VERSION].jar in einer Anwendung eindeutig identifizieren k\u00f6nnen, empfehlen wir die Entfernung der Klasse org.apache.logging.log4j.core.lookup.JndiLookup<\/em> aus dieser Datei w\u00e4hrend einer Downtime sowie einen Neustart danach. Dies kann zum Beispiel durch den Befehl<\/p>\n zip -q -d \/pfad\/zu\/datei.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class<\/em><\/p>\n geschehen. Hierbei muss der korrekte Pfad zur entsprechenden Jar-Datei angeben werden.<\/p>\n Einige Anwendungen haben die Jar-Datei jedoch signiert und starten nach dem Entfernen nicht mehr. In diesem Falle ist die Entfernung nicht m\u00f6glich. Wir empfehlen deshalb dringend, vorher eine Sicherheitskopie der Original-Datei zu machen und nach M\u00f6glichkeit das Vorgehen auf einer Testinstanz zu pr\u00fcfen, damit es nicht zu unn\u00f6tigen Downtimes kommt.<\/p>\n Es gibt au\u00dferdem F\u00e4lle, in denen die Quelle der zu entfernenden Klasse nicht robust zu erkennen ist, etwa sogenannte \u00dcber-Jar-Dateien oder auch Repackaging. Schlie\u00dflich ist auch denkbar, dass sie sowohl in einer leicht zu erkennenden Jar-Datei steckt, aber zus\u00e4tzlich auch aus einer nicht aufgefallenen Quelle kommt.<\/p>\n Wir empfehlen deshalb die folgende Variante 2 zus\u00e4tzlich und nat\u00fcrlich auch dort, wo Sie Variante 1 nicht durchf\u00fchren k\u00f6nnen.<\/p>\n Dies empfehlen wir erg\u00e4nzend zu Variante 1 oder, wenn diese nicht m\u00f6glich ist, als Fallback.<\/p>\n Setzen Sie das System Property „log4j2.formatMsgNoLookups<\/em>“ oder alternativ die Environment-Variable LOG4J_FORMAT_MSG_NO_LOOKUPS<\/em> auf den Wert „true<\/em>„. Das Setzen als System-Property sollte auf der Kommandozeile erfolgen, indem Sie dem Java-Prozess das zus\u00e4tzliche Argument „-Dlog4j2.formatMsgNoLookups=true<\/em>“ mitgeben. Wenn Sie alternativ die Environment-Variable LOG4J_FORMAT_MSG_NO_LOOKUPS<\/em> auf „true<\/em>“ setzen, vergessen Sie bitte nicht, diese auch zu exportieren.<\/p>\n Bitte beachten Sie, dass der Schutz durch Variante 2 in bestimmten F\u00e4llen nicht wirkt. Der Schutz wird f\u00fcr viele Anwendungen vollst\u00e4ndig sein. Es ist jedoch schwer herauszufinden, f\u00fcr welche Anwendungen dies nicht gilt. Ist eine Anwendung davon betroffen, dass die Schalter nicht helfen, ist sie weiter voll angreifbar. Deshalb verzichten Sie bitte nicht auf die H\u00e4rtung nach Variante 1.<\/p>\n Zur Behebung des verbleibenden DoS-Szenarios ohne Updates muss die Log-Konfiguration gepr\u00fcft und ggf. angepasst werden. Wir verweisen hierf\u00fcr auf den Eintrag zu CVE-2021-45105 auf der Seite https:\/\/logging.apache.org\/log4j\/2.x\/security.html<\/a>.<\/p>\n Erg\u00e4nzend zu diesen Behebungen kann es sinnvoll sein, bei Einsatz einer Web Application Firewall (WAF), wie etwa Apache Web Server mit mod_security, g\u00e4ngige Angriffe durch zus\u00e4tzliche Regeln abzufangen. Auch wenn diese Regeln nach einiger Zeit vom Angreifer erkannt und evtl. umgangen werden k\u00f6nnen, sichert man sich doch gegen einfache Angriffe ab und kauft sich damit Zeit f\u00fcr die Bestandsaufnahme betroffener Anwendung und die Umsetzung der vollst\u00e4ndigen Behebung.<\/p>\n F\u00fcr mod_security ist eine entsprechende Regel (Regel „1005“) beschrieben im folgenden Blog-Beitrag des wichtigen Core Rule Set (CRS) Entwicklers Christian Folini: https:\/\/coreruleset.org\/20211213\/crs-and-log4j-log4shell-cve-2021-44228\/<\/a>. Bitte beachten sie auch ggf. hinzugef\u00fcgte sp\u00e4tere Blog-Beitr\u00e4ge.<\/p>\n <\/p>\n Die Java-Logging-Bibliothek Log4j 2 unterst\u00fctzt die Aufl\u00f6sung von String-Referenzen der Form „${etwas}<\/em>“ im Nachrichten-Teil der Log-Zeile durch Nachschlagen in Tabellen und anderen Quellen. Dies sind sogenannte Lookups. Ein solcher Quell-Typ ist ein JNDI-Lookup (Java Naming and Directory Interface), der andere Server etwa \u00fcber RMI- oder LDAP-URLs ansprechen kann. Solch ein Lookup wird von Log4j 2 dann zun\u00e4chst durch die Antwort dieses Servers auf den RMI- oder LDAP-Aufruf ersetzt. Da die Aufl\u00f6sung der Referenzen jedoch rekursiv geschieht, kann es durch weitere Aufl\u00f6sungen in diesen Antworten zur Ausf\u00fchrung von Anwendungs-Code kommen.<\/p>\n Andere Lookups als mittels JNDI sind bislang nicht als Angriffsvektoren bekannt. Weil sich jedoch die erste H\u00e4rtung in Version 2.15.0 als unvollst\u00e4ndig herausgestellt hat, wurden in Version 2.16.0 alle Lookup-M\u00f6glichkeiten entfernt.<\/p>\n Wie aber schafft es ein Angreifer einen Text der Form „${etwas}<\/em>“ in eine Log-Nachricht zu bekommen, die doch meist vom Entwickler als fester Text vorgesehen wird? Nehmen wir an, eine Anwendung empf\u00e4ngt Daten aus dem Internet und erwartet an einer bestimmten Stelle eine Zahl. Wird dort etwas anderes geschickt, gibt die Anwendung intern eine Fehlermeldung in die Log-datei aus. Damit besser nachvollziehbar wird, warum es zu dem Fehler kam, wird dann h\u00e4ufig auch der Text, der statt einer Zahl empfangen wurde mit ausgegeben. Schickt der Angreifer jetzt also einfach statt der Zahl den Text „${etwas}<\/em>„, wird dieser in die Fehlernachricht f\u00fcr das Log integriert und verursacht das Lookup.<\/p>\n <\/p>\n Wir haben unsere Kunden nach Bekanntgabe des Problems zeitnah \u00fcber die Auswirkungen und die m\u00f6glichen Behebungen informiert. Diese Information wurde sofort aktualisiert, als wir selbst weitere Angriffsszenarien gegen die bis dahin noch als sicher geltende Version 2.15.0 gefunden haben.<\/p>\n Wir haben unseren Kunden dann ein robustes Werkzeug bereit gestellt, um eine H\u00e4rtung nach Variante 1 durchzuf\u00fchren sowie genaue Informationen gegeben, wie Variante 2 umgesetzt wird. Danach haben wir umgehend neue Versionen aller unterst\u00fctzten Versionslinien von Apache Tomcat bereit gestellt, in denen wir die geb\u00fcndelte Log4J-Bibliothek aktualisiert haben.<\/p>\n Dar\u00fcber hinaus haben wir unsere Support-Kunden durch Beantwortung individueller Fragen betreut und dar\u00fcber hinausgehende Beratungen auch f\u00fcr nicht von uns gelieferte Java-Anwendungen angeboten.<\/p>\n <\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" Log4Shell Zuletzt aktualisiert mit Hinweisen zu Log4J2 Version 2.13.1 und 2.3.1 f\u00fcr Java 7 und Java 6 am 22.12.2021, 11:25. Davor aktualisiert mit Hinweisen zu CVE-2021-45105 und Absicherung mittels mod_security am 20.12.2021, 11:55. Die Apache Software Foundation hat am 10.12.2021 ein kritisches Sicherheits-Problem in der Logging-Bibliothek Log4j ver\u00f6ffentlicht. Das zugeh\u00f6rige Problem hat den Namen „Log4Shell“ […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"\r\n die Apache Software Foundation hat am 10.12.2021 einen Hinweis zu einem kritischen Sicherheits-Problem in Log4j herausgegeben. Das zugeh\u00f6rige Problem hat den Namen \"Log4Shell\" und tr\u00e4gt die Nummer CVE-2021-44228. Was ist das Problem?<\/strong> Welche Software kann betroffen sein?<\/strong> Ist auch Log4j 1.2.x betroffen?<\/strong> Wie steht es mit anderen Logging-Bibliotheken?<\/strong> Behebungsm\u00f6glichkeiten<\/strong> Umgang mit der kippdata Tomcat-Distribution<\/strong> Weitere FAQ<\/strong>\n
Welche Software kann betroffen sein?<\/h4>\n
\n
Wie steht es mit anderen Logging-Bibliotheken?<\/h4>\n
Wie finde ich heraus, ob meine Anwendungen wirklich betroffen sind?<\/h4>\n
\n
Gibt es Listen, welche Anwendungen betroffen sind?<\/h4>\n
Seit wann ist das Problem bekannt?<\/h4>\n
Kann ich erkennen, ob ich schon angegriffen wurde?<\/h4>\n
Ist mein System jetzt korrumpiert?<\/h4>\n
Mein System kann keine Aufrufe ins Internet machen – ist es sicher?<\/h4>\n
Wie weit hilft ein Java-Patchupdate?<\/h4>\n
Behebungsm\u00f6glichkeiten<\/h4>\n
\n
\n
\n
<\/u><\/li>\n<\/ul>\n\n
<\/u><\/li>\n<\/ul>\nWie ist die technische Ursache f\u00fcr das Problem?<\/h4>\n
Wie hat kippdata f\u00fcr seine Apache Tomcat-Distribution reagiert?<\/h4>\n
Offizielle Referenz ist:
https:\/\/logging.apache.org\/log4j\/2.x\/security.html<\/a>
und:
https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2021-44228<\/a>
Die Auswirkungen des Problems sind Remote Code Execution. Treffen also die Voraussetzungen f\u00fcr die Angreifbarkeit zu, kann der Angreifer eigenen Anwendungscode auf dem angegriffenen Server ausf\u00fchren. Das Problem hat deshalb den h\u00f6chsten CVSS Score 10.0.
<\/p>\r\n\r\n\r\n\r\n
Die Java-Logging-Bibliothek Log4j 2 unterst\u00fctzt die Aufl\u00f6sung von String-Referenzen der Form \"${etwas}\" im Message-Teil der Log-Zeile. Dabei kann \"etwas\" auf unterschiedliche Quellen verweisen. Ein solcher Quell-Typ ist ein JNDI-Lookup, der andere Server etwa \u00fcber RMI- oder LDAP-URLs ansprechen kann. Solch ein Lookup wird von Log4j 2 dann zun\u00e4chst durch die Antwort dieses Servers auf den RMI- oder LDAP-Aufruf ersetzt. Da die Aufl\u00f6sung der Referenzen jedoch iterativ geschieht, kann es durch weitere Aufl\u00f6sungen in diesen Antworten zur Ausf\u00fchrung von Anwendungs-Code kommen.
Dabei m\u00fcssen folgende Voraussetzungen erf\u00fcllt sein:
- Der Angreifer schafft es, eine solche URL in den Meldungstext oder Parameter des Meldungstextes hinein zu bekommen. Beispiel: Eine Anwendung loggt im Meldungstext den Wert eines HTTP-Headers, und der Angreifer kann diesen von au\u00dfen frei auf einen beliebigen Wert setzen. Insbesondere gelingt dies, wenn dieser Header durch vorgeschaltete Reverse Proxies ungefiltert hindurch l\u00e4uft.
- Der laufende Java-Prozess - in unserem Fall ein Tomcat-Prozess - hat Netzwerk-Zugriff auf ein System und einen Port, die unter Kontrolle des Angreifers stehen, so dass dieser von dort die b\u00f6sartige Antwort ausliefern kann.<\/p>\r\n\r\n\r\n\r\n
Grunds\u00e4tzlich kann jede Software betroffen sein, die die Java-Logging-Bibliothek Log4j 2 bis zur Version 2.14.1 einsetzt. In unseren Auslieferungen wird Log4j 2 eingesetzt in:
- Apache Tomcat 10.0.x, 9.0.x, 8.5.x und 8.0.x
Bislang ist dem Tomcat-Projekt und uns kein direktes Angriffszenario bekannt, bei dem die L\u00fccke im Tomcat oder einem der von uns geb\u00fcndelten Addons, die ebenfalls Log4j 2 verwenden, ausgenutzt werden kann.
Da eine komplette Pr\u00fcfung jedoch eine Sichtung aller m\u00f6glichen Log-Texte bedingt, kann aktuell eine Angreifbarkeit auch nicht vollst\u00e4ndig ausgeschlossen werden. Wir raten deshalb zu einer der weiter unten beschriebenen Ma\u00dfnahmen.
Selbstverst\u00e4ndlich k\u00f6nnen au\u00dferdem Web-Anwendungen, die in Tomcat deployt wurden, unabh\u00e4ngig vom umgebenden Tomcat betroffen sein. Bei den unten beschriebenen Ma\u00dfnahmen geben wir an, welche automatisch auch das Problem in den deployten Web-Anwendungen beheben.
Das \"Nationaal Cyber Security Centrum\" aus den Niederlanden pflegt aktuell eine Liste betroffener Java-Software unter:
https:\/\/github.com\/NCSC-NL\/log4shell\/<\/a>
Dort gibt es verschiedene Kategorien, unter anderem eine Liste unter:
https:\/\/github.com\/NCSC-NL\/log4shell\/tree\/main\/software<\/a>
<\/p>\r\n\r\n\r\n\r\n
Nach aktuellem Stand ist die alte Versionslinie Log4j 1.2.x nicht von dem eigentlichen schwerwiegenden Problem betroffen. Hier kann es h\u00f6chstens zu einem Problem kommen, wenn der Angreifer auf anderem Wege die Log4j-Konfiguration ver\u00e4ndern kann. Dazu m\u00fcsste in die Log4j 1.2-Konfiguration ein Appender vom Typ JMSAppender aufgenommen werden, der au\u00dferdem unsichere Parameter verwendet. In unseren Auslieferungen ist dies nicht der Fall.<\/p>\r\n\r\n\r\n\r\n
Nach aktuellem Stand sind die g\u00e4ngigen Logging-Fassaden und -Implementierungen SLF4J, Logback und java.util.logging nicht betroffen.<\/p>\r\n\r\n\r\n\r\n
Das Apache Logging-Projekt hat am Montag, dem 13.12.2021, die neue Version 2.16.0 bereit gestellt. Ein Update der Log4j 2 Bibliothek auf diese Version ist die beste Behebung. Ein Update auf die Version 2.15.0 vom Freitag, dem 10.12.2021, wird nicht mehr empfohlen, auch wenn sie dieses Problem ebenfalls behebt. Wir empfehlen dringend mit Prio 1 ein schnelles Update auf 2.16.0. Allerdings setzt Log4j 2.16.0 minimal Java 8 voraus, und diese Behebung wirkt sich in der Regel nicht auch auf in Tomcat deployte Anwendungen als Behebung aus.
Sollte ein Update auf 2.16.0 nicht m\u00f6glich sein oder Java < 8 eingesetzt werden, empfehlen wir alternativ:
Variante 1: Patchen der Jar-Datei<\/u>
Falls Sie die Log4j2-Jar-Datei log4j-core.jar oder log4j-core-[VERSION].jar in einer Anwendung eindeutig identifizieren k\u00f6nnen, empfehlen wir die Entfernung der Klasse
org.apache.logging.log4j.core.lookup.JndiLookup
aus dieser Datei w\u00e4hrend einer Downtime plus Neustart danach. Dies kann zum Beispiel durch den Befehl
zip -q -d \/pfad\/zu\/datei.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class
geschehen. Hierbei den korrekten Pfad zur Jar-Datei angeben. Einige Anwendungen haben die Jar-Datei jedoch signiert und starten nach dem Entfernen nicht mehr. In diesem Falle ist die Entfernung nicht m\u00f6glich. Wir empfehlen deshalb dringend, vorher eine Sicherheitskopie der Original-Datei zu machen und nach M\u00f6glichkeit das Vorgehen auf einer Testinstanz zu pr\u00fcfen, damit es nicht zu unn\u00f6tigen Downtimes kommt.
Es gibt F\u00e4lle, in denen die Quelle der zu entfernenden Klasse nicht robust zu erkennen ist, etwa sogenannte Uber-Jar-Dateien oder auch Repackaging. Au\u00dferdem kann die Klasse auch in einer signierten und deshalb nicht ver\u00e4nderbaren Jar-Datei stecken. Schlie\u00dflich ist auch denkbar, dass sie sowohl in einer leicht zu erkennenden Jar-Datei steckt, aber zus\u00e4tzlich auch aus einer nicht aufgefallenen Quelle kommt.
Wir empfehlen deshalb Variante 2 zus\u00e4tzlich und nat\u00fcrlich auch dort, wo Sie Variante 1 nicht durchf\u00fchren k\u00f6nnen.
Variante 2: Setzen von System Property oder Environment-Variable<\/u>
Dies empfehlen wir erg\u00e4nzend zu Variante 1 oder, wenn diese nicht m\u00f6glich ist, als Fallback.
Setzen Sie das System Property \"log4j2.formatMsgNoLookups\" oder alternativ die Environment-Variable LOG4J_FORMAT_MSG_NO_LOOKUPS auf den Wert \"true\". Das Setzen als System-Property sollte auf der Kommandozeile erfolgen, indem Sie dem Java-Prozess das zus\u00e4tzliche Argument \"-Dlog4j2.formatMsgNoLookups=true\" mitgeben. Im konkreten Fall eines Tomcat k\u00f6nnen Sie dies als Erg\u00e4nzung in die Variable JAVA_OPTS in der Datei bin\/setenv.sh aufnehmen. Wenn Sie alternativ die Environment-Variable LOG4J_FORMAT_MSG_NO_LOOKUPS auf \"true\" setzen, vergessen Sie bitte nicht, diese auch zu exportieren.
Bitte beachten Sie, dass der Schutz durch Variante 2 in bestimmten F\u00e4llen nicht wirkt. Der Schutz ist vollst\u00e4ndig beispielsweise f\u00fcr das Tomcat-eigene Logging und wird auch f\u00fcr die meisten Anwendungen vollst\u00e4ndig sein. Es ist jedoch schwer herauszufinden, f\u00fcr welche Anwendungen dies nicht gilt. Ist eine Anwendung davon betroffen, dass die Schalter nicht helfen, ist sie weiter voll angreifbar.
Variante 3: Java Patch-Update<\/u>
Dies ist nat\u00fcrlich generell empfohlen, auch ganz unabh\u00e4ngig vom aktuellen Problem!
Im Kontext des aktuellen Sicherheitsproblems stellt dies keine L\u00f6sung f\u00fcr Anwendungen innerhalb eines Tomcat dar. F\u00fcr andere angreifbare Anwendungen ist es durchaus m\u00f6glich, dass sie nach einem Java-Patch-Update nicht mehr angreifbar sind.
<\/p>\r\n\r\n\r\n\r\n
In unseren Auslieferungen ist Log4j2 mit 2.10.0 oder neuer enthalten in:
- allen Versionen von Tomcat 10.0
- allen Versionen von Tomcat 9.0
- in Tomcat 8.5 ab Version 8.5.24-1
- in Tomcat 8.0 ab Version 8.0.48-1
Wir haben unseren Tomcat Support-Kunden zun\u00e4chst am Dienstag, 14.12.2021, ein Skript zur Verf\u00fcgung gestellt, mit dem bei bereits installierten und betroffenen Tomcat-Paketen das in Variante 1: Patchen der Jar-Datei beschriebene Entfernen einer Klasse in dem von uns gelieferten Log4j 2 robust durchgef\u00fchrt werden kann.
Zus\u00e4tzlich werden wir im Laufe der Woche aktualisierte Tomcat-Versionen bereit stellen, die ein abgesichertes Log4j 2 enthalten.
<\/p>\r\n\r\n\r\n\r\n
Gibt es Listen, welche Anwendungen betroffen sind?<\/u>
Die bereits erw\u00e4hnte Liste des \"Nationaal Cyber Security Centrum\" aus den Niederlanden ist unter
https:\/\/github.com\/NCSC-NL\/log4shell\/<\/a>
und dort vor allem
https:\/\/github.com\/NCSC-NL\/log4shell\/tree\/main\/software<\/a>
erreichbar.
Die Apache Software Foundation hat eine aktuelle Liste der von der ASF bereitgestellten Software mit Status ver\u00f6ffentlicht:
https:\/\/blogs.apache.org\/security\/entry\/cve-2021-44228<\/a>
Eine weitere umfangreiche inoffizielle Liste findet sich unter
https:\/\/gist.github.com\/SwitHak\/b66db3a06c2955a9cb71a8718970c592<\/a>
Bitte beachten Sie, dass in den Listen meist steht, dass Tomcat nicht betroffen ist. Das ist grunds\u00e4tzlich korrekt, weil Tomcat nicht zwingend mit Log4J2 f\u00fcr das Logging kommt. Viele Distributionen - wie etwa unsere - f\u00fcgen jedoch Log4j 2 wegen seiner F\u00e4higkeiten hinzu, wodurch Tomcat angreifbar wird. \u00c4hnliches mag auch f\u00fcr andere Software in den Listen gelten.
Mein System kann keine Aufrufe ins Internet machen - ist es sicher?<\/u>
Die bekannten Angriffsszenarien nutzen alle initial einen Aufruf zu einem Netzwerkdienst, der eine vom Angreifer kontrollierte Antwort liefert.
Einen solchen Dienst zu starten ist beispielsweise mit einer Java-Klasse von wenigen Bytes Gr\u00f6\u00dfe m\u00f6glich. Der Dienst ben\u00f6tigt keinen privilegierten Port oder besondere Nutzer-Rechte.
Auch wenn der anzugreifende Java-Prozess keine Netzkommunikation ins Internet \u00f6ffnen kann, ist denkbar, dass ein Angreifer zun\u00e4chst auf einem weniger gut abgesicherten internen System den notwendigen Dienst startet und diesen aufruft.
Auch ist denkbar, dass weitere Szenarien auftauchen, die den externen Dienst nicht mehr voraussetzen. Die Einschr\u00e4nkung der Kommunikation auf Kommunikationspartner (Systeme und Ports), die f\u00fcr die Funktion einer Anwendung zwingend notwendig sind, ist auf jeden Fall sinnvoll. Es ist aber aktuell nicht klar, ob dies in jedem Fall auch zur Absicherung gegen das aktuelle Problem ausreicht.
Wie weit hilft ein Java-Patchupdate?<\/u>
Aktuelle Java Patchversionen unterbinden das Nachladen von Klassen aus unsicheren Quellen. Die originalen Angriffsszenarien nutzten ein solches Nachladen, weshalb zun\u00e4chst der Eindruck entstand, dass Java Patchupdates ausreichen. Anwendungen k\u00f6nnen jedoch eigene Klassen beinhalten, die so instanziiert werden k\u00f6nnen, das Fremdcode ausf\u00fchrbar wird.
Insbesondere bringt Tomcat als Ablaufumgebung f\u00fcr in ihn deploybare Anwendungen Klassen mit, mit deren Hilfe das Remote Code Execution-Problem in Log4j 2 genutzt werden kann, ohne Klassen von au\u00dfen nachzuladen.
Es findet auch bei diesen bekannten Angriffen zwar immer noch eine Kommunikation zu einem b\u00f6sartigen Server statt. Diese ist jedoch deutlich einfacherer Art, als das Nachladen von Klassen, und wird auch von aktuellen Java Patchlevels nicht unterbunden.
Kann ich erkennen, ob eine Anwendung angreifbar ist?<\/u>
Jede Anwendung, die Log4j 2 in einer Version < 2.15.0 beinhaltet - das ist die Version, die letzten Freitag, den 10.12.2021, ver\u00f6ffentlicht wurde - muss als angreifbar gelten. Eine weitergehende Pr\u00fcfung ist nur durch ein aufwendiges professionelles und dennoch nicht eindeutiges Penetration Testing m\u00f6glich - oder alternativ durch ein extrem aufwendiges Source Code Review, das jede Log-Nachricht im Source Code der Anwendung und aller Hilfsbibliotheken untersucht.
Kann ich erkennen, ob ich schon angegriffen wurde?<\/u>
Das ist leider ebenfalls nicht robust m\u00f6glich. Hinweise k\u00f6nnen zwar Zeichenketten wie etwa \"jndi:\" in Log-Dateien sein. Aus dem Fehlen dieser l\u00e4sst sich aber nicht schlie\u00dfen, dass es keinen Angriff gab.
Seit wann ist das Problem bekannt?<\/u>
Leider gibt es mittlerweile Hinweise, dass die ersten Versuche, die L\u00fccke auszunutzen, etwa am 01.12.2021 geschahen. Das Problem wurde dem Projekt aber erst etwa eine Woche vor Ver\u00f6ffentlichung der korrigierten Version und der Problembeschreibung letzten Freitag gemeldet. Das Projekt hat also sehr z\u00fcgig reagiert, aber insgesamt war das Problem bis jetzt ca. 14 Tage in Hackerkreisen bekannt.
Ist mein System jetzt korrumpiert?<\/u>
Eine Remote Code Execution l\u00e4sst nat\u00fcrlich auch eine Korruption des betroffenen Systems bis hin zum Einbau von Backdoors zu. Der Code l\u00e4uft zwar \"nur\" unter dem Benutzer, unter dem der Java-Prozess ausgef\u00fchrt wurde, kann jedoch durch Kombination mit ggf. anderen vorhandenen Sicherheitsl\u00fccken m\u00f6glicherweise auch zu erweiterten Privilegien des Angreifers f\u00fchren.<\/p>\r\n","_et_gb_content_width":"","footnotes":""},"class_list":["post-395","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/pages\/395","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/comments?post=395"}],"version-history":[{"count":33,"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/pages\/395\/revisions"}],"predecessor-version":[{"id":465,"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/pages\/395\/revisions\/465"}],"wp:attachment":[{"href":"https:\/\/www.kippdata.de\/index.php\/wp-json\/wp\/v2\/media?parent=395"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}