Log-Injection-Angriff

Bedrohungen im Blickpunkt: Log-Injection-Angriffe

Druckfreundlich, PDF & E-Mail

Injection-Angriffe stehen ständig auf der Liste der OWASP Top 10 Schwachstellen in Webanwendungen. Während SQL-Injection, Befehlsinjektion und Cross-Site-Scripting (XSS)-Angriffe üblich sind, kann Log-Injection weiterhin ein Risiko darstellen und oft übersehen werden.

Log injection can have a number of consequences, including remote code execution (RCE). This was the case with the recently disclosed CVE-2021-44228 a.k.a. “log4shell” attack against log4j versions prior to 2.16.0.

Bedrohung im Fokus

Log4j log injection RCE — If an application using a vulnerable version of log4j logs a specially crafted string, the vulnerable library can be induced to execute code provided by an attacker. Given the popularity of log4j for Java applications as well as the ability to execute arbitrary code, Apache gave this vulnerability the highest severity rating possible when it was disclosed. Many high-profile companies were affected by this vulnerability.

Die Details

Logging is a critical component of most applications and systems because it allows developers and system administrators to verify that software is working properly and identify more specific details when it is not. Log injection is not just a risk for the application and/or system itself, however, since it is quite common for logs to be processed by other software, which could also be vulnerable to log injection attempts. Anything that writes to or reads from the log files could be a target of log injection attacks. Even a person reading the logs can be the target for some log injection attacks. Possible log injection attacks include log forgery, denial of service, and malicious string injection — which has several possible attacks in itself.

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 Remote Code Execution, wie 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 von der Expression Language von log4j in einem Protokoll 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. Folglich kann der log4shell-Angriff schwerwiegende Auswirkungen auf sowohl Daten-, als auch Netzwerksicherheit haben, wenn er ausgenutzt wird.

Offering too much functionality that could potentially lead to severe vulnerabilities such as log4shell might also be a topic maintainers should look at. Given that the functionality enabling this RCE was removed in 2.16.0, it seems that the log4j maintainers might have already realized this point.

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

The best way to protect against log4shell specifically is to upgrade to the latest version of log4j. Maintaining up-to-date software and libraries helps ensure that vulnerabilities are patched in a timely manner. Since log4j may be included in an application outside of being a direct dependency, the build system can likely be used to obtain a dependency tree to check for vulnerable version(s) of log4j as indirect dependencies. Maven and Gradle both include command-line tools to print dependency trees for a project.

A firewall — whether network or web application — may potentially be able to offer some level of protection as an interim fix should upgrading require time to plan and execute. A network firewall can be configured to block outgoing LDAP traffic that would result from exploiting this vulnerability. A web application firewall may be able to protect against the attack in the first place if it offers protection against template injection. Barracuda Web Application Firewall and WAF-as-a-Service protect against template and log injection attempts, including those related to log4shell. These measures only protect against this specific threat, however, and not log injection in general.

Considering what systems the logs might be processed by and what possible vulnerabilities might exist within them would make for a good assessment of risks logging might introduce, as well as potential remediation for future logging-related threats by development and security teams. Since log injection can affect any system that reads from the logs, keeping track of the systems that are reading or processing the logs can help with understanding specific risks that might be associated with logging. For the security and development teams, this can help identify specific aspects of logging that might require additional consideration.

Bericht: Application Security 2021 - Ein Überblick

Nach oben scrollen
Twittern
Teilen
Teilen