Bedrohungen im Blickpunkt: Log-Injection-Angriffe

Injection-Angriffe stehen ständig auf der OWASP Top 10 Schwachstellen in Webanwendungen. Während Angriffe mit SQL-Injection, Befehl-Injection und Cross-Site-Scripting (XSS) übliche Arten von Injection-Angriffen sind, kann Log-Injection weiterhin ein Risiko darstellen und häufig übersehen werden.

Log-Injection kann eine Reihe von Konsequenzen haben, einschließlich Ausführen von Remote Code (RCE). Das war der Fall bei der kürzlich offengelegten CVE-2021-44228 alias „log4shell“-Angriff gegen Log4j-Versionen vor 2.16.0.

Bedrohung im Fokus

Log4j Log Injection RCE – Wenn eine Anwendung, die eine anfällige Version von log4j verwendet, eine speziell gestaltete Zeichenfolge protokolliert, kann die anfällige Bibliothek dazu veranlasst werden, von einem Angreifer bereitgestellten Code auszuführen. Aufgrund der Beliebtheit von log4j für Java-Anwendungen und der Fähigkeit, willkürlichen Code auszuführen, bewertete Apache diese Schwachstelle mit dem höchsten Schweregrad, als sie bekannt wurde. Viele namhafte Unternehmen waren von dieser Schwachstelle betroffen.

Die Details

Protokollierung ist eine wichtige Komponente der meisten Applikationen und Systeme, da Entwickler und Systemadministratoren mit ihr sicherstellen können, dass die Software ordnungsgemäß funktioniert. Zudem können sie genauere Details identifizieren, sollte die Applikation nicht funktionieren. Log-Injection ist allerdings nicht nur für die Applikation und/oder das System selbst ein Risiko, denn Protokolle werden häufig von anderer Software aufbereitet, welche auch für Log-Injection-Versuche anfällig sein könnte. Alles, was in die Protokolldateien schreibt oder von ihnen liest, kann Ziel von Log-Injection-Angriffen sein. Selbst Personen, die die Protokolle lesen, können Ziel mancher Log-Injection-Angriffe sein. Mögliche Log-Injection-Angriffe sind: Protokollfälschungen, Dienstverweigerung (Denial of Service), und bösartige String-Injection — was seinerseits mehrere Angriffsmöglichkeiten bietet.Protokollfälschung umfasst das Erstellen von Nutzdaten, welche eine echt aussehende aber gefälschte Protokollzeile hinzufügen. Dadurch kann sowohl Protokoll-Analyse-Systemen als auch Menschen, welche die Protokolle manuell lesen (oder durch Ereignissysteme die Protokolle einsehen), vorgetäuscht werden, dass ein Ereignis tatsächlich stattgefunden hat. Außerdem kann es zu Verzerrungen der Analysen kommen, wie häufig ein bestimmtes Ereignis stattfand. Bei Denial of Service-Angriffen überflutet ein Angreifer die Protokolldatei mit großen Datenmengen. Das kann zur Erschöpfung von Arbeitsspeicher oder Überfüllung von Festplattenspeicher führen. Im Fall von Protokollen, die nach Größe gewälzt werden und bei denen nur eine Teilmenge der Datei beibehalten wird, können Protokolleinträge vorzeitig von Protokollsystemen gelöscht werden. Beide Arten von Log-Injection-Angriffen brauchen weder eine spezielle Programmiersprache noch eine Template-Engine.Böswillige String-Injection kann viele Formen und Nutzdaten annehmen, einschließlich der Remote-Code-Ausführung im Fall der kürzlich bekanntgewordenen log4j-Schwachstelle. Diese bösartigen Strings können integrierte Funktionen des Loggers oder jeder Software, welche die Protokolle ausliest, ausnutzen. Im Fall von log4shell wird ein Aspekt der String-Substitution ausgenutzt, insbesondere eine Funktion, mit der Variablen mithilfe der Expression Language von log4j in der Log-Ausgabe gesucht und ersetzt werden können. Wird eine Template-Engine von einer Software verwendet, die Protokolle anzeigt oder aufarbeitet, kann eine Template-Injection unter Verwendung der Syntax der verwendeten Template-Engine ermöglicht werden. Wenn die Protokolle in einem Webbrowser angezeigt werden, kann zusätzlich zur Template-Injection auch Code in der vom Webdienst verwendeten Programmiersprache injiziert werden, beispielsweise die Injektion von PHP-Code in die Protokolle, die ausgeführt werden, wenn die Protokolle einem Benutzer angezeigt werden, bei dem es sich nicht einmal um einen Angreifer handeln muss. Ein Angriff kann auch JavaScript in das Protokoll schreiben, das angezeigt und ausgeführt wird, wenn ein Benutzer die Protokolleinträge über eine Web-Applikation eimsieht; hierbei handelt es sich um einen Stored Cross-Site-Scripting-Angriff.Während Injection-Angriffe verschiedene Folgen und Risiken haben können, wie etwa Datenlecks, ist Remote-Code-Ausführung (RCE) eine der schwerwiegenderen Folgen einer Schwachstelle. RCE ermöglicht Angreifern, einen Code innerhalb einer Applikation auszuführen, als ob er Teil der Applikation wäre, wodurch sie alle möglichen Zugriffsrechte und Privilegien erlangen, die der Applikation selbst zur Verfügung stehen. Das kann zu Zugriff auf Dateien führen, die der Applikation zur Verfügung stehen, auf Datenbanken, mit welchen die Applikation kommuniziert, oder sogar zu Zugriff auf das Host-System über eine Reverse Shell. Zugriff auf Dateien und Datenbanken kann zu Datenlecks führen, während eine Shell für einen Angreifer einen Ausgangspunkt erstellen kann, mit dem weiter in das Netzwerk eingedrungen werden kann, um Systeme und Ressourcen zu kompromittieren, die sich außerhalb der Applikation befinden. Daher kann der Log4shell-Angriff schwerwiegende Auswirkungen auf sowohl Daten- als auch Netzwerksicherheit haben, wenn er ausgenutzt wird.

