IT-Sicherheit-DE
Published in

IT-Sicherheit-DE

Was haben wir aus Log4Shell gelernt?

Beitragsbild

Das Wochenende am 11. und 12. Dezember 2021 werde ich nie wieder vergessen. Wohlwissend, dass am Montag im Büro so einiges passieren wird klemmte ich mich am Sonntag Abend an den Rechner und sammelte Informationen zu Log4j und einer möglichen Lösungsstrategie (die sich im Laufe der nächsten Tage — gefühlt stündlich — änderte). Alleine war ich damit sicher nicht, denn so ziemlich alle, die in der IT oder IT Sicherheit arbeiten, hatten damit zu tun.

Womöglich haben wir es nach einigen Patchständen geschafft und können mit Version 2.17.1 auf einen relativ sicheren Stand blicken (vermutlich!). Jetzt wäre es an der Zeit den Lessons learned Teil durchzuführen. Ich möchte die Lektionen, die aus dem Schlamassel gelernt werden sollen in folgende Fragen unterteilen:

  • Warum wurde die “Lücke” nicht früher gefunden?
  • Warum betraf es so viele Systeme?
  • Wie schützen wir uns in Zukunft davor?

Warum wurde die “Lücke” nicht früher gefunden?

Eine Lücke war eigentlich nicht vorhanden. Das bekannte Sprichwort “It’s a feature not a bug” greift hier wohl am besten. Denn durch die {{ }} signalisiert man Log4j, dass man Logdaten weiter anreichern möchte, wie die eingesetzte Java Version mittels: {{java:version}} (korrigiert mich falls das falsch ist.)

Eigentlich ist dies sehr nützlich, denn Logs könnten damit zu ausgezeichneten forensischen Quellen werden (was sie ja schon sind, aber es geht immer besser), die dynamische Inhalte zur Laufzeit mit einbeziehen.

Wenn ich den vorherigen Abschnitt lese, so denke ich aber: Moment, das ist die Grundlage (fast) aller Sicherheitsprobleme im Webentwicklungsbereich, wenn ich so an PHP denke. Dynamisch etwas mit einbinden …

Jedes Feature einer Anwendung hat das Potenzial Sicherheitsprobleme zu verursachen. Vielleicht sollte beim Review des Codes, oder der Features generell “um die Ecke” gedacht werden. Aus eigener Erfahrung kann ich aber sagen: So einfach ist das nicht.

Warum betraf es so viele Systeme?

Log4j ist keine Software, die man einfach irgendwo installiert. Sie ist damit auch nicht in den üblichen gelisteten installierten Programmen vorhanden. Folgendes wäre ein passender Vergleich: Nehmen wir an ein Server besteht nur aus installierter Software (ohne Hardware, OS usw.), analog dazu besteht ein Nahrungsmittel aus vielen Zutaten. Log4j ist jetzt eine Zutat irgendeiner oder sogar mehrerer Zutaten. Damit taucht es nicht direkt auf, ähnlich wie die “versteckten” Zutaten bei Nahrungsmitteln.

Denkt man dieses Konzept weiter und breitet es auf viele Softwaresysteme aus, so haben wir — je nach Komplexität — einen sehr stark verzweigten Abhängigkeitsbaum.

Dependency Tree von https://julien.danjou.info/dependencies-handling-in-python-automatic-update/

Gehen wir mal ein typisches Beispiel aus der Pythonwelt an. “Warum nicht Java?” höre ich einige Fragen. Das letzte mal habe ich Java im Studium gemacht, deshalb.

Installiert man beispielsweise die Library für das sammeln von Informationen auf Webseiten “scrapy” erfolgt dies über den Befehl:

pip install scrapy

Daraufhin legt der Paketmanager pip los und liest sich erst alle “dependencies” durch, die vorher installiert werden. Falls diese auch “dependencies” haben, werden diese auch vorher installiert. Das ganze kann — wie sich nun jeder Leser denken kann — sehr komplex werden.

Und was mache ich jetzt mit dieser Information? Theoretisch müsste man jede Abhängigkeit auf Schwachstellen prüfen, oder man vertraut auf den Entwickler/Hersteller, der diese Prüfung vielleicht selbst schon gemacht hat?

Wie schützen wir uns in Zukunft davor?

Das zu beantworten ist schwierig. Aus meiner Sicht befinden wir uns hier im Feld der Supplychain Attacks (nicht ganz so wie Kaseya, aber ähnlich), denn Log4j und jede andere Bibliothek gehören zu irgendeiner “Lieferkette”, meistens zu einem Service, der bspw. on-premise läuft.

  • Kontrolle ist besser als Vertrauen: Damit wird die Wichtigkeit der Admins weiter betont, man benötigt also mehr Personal, denn irgendjemand muss sich die Zeit nehmen und Dinge auch genauer kontrollieren.
  • Features, die nicht benötigt werden deaktivieren: Genau prüfen welche Features einer Software man unbedingt benötigt. Alles andere abschalten, dazu gehört auch, dass mans ich mit dem System näher beschäftigt (wie im ersten Punkt schon beschrieben)
  • “Kann das kein anderer tun?” (Zitat: Homer Simpson): Doch, denn on-premise bedeutet, dass man die volle Verantwortung trägt. Als Administrator, der für 200 Mitarbeiter zuständig ist und alles on-premise gehalten wird, ist man schnell so stark gefordert, dass viele wichtige Dinge nicht mehr gemacht werden (nur das nötigste geht gerade so) -> Ab in die Cloud.

Und sonst so? Es gibt Lösungen, die das versuchen. Ich persönlich schaue mir gerade Snyk.io etwas genauer an. Wer macht mit?

--

--

--

IT Sicherheit ist meist so komplex, dass im Business Alltag keine Zeit bleibt, sich damit im Detail zu befassen. Diese Publication ist für die gedacht, die sich darauf verlassen, dass sie einen kurzen Abriss zu aktuellen Bedrohungen erhalten, den sie auch verstehen.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andre Fritsche

Andre Fritsche

More from Medium

官方 | 深入了解存储提供商生态系统

Introduction to Axelar

Partnership between Axelar and Polygon

POLY NETWORK’S FAIRYTALE ENDING