#8 – log4Shell und andere Risiken
Log4J ist eine weit verbreitete Java-Bibliothek mit einer kritischen Sicherheitslücke, die es Angreifern ermöglicht, Code auszuführen. Philip Kraatz und Dennis Kreft erläutern die Risiken und geben Handlungsempfehlungen für Unternehmen, um sich zu schützen.
Das lernen Sie in dieser Folge
- Log4J ist in vielen Java-Anwendungen integriert, was die Identifikation betroffener Systeme erschwert.
- Die Sicherheitslücke kann einfach ausgenutzt werden, was die Gefahr für Unternehmen erhöht.
- Unternehmen sollten ihre Systeme überwachen und sicherstellen, dass alle Anbieter zeitnah Patches bereitstellen.
- Es ist wichtig, potenziell gefährdete Schnittstellen vorübergehend abzuschalten, bis Updates verfügbar sind.
- Die Cyber-Risiko-Analyse hilft Unternehmen, ihre IT-Sicherheit zu bewerten und Verbesserungspotenziale zu identifizieren.
Kapitel
In Folge 8 unseres Podcasts beschäftigen wir uns mit der log4Shell Sicherheitsbedrohung.
Wir erklären kurz die Hintergründe und die möglichen Auswirkungen auf kleine und mittelständische Unternehmen.
Außerdem stellen wir unsere Cyber-Risiko Analyse vor und erklären, was es damit auf sich hat und warum jeder eine solche Analyse durchführen sollte.
Lade die hier unser Merkblatt zum Thema Cyber Risko kostenlos herunter:
Zitate, die
sitzen.
Je einfacher eine Sicherheits-Lücke auszunutzen ist, desto schneller wird sie auch ausgenutzt.
Volltext-Transkript
2.713 Wörter · 41 Sprecher-Blöcke
Volltext-Transkript
2.713 Wörter · 41 Sprecher-Blöcke
Ich sollte anfangen, ne? Ja, ja. Ja, so ist es. Moin Dennis, herzlich willkommen zu Folge 8.
Ja, Folge 8, Wahnsinn, oder?
Ja, ich habe ja anfangs daran gezweifelt, dass wir die ersten zwei, drei Folgen überstehen, aber jetzt haben wir Folge 8, das Jahr ist fast rum, also läuft gut.
Ja, was haben wir auf dem Zettel? Log4J, bestimmte News.
Genau, wir haben was ganz Aktuelles auf dem Zettel natürlich. Ich glaube, selten war ein Thema so aktuell und so brandheiß, dass es ein IT-Thema prominent in die 20-Uhr-Nachrichten der Tagesschau geschafft hat. Ja. Ja, Sicherheitslücke. Sicherheitslücke, Log4J, Log4Shell, so wird sie genannt. Fit.
Für die, die es genau nehmen wollen, die nennen es dann CVE 202144228.
Genau, das ist die Kurzform quasi dieser Sicherheitslücke. Nein, Spaß beiseite ist natürlich die internationale Bezeichnung dieser Sicherheitslücke, damit man eben weltweit quasi auf das gleiche Thema referenzieren kann und darunter alles sammeln kann.
Aber was ist denn da eigentlich los? Also Log4J ist eine beliebte Bibliothek. Eine Bibliothek zum Loggen von Ereignissen in diversen Java-Umgebungen.
Genau, ja, du hast es ja eigentlich schon gesagt, das ist eigentlich genau das. Also Java ist ja eine relativ weit verbreitete Programmiersprache. Relativ viele Applikationen basieren auf Java, weil es halt sehr, sehr weit verbreitet ist und sehr große Unterstützung hat. Und genau, es gibt eben eine Java-Bibliothek, die nennt sich Log4J. Das Wort Log darin lässt vermuten, wohin die Reise geht. Das ist halt eine Logging-Applikation und Logging-Bibliothek. Also genau, mit Bibliotheken fasst man halt bestimmt immer wiederkehrende Befehle zusammen. Und Log4J ist halt eine dieser Bibliotheken, mit denen man ein Log schreiben kann, also Probleme oder Fehler aus Anwendungen in eine Log-Datei schreiben kann, damit nachher der Entwickler darauf zugreifen kann und dann sich anschauen kann, was sind da für Fehler aufgetreten und dann an die Behebung gehen kann. Und diese Log4J-Bibliothek ist halt verwundbar, weil sie ermöglicht, dass quasi absichtlich falsch eingegebene Werte in ein solches Eingabefeld, eine Applikation, dann dazu führen, dass auf dem System Code ausgeführt wird, der eigentlich gar nicht ausgeführt werden soll.
Und das können ja vor allem... Das können auch ganz banale Sachen sein, von denen man das vermutlich gar nicht so erwarten würde. Also ich habe jetzt so ein klassisches Kontaktformular zum Beispiel. Jetzt fülle ich das üblicherweise aus. Und auch da kann halt durch den Klick auf den Senden-Button eben das Log4J bemüht werden, da das, was ich eingegeben habe, zu loggen. Und da kann ich nun eben auch diesen mit Absicht eingegebenen Chartcode übermitteln.
Genau. Also das große Problem ist halt, die weite Verbreitung dieser Java-Applikation und halt auch dieser Java-Bibliothek. Also es gibt inzwischen immer noch unvollständige Sammlungen von Programmen, die diese Log4J-Bibliothek verwenden. Und diese Listen sind halt wahnsinnig lang.
Und das Problem ist halt eben, dass es nicht nur direkte Applikationen sind,
sondern teilweise diese Bibliothek Bestandteil von Applikationen ist, die wiederum selber in anderen Applikationen verwendet werden. Also wir haben quasi eine doppelte Verschachtelung. Und das macht es natürlich teilweise sehr, sehr schwer zu durchschauen, betrifft oder ist meine Applikation jetzt davon betroffen oder nicht. Weil ich muss erst mal gucken, welche Unterapplikation verwende ich und was verwenden die wiederum. Also das ist sehr, sehr schwierig. Und die Lücke ist halt denkbar einfach auszunutzen. Und das macht es halt so extrem gefährlich, weil je einfacher, so eine Lücke auszunutzen ist, desto schneller wird es natürlich auch gemacht. Und es gibt aus den letzten Tagen zig Nachweise, dass diese Lücke aktiv ausgenutzt wird an diversen Stellen. Und dazu kommt halt eben, dass sie, weil sie so verschachtelt teilweise ist, die Bibliothek auch nur schwer zu schließen ist.
Ja, es geht jetzt im Prinzip ja eigentlich nur noch darum, die Stundentage, also ich hoffe, es sind nur Stunden zu warten, bis eben alle der jeweiligen Anbieter ihre Patches bereitstellen und das Ganze updaten lassen.
Ich glaube, ich glaube, es kann tatsächlich noch Tage dauern an der Stelle. Also ich glaube, wir reden da nicht über Stunden, sondern weil eben das so viele Systeme betrifft und teilweise auch indirekt betrifft, wird das sicherlich noch Tage dauern bei einigen. Die meisten Hersteller sind natürlich da sehr hinterher, gerade weil auch die Lücke so prominent ist. Aber ich glaube, um jetzt so ein bisschen den Weg zurück wieder zu schlagen, zu dem, wie das unsere Kunden betrifft, also typische IT-Systeme aus Kunden, da ist es ein bisschen schwieriger. Insofern ist das man ein bisschen schwerer, dann ist es rauszufinden, welche Applikation betrifft es bei mir, weil ich erst mal gucken muss, welche Applikation setze ich ein? Und hat der Hersteller diese Applikation dazu schon irgendwas veröffentlicht? Und auf der anderen Seite kann man aber sagen, dass die Lücke, die ich benutze, für den typischen unserer Kunden gar nicht so großartig relevant ist. Also natürlich schon relevant, weil sie sicherheitskritisch ist, aber weil sie eben nur dann wirklich gefährlich ausgenutzt werden kann, wenn ich eine Applikation habe, die nach außen hin, also sprich Richtung Internet geöffnet ist. Das heißt, typischerweise habe ich ja meine Applikation, die ich nutze in der Firma, mein ERP-System, mein CRM-Tool, die habe ich alle bei mir irgendwo auf einer Private Cloud betrieben oder ich habe sie bei mir auf dem Server installiert und darauf habe ich erst mal nur Zugriff, entweder über eine gesicherte VPN-Verbindung oder aber, wenn ich mich im selben Netzwerk befinde. Das heißt, um die auszunutzen, muss ich schon im Netzwerk sein und wenn jemand schon im Netzwerk ist, dann habe ich ein größeres Problem als eine Log4j-Bibliothek.
Dann kann ich guten Wissens behaupten, dass Log4j mein kleineres Übel ist. Genau richtig.
Also da hast du andere Probleme als Log4j, beziehungsweise Log4shell, die Lücke. Genau, aber es gibt natürlich auf anderer Stelle irgendwo schon Systeme,
die nach außen geöffnet sind und da wird es dann kritisch.
Also das betrifft typischerweise das dann, wenn ich irgendwo Systeme habe, mit denen ich Daten meinen Kunden austauschen kann. Also Beispiel, mein ERP-System hat vielleicht eine Schnittstelle, über die meine Kunden oder Geschäftspartner mir Daten hochladen können oder runterladen können. Und wenn die Daten hochladen können, wenn die auf Java basiert, diese Applikation, dann besteht natürlich auch da die Gefahr, dass dieses Java-Programm dann eben Log4j nutzt und dann habe ich natürlich eine Lücke, die ich schnell schließen muss, beziehungsweise wo ich mich darum kümmern muss,
dass die geschlossen wird vom Hersteller.
Und auf der anderen Seite gibt es natürlich auch vermutlich diverse Online-Dienste, die ich nutze, bei denen ich genauso gucken muss. Da habe ich vielleicht persönliche Daten von mir hinterlegt, da habe ich vielleicht Kreditkarten-Daten von mir hinterlegt oder, oder, oder. Heißt auch da kann es mich betreffen, wo man schauen muss, okay, wie geht es da jetzt weiter. Also ich würde auf jeden Fall gucken, dass man da Augen und Ohren offen hält, sich informiert und klar, letztlich immer schaut, gibt es irgendwo Dinge, die da auftreten,
irgendwelche Auffälligkeiten passieren, Dinge, die nicht normalerweise passieren sollten.
Also ist mein Netzwerk stark, ist mein Netzwerk ausgelastet oder auch sowas wie ein Dark Web Scan.
Wir haben also Dark Web Monitoring, wo man gucken kann,
tauchen irgendwo persönliche Daten auf im Darknet. Also einfach Augen und Ohren offen halten, gucken, was bieten die Hersteller meiner Programme an, was gibt es da für Informationen und dann entsprechend handeln.
Ja, jetzt habe ich gelesen, dass eben im Falle der Ausnutzung dieser Sicherheitslücke es dazu gekommen ist, dass die etwaigen Angreifer das Ganze dann nutzen, um Bitcoins zu minen. Jetzt las ich in Bezug dessen auch noch, dass das ja im Prinzip, ich sage mal, das kleinere Übel wäre. Also das wäre nicht cool, aber es wäre jetzt halt auch nicht, im Zweifel erstmal nicht betriebskritisch. Jetzt stellt man sich darüber die Frage, ich meine, jetzt habe ich die Möglichkeit, so tief im weitesten Sinne in so ein Thema einzudrängen, wieso versuche ich jetzt Bitcoins zu schärfen? Was ja extrem ressourcenlastig ist und wo am Ende ja jetzt in dem Einzelfall oder in dem einzelnen Netzwerk wahrscheinlich auch gar nicht so viel mehr rumkommt. Ich glaube aber, dass man trotz dessen sich immer am Klaren darüber sein muss, dass das nur die Spitze des Eisbergs ist, dessen, was da eben passieren kann, wenn jemand diese Lücke ausnutzt.
Ja, also auf jeden Fall das sowieso. Und natürlich auch da, das Bitcoin-Mining lastet meine Hardware aus, mein Netzwerk aus. Heißt, ich kann es nicht mehr so nutzen, wie ich das möchte. Und natürlich ist dann das Nächste, wenn so eine Lücke erstmal geöffnet ist, dann ist ja auch die Frage, bleibt es dann in Anführungszeichen nur beim Bitcoin-Mining oder geht es dann eben weiter und dann werden möglicherweise die geöffneten Zugänge eben auch im Darknet gehandelt. Auch das passiert ja immer wieder, dass dann dort die ja schon installierten Backdoors eben weiterverkauft werden. Und das ist ja ein Fass ohne Boden. Also das ist schon sehr, sehr kritisch. Da muss man auf jeden Fall gucken, dass man das im Blick behält und möglichst alle Zugriffe unterbindet. Das heißt auch zum Beispiel, dass man möglicherweise, bis es ein Update gibt dafür, solche Systeme abschalten muss. Also um bei Beispiel von vorhin zu bleiben, wenn ich eben so ein ERP-System habe, was mir eine Schnittstelle zum Kunden bietet, die über Java läuft, die mit der Log4j-Bibliothek arbeitet, die verwundbar ist und es gibt kein Update, dann muss ich durchaus eine Bewegung ziehen, diese Schnittstelle bis dahin abzuschalten, um einfach zu verhindern, dass darüber schlimmerer Schaden entsteht, als zu sagen, ich verzichte jetzt irgendwie zwei, drei Tage auf diese Schnittstellen-Funktionalität. Also das ist durchaus eine Abwägung, die man da auf jeden Fall tätigen muss. Beziehungsweise sinnvollerweise gibt es darauf nur die Antwort, ich schalte die Schnittstelle ab, weil das Risiko ist einfach unüberschaubar groß, weil sie so einfach ausnutzen ist.
Ja, also ich denke einfach, man kann hier zusammenfassend sagen, dass es gilt, eben abzuwarten, was die Hersteller liefern. Wie schnell sie es liefern und dann eben entweder selbst zu schauen, was für Dienste biete ich eben an oder nutze ich intern selber, die eben Log4j in Betrieb haben oder ansonsten mich eben an meinen IT-Dienstleister zu wenden, die das Ganze überprüfen zu lassen und auch dann darauf zu hoffen, dass der relativ zeitnah Updates bekommt, einspielen kann. Ich würde sagen, wir bleiben da ein bisschen am Ball und schauen auch in den nächsten Wochen, in den nächsten Folgen vielleicht immer mal wieder rein, wie da so der aktuelle Stand ist, damit da unsere ZuhörerInnen auch immer im Bilde sind. Genau. Ja, ich denke, dass wir das Thema an dieser Stelle so abschließen können. Ich wollte nämlich gerne noch an unser Thema letzter Woche anknüpfen. Da haben wir ja einmal vorgestellt, mit welchen sieben doch relativ einfachen Fragen. Ich eigentlich gucken kann, wie bin ich aufgestellt, was meine IT-Infrastruktur angeht, gerade eben im Hinblick auf die Sicherheit. Und würde das gerne noch mal zum Anlass nehmen, mit dir einmal ganz kurz und knapp darüber zu sprechen, wie wir denn das Ganze so in dieser Form für unsere Kunden oder eben auch potenziellen Kunden abbilden, nämlich in Form unserer Cyber-Risiko-Analyse, die meines Erachtens es verdient hat, hier auch mal eine Plattform zu kreieren. Und die unseren ZuhörerInnen mal ein bisschen näher zu bringen.
Auf jeden Fall. Also die Cyber-Risiko-Analyse, die wir anbieten, die wir durchführen, die baut ja letztendlich diese Fragen noch mal weiter aus.
Sprich, wir gehen ja auf die einzelnen Teilbereiche ein.
Also wir haben ja drei Teilbereiche, die wir betrachten in der Analyse. Das eine ist der Bereich Infrastruktur. Das zweite ist der Bereich Sicherheit. Und das dritte ist der Bereich Support. Und Service. Und innerhalb dieser Teilbereiche gibt es dann ja die entsprechenden Unterkategorien, Unterfragen, die das nachher wieder aufgreifen und dann irgendwo zusammen auswertbar machen, um ein Risikoscore zu ermitteln.
Ich glaube einfach, dass das Schöne an diesem Produkt letztendlich auch ist, dass es das demjenigen, der es beauftragt, eben ganz, ganz plakativ nach einem Ampelschema widerspiegelt, wie er aufgestellt ist. Und das ohne groß, ich sag mal, Fachjargon zu benutzen, sondern man hat im Prinzip die drei Teilbereiche, die du schon aufgezählt hast, die jeweils noch unterkategorisiert sind in neun einzelne Punkte. Und ich habe dann eben danach die Übersicht grün, gelb, rot, klassisches Ampelsystem. Und erhalte am Ende im Prinzip ein Score. Der maximal 100 betragen kann und weiß einfach, wie bin ich aufgestellt, was muss ich verbessern.
Genau, also ich kann relativ einfach dann eben auch erkennen, wie du gesagt hast, was muss ich verbessern und wie kann ich das verbessern. Also ich kriege ja direkt quasi dann die Lösung mit an die Hand und weiß genau, an welcher Stelle muss ich jetzt ansetzen, welche Stellschrauben muss ich drehen, um eben in Richtung der 100 Punkte zu kommen, in Richtung grün zu kommen. Und das kann man immer wieder machen. Und das kann man eben für jeden Kunden eben auch machen. Das ist das Schöne. Und was ich sehr gut finde, ist, man muss jetzt kein IT-Experte sein, also auf Kundenseite kein IT-Experte sein, um diese Analyse zu machen oder zu beantworten, die Fragen zu beantworten. Sondern es reicht eben, wenn man ein wenig über seine IT-Infrastruktur Bescheid weiß, da ein paar Fragen zu beantworten kann. Und dann kommt man relativ gut auf ein brauchbares Ergebnis.
Ich glaube, das, was du gesagt hast, also einer der Punkte, die du gerade gesagt hast, ist da relativ wichtig. Ich glaube, dass es auch gar nicht im ersten Schritt darum geht, zu sagen, ich muss hier 100 Punkte haben, sondern man kann eben das Ergebnis dieser Cyber-Risiko-Analyse auch ganz hervorragend als, ich sage mal, Wegbegleiter der Betreuung sehen. Also ich habe ja quasi meinen Stand jetzt und kann ja mit allem, was ich mache, was ich beauftrage, was ich an Projekten umsetze, eben in Echtzeit sehen, was verwandelt sich beispielsweise von Rot in Grün oder eben von Gelb in Grün. Und ich glaube, dass das eben als Visualisierungstool wirklich hilfreich ist für den einen oder anderen Kunden oder eben auch potenziellen Kunden.
Ja, genau. Also es macht das sehr, sehr greifbar, was sonst eben ein bisschen abstrakter ist. Und man hat, genau wie du gesagt hast, direkt in dem Moment, wo man ein Projekt erfolgreich abgeschlossen hat, dann die Möglichkeit, das darin direkt wieder zu machen. Und das ist auch ein sehr, sehr guter Weg, um zu sagen, okay, jetzt sind wir eben von 60 Punkten auf 75 Punkte angestiegen in der Bewertung, weil wir eben bestimmte Maßnahmen umgesetzt haben. Und da hat man eben gleich einen vergleichbaren Wert auch dabei, wo man sagen kann, gut, jetzt sind wir auf einem guten Weg, wir können das weiterentwickeln. Man kann sich Ziele setzen, kann sagen, okay, im nächsten Jahr wollen wir von 75 auf 90 Punkte kommen oder ähnliches und kann das eben gleich verknüpfen mit den entsprechenden Maßnahmen.
Das ist schon sehr, sehr gut, ja.
Ja, jetzt haben wir doch Werbung in eigener Sache gemacht. Aber ich glaube, das hat es verdient.
Ja, ich denke auch, also das Thema ist ja, wie man jetzt an der Log4J-Lücke sieht, das Thema Sicherheit, IT-Sicherheit, Cybersicherheit, wie auch immer man es nennen möchte, ist ja wichtiger denn je. Es gibt immer mehr Bedrohungen, jeden Tag kommt was Neues dazu. Die IT-Bedrohungslandschaft verändert sich. Auf der anderen Seite gibt es wieder neue mögliche Lösungen dafür. Dieses klassische Katz-und-Maus-Spiel, irgendwo geht einer vorweg, der andere rennt hinterher und dann tauscht man plötzlich wieder Rollen. Und da muss man halt am Ball bleiben. Und ich denke, dieses Tool Cyberrisikoanalyse, wie du schon gesagt hast, ist eigentlich ein sehr, sehr gutes visuelles Mittel dafür, um das zu erreichen.
Ja, exakt. Ja. Sehr schön. Das ging schnell. Ja. Vielen Dank. Wir sind ja vor Ort früh. Vielleicht noch ganz kurz, für jeden, der jetzt Interesse an so einer Cyberrisikoanalyse hat, gerne unsere Internetseite benutzen. Genau. Terminbuchung auf der Internetseite und dann schauen wir einfach gemeinsam mal, wie es bei Ihnen aussieht oder wie es bei euch aussieht und wo die Reise hingehen kann. Philip, vielen Dank.
Ja, www.hagel-it.de slash Termin. Link auch in der Folgenbeschreibung. Gerne vorbeischauen. Wir freuen uns und danken dir. Ja, vielen Dank. Bis zum nächsten Mal. Danke, Dennis. Bis nächste Woche.
Bis zum nächsten Mal. Bis nächste Woche. Bis zum nächsten Mal.