Log4j-Schwachstelle: Log4Shell

Die Sicherheitslücke erlaubt es Angreifern, beliebigen Code auf den die Java-Bibliothek Log4j verwendenden Servern auszuführen. Ausgelöst wird der Effekt durch Empfang und Protokollierung (Schreiben des Logs auf dem betroffenen Server) einer spezifisch ausgestalteten Zeichenkette, die u.a. eine unter Kontrolle des Angreifers stehende URL enthält. Der Server lädt anschließend automatisch den über die URL adressierten Code herunter und bringt diesen auf dem Log-Server zur Ausführung.

Solche Angriffe sind als „Remote Code Execution“ (RCE) bekannt. Da der Code auch ausführbar ist, ohne dass sich die Angreifer an den jeweiligen Systemen authentifizieren müssen, geht von diesem Angriff ein sehr hohes Schadenspotenzial aus. Es gibt bereits einen Patch zur Behebung der Schwachstelle für die Bibliothek, welcher so schnell wie möglich installiert werden sollte. Unter Umständen sind auch Systeme gefährdet, auf denen Java-Applikationen betrieben werden, welche die von Log4j verzeichneten Nachrichten verarbeiten. Daher sollte für alle Java-Applikationen umgehend und sorgfältig nach Sicherheitsupdates gesucht werden bzw. gezielte Abwehrmaßnahmen ergriffen werden.

Gegenwärtige Situation

Die Bibliothek Log4j ist eine Logging-Bibliothek. Mit ihr werden also Ereignisse, die ein System wie z. B. einen Server betreffen, aufgezeichnet. Sie wird von einer Vielzahl von Firmen und Produkten verwendet, dementsprechend besteht die Möglichkeit einer akuten Gefährdung zahlreicher Unternehmen, in denen diese Produkte verwendet werden. Das genaue Ausmaß der Bedrohungslage ist aktuell noch nicht feststellbar, da keine vollumfängliche Liste von Produkten, die Log4j verwenden, existiert. Aktuell werden Listen derartiger Produkte zusammengestellt. 

Dem Bedrohungsgrad der Schwachstelle wurde ein CVSS-Wert von 10.0, dem höchstmöglichen Wert, zugewiesen. Da die Angriffe ohne Authentifizierung stattfinden und Angreifer u.a. in der Lage sein könnten, Hintertüren in Systeme einzuschleusen, besteht die Gefahr, dass die Sicherheitslücke zunächst nur dazu genutzt wird, um weiterführende Angriffe vorzubereiten. Bleiben erfolgreiche Angriffe über die hier beschriebene Sicherheitslücke unerkannt, kann es für betroffene Unternehmen erst in Wochen oder gar Monaten dazu kommen, dass diese mit den Folgen eines Cyber-Angriffes konfrontiert werden. Die Angreifer haben dann in der Regel die Zwischenzeit genutzt, um das Unternehmensumfeld bestmöglich und unerkannt auszuspionieren (Identifikation der IT-Assets, Übernahme der Domänen-Controller, Abzug von Daten, Manipulation der Backups, Vorbereitung eines flächendeckenden Ransomware-Angriffs).

Ab wann genau die Sicherheitslücke Angreifern bekannt war, ist ebenfalls nicht bekannt. Medienberichten zufolge gibt es aber Hinweise auf Ausnutzung der Schwachstelle schon ab dem 01. Dezember 2021.

Allgemeine Handlungsempfehlungen

Sicherheits-Updates für Log4j sind verfügbar und sollten so schnell wie möglich installiert werden: Version 2.17 ist nicht mehr gegen den Angriff verwundbar. Für alle Java-Applikationen, die diese Bibliothek möglicherweise einsetzen, sollten ebenfalls Sicherheitsupdates gesucht und bei Verfügbarkeit installiert werden. Das Risiko für Log4j-Versionen 1.x ist unter Umständen geringer, aber eine direkte Betroffenheit ist dennoch nicht auszuschließen. 

Sollte ein Update nicht möglich sein, sollte die Option „log4j2.formatMsgNoLookups“ auf „true“ gesetzt werden (Java Virtual Machine mit dem Argument „-Dlog4j2.formatMsgNoLookups=True“ starten oder Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf „true“ setzen – beide Maßnahmen sind allerdings erst ab Log4j-Version 2.10 möglich). Dies schränkt jedoch u.U. die Funktionsweise der Java-Applikation ein (BSI, S. 3)

Darüber hinaus sind die folgenden Sicherheitsmaßnahmen zu beachten: 

• Um einen Angriff zu verhindern, empfehlen wir, soweit möglich, die Trennung aller öffentlich erreichbaren Systeme vom Internet. Nach Prüfung dieser Systeme auf die verwundbare Bibliothek können die Systeme sukzessive wieder ans Netz gehängt werden. Für Appliances und andere intransparente Produkte empfehlen wir, auf die Veröffentlichung von Sicherheitspatches oder die Entwarnung durch den Hersteller oder die Community zu warten. Der gleiche Prozess sollte auch für alle Systeme durchgeführt werden, die zwar nicht öffentlich erreichbar sind, aber Eingabedaten aus öffentlich erreichbaren Endpunkten verarbeiten. Eine technische Beschreibung des IoC sowie eine Liste der IP-Adressen, von denen aus Angriffe bisher durchgeführt wurden, können wir gerne auf Nachfrage bereitstellen.
• Weiterhin sollten die Systeme engmaschig durch Fachpersonal und Technik überwacht werden. Nicht akut benötigte Systeme können zur Reduktion der Angriffsfläche auch vorerst abgeschaltet werden oder in isolierte Netzwerksegmente bewegt werden.
• Server sollten nur Verbindungen aufbauen dürfen, die zwingend für ihren Einsatzzweck notwendig sind. Diese Verbindungen, vor allem Verbindungen in nicht vertrauenswürdige Netze – insbesondere das Internet – sollten entsprechend durch Sicherheitsmechanismen wie z. B. Paketfilter abgesichert werden.
• Um zu ermitteln, ob die eigenen Systeme bereits angegriffen wurden, kann man die HTTP-Request-Logs durchsuchen. Bei bisher bekannten Angriffen begannen die User-Agent-Header der HTTP-Requests mit den Strings „${jndi:ldap“ oder „{jndi:rmi}“. Sollten Hinweise auf Angriffsversuche bestehen, sollten die betroffenen Systeme auf den Start ungewöhnlicher JVM-Prozesse untersucht werden.

Wie kann PwC helfen?

PwC kann Ihre Systeme auf potenzielle Anfälligkeit gegen diese Schwachstelle untersuchen und Sie bei der Schließung der Sicherheitslücke unterstützen. Ebenso können unsere Fachteams auch nach bereits stattgefundenen Angriffen oder Angriffsversuchen auf Ihrer IT-Infrastruktur suchen. Sollten dabei Hinweise auf Angriffe offenbar werden, wird PwC Sie bei der Sicherung von Beweisen, der Absicherung von Systemen und weiteren Maßnahmen unterstützen.