Wenn es ein Thema schafft, in der Tagesschau, auf fast allen Nachrichtenseiten und auch beim Bundesamt für Sicherheit in der Informationstechnik (BSI) präsent zu sein, muss es sich schon um etwas Besonderes handeln – die Schwachstelle in der weit verbreiteten Javabibliothek „log4j“ hat dieses Kunststück geschafft.

Schwachstellen in Softwareprodukten sind keine Seltenheit. Sie werden entdeckt, meist schließt der Hersteller der Software die Lücke und stellt ein Update zur Verfügung, „business as usual“. Doch im Fall von „log4j“ ist es leider nicht so einfach …

Es beginnt damit, dass Java-Anwendungen meist als Paket bereitgestellt werden – und die problematische Bibliothek vom Hersteller in dem Paket mitgeliefert wird. Ein Update des betreffenden Betriebssystems allein reicht meist nicht, da die Java-Anwendung die mitgelieferte, problematische Version von log4j weiterhin nutzt und nicht etwa die aktualisierte Version des Betriebssystems. Mit anderen Worten: Betriebssystem aktualisieren allein reicht oft nicht aus, auch der Hersteller der Java-Anwendung muss eine Aktualisierung liefern.

… und zwar jeder Hersteller von Anwendungssoftware, die auf Java basiert und die „log4j“ einsetzt. Java ist weit verbreitet, und oftmals ist es für einen Anwender nicht einfach zu erkennen, ob diese Programmiersprache eingesetzt wird. Bei der enormen Masse an weltweit existierenden Anwendungen ist es schwer einzuschätzen, in wie vielen Produkten diese Schwachstelle schlummert. Und dann sind da ja noch die selbst entwickelten Java-Anwendungen, die man im Unternehmen einsetzt, … Viel Arbeit für die IT-Abteilungen.

Wenn es einem Angreifer gelingt, die Protokollinformationen auf seinen eigenen Server verweisen zu lassen, kann er bei der Interpretation des Protokolleintrags schädliche Informationen an die Java-Anwendung zurück liefern, welche dann ungefragt ausgeführt werden – und die Infektion ist geschehen. Ja, wirklich: Ohne Rückfrage, einfach so. Und vermutlich existiert diese Schwachstelle seit ca. 2016.

Was kann man gegen Log4j tun?

• Sich informieren. Das BSI stellt den aktuellen Erkenntnisstand auf seiner Webseite zur Verfügung. Mittlerweile gibt es auch ständig wachsende Übersichten, ob oder ob nicht populäre Produkte betroffen sind. Hier mal die von Github.
• Aufmerksam bleiben. Wir halten es für denkbar, dass die Berichterstattung und Paketaktualisierungen auch für Angriffe über Social Engineering und Phishing genutzt werden.
• Aktualisieren. Und zwar sowohl das Betriebssystem als auch die Java-Anwendungen, die eingesetzt werden – dazu muss der Hersteller der Java-Anwendung allerdings aktiv werden.
• Künftig die Risiken bei komplexen Softwarekonstellationen gründlicher abwägen. Aber das ist ein anderes Thema …

Was Sie auch interessieren könnte:

Seminar:

“Business Continuity Management (BCM) nach ISO 22301”

Weitere Seminare finden Sie unter https://anmatho.de/seminare diese können Sie auch als individuelles Inhouse-Seminar buchen. Sprechen Sie uns gern an KONTAKT.

Podcast:

Unser Podcast “Security on Air” beschäftigt sich mit den Themen Informationssicherheit und Datenschutz. In lockerer, informativer Form werden Sie zu allen Teilbereichen und gesetzlichen Neuerungen informiert. Sie finden uns auf “Apple Podcast”, “Spotify” und “Google Podcast” sowie natürlich auf unserer Website.

Hören Sie rein!