Menu
Recently a 0-day exploit got disclosed, that uses a security vulnerability in log4j which allows unauthorised remote code execution.
I'm wondering, what was the actual reason, why log4j has implemented this JNDI lookups, which have cause the vulnerability at all?
What would be an example for using this LDAP lookup feature in log4j?
594
What Is Log4j Vulnerability? The vulnerability lice in when the Log4j2 library is able to receive variable data from the LDAP and JNDI lookup and execute it without verification. This resulted in an open threat that could be used to send the malicious payload by crafting a malicious request.
When the malicious requests get logged, the Log4J library will parse the injected inputs and reach out to the rogue LDAP server to load the malicious class. The application then executes the referenced class, and the attacker gains remote code execution on the vulnerable application.
Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. Information on how to use Lookups in configuration files can be found in the Property Substitution section of the Configuration page.
If there is a JNDI reference in the log entry, Log4j uses the JNDI feature to request data from an LDAP (Lightweight Directory Access Protocol) server. For example, an expression ${jndi:ldap://example.com/file} specifies the lookup through LDAP protocol and loads data from the URL example.com.
If there is a JNDI reference in the log entry, Log4j uses the JNDI feature to request data from an LDAP (Lightweight Directory Access Protocol) server. For example, an expression $ {jndi:ldap://example.com/file} specifies the lookup through LDAP protocol and loads data from the URL example.com.
Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. Information on how to use Lookups in configuration files can be found in the Property Substitution section of the Configuration page.
Wireshark decodes the LDAP search response as Java! You can also see “javaClassName” in the bytes. But you may still be asking how we can detect this without a Zeek LDAP protocol analyzer? We will do it with Zeek’s signature framework .
Log4j JNDI vulnerability, dubbed Log4Shell by researchers, is a critical zero-day vulnerability that allows a cyber attacker to use the logging framework Log4j (version 2 to be precise) and the lookup feature JNDI within an application to generate special requests to an attacker-controlled server.
Log4j is a popular logging framework used in Java (you can figure the popularity by seeing the widespread impact of the vulnerability). Log4j offers a specific feature, where you can add tokens to your logging string, that get interpolated to fetch specific data. E.g. "%d{dd MMM yyyy}" will insert the date at which the message was logged.
In the mean time JNDI (Java Naming and Directory Interface) is commonly used for sharing configuration settings to multiple (mirco)services.
You can imagine a situation where somebody would like to log configuration settings in e.g. error situations.
See this article explaining a bit
A Java based application can use JNDI + LDAP together to find a Business object containing data that it might need. For example, the following URL ldap://localhost:3xx/o=BusinessObjectID to find and invoke theBusinessObject remotely from an LDAP server running on either a same machine (localhost) on port 3xx or remote machine hosted in a controlled environment and goes on to read attributes from it.
The update it refers to mentions it as "LOG4J2-313: Add JNDILookup plugin." The motivation is found in the Apache JIRA entry
Currently, Lookup plugins [1] don't support JNDI resources. It would be really convenient to support JNDI resource lookup in the configuration.
One use case with JNDI lookup plugin is as follows: I'd like to use RoutingAppender [2] to put all the logs from the same web application context in a log file (a log file per web application context). And, I want to use JNDI resources look up to determine the target route (similarly to JNDI context selector of logback [3]).
Determining the target route by JNDI lookup can be advantageous because we don't have to add any code to set properties for the thread context and JNDI lookup should always work even in a separate thread without copying thread context variables.
[1] http://logging.apache.org/log4j/2.x/manual/lookups.html [2] http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender [3] http://logback.qos.ch/manual/contextSelector.html
The big problem with log4j, is that by default all string interpolation of all modules is turned on. In the mean time it has become opt-out, but it wasn't always.
110
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
