Log4j betrifft uns alle – auch Sie
von | veröffentlicht am
Derzeit herrscht kein Mangel an Nachrichten zu Angriffen über Log4j. Das ist gut so. Schnelle und sichtbare Warnungen, verfügbare Hilfen bei der Entdeckung und eine aktive Gemeinschaft von Experten sind der Schlüssel zur Abwehr. Selten wurde so schnell und konzertiert reagiert, vor allem mit Blick auf Unternehmen, gut organisierte IT Abteilungen und deren Web Anwendungen.
Ein Aspekt kommt mir aktuell aber deutlich zu kurz: Angriffe über Log4j fordern uns alle heraus, auch Sie, auch als Privatperson. Warum? Drei Schlagworte:
Verbreitung
Aktuelle Hinweise und Abwehrmaßnahmen fokussieren auf leicht erreichbare Ziele von hohem Wert, also große Server Anwendungen mit sensiblen Daten. Java hat aber wegen der Plattformunabhängigkeit eine extrem hohe Verbreitung in allen Bereichen gefunden, vor allem in „Geräten“. Dazu gehören Multimedia Systeme im Besprechungsraum, Multifunktions-Drucker, Netzwerkausrüstung und eine Vielzahl von IoT Geräten wie Klimaanlagen und Belegungsmelder. Das gilt auch für das Home Office, dort ergänzt durch Smart-TVs, Multimediasysteme und Spielzeug. Oft werden diese Geräte nicht mit der gleichen Akribie verwaltet und aktualisiert wie offensichtlich „relevante“ Systeme. In vielen Fällen ist das mangels Herstellersupport auch gar nicht mehr möglich. Nicht in jeder Java Anwendung wird auch Log4j genutzt, aber selbst Geräte-Hersteĺler können derzeit kaum verbindliche Aussagen machen.
Schauen Sie daher nach aktueller Software für alle ihre Geräte und deaktivieren Sie nicht benötigte Funktionen. Scannen Sie auch Geräte, die Sie als harmlos einstufen, nach gängigen Schwachstellen. Überlegen Sie sich auch, mal ein Gerät aus Sicherheitsgründen auszusortieren. Es kann sich lohnen, im Sinne des Wortes.
Einfacher Zugriff
Angriffe auf Log4j können sehr einfach durchgeführt werden. Gerade wurde u.a. eine Möglichkeit des Zugangs über WebSockets bekannt. So kann unter ungünstigen Umständen bereits das Browsen einer präparierten WebSite den Angriff auf ein System im Netz des Browsers ermöglichen. Vielleicht nur auf ein Multimedia Gerät, aber eventuell eben auch auf die interne Kundendatenbank.
Dabei müssen Sie oder ihr Unternehmen gar nicht unbedingt das Ziel sein, können aber trotzdem sehr schnell zum Opfer werden. Nur weil Sie zufällig auf ein (evtl. durch Log4j) kompromittiertes System geraten.
Achten Sie auch in vermeintlich sicheren Netzen und auf vermeintlich sicheren Websites auf ungewöhnliches Verhalten.
Indirekte Angriffe
Es haben bereits erfolgreiche Angriffe stattgefunden. Auf Systeme, die sensible, für Phishing nutzbare Daten speichern. Auf Systeme – und das macht mich persönlich nervös – die Software für andere Systeme verwalten und bereitstellen. Ich gehe davon aus, dass bereits das eine oder andere Hintertürchen platziert wurde, bereit für den Einsatz zu einem passenden Zeitpunkt.
Ich werde jedenfalls nicht nur bei der nächsten Installation eines Software Plugins, eines Firmware Updates oder Erhalt der nächsten „Versandbestätigung“ per eMail deutlich genauer hinsehen. Das sollten Sie auch.
Noch ein Gedanke
Die aktuell kritische „Funktion“ in Log4j stammt aus einer Zeit, in der Funktion oberste Maxime war. Der Gedanke, quasi beliebigen Code einfach per Nachricht an einen Server zur Ausführung zu schicken, wurde schon damals aus dem Blickwinkel der Sicherheit sehr kontrovers diskutiert, nicht nur bei Log4j. „Funktion“ hat gewonnen.
Wir brauchen einen Wandel in der Grundeinstellung. Eine Risikoabwägung muss auch bei vermeintlich harmlosen Systemen Bestandteil der Produktentwicklung, Sicherheit muss integraler Bestandteil der Lösung werden. Built in, not bolt on. Es „funktioniert“ erst, wenn es sicher ist!
In Java gesagt: if (securityscore <= 0.99) { capability = false; }
Das ist doch selbstverständlich, meinen Sie? Es steht bereits in allen Richtlinien? Stimmt. Allerdings sehen wir die Ergebnisse jeden Tag.