stackable-blog-header-blau-laptop

Wie wir mit den Risiken von Log4Shell umgehen

Hintergrund

Es ist schon eine Weile her, seit die letzten hochkarätigen Schwachstellen wie Heartbleed oder die Rowhammer-Familie veröffentlicht wurden. Doch am vergangenen Freitag machte ein weiterer Exploit internationale Schlagzeilen: CVE-2021-44228 oder besser bekannt als Log4Shell.

Dieser Exploit fällt in die Kategorie der nicht authentifizierten Remote Code Execution (RCE), sodass Angreifer aus der Ferne beliebigen Code ausführen können. Dieser Exploit ist deshalb besonders schlimm, weil die betroffene Software log4j das gängigste Logging-Framework in der Java-Welt ist und so ziemlich überall präsent ist.

Abgesehen davon, dass log4j allgegenwärtig ist, benötigen Angreifer auch keinen speziellen Zugriff auf die Zielanwendung, sondern es genügt, einfach eine benutzerdefinierte Zeichenfolge protokollieren zu lassen. Das kann zum Beispiel beim Besuch einer Website passieren, wenn der Webserver den User-Agent des Browsers beim im Access-Log protokolliert.

Weitere Informationen zu diesem Exploit finden sich unter https://www.lunasec.io/docs/blog/log4j-zero-day

Abwehrmaßnahmen

Das Problem in solchen Fällen ist normalerweise nicht das Warten auf ein Bug-Fix-Release des betroffenen Produkts – in diesem Fall log4j –, sondern die Zeit, die dieses Release benötigt, um durch den gesamten Software-Stack zu rieseln, bis es auch die letzte betroffene Komponente erreicht hat.

Daher versuchen gerade viele Unternehmen, die Software anbieten, die von log4j abhängig ist, so schnell wie möglich vorläufige Fixes für den Zeitraum bereitzustellen, bis schließlich alle erforderlichen Upstream-Releases verfügbar sind.

Die meisten Tools, die von der Stackable-Plattform verwaltet werden, sind in Java geschrieben, daher sind einige von ihnen auch anfällig für den Exploit und wir haben sofort nach einer Lösung für unsere Kunden gesucht.

Da wir unsere Software containerisiert ausliefern, haben wir di Möglichkeit, beim Build-Prozess unserer Container Schritte hinzuzufügen, mit denen wir auch die Laufzeitumgebung – also die jeweiligen Container – beeinflussen können. Dies ermöglicht uns ein hohes Maß an Flexibilität im Umgang mit solchen Situationen.

Da wir die Containerversion unabhängig von der aktuellen Produktversion verwalten, können wir den Container aktualisieren, ohne die Version des im Container ausgeführten Produkts zu ändern. Dadurch konnten unsere Kunden unabhängig von der aktuell ausgeführten Version einfach einen rollierenden Neustart ihrer Dienste durchführen und sie mit einer neuen Version, in der der Exploit nach den aktuellen Best Practices behoben worden ist, wieder hochfahren lassen.

Als ersten Schritt haben wir einfach allen unseren Dockerfiles eine Umgebungsvariable hinzugefügt, die die anfällige Funktionalität in unterstützten Versionen von log4j (> 2.15) deaktiviert. Dies behebt jedoch einerseits nur spätere Versionen von log4j, und selbst dann ist es kein perfekter Fix, wie eine nachfolgende CVE-2021-45046 zeigt, die diesen Parameter betrifft.

Also sind wir noch einen Schritt weiter gegangen und haben uns nach einigen Recherchen für einen Weg entschieden, der auf einer Lösung basiert, die Cloudera ihren Benutzern empfohlen hat.

Sie stellen ein Skript bereit, das alle Pfade durchläuft, von denen bekannt ist, dass sie Java-Bibliotheken für die von Cloudera unterstützten Plattformen enthalten, jede einzelne JAR-Datei auf die anfällige .class-Datei überprüft und diese Datei entfernt.

Dies ist eine schnelle und durchaus praktikable Lösung, sie hat jedoch unter anderem insbesondere den Nachteil, dass das die von der Plattform verteilte Software verändert. Das bedeutet, dass diese Änderungen bei jedem nachfolgenden Update oder sogar beim Hinzufügen weiterer Server zum System überschrieben werden und das Problem erneut auftritt und behoben werden muss.

Wir haben uns daher entschieden, eine angepasste Version dieses Skripts unmittelbar in unseren Container-Build-Prozess zu integrieren, damit alle Container-Images, die als Teil unserer Plattform ausgeliefert werden, automatisiert vom anfälligen Code bereinigt werden.

Wir werden die Situation in Zukunft genau beobachten und bei Bedarf zusätzliche Maßnahmen ergreifen, um die Sicherheit unserer Plattform durchgängig zu gewährleisten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© Stackable.