Log4J-Sicherheitslücke: Warum der Fehler unvermeidbar war
Warnstufe Rot: Log4Shell gilt als größte Sicherheitslücke in der Geschichte des Internets. Doch auch in der Zukunft wird ein solches Szenario nicht vermeidbar sein, sagen Experten. Das hat strukturelle Gründe.
Die Log4Shell genannte Schwachstelle im Java-Tool Log4J ist eine der gravierendsten Sicherheitslücken in der Geschichte des Internets.
Foto: Panthermedia.net/dotshock
Der Vergleich mit dem Kartenhaus, der seit Bekanntwerden von Log4Shell immer wieder bemüht wird, hinkt. Denn so ein Kartenhaus hat in der Regel eine ziemlich klare und nachvollziehbare Struktur: Man dürfte ganz gut erahnen können, welche Folgen es hat, wenn man diese oder jene Karte aus dem Gebilde zieht – im Zweifel bricht dann das Kartenhaus zusammen.
Bei der Java-Sicherheitslücke Log4Shell – eine der gravierendsten in der Geschichte des Internets – ist das aber anders. Die Softwarewelt ist kein Kartenhaus. Das System dahinter ist viel komplexer und über Jahrzehnte organisch gewachsen. Fast wie ein empfindliches Ökosystem, das aus dem Gleichgewicht geraten kann und akut gefährdet ist, wenn an irgendeinem Punkt, der von außen betrachtet bedeutungslos erscheint, eine Lücke entsteht. Kaum ein Mensch hätte Log4Shell voraussehen können, und selbst die Folgen sind ungewiss. Expertinnen und Experten gehen davon aus, dass das ganze Ausmaß der Probleme, die sich daraus ergeben, erst in Wochen und Monaten absehbar sein und uns noch Jahre beschäftigen werden.
IT-Security-Spezialisten, Softwarefirmen, Konzerne, ganze Staaten sind seit dem Wochenende alarmiert. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat gar die Warnstufe Rot ausgegeben. Endverbraucher seien eher nicht betroffen und müssten sich wenig Sorgen machen, heißt es. Doch das ist ein riskanter Trugschluss. Was genau ist da an jenem Wochenende Mitte Dezember eigentlich passiert? Und lässt sich das in Zukunft vermeiden?
Der Versuch einer Entwirrung:
Was ist Java?
Fangen wir mit einer Tasse Kaffee an. Das Symbol hat jeder Internetnutzer schon mal gesehen: Die dampfende Kaffeetasse ist das Emblem von Java und viele kennen es vom Popup-Fenster, das in unregelmäßigen Abständen beim Arbeiten am PC aufpoppt: Java-Update verfügbar (kleiner Tipp an der Stelle: Nicht einfach wegklicken, sondern updaten!). Für viele Anwendungen benötigen Nutzerinnen und Nutzer eine Java-Installation – und Java ist indirekt Teil des Log4Shell-Problems, doch dazu später.
Cybersicherheit: Diese Skills brauchen Sie im Security-Team
Warum ist Java überhaupt auf meinem Rechner? Zunächst: Java ist eine sogenannte objektorientierte Programmiersprache – im Gegensatz zu sogenannten prozeduralen Programmiersprachen wie beispielsweise Pascal. Bei prozeduralen Programmiersprachen wird grob gesagt ein Programm in Unterprogramme zergliedert, die jeweils Teilprobleme lösen. Dabei wird eine bestimmte Menge benötigter Schritte und deren Abfolge definiert, die zur Lösung führen sollen. Der so entstandene Code ist recht unflexibel: Die Maschine arbeitet Befehle nacheinander ab. Bei Java hingegen steht im Fokus, welche Eigenschaften einzelne Elemente des Programms haben. Diese werden dafür in Klassen eingeteilt und können miteinander kommunizieren. Die Programmiersprache ist sehr viel flexibler und ökonomischer, da sie durch die Einteilung in Klassen weniger redundant ist. Ein wichtiges Merkmal von Java ist zudem die Portabilität, das heißt, auf allen Plattformen funktioniert Java gleich gut.
Nicht zuletzt deshalb hat sich Java zu einer beliebten und sehr weit verbreiteten Programmiersprache entwickelt. Zahlreiche Programme und vor allem Webanwendungen und Android-Apps sind in Java programmiert. Und auch Anwendungen, die nicht direkt auf Java beruhen, hängen oft mit anderen Programmen zusammen, die in Java geschrieben worden sind.
Wikipedia etwa beruht auf Java, ebenso das Spiel Minecraft und zahlreiche andere Programme. Auch große Konzerne wie SAP oder etwa die Bahn nutzen Java für ihre Software. Das heißt: Fast jeder Internetnutzer kommt zwangsläufig mit Java in Berührung.
Wofür ist Log4J da?
Log4J ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Mit der sehr verbreiteten Open-Source-Software der Apache Foundation, einer Stiftung in den USA, die seit Jahrzehnten wichtige Internetsoftware entwickelt und wartet, spielt zum Beispel beim Betrieb von Webservern eine Rolle. Da es sich um einen Open-Source-Code handelt, kann dieser gratis verwendet und von allen, die es nutzen wollen, offen eingesehen werden. Log4J ist Bestandteil der meisten Java-Programme und dient in erster Linie dazu, Meldungen von Software aufzuzeichnen, zum Beispiel Fehlermeldungen, die wie in einem Logbuch protokolliert werden.
Aber auch darüber hinausgehende Zeichenketten zeichnet Log4J auf, etwa Anmeldeversuche mit einer Email-Adresse oder Benutzernamen oder Befehle einer API – das sind Schnittstellen zwischen verschiedenen Programmteilen oder zwischen Hardware und Software.
Sicherheitslücke in JNDI: Was ist genau passiert?
Die Schwachstelle in der Programmierumgebung Java gilt als die größte Sicherheitslücke in der Geschichte des Internets. Die Server-Schwachstelle nennt sich Log4Shell und ermöglicht es Hackern, jeden Systemcode ihrer Wahl durchzuführen. Es handelt sich um eine bis dato unentdeckte Schwachstelle, die wiederum hunderttausende weitere Lücken in Softwareprodukten erzeugen kann. Besonders gefährlich ist, dass Cyberkriminelle Daten von Server selbst abfließen lassen oder beliebige Codes schreiben lassen können. Interne Netzwerke werden ausgespäht oder Daten auf dem Server verändert.
Wie funktioniert das? Die Angreifer nutzen aus, dass Log4J mehr ist, als eine Blackbox, die Vorgänge aufzeichnet. “Das Problem liegt in der Komplexität, denn das Protokollinterface ist relativ mächtig. Anfragen von außen werden von Log4J nicht immer einfach nur in eine Log-Datei geschrieben, sondern bei Bedarf auch interpretiert”, erklärt Steven Arzt vom Fraunhofer-Institut für Sichere Informationstechnologie. Das Sicherheitsproblem liegt im sogenannten JNDI-Lookup in Log4J. JNDI steht für “Java Naming and Directory Interface” und gibt Java-Programmen unter anderem Zugriff auf Verzeichnisdienste, um Objekte mit einem Verzeichnisnamen verknüpfen zu können oder bei einer Anfrage einen Namen nachzuschlagen – JNDI greift dabei auch auf Referenzen von entfernten Rechnern zu, und da liegt das Problem: Denn dahinter könnte sich ein Angreifer verbergen, der sich Zugang zum System erschleichen will.
Log4Shell – also praktisch der Zugriff auf das gesamte System – kann ausgelöst werden, wenn Log4J einen Befehl von außen für das JNDI erhält:
- Der Angreifer übermittelt Daten an den Server, den er attackieren will. Log4j nimmt den Vorgang in eine Logdatei auf.
- Falls die Daten JNDI triggern, sendet Log4j eine Anfrage an die Website des Angreifers.
- Und an dieser Stelle kann der Angreifer sich Zutritt verschaffen: Die Webseite antwortet auf die Request und kann zum Beispiel Schadcode einschleusen. “Wenn ich das schlau mache, kann ich mithilfe von Variablen über das JNDI jeden beliebigen Code ausführen“, so Steven Arzt.
Was macht Software wie diese so fehleranfällig?
“Aktuell wird Software zu großen Teilen durch ein „Zusammenstecken“ von existierenden Komponenten entwickelt”, sagt Thorsten Strufe. Er ist ist Professor für praktische IT Sicherheit am KIT – und erklärt es mit einem bildlichen Vergleich: “Das kann man sich ein wenig so vorstellen, wie die Autoindustrie sich diverse Schrauben, Bolzen, Zahnräder und Plastikteile beschafft – und diese dann zu einem Gesamtsystem kombiniert.” Während die Autoindustrie feste Standards und Gewährleistungsklauseln für diese Teile habe. würden bei Software häufig Komponenten verwendet, die jemand in seiner Freizeit entwickelt und kostenlos zur Verfügung gestellt habe. “Gewährleistung oder Sicherheitsgarantien gibt es da natürlich selten, dafür ist es einfach, schnell und billig”, so Strufe.
Viele dieser freien Softwarebibliotheken seien ausgezeichnet entwickelt und gut gewartet. “In einigen Fällen ist dies allerdings nicht der Fall und in einigen Fällen sind diese Bibliotheken schon in sich komplex und bieten viele Funktionen, auf die importierende Entwickler keine Acht geben. Damit bauen sie sich implizit Funktionalitäten in ihr neues, kombiniertes System ein, die ihnen gar nicht bewusst ist, die von Angreifern aber ausgenutzt werden können.”
So sei auch im Fall von Log4Shell die Logging-Funktion mit der Bibliothek Log4J in den Code vieler Systeme importiert worden. “Log 4J hat sich zu einem Quasi-Standard entwickelt, weil es zuverlässig funktioniert und einfach zu bedienen ist. Das hat zu einer sehr große Verbreitung geführt, was die aktuelle Krise deutlich verstärkt”, so Strufe.
Ransomware: So werden Sie Erpressungstrojaner wieder los
Sollten Softwareentwickler dann nicht lieber auf Open-Source verzichten und Programme von grund auf selber zusammenbauen? Fehler würden dann nur innerhalb eines Systems vorkommen – und nicht überall. Christoph Skornia hält das für undenkbar. Er ist Leiter des Labors für Informationssicherheit an der Ostbayerischen Technischen Hochschule (OTH) Regensburg. „Wenn wir Software so bauen würden, dass jeder seine Funktionalitäten selbst erfinden und schreiben müsste, wären wir heute auf dem technischen Stand von 1989. Das Verteilen von Aufgaben und das gemeinsame Nutzen von Bibliotheken ist ein enormer Technologie-Booster. Insofern würde ich auch der Apache Foundation hier keinen großen Vorwurf machen. Im Gegenteil, ohne Institutionen wie Apache oder Linux wäre das Internet, wie wir es heute kennen, undenkbar.“
Wer ist von der Sicherheitslücke in Log4J betroffen?
Zahlreiche Softwareentickler, Dienstanbieter, Unternehmen, Behörden – sie alle sind direkt oder indirekt von Log4Shell betroffen, wenn sie mit Programmen zu tun haben, in denen Log4J eine Rolle spielt. Das Blöde: Es ist nicht leicht nachzuvollziehen, ob Log4J in einem Dienst enthalten ist. “Das kann man nicht von außen auf Anhieb sehen, weil es sich um eine Bibliothek handelt, die schlicht in Programme integriert wird, häufig ohne dieses nach außen ordentlich zu dokumentieren. Es gibt allerdings inzwischen Werkzeuge um vorliegende Software daraufhin zu untersuchen”, sagt Experte Thorsten Strufe vom KIT. Auch ist schwer zu entdecken, ob ein System bereits korrumpiert wurde. “Wenn eine Protokollierung der Zugriffe eingeschaltet ist kann man hier Glück haben. Im Allgemeinen gilt allerdings: Nicht in jedem Fall und nicht durch Laien”, so Strufe. “Forensiker können hier helfen und nach Spuren schauen. Sollten Aufrufprotokolle vorliegen, können diese nützliche Hinweise enthalten, aber eine Abwesenheit gefundener Indizien sollte nicht als Nachweis verstanden werden, dass es keine Zugriffe gegeben hat.”
Klar ist inzwischen: Auch staatliche Institutionen hatten die Sicherheitslücke in ihren Systemen. “Bei einer Schwachstelle mit dieser Verbreitung ist auch die Bundesverwaltung insofern betroffen, als das für diese Schwachstelle verwundbare Systeme im Einsatz sind”, so ein Sprecher des BSI gegenüber ingenieur.de. Das BSI habe die betroffenen Behörden informiert und entsprechende Schutzmaßnahmen empfohlen.
Laut dem BSI sind Privatanwenderinnen und Privatanwender weniger stark gefährdet als Unternehmen und Organisationen. Das sagt auch IT-Sicherheitsexperte Christoph Skornia: „Viele Endbenutzer sind zwar indirekt, aber nicht unmittelbar gefährdet. Zumindest sind aktuell keine Angriffe bekannt, die darauf abzielen, den Nutzer eines Dienstes direkt zu attackieren.“ Sprich: Betroffene Unternehmen wie zum Beispiel Amazon oder Cisco haben selbst zwar ein großes Problem – “aber wenn diese Dienste in ihren Systemen nicht massive Fehler gemacht haben, dann haben Nutzer erst einmal kein großes Problem. Das heißt aber nicht, dass das nicht noch passieren kann.“
Was muss man jetzt unternehmen?
Das JNDI-Lookup im neuesten Update zu Log4j wurde deaktiviert. „Die Entwickler von Log4j haben diese JNDI-Funktion nun standardmäßig ausgeschaltet. Log4j funktioniert weiter – nur wer dieses JNDI-Feature nutzen will, muss es nun explizit aktivieren. Damit ist die kritische Funktion innerhalb von log4j weg, ohne dass es groß jemand vermissen würde”, so Steven Arzt vom Fraunhofer Institut.
Schnelligkeit sei jetzt wichtig, sagt Christoph Skornia: „Jedes Softwareunternehmen muss jetzt unbedingt prüfen: Setze ich diese Bibliothek ein und wenn ja, mit welcher Version und Konfiguration?” Auf die Frage, ob es ein gewisses Zeitfenster für ITler gibt, in dem sie agieren sollten, sagt der Experte: „Wichtig ist eine schnelle Reaktion. Dabei darf man nicht in sich schließenden Fenstern denken, sondern muss großen Risiken so schnell wie möglich beseitigen und dabei gegebenenfalls kleine Risiken in Kauf nehmen.“ Da sich Programmierfehler nie ausschließen lassen, empfiehlt er “eine professionelle Qualitätssicherung und klare Standards für den Fall, dass etwas schief geht.“ Das A und O ist laut Skornia ein funktionierendes Incident Management. “Das muss auch bei der kleinsten Firma sitzen.”
Cyberattacken: „Angriffe werden immer aggressiver“
Thorsten Strufe vom KIT ergänzt diese Empfehlung: “Unternehmen sollten alle Dienste, von denen sie nicht sicher wissen, ob sie Log4J enthalten, vom Netz nehmen und auf Patches von den Herstellern und Entwicklern warten.” Bei Diensten, die sich partout nicht vom Netz trennen ließen, bis sie gepatcht sind, bestehe grundsätzlich die Möglichkeit, sie durch eine vorgeschaltete Firewall zu schützen. “Dieser Schutz ist allerdings nicht zwangsläufig effektiv und darauf sollte sich nur verlassen, für den selbst ein kurzfristiges Abschalten zum Patchen fatale Folgen hätte. Denn es muss davon ausgegangen werden, dass die Systeme weiterhin unsicher sind”, so Strufe. Als Nutzer könne man im Prinzip nicht viel tun, als selbst Updates einzuspielen, sobald sie vorliegen. “Mit der Bewegung vieler Anwendungen in die Cloud und dem Abonnement-Modell, bei dem Programme nicht mehr lokal installiert und ausgeführt werden, ist man letztlich immer darauf angewiesen, dass die unzähligen Dienstanbieter, deren Dienste man nutzt, alle verantwortungsvoll handeln”, sagt der Experte. “Geräte zu Hause, die auch über das Internet erreichbar sind, sollte man vom Netz trennen und auf Patches bzw Entwarnungen von den Herstellern warten, bevor man sie wieder erreichbar macht.”
Steven Arzt vom Fraunhofer Institut rät grundsätzlich: „Updates installieren. Immer. Und nicht nur die Windows Updates. Endanwender sollten alle ihre Programme unbedingt aktuell halten, ein veralteter PDF-Reader oder Browser ist genauso Murks wie ein veraltetes Windows.“
Welche Folgen kann es haben, wenn Betroffene jetzt nicht handeln?
“Seitens der Dienstanbieter ist es unverantwortlich, derzeit Server, von denen nicht klar ist, dass sie die betroffenen log4j-Versionen nicht enthalten, in Betrieb zu lassen”, warnt Thorsten Strufe. “Es handelt sich um eine extrem kritische Schwachstelle, da Angreifer ohne viel Know-How und ohne großartige Infrastruktur aus dem Internet angreifen und praktisch beliebigen Code auf den angegriffenen Rechnern ausführen können.”
Wer hat die Sicherheitslücke Log4Shell entdeckt?
Am 24. November entdeckte der Alibaba-Cloud-Sicherheitsdienst die Schwachstelle und meldete diese an Apache. Am 9. Dezember wurde der erste Angriff dokumentiert – und zwar betraf es den Server des Spiels „Minecraft“.
Warum hat vorher keiner die Schwachstelle in Log4J bemerkt?
Tatsächlich schlummerte die Lücke schon seit Jahren in dem Java-Tool. Aber die meisten Experten gehen davon aus, dass auch Profi-Tester die Lücke nur sehr schwer hätten ausfindig machen können.
Cybersicherheit: Diese Skills brauchen Sie im Security-Team
Zudem habe sich – auch durch gesteigerten Marktdruck – ein gewisser Laissez-Faire etabliert. “Es gibt schon lange Anzeichen, dass wir uns zu sehr auf eine scheinbare Sicherheit von Software verlassen”, sagt Thorsten Strufe. “Kunden haben sich daran gewöhnt, lieber billige Geräte und Software zu kaufen, als solche, die ordentlich entwickelt und sicherer sind – meist läuft ja auch nichts schief.”
Natürlich erwarte niemand so weitreichende Verwundbarkeiten wie im aktuellen Fall. “Und zumindest für dieses konkrete Problem sind mir keine früheren Anzeichen bekannt”, so der IT-Sicherheitsexperte. “Dennoch müssen wir auch auf Weiteres mit solchen Zwischenfällen rechnen, so lange wir uns bei der Software-Entwicklung grundsätzlich mit der kostenoptimierten Rekombination existierender Bibliotheken und bei Produkten mit völliger Haftungsfreiheit der Hersteller zufrieden geben.”
Müsste nicht jeder, der programmiert, auch IT-Sicherheitskenntnisse haben?
Expertinnen und Experten warnen: Viele IOT-Geräte können durchaus auch betroffen sein – also etwa auch programmierbare Maschinen, die in der Industrie eingesetzt werden. Sollten Unternehmen ihre Mitarbeiterinnen und Mitarbeiter in IT-Sicherheit schulen? “Jeder kann sich vielleicht das Bein brechen, wenn er Pech hat. Die Gefahr besteht. Aber niemand würde sagen: Jeder muss ein bisschen ein Unfallchirurg sein, damit er im Fall der Fälle das Bein richten kann”, sagt Steven Arzt. “Wenn ein Unternehmen kritische Geräte entwickelt, dann sollte es sich ein Team aufbauen oder einkaufen. Aber es funktioniert eben nicht, jedem Programmierer ein bisschen IT-Sicherheit beizubringen, das wird am Ende nicht reichen.” Im Entwicklungsprozess müssten entsprechende Prüfungsschritte – angefangen bei der Konzeption neuer Systeme – durch Spezialisten vorgesehen sein, so Arzt. “Nur wird eben niemand von einem beliebigen Programmierer erwarten, diesen Spezialisten ersetzen zu können. Aus Firmensicht gilt aber: Jede Firma, die so etwas anfasst, braucht einen Plan mit internen oder externen Spezialisten.”
Ein Beitrag von:
