Das Problem mit Log4j hat auch unsere Entwickler:innen in den vergangenen Tagen beschäftigt und auf Trab gehalten. Jetzt, wo sich der erste Staub gelegt hat, nutzen wir diese Chance für ein Zwischenfazit. So viel vorweg: Wir haben schnell reagiert und aktuell keinerlei Grund zur Annahme, dass unsere Systeme erfolgreich angegriffen wurden. Hier ein detaillierter Überblick zur Situation:
Was ist eigentlich passiert?
Bis zum vergangenen Donnerstagabend war die Weste des Open-Source-Werkzeuges Log4j eine vergleichsweise weiße. Vor 21 Jahren zum ersten Mal veröffentlicht, hat sich das kleine Stück Software zur Standardanwendung bei Firmen, Behörden und technikaffinen Privatpersonen im Umfeld der Programmiersprache Java entwickelt. Dementsprechend ist es in der IT-Landschaft ziemlich weit verbreitet. Die Bibliothek Log4j hilft Menschen in IT-Abteilungen zu beobachten, was in den verschiedenen auf Java-Technik basierenden Programmen auf ihren Servern passiert.
Die Log4j-Welt schien in allerbester Ordnung. Doch dann wurde das, was in den Tagen zuvor noch etwas nebulös durch die IT-Foren dieser Welt geisterte, Gewissheit: Log4j kann ein weit geöffnetes Einfallstor für Angreifer:innen sein. Dadurch, dass Log4j nicht nur protokolliert, sondern auch interpretiert, haben Hacker die Möglichkeit, Informationen von z. B Servern abzugreifen. Und sie können im Extremfall auch Befehle auf Servern ausführen lassen und Netzwerke kapern. Wer mehr zu den technischen Hintergründen erfahren will, kann das in diesem Heise-Artikel und in diesem Dokument des Bundesamtes für Sicherheit in der Informationstechnik nachlesen.
“Extrem kritische IT-Sicherheitslage”
Die Sicherheitslücke ist derart groß, dass sich das Bundesamt für IT-Sicherheit genötigt sah, eine “extrem kritische IT-Sicherheitslage” auszurufen. Angreifer:innen scannen seit einigen Tagen weltweit flächendeckend Server und Software im Netz und suchen die Stellen, wo sie sich einnisten können. Und sie werden an etlichen Stellen fündig. Das Perfide dabei: Der wirklich verursachte Schaden tritt oftmals erst später in Erscheinung. Die Angriffstaktik ist dabei traditionell die gleiche: Erst unbemerkt Zugriffe verschaffen, um sich dann leise und unauffällig Stück für Stück voran zu arbeiten. Im Idealfall gibt es Beute in Form von Daten oder sogar der Übernahme größerer Teile des Netzwerkes.
Was haben wir getan?
Angreifer:innen bekommen nicht einfach so Zugriff auf unsere Server. Wir arbeiten mit einem komplexen System aus Firewalls und weiteren Sicherheitsmaßnahmen, um unsere Strukturen zu schützen. Aber klar, auch wir mussten handeln. Als sich Donnerstagabend abzeichnete, wie groß das Problem wirklich ist, wurden schnell Pläne geschmiedet, die dann ab dem frühen Freitagmorgen von einer 12-köpfigen Taskforce in die Tat umgesetzt wurden. Für alle bei sipgate angestellten Entwickler:innen hieß es dann am Montagmorgen: “stop ‘n fix”. Im Klartext: Die eigentlichen Pläne für den Tag wurden zu den Akten gelegt und sich mit kompletter Power dem Problem gewidmet.
Wir mussten am Freitagmorgen als Erstes herausbekommen, welche Systeme wie betroffen sind. Oberste Priorität hierbei: Alles, was nah an unseren Kund:innen ist. Dann wurde genau hingeschaut, wie gefährlich die Sicherheitslücken an welchen Stellen sind (“Was sind unsere verwundbaren Instanzen mit der Log4j-Bibliothek?”) und eine Priorisierungsliste erarbeitet. Mit dieser Liste in der Hand ging es dann für unsere Teams ans Updaten. Denn die Donnerstagnacht um 23.45 Uhr geshippte Version log4j 2.15.0 ist die gefixte und vom Einfallstor bereinigte. Auf diese Version wurden und werden unsere Systeme aktualisiert. Dazu wurden an Stellen, an denen ein Update nicht möglich ist, Einstellungen angepasst. Zudem haben wir externe Anbieter, die bei uns Software betreiben, kontaktiert und aufgefordert, problematische Stellen zu identifizieren und zu reparieren. Bisher haben wir insgesamt 140 Systeme angeschaut und repariert.
Gab es schon Angriffe?
Wir mussten herausfinden, ob sich ein früh aufgestandener Angreifertrupp schon an unseren Systemen versucht hat. Also haben wir uns an die Detektivarbeit begeben, haufenweise Logs gescannt und unsere Systeme auf Verhaltensanomalien untersucht. Unser (vorläufiges) Ergebnis: Es gab und gibt eine Reihe von erfolglosen Angriffen auf unsere Systeme. Offensichtlich hat das schnelle und gründliche Eingreifen unserer Entwickler:innen aber jeglichen Schaden abgewendet. Dennoch lehnen wir uns natürlich nicht zurück und bleiben wachsam.
Keine Kommentare