LogJ4 betrifft Hälfte aller deutschen Firmen-Netzwerke

LogJ4 zieht immer weitere Kreise. Die Sicherheitsforscher von Check Point Research (CPR), der Forschungsabteilung von Check Point® Software Technologies Ltd. (NASDAQ: CHKP), untersuchen intensiv die LogJ4-Schwachstelle in Java, die derzeit für Schlagzeilen sorgt. Die wichtigsten Erkenntnisse für Deutschland:

• In Deutschland wurden 45 Prozent aller von Check Point erfassten Firmen-Netzwerke attackiert.
• In Österreich beläuft sich die Zahl auf 46 Prozent, in der Schweiz auf 40 Prozent.
• Weltweit liegt der Schnitt bei 40 Prozent. In Europa bei 42,2 Prozent.
• Einmal registrieren die Sicherheitsforscher sogar 100 Attacken in der Minute.
• Mittlerweile hat Check Point rund 846 000 Angriffe registriert, 72 Stunden nach der ersten Attacke.
• 46 Prozent der Attacken gingen von bekannten Hacker-Gruppen aus.
• Nach 72 Stunden gab es bereits über 60 neue Varianten der Attacke.

Lotem Finkelstein, Head of Threat Intelligence bei Check Point Software, erklärt: „Es handelt sich um eine der schwerwiegendsten Sicherheitslücken der letzten Jahre, die sich wie ein Lauffeuer verbreitet. Zu einem bestimmten Zeitpunkt gab es über 100 Attacken in der Minute im Zusammenhang mit der Log4J-Schwachstelle. Es scheint sich um eine evolutionäre Kampagne zu handeln, da in kürzester Zeit neue Varianten der ursprünglichen Attacke eingeführt wurden – über 60 in 72 Stunden. Diese Vielfalt der Kombinationen, wie die Schwachstelle ausgenutzt werden kann, gibt dem Angreifer viele Möglichkeiten, neu eingeführte Schutzmaßnahmen zu umgehen. Das bedeutet, dass eine Schutzschicht nicht ausreicht und nur eine mehrschichtige Sicherheitsarchitektur eine widerstandsfähige Abwehr bietet.

Im Gegensatz zu anderen großen IT-Angriffen, die eine oder eine begrenzte Anzahl von Software betreffen, ist Log4J im Grunde in jedes Java-basierte Produkt oder jeden Java-basierten Web-Dienst eingebettet. Es ist sehr schwierig, sie manuell zu beheben. Sobald eine Untersuchung veröffentlicht worden war (in diesem Fall am vergangenen Freitag), wurde das Internet durchforstet, um die durch diesen Vorfall verwundbaren Oberflächen zu bestimmen. Diejenigen, die keinen Schutz implementieren wollen, werden wahrscheinlich bereits von Hackern geprüft. Wir haben bereits über 846 000 Angriffe dokumentiert, die über 40 Prozent der Unternehmensnetze weltweit angegriffen haben.

Sicher ist: Diese Schwachstelle wird uns aufgrund der Komplexität ihrer Behebung und der Einfachheit, mit der sie ausgenutzt werden kann, jahrelang begleiten – es sei denn, Unternehmen und Dienste ergreifen sofort Maßnahmen, um Angriffe auf ihre Produkte durch die Implementierung eines wirksamen Schutzes zu verhindern. Besonders in der Urlaubszeit, wenn IT-Sicherheitsabteilungen langsamer arbeiten, ist das wichtig.“

Ransomware transportiert

Am gestrigen Dienstag meldeten IT-Sicherheitsexperten, dass die erste Ransomware-Gruppe entdeckt wurde, die Log4Shell nutzt. Die dort genutzte Ransomware mit dem Namen Khonsari ist weit davon entfernt, sich zu einer großen Kampagne zu entwickeln, da sie von Fachleuten als einfache „Skidware“ (Skript-Kiddie-Software) eingeordnet wird, die leicht zu bekämpfen sei. Die Ransomware ist jedoch funktionsfähig und kann – wenn sie nicht rechtzeitig gestoppt wird – Dateien verschlüsseln.

Amit Yoran, Chairman und CEO von Tenable meint dazu:

„Genau wie wir gewarnt haben, bringt die Log4Shell -Schwachstelle jetzt Unternehmen überall in der Welt in Bedrängnis. Und das Schlimmste steht noch bevor, wenn die Unternehmen nicht sofort Maßnahmen ergreifen. IT-Sicherheitsforscher beobachten bereits Ransomware-Aktivitäten, bei denen Cyberkriminelle Log4Shell in ihren Playbooks einsetzen. Ich möchte klarstellen, dass diese Ransomware-Aktivitäten definitiv nicht verschwinden werden. Sie werden wie ein Lauffeuer zunehmen, auch dank dieser neuen, perfekten Gelegenheit in Form von Log4Shell. Unternehmen müssen schnell und entschieden handeln, da Log4Shell ihre vorhandene Sicherheitsstrategie vollständig untergraben kann und wird. Kein Sicherheitsprodukt eines Anbieters ist ein Allheilmittel, um dieses Problem komplett zu lösen. Die Beseitigung der von Log4Shell ausgehenden Bedrohungen erfordert harte Arbeit und Zeit, um diese Schwachstelle zu verstehen und herauszufinden, wie sie sich im Laufe der Zeit verändert und weiterentwickelt, um Schutzmaßnahmen zu umgehen.“

Wer sich auf Prävention verlässt, der ist verlassen

„Die Unvorhersehbarkeit und Durchschlagskraft von Sicherheitslücken wie Log4j ist ein weiterer drastischer Beleg, dass Prävention und Patches nicht ausreichen. Sicherheitsteams benötigen Detection and Response – also die Möglichkeit zur automatisierten Erkennung von Angriffen und die Fähigkeiten zur schnellen Reaktion“, erklärt Andreas Riepen, Head of Central & Eastern Europe (CEE) beim IT-Sicherheitsanbieter Vectra AI.

Andreas Riepen nennt hierzu einige Fakten:

1. Es ist unmöglich, alles mit Dringlichkeit zu patchen:Die Angriffsfläche ist sehr groß. Das betroffene Modul von Log4j wird von einer Vielzahl von Software und Produkten verwendet. Es ist schon schwierig, herauszufinden, wo es verwendet wird! Ganz zu schweigen von dem Versuch, es zu patchen. Außerdem sind Unternehmen von den Herstellern abhängig, die ihnen Patches für ihre Produkte zur Verfügung stellen. Bei einigen werden sie sehr lange warten müssen und wahrscheinlich nie 100 Prozent erreichen.
2. EDR (Endpoint Detection & Response) kann weder den ersten Exploit stoppen, noch kann es eine vollständige Abdeckung bieten:Alle EDR-Anbieter sprechen davon, nach dem Download oder dem Verhalten nach der Ausnutzung zu suchen. Außerdem betrifft dies eine Vielzahl von Tools und Produkten, auf denen kein EDR installiert werden kann – Router, Switches, Sicherheitsprodukte, Linux-Server etc.
3. SIEM () ist nicht geeignet, um danach zu suchen:Es ist nicht garantiert, dass jede Anwendung die Felder protokolliert, in denen der Exploit-String zu sehen ist. Außerdem gelangen nicht alle Protokolle von jeder Anwendung in das SIEM. Man kann nicht suchen, was man nicht sehen kann.
4. Schnelle Entwicklung:Der Angriff entwickelt sich schnell weiter. Angreifer werden dies auf vielerlei Weise nutzen. Es gibt bereits Versuche der Verschleierung, die an grundlegenden Signaturen vorbeigehen, um nach dem Exploit-String zu suchen.

Riepen rät Unternehmen daher: „Gehen Sie davon aus, dass Systeme kompromittiert sind, und seien Sie darauf vorbereitet, den Angriff in Echtzeit zu erkennen und darauf zu reagieren. Schließen Sie die EDR-Lücke und überwachen Sie zuverlässig jede Verbindung vom Netzwerk zur Cloud. Recall- und Stream-Daten können dabei helfen, jeden Versuch, dies auszunutzen, schnell zu erkennen. Moderne KI-Modelle für Cybersicherheit sind so konzipiert, dass sie die Methoden erkennen, die Angreifer nach einer Kompromittierung anwenden würden. Darüber hinaus kann ein KI-basierter Überwachungsansatz die Bedrohung durch die Ausnutzung dieser Schwachstelle am schnellsten erkennen und entschärfen. Aus den oben genannten Gründen ist dies weder mit Prävention noch mit Patching zu leisten. Für Unternehmen, die sich absichern und das Risiko mindern wollen, ist eine automatisierte und kontinuierliche Überwachung des Datenflusses die beste Investition, die sie tätigen können.“

Argumente für Software Supply Chain Management

Die kritische Bedrohung durch die Log4Shell-Schwachstelle erfordert natürlich eine sofortige Reaktion. Doch im zweiten Schritt müssen sich Unternehmen generell Fragen zu Prozessen rund um Software-Lieferketten und dokumentierte (?) Abhängigkeiten stellen, erklärt  Udo Schneider, IoT Security Evangelist Europe bei Trend Micro.

Die vor ein paar Tagen bekannt gewordene Log4Shell-Sicherheitslücke ist gerade in aller Munde und hält die Sicherheitsfachleute weltweit auf Trab. Das BSI spricht von einer „extrem kritischen Bedrohungslage“, denn die angreifbare Log4J-Bibliothek ist gewissermaßen „der“ Log-Standard in Java-Umgebungen. Dementsprechend wird sie auch in tausenden von Applikationen und Internet-Diensten genutzt. Hinzu kommt, dass die Lücke einfach zu missbrauchen ist und in vielen Fällen aus der Ferne ausgenutzt werden kann, wobei sie letztendlich die Ausführung beliebiger Kommandos erlaubt. Aus Cybersecurity-Sicht ein wahrer Albtraum! Unternehmen können als unmittelbare Reaktion unseren detaillierten Empfehlungen folgen und vorhandene Patches aufspielen sowie Best Practices anwenden. Doch in einem zweiten Schritt sollten sie einen generellen Blick auf Prozesse rund um Software-Lieferketten werfen. Denn letztendlich ist auch Log4Shell, so sicherheitsrelevant die Lücke auch sein mag, „nur“ ein fehlerhafter Baustein in der Software-Lieferkette.

Um Software-Lieferketten und deren Kontext zu verstehen, hilft ein Blick auf die „reale“ Welt, etwa die Herstellung von Elektronikprodukten. Dabei sind so genannte „Stücklisten“ (BOM – Bill of Material) für Baugruppen gang und gäbe. Betrachtet man eine einzelne Platine als Baugruppe, so enthält die passende Stückliste eine Auflistung aller verwendeten Komponenten wie Widerstände, Kondensatoren, Dioden, ICs und vieles mehr. Zu jeder Komponente werden auch genaue Parameter, Hersteller, Preise, Bezugsquellen und letztendlich auch Seriennummern bzw. zumindest Chargeninformationen gespeichert.

Sollte es also vom Hersteller einer der Bauelemente eine Information geben, dass bestimmte Bauteile einer Charge z.B. nicht den spezifizierten Temperaturwerten entsprechen, so ist es möglich selbst im Nachhinein genau nachzuverfolgen, welche Platinen (mit jeweils eigener Seriennummer) davon a) betroffen sind und b) ob Handlungsbedarf entsteht. Müssen entsprechende Maßnahmen eingeleitet werden, hilft die Information, welche Baugruppen (aufgrund der Seriennummer) überhaupt betroffen sind natürlich massiv. Letztendlich setzt sich dieses Vorgehen mit „Baugruppen“ fast beliebig fort … bis man letztendlich eventuell bei massiven Installationen wie z.B. dem LHC am CERN landet. Selbst bei einer so großen Maschine kann der Fehler an einem winzigen SMD-Bauteil zum Versagen der gesamten Maschine führen. Werden also z.B. fehlerhafte Chargen bekannt, so muss man letztendlich in der Lage sein, jeden einzelnen verbauten Widerstand zu verifizieren.

Software Bill of Material (SBOM)

Genauso funktionieren auch Software-Lieferketten, also SBOMs“ — und ganz konkret zurück zu Log4Shell: Können Sie auf die Schnelle sagen, ob Sie von dieser Lücke betroffen sind? Bei eigener Software, die Log4J nutzt, lässt sich die Frage vielleicht noch schnell beantworten. Oft bieten sogar SCM-Dienste wie GitHub oder GitLab solche Funktionen direkt an. Was aber ist mit transienten Abhängigkeiten? Nutzt vielleicht eine bei Ihnen eingesetzte Bibliothek eines Drittanbieters intern Log4J? Oder noch schlimmer – nutzt eine Library, die Sie verwenden, eine Library, die wiederum von einer Library abhängt (usw.) die Log4J nutzt? Setzt die eingekaufte Software eines Dienstleisters auf Log4J? Verwendet ein Cloud-Dienst, den Sie einkaufen, Log4J?

Fragen über Fragen, die der Antworten bedürfen, für die Sie sich mit SBOMs auseinandersetzen müssen. Log4Shell führt sehr deutlich die Probleme vor Augen, die entstehen, wenn die Software-Lieferkette eben nicht dokumentiert ist. Aber lassen Sie sich nicht täuschen. Log4Shell ist gerade sicherlich eine Art Worst-Case-Szenario. Doch selbst bei einfachen „Fehlern“, die keine direkte Sicherheitsrelevanz haben, ist die Frage, ob man betroffen ist, von Bedeutung!

Abhängigkeiten dokumentieren

Grundsätzlich geht es bei SBOMs um die Dokumentation von Abhängigkeiten. Dies können Abhängigkeiten in Form von Software (Bestandteilen) sein aber auch Dienste, Lizenzen, Server und vieles mehr. Speziell bei der Modellierung von Softwareabhängigkeiten haben sich im Laufe der Zeit zwei Austauschformate herauskristallisiert: CycloneDX und SPDX. Beide erlauben die Beschreibung verschiedener Softwarekomponenten inkl. eventueller Abhängigkeiten:

Mit der Beschreibungssprache ist es aber nicht getan. Vielmehr muss die konkrete Umgebung ebenfalls beschrieben und auf aktuellem Stand gehalten werden. Natürlich lassen sich diese Beschreibungen manuell erstellen – und manchmal, z.B. bei der Abhängigkeit von externen Diensten, bleibt auch nichts anderes übrig. Wenn es aber um die Erstellung von Beschreibungen bei Software geht, sind manuelle Aufwände nicht sinnvoll. Hier muss die Erstellung und Pflege dieser Beschreibungen vollautomatisiert im Rahmen der CI/CD Pipeline stattfinden. Dabei gibt es grundsätzlich zwei Ansätze: Die Einbindung in den Build-Prozess und das Scannen von Build-Artefakten.

CI/CD Einbindung – Build-Prozess

Sowohl bei CycloneDX als auch bei SPDX gibt es Werkzeuge, die sich direkt in den Build-Prozess integrieren lassen. Diese extrahieren direkt „an der Quelle“ (transiente) Abhängigkeiten. Dies können Libraries, ausführbare Dateien aber auch Container bzw. Container-Layer sein. Die direkte Einbindung erlaubt es auch, Abhängigkeiten zu verfolgen, die z.B. nur während des Builds selbst, aber nicht im fertigen Produkt bestehen.

CI/CD Einbindung – Build Artefakt

Selbst wenn nicht direkt in den Build Prozess eingegriffen werden soll darf, gibt es für CycloneDX und SPDX Werkzeuge, die „im Nachhinein“ das Endergebnis scannen. D.h. diese Werkzeuge extrahieren z.B. aus der Java Anwendung die Abhängigkeiten und dokumentieren diese. Da diese Werkzeuge immer nur das fertige Ergebnis sehen, kann es aber durchaus sein, dass einige Abhängigkeiten schlichtweg übersehen werden, da diese sich aus dem Endergebnis nicht mehr erschließen lassen.

Schwachstellen-Monitoring

Für Unternehmen, die ausschließlich an einem Schwachstellen-Monitoring interessiert sind, bieten viele dieser Werkzeuge auch eine direkte Korrelation mit Schwachstellen-Datenbanken an. Das bedeutet, dass die Ausgabe nicht nur die gefundenen Komponenten enthält, sondern auch gleich eine Liste von Verwundbarkeiten. Dies ist z.B. vergleichbar mit der Einbindung von snyk, Trend Micro Application Security oder Trend Micro Container Security in die CI/CD Pipeline.

OWASP Dependency Track

Wenn auch die Nachverfolgung und Dokumentation von Lizenzen, Inventar oder Verbreitungsgrad eine Rolle spielen, so bieten sich andere Lösungen (zusätzlich) an. In diesem Umfeld ist das Dependency Track-Tool der OWASP (Open Web Application Security Project) sicherlich einer der Platzhirschen. Als Open Source-Lösung ist es in der Regel in CI/CD Pipelines integriert und erhält dort SBOM-Daten – entweder über CycloneDX/SPDX Daten (manuell, API) oder direkt aus dem Build Prozess. Zusätzlich hält Dependency Track automatisiert Verwundbarkeitsdaten aus verschiedenen Schwachstellen-Datenbanken vor und korreliert laufend die Daten aus (historischen) Builds und Verwundbarkeiten. Matches werden entsprechend in einem Dashboard angezeigt oder direkt via Chat und CI/CD Integration gemeldet bzw. optional auch an Werkzeuge zur automatischen Behebung weitergeleitet.

Dependency Track stellt also eine Datenbank dar, mit der sich die Frage: „Wo bin ich von Log4Shell betroffen“ einfach beantworten lässt. Diese Antwort umfasst nicht nur aktuelle Versionen der Software, vielmehr werden auch Beschreibungen alter Version vorgehalten. Eine mögliche Erkenntnis kann also sein, dass ein Unternehmen in der aktuellen Version nicht betroffen ist (da ausreichend gepatcht), 34 ältere Versionen aber betroffen sind. Wenn man nun auch noch Informationen über die Anzahl der installierten Versionen mit verfolgt, sind das nahezu perfekte Daten für eine fundierte Risikobetrachtung.

Fazit

Letztendlich ist es wichtig, die eingangs gestellten Fragen beantworten zu können: Nutzen wir (direkt oder in unserer Software-Lieferkette) Log4J? Wenn ja, in welchem Ausmaß (Version, Verbreitung) sind wir von Log4Shell betroffen? Der Aufwand zur Beantwortung dieser Frage stellt einen Gradmesser dar, inwiefern Sie Einblick in Ihre Software-Lieferkette haben, bzw. ob es sich lohnt, dort mit Werkzeugen nachzuhelfen.

Bezüglich der Werkzeuge gilt es zu klären, ob es „nur“ um die Frage „bin ich betroffen“ geht. Ist dies der Fall, helfen Tools wie snyk oder die bei GitHub und GitLab integrierten Möglichkeiten schon weiter. Ist hingegen ein umfassenderer Einblick gewünscht, so bieten sich weitere Lösungen zum Erfassen und Katalogisieren von Software-Artefakten an. Diese gibt es sowohl kommerziell als auch kostenlos. Aus dem OpenSource-Lager ist Dependency Track hier sicherlich das am weitesten verbreitete.

Schlussendlich bleibt aber festzuhalten, dass Sicherheitslücken ein wichtiges Argument für Software Supply Chain Management ist – aber sicherlich nicht das einzige!