Das Anbieten zu vieler Funktionen, die möglicherweise zu schwerwiegenden Schwachstellen führen können, wie Log4shell, ist auch ein Thema, mit dem sich Entwickler befassen sollten. Angesichts der Tatsache, dass die Funktion, die RCE ermöglichte, 2,16,0 entfernt wurde, scheint es, dass die log4j-Wartungsleiter dies bereits erkannt haben.

Wie Sie sich vor solchen Angriffen schützen können

Der beste Weg, sich speziell vor Log4Shell zu schützen, ist ein Upgrade auf die neueste Version von Log4j. Aktuelle Software und Bibliotheken zu warten, trägt dazu bei, dass Schwachstellen zeitnah gepatcht werden.

Da log4j in einer Anwendung enthalten sein kann, ohne eine direkte Abhängigkeit zu sein, kann das Build-System wahrscheinlich verwendet werden, um einen Abhängigkeitsbaum zu erhalten und nach anfälligen Log4j-Versionen als indirekte Abhängigkeiten zu suchen. Maven und Gradle beinhalten beide Befehlszeilen-Tools zum Drucken von Abhängigkeits-Baumdiagrammen für ein Projekt.

Eine Firewall – ob für das Netzwerk oder die Webanwendung – kann möglicherweise einen gewissen Grad an Schutz als Zwischenlösung bieten, wenn die Aktualisierung Zeit für die Planung und Ausführung benötigt. Eine Netzwerk-Firewall kann so konfiguriert werden, dass sie ausgehenden LDAP-Verkehr blockiert, der durch das Ausnutzen dieser Sicherheitslücke entstehen würde. Eine Web Application Firewall kann den Angriff möglicherweise von vornherein abwehren, wenn sie Schutz vor Template Injection bietet. Barracuda Web Application Firewall und WAF-as-a-Service schützen vor Vorlagen- und Protokoll-Injection-Versuchen, einschließlich denen im Zusammenhang mit log4shell. Diese Maßnahmen schützen jedoch nur vor dieser speziellen Bedrohung und nicht vor Log-Injection im Allgemeinen.

Wenn man bedenkt, welchen Systeme die Protokolle verarbeiten und welche möglichen Schwachstellen in ihnen vorhanden sind, kann man die Risiken, die Protokollierung mit sich bringen könnte, gut einschätzen und mögliche Abhilfemaßnahmen für zukünftige auf die Protokollierung bezogene Bedrohungen durch die Entwickler- und Security-Teams finden. Da Log-Injection jedes System, das die Protokolle ausliest, betreffen kann, ist es hilfreich, die Systeme, welche die Protokolle auslesen oder verarbeiten, im Auge zu behalten, damit die Risiken, die mit Protokollierung in Verbindung stehen, verstanden werden können. Für die Security- und Entwickler-Teams kann dies dazu beitragen, bestimmte Aspekte der Protokollierung zu identifizieren, die möglicherweise zusätzliche Überlegungen erfordern.

Bericht: Application Security 2021 - Ein Überblick