Blog

Was wir aus Log4Shell und ähnlichen Zero-Day Attacken lernen können

/ Kategorie: Threat Intelligence

Spätestens seit dem 10. Dezember kennt die ganze Welt ein kleines Stück Programmcode, welches bisher bestenfalls nur Entwicklern und Systemadministratoren ein Begriff war: Log4j. Die unerwartet grosse Bekanntheit verdankt das Softwareteilchen einer schweren kritischen Sicherheitslücke namens Log4Shell, die viele Versionen der Apache Log4j Anwendung betrifft, und die an diesem Tag öffentlich bekannt wurde. Experten bezeichnen Log4Shell als die grösste und kritischste Schwachstelle aller Zeiten.

ISPIN Blog - Log4J Lessons learned

Log4j steht für Logging for Java. Eingesetzt wird es von vielen Entwicklern, die in der Programmiersprache Java Software entwickeln. Der Baustein Log4j ist dazu da, ein Protokoll aller Prozesse zu erstellen, die bei der Anwendung einer Software ablaufen. Was ist im Dezember passiert? Eine bisher unbekannte Schwachstelle wurde öffentlich. Das Problem dabei: Log4j wird millionenfach in Systemen und Anwendungen eingesetzt. In vielen Fällen betrifft es Komponenten, die zudem direkt aus dem Internet erreichbar sind. Dementsprechend haben verschiedene Actor Groups begonnen, die Welt nach diesen Schwachstellen abzusuchen. Sie liefern sich nun ein Wettrennen mit den Securityteams, welche die betroffenen Systeme aktualisieren, um diese Schwachstelle so rasch wie möglich zu beheben. Eine stetig aktualisierte Liste mit betroffenen Produkten ist auf der Plattform Github einsehbar. 

Rekordjahr 2021

Dieser Vorgang ist in der Fachwelt grundsätzlich unter dem Begriff Zero-Day Schwachstelle bzw. Zero-Day Attacke bekannt. Es handelt sich hier nicht um aussergewöhnliche Einzelfälle. Mittlerweile sind Zero-Day Schwachstellen eher zu einer regelmässigen Erscheinung geworden. Was jedoch auch klar ist: Das Jahr 2021 war in Sachen Zero-Day Vulnerability ein Rekordjahr.

Dies hat primär zwei Ursachen. Einerseits wurden noch nie so viele Schwachstellen gemeldet. Anderseits wird die Zeitspanne zwischen dem Bekanntwerden einer Schwachstelle bis zu ihrem aktiven Ausnutzen (Exploitation) immer kürzer. Im Fall Log4j waren es gerade mal wenige Stunden. Das stellt die Security- und Sys-Admin Teams vor eine fast unlösbare Aufgabe. Diese Zeit reicht häufig nicht aus, um alle verwundbaren Systeme rechtzeitig zu aktualisieren.

Das sieht im ersten Moment nach einem verlorenen Kampf für die Securityteams aus. Auf jeden Fall erfordert der Umgang mit Schwachstellen ein Umdenken. Der Kampf ist jedoch auf keinen Fall verloren. Dazu müssen wir uns das kleine Einmaleins des Risikomanagements in Erinnerung rufen.

Andere Priorisierung von Zero-Day Schwachstellen

Demnach entsteht ein Risiko, wenn eine gegebene Gefahr (Threat) auf eine entsprechend exponierte (Exposure) Schwachstelle (Vulnerability) trifft. Auf die Threat Actors und auf die Schwachstellen haben wir dabei wenig Einfluss. Allerdings können wir das Exposure der Schwachstellen massgeblich steuern. Und wenn es uns gelingt, das Exposure einer Schwachstelle im Griff zu haben, dann sinkt auch das gesamte Risiko signifikant. Im Fall von Log4j (und den meisten anderen Zero-Day Schwachstellen) bedeutet das: Wenn es gelingt, die Schwachstelle vom direkten Zugriff von ausserhalb meiner Organisation fernzuhalten, dann sinkt das Risiko deutlich und die Verantwortlichen gewinnen Zeit, die Schwachstelle in Ruhe zu beheben. Dieses Problem ist mittlerweile auch den Behörden bewusst geworden. So hat die US Cyber Infrastructure and Security Agency (CISA) Anfang Dezember erstmals eine Direktive erlassen, welche die Schwachstellen nicht mehr nach Kritikalität, sondern nach der aktiven Ausnutzung (Actively exploited) durch Threat Actors priorisiert.

Technisch lässt sich das am besten umsetzen, indem man die Zahl der von aussen sichtbaren (exponierten) Systeme grundsätzlich möglichst klein hält und zudem hinter entsprechende Proxy (bspw. Web Application Firewalls und/oder IDS/IDPs) platziert. Diese Systeme erlauben es zudem, auch temporäre Schutz- und/oder Erkennungsmassnahmen zu implementieren, selbst wenn noch kein offizieller Patch des Herstellers zur Behebung der eigentlichen Schwachstelle verfügbar ist. Zwar können, wie im Fall von Log4j, auch diese Komponenten von Zero-Day Schwachstellen betroffen sein, jedoch lässt sich diese begrenzte

Die richtigen Schlüsse ziehen

Die finalen Auswirkungen des Log4Shell-Exploits sind noch längst nicht bekannt. Security-Verantwortliche können und sollten diese Erfahrung aber als Gelegenheit nutzen, um ihre Sicherheitsstrategien und -massnahmen zu überprüfen und zu optimieren. Denn letztlich ist klar: Jede Organisation kann jederzeit von einer Sicherheitsverletzung betroffen sein. Daher ist es eine unvermeidbare Notwendigkeit, das Unternehmen auf Cyberangriffe und Erpressungssituationen vorzubereiten. Zudem ist es wichtig, zu trainieren, wie mit so einer Situation umgegangen werden kann, wenn sie eintritt – und zwar so, als würde sie tatsächlich eintreten.

Zusammen. Sicher.

Ist Ihr Unternehmen ausreichend vorbereitet? Haben Sie die Antworten auf Fragen wie «Zahlen wir das Lösegeld?», «Sagen wir der Öffentlichkeit, was passiert ist?», «Schalten wir die betroffenen Server ab?» parat? Reichen Ihre Schutzmassnahmen aus? Wir unterstützen Sie gerne. Nehmen Sie Kontakt auf und profitieren Sie von unserer Erfahrung.
Kontaktieren Sie uns via cybersecurity[at]ispin.ch oder +41 44 838 3111.

 

Sie haben einen Security-Notfall und brauchen Hilfe? Unser Incident Response Team ist 7x24 für Sie da.
Incident melden